2.3.7 G & R for Security Incident Processing (grip)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


Barbara Fraser <byfraser@cisco.com>
K.P. Kossakowski <klaus-peter@kossakowski.de>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

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


Request For Comments:







Expectations for Computer Security Incident Response

Current Meeting Report

Minutes for GRIP Working Group Meeting
Date: Tuesday, August 1, 2000
Time: 2:15pm - 3:15pm
Scribe: David Blumenstein (www.david.com)

The working group met for a single one-hour session this IETF. The first part of the meeting focused on the current status of the ISP document. During the IETF Last Call, at least one person expressed discomfort with the content. The IESG sought external comment and the ISPs contacted said the draft "needed cleaning up". There were issues that the draft was overly prescriptive, and some of the practices that were included were unrealistic business practices. Jeff Schiller, Area Director for Security Area, commented that there exists a tension between Internet security and business interests of ISPs to the point that the relationship between the user and the ISP would be one of a contractual basis. He gave an example of wanting his ISP to inform him when a security incident occurs that effects him.

The document editor, Tom Killalea, reported that he had revised the -03 version and thought the new draft addressed all the concerns that surfaced during the IETF last call. He reviewed the changes he has made:

The next portion of the meeting was spent reviewing the current evidence protection draft. There was some discussion concerning the collection procedures and the use of digital signatures.Signing makes the verification easier.

Sections 3.2 "Collection Steps" and 4.2 "Archive" are really weak and need to get bolstered. Attendees were encouraged to send content to the list.

Tom requested that attendees take the draft to their local law enforcement folks for review. We want to ensure the document is as internationally appropriate as possible.

There was some discussion about who the evidence was being protected for. That is, is the document focused on protecting evidence so that law enforcement can use it to track down the perpetrator, or is it focused on protecting evidence so that when a perpetrator is identified, the evidence will hold up in a court of law. It is the latter that this document is concerned with.

Someone asked that the use of the phrase "law enforcement" be elaborated for the context of this document. Others said the definition varies with jurisdiction. These points will be discussed on the mailing list and the revised draft will be uploaded by September 1, 2000

A new version of the user document will also be made available by September 1 by editor Manos Megagiannis. Attendees were urged to look for each of these two documents and send their review comments to the list.


None received.