Meetings:
30th IETF, 31st IETF, 32nd IETF, 33rd IETF, 34th IETF, 35th IETF, 36th IETF, 38th IETF, 39th IETF,
40th IETF, 41st IETF, 43rd IETF, 44th IETF, 45th IETF and 46th IETF


31st IETF, San Jose, Calif. - December 1994

Guidelines and Recommendations for Incident Processing (GRIP)


The GRIP (Guidelines and Recommendations for Incident Processing) BOF met for two sessions on December 6, 1994. The agenda for the meetings was:


Agenda for the two sessions

A charter for the GRIP working group was proposed, and discussed and modified. A revised charter was produced and agreed upon. The problem statement for the group was:

The purpose of the Security Incident Response working group is to provide guidelines and recommendations to facilitate the consistant handling of security incidents in the Internet commnity. Guidelines will address technology vendors, network service providers, response teams in their roles assisting roles assisting organizations in resolving security incidents. These relationships are functional and can exist within and across ogranizational boundaries.

The working group will produce two standards-track quality documents:

  1. Guidelines for security incident response teams.
  2. Guidelines for vendors (this will include both technology producers and network service providers).

Milestones

A set of milestones was agreed upon to measure the progress of the working group. Since the output of the working group will be two documents, most of the milestones refer to measuring the progress of the two documents to be produced. The milestones are:


Outline of Documents

The group decided to begin with the response team document, since it will likely describe all of the terms which will likely be used in the other document as well. Both documents will have a very similar introduction or prologue to explain where the document fits within a related set of documents including the two produced by the GRIP working group as well as the Site Security Handbook produced by another IETF working group.

The group discussed how the documents would be treated once released, and what the flavor of the documents would be. There was a discussion and observation that documents produced, even if not a standard, will likely be cited in a legal context. The document will be something to measure and describe how a response team, for instance, operates rather than offering advice on the "correct" way to operate a response team. The documents would act as an aid to describe the specific policies and functions of entities acting as response teams and in othe roles.

There was disucssion about the paritioning of the "problem" between the GRIP group work, and what happens in the SSH working group. That is, site requirements and recommendations should be cited in the SSH group, while response team expectations and procedures be in the GRIP documents.

There was an observation that there is a recursive property when describing the roles that particular entities take. For example, a "Site" is a recursive sort of entity, where it may hae a response team component "inside", but potentially looks like "victim" from the outside.

There was agreement that we don't need to address *causes* of outages; only address when happens when it is diagnosed as a security incident. That is, there will not be specific recommendations on preventing incidents (which will be in the scope of the Site Security Handbook work), but to focus on incident handling related issues.

Peter Berger graciously volunteered to be the editor of the first document.

At the second meeting of the GRIP BOF later in the day, there was a brief recap of the work which occured in the first session. The bulk of the time was spent working on an outline of the first document. It was felt that there should be a set of terms which should be defined in the document (which could then be re-used in the second document). It was pretty clear that many of the terms which are used in talking about these issues are somewhat ambiguous.

The following list of terms was proposed. Specific definitions can be filled in later:

The members of the group then began to flesh out an outline of the topics to be covered in the "response team" document. There were a few major areas, with topics which fit under each: There was considerable discussion during the building of this list, and some issues came to light regarding the scope of the response team activities, the degress of assistance they could provide, etc.

As a part of handling an incident, you're removing the immediate cause incident from a system (or decide not to).

Part of responding is being able to deal with other response teams.

Response teams may have limitations due to span of control. Response teams must establish their scope of control before incidents occur.

We should have a standard template or form which describes the way that repsonse teams operate to facilite communications between response teams. Information in the template would be the points described in the document.

This concluded the work done by the group at the second BOF meeting. The editor offered that a first draft of the introduction to the first document could be available before the end of the year.

Further work on the remainder of the document will occur on the mailing list, with an internet draft to be produced before the next IETF meeting where it will be commented on and modified.


Please send questions, comments, and/or suggestions regarding the GRIP working group to the open mailing list grip-wg@uu.net.

All issues regarding these web pages should be directed to klaus-peter@kossakowski.de.

These pages are hosted on http://www.kossakowski.de and are provided on an "AS IS" basis without any explicite or implicite responsibility, liability, etc. (For a more fully understanding please refer to the legal statements within the Impressum, which is only available in German.)