NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Barbara Fraser <byf@cert.org>
K.P. Kossakowski <kpk@cert.dfn.de>
Louis Mamakos <louie@uu.net>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Mike O'Dell <mo@uu.net>
General Discussion:grip-wg@uu.net
To Subscribe: grip-wg-request@uu.net
Archive:
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, 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 two quality documents:
· Guidelines for security incident response teams. · Guidelines for vendors (this will include both technology producers and network service providers).Goals and Milestones:
· Expectations for Security Incident Response
Minutes of the Guidelines and Recommendations for Incident Processing (GRIP) Working Group
Reported by: Klaus-Peter Kossakowski
The GRIP working group met once during the Memphis IETF.
Agenda
Review New Draft Review New Filled-in Template Update Schedule Future DirectionsI. Review of the New Draft (Version 4)
The first part of the working group session was spent reviewing the current draft document. At least half of the group in attendance had read, and was familiar with, the draft.
The point was made that under Services there are only two items: Incident Response and Proactive Services. It was suggested that this leaves the interpretation completely up to the team and each will end up using its own definitions. It was suggested that we need more granularity and examples to direct the teams to use a more useful level of detail. On Page 15 of the draft, there are already some examples given. It was further suggested that using different types of incidents would be a good way to provide better explanations.
It was mentioned that there are different types and levels of services. For example, there is "technical incident response on a site level," "high-level incident response coordination within an organization, and still "higher level incident coordination across multiple organizations." These are very different. Don Stikvoort (SURFnet) agreed to look into this topic during the next month and will send his comments to the list.
The group felt that it is necessary to highlight coordination as one important service (on different levels) and to include the aggregation of information towards a more complete picture as another service.
Ann Bennett (Concordia University) submitted a number of useful comments that were reviewed, and the editors will make the necessary changes. In addition to the general editing comments, she also noted some other problems in the draft while attempting to populate a template for her local team. (The template will be provided as an appendix to the draft).
"About this document" comes after Section 1, which does not allow a reader to easily check whether the document is the current version. It also makes it difficult for the reader to find other relevant information about the document itself. Ann suggested reversing the orders of Sections 1 and 2. A compromise would be to give the date and location of the document in the header and to go on with the actual order of the template.
By filling out the template, a problem showed up with Section 4.2 and 4.3. Section 4.2, "Interaction," deals with the same content as Section 4.3, "Disclosure," to some degree. Because they are so similar, Ann suggested that we combine the two sections. The group supported this suggestion. It was also noted that it is still important to list special relationships since constituents might consider this information important.
Another topic brought to the attention of the group was that use of the term "customer" in Section 3.4.5, is misleading. That led to a discussion about contact information by itself. Section 3.4.5 will be moved to 3.1 to collect contact information in one place. The subscription for a mailing list, for example, goes with additional services (together with information about other information services) in Section 3.5. All of the different services listed will need some more content to explain exactly what is meant by the service.
Acknowledgement will be given to Ann's contributions!
II. Review of the Filled-in Template
Ann Bennett provided a new filled-in template after the draft (Version 4) was finally sent out on the list.
Some issues that came up during her work were already discussed (see above). The discussion of other issues was skipped, as nobody had really reviewed the new filled-in template in detail. Further discussion will be carried out on the mailing list.
Don will provide suggestions and comments about his task within one month. Erik will get the majority of the smaller comments and corrections into the draft within a very short time and send an updated version to the list. The goal is to submit a new draft within one month to IETF-Drafts, including all issues brought up during this meeting. Comments will continue to be solicited from the list, and if possible, another draft will be produced prior to the August meeting.
The group then discussed two documents that had been proposed in past meetings:
· Addressing the vendors · Addressing the ISP community
The working group, in the past, has contributed a fair amount of material for a vendor document. There was a reasonable structure developed during the 37th IETF in Los Angeles, California, and Barbara will take an action item to distribute a short draft as input to the list for further discussion.
The group also felt that there would be a reasonable benefit to working on the ISP document. There was discussion as to the scope of this document and it wasn't clear how many operational issues would be included along with the incident handling/response material. There is no clear boundary between operations and incident-related topics and we will try to develop this document like the IRT document, where we describe what is expected but not dictate the details of how it is to be provided.
The example of IP spoofing filters in routers was given to illustrate the difficulties involved in balancing between incident response and operations. Such filters will clearly stop many attacks and avoid intrusions, but they may interfere with the operation and policies of the service provider. The provision of such filters will also impact the relationship between customer and provider. The problems with telling IRTs how to do their work, apply to this document as well. It was agreed that it will be difficult to write this document in such a way that it is both helpful to the community and acceptable to the service providers.
Nevil will put some initial ideas together for the ISP and distribute this to the list by end of June. Don is also interested in contributing to this document.
Vendors and ISPs are part of the overall community that is involved with dealing with incidents. Both documents should be based on the first document and should be very short. They should provide notice to the vendors and ISPs communities that people have expectations from them with regard to overall incident response in the Internet.
The mailing list is:
grip-wg@uu.net Subscription: grip-wg-request@uu.net Access to the GRIP charter and minutes is possible via World Wide Web. http://www.cert.dfn.de/eng/resource/ietf/grip/