2.4.4 G & R for Security Incident Processing (grip)

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


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


Request For Comments:







Expectations for Computer Security Incident Response

Current Meeting Report

GRIP WG meeting - Minneapolis
Minutes recorded by: Tristan Debeaupuis
15th, March 1999

1. Agenda


Review Agenda


Review Expectations for ISP-ISP Security Coordination


Review Consumer Checklist for ISPs


Site Security Handbook Addendum for ISPs


Review Security Expectations for Product Vendors


Open Discussion; Document Authors


Next Steps

After discussion, the new agenda was:

Modified :


Review Agenda


Review Consumer Checklist for ISPs


Review Expectations for ISP-ISP Security Coordination


Review Security Expectations for Product Vendors


Open Discussion; Document Authors


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.