NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 10-Mar-99
Chair(s):
Barbara Fraser <byf@cert.org>
K.P. Kossakowski <kpk@cert.dfn.de>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Mailing Lists:
General Discussion:grip-wg@uu.net
To Subscribe: grip-wg-request@uu.net
Archive: http://www-ext.eng.uu.net/grip-wg/grip-wg.txt
Description of Working Group:
The full name of this working group is Guidelines and Recommendations for Security Incident Processing.
This working group is co-chartered by the Security Area.
The purpose of the GRIP Working Group is to provide guidelines and recommendations to facilitate the consistent handling of security incidents in the Internet community. Guidelines will address technology vendors, network service providers and response teams in their roles assisting organizations in resolving security incidents. These relationships are functional and can exist within and across organizational boundaries.
The working group will produce a set of documents:
1) Guidelines for security incident response teams (IRT).
2) Guidelines for internet service providers (ISP) consisting of three documents covering the following topics:
* Expectations on how ISPs will coordinate with each other and IRTs in incident handling
* Consumer Checklist on ISPs
* Site Security Handbook (SSH) Addendum for ISPs
3) Guidelines for vendors (technology producers).
Goals and Milestones:
Mar 99 |
|
Submit Expectations for ISPs as an Internet-Draft |
Mar 99 |
|
Submit Consumer Checklist on ISPs as an Internet-Draft |
Mar 99 |
|
Submit Internet-Draft on security guidelines for technology providers |
Mar 99 |
|
Submit Roadmap document as an Internet-Draft |
May 99 |
|
Submit Revisions to three major I-Ds |
Jun 99 |
|
Submit ISP documents to IESG for consideration as a BCP RFC |
Jul 99 |
|
Submit revision to guidelines for technology providers as an I-D |
Jul 99 |
|
Meet at IETF in Oslo |
Sep 99 |
|
Submit final verion of guidelines for technology providers Internet-Draft |
Oct 99 |
|
Submit guidelines for technology providers to IESG for consideration as a BCP RFC |
Internet-Drafts:
· Security Expectations for Internet Service Providers
· Security Expectations for Internet Service Provider Consumers
Request For Comments:
RFC |
Status |
Title |
RFC2350 |
Expectations for Computer Security Incident Response | |
GRIP WG meeting - Minneapolis
Minutes recorded by: Tristan Debeaupuis
15th, March 1999
1. Agenda
15:30-15:40 |
Review Agenda |
15:40-16:00 |
Review Expectations for ISP-ISP Security Coordination |
16:00-16:20 |
Review Consumer Checklist for ISPs |
16:20-16:40 |
Site Security Handbook Addendum for ISPs |
16:40-17:00 |
Review Security Expectations for Product Vendors |
17:00-17:15 |
Open Discussion; Document Authors |
17:15-17:30 |
Next Steps |
After discussion, the new agenda was:
Modified :
15:30-15:40 |
Review Agenda |
16:00-16:20 |
Review Consumer Checklist for ISPs |
15:40-16:00 |
Review Expectations for ISP-ISP Security Coordination |
16:40-17:00 |
Review Security Expectations for Product Vendors |
17:00-17:15 |
Open Discussion; Document Authors |
17:15-17:30 |
Next Steps |
2. Review Consumer Checklist for ISPs
There was discussion about the format we should use for this document. There was concern that the existing paragraph style wasn't what the working group had in mind.
Tony Hansen (ATT) presented several alternatives for making the document more similar to a checklist. After discussion, there was there a consensus that we will begin each section with a list of questions that the consumer would ask of their ISP candidate. The following section would expand on the importance and rationale for asking the questions. In addition to the main document text, we will also list the complete list of questions as an appendix. IESG. Concern was raise by the AD that we keep the appendix consistent with the rest of the document. Therefore, we won't create the appendix until after we have completed the document, just before submission to the IESG.
The rest of discussion on this document focused on the content of the sections. The following is a summary of those discussions.
Comments on the document :
About the title : The title "Security Expectations for Internet Service Provider Consumers" has to be modified for "Security Checklist for Internet Service Provider Consumers".
The abstract will also be modified to reflect this change.
Section 2.1 :
The suggestion was made to use "incident handling" instead of just incident reporting or response.
Section 2.2 :
"Assistance with inbound security incident" included suggestion that the ISP inform users of incidents that were targeted at other customers. This was decided to be inappropriate. This section will be rewritten to cover questions designed to solicit information about how the ISP will respond to attacks on the consumer. For example: What help will you get from ISP ? What are you going to be told if the ISP notices that someone is attacking you ?
Section 2.3 :
This section will be revised to cover a set of questions "What sort of security information the ISP will make available to you ?"
Section 2.4 :
Comments made on the list will be incorporated into this section by the document editor.
Section 2.5 :
To make it easier to understand, we will provide some examples of what we mean by "secure channels" e.g., Secure Web, Secure Email, telephone, fax, ...
Section 3 :
This section will simply ask if the ISP has a security policy and what is in it.
Section 3.2 :
The first sentence will be rewritten.
Section 3.4 :
Content will include questions covering whether the policy is public and where it is published.
Section 4 :
It was decided that this section doesn't belong in this document and it will be removed.
Section 5 and 6 :
Discussion will occur on the mailing list.
3. Review Security Expectations for ISPs
Section 2.1 :
Comments from the mailing list will be integrated
Section 2.3 :
This section has to be synchronised with the previous document (Security Checklist for Internet Service Provider Consumers), especially the last sentence.
Sections 2.4 and 2.5 should be removed from this document. The subject of how the ISP deals with security incident that involve them will be added.
Section 2.3 :
Include recommendation to notify appropriate people when a new vulnerability is discovered.
Section 2.5 : Contacts
Section 3 :
The language needs to be edited so that it no longer reads as if there is a contracts AUP that guides everything.
Section 4 :
A reference to the site security handbook RFC will be added.
Section 4.1, 4.2 :
Some duplications will be removed.
Section 4.1 :
Modify to read "ISP should 'SWIP' or equivalent."
Section 4.2 :
A transition sentence is needed to explain that the advice given is not going to prevent bogus announcement.
Section 4.3 and 4.4 are already in RFC 2265, so the major portions of text will be removed and a reference to 2265 will be highlighted.
Section 4.6 :
There is a proposal to change default way to accept directed broadcast to the opposite. Must add the reference to "Changing the Default for Directed Broadcasts in Routers", D. Senie, 02/22/1999, draft-senie-directed-broadcast-02.txt.
Section 5 :
This section will be removed from this document and included in the SSH addendum document.
4. Site Security Handbook Addendum for ISPs
We didn't have a draft prepared in time for this IETF. Tristan volunteered to be the document editor.
5. Security Expectations for Technology Vendors
We ran out of time. The draft will be submitted to I-Ds and discussed on the list.
6. Next Steps
New drafts for each document will be ready by April 15, 1999. The goal of the working group is to complete all documents by the Oslo IETF meeting.
None received.