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

• GRIP Charter
• Milestones
• Vendor recommendations document
• Response team recommendations document
• Begin document outline, if time permits

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:

• Feb 1, 1995 - Draft describing problem statement and document taxonomy/vocabulary. Also cite the Site Security Handbook documents to make clear the relationship and scope between the two working groups and documents.

• Feb 15, 1995 - Draft outline for remainder of Response Team document.

• April 3, 1995 [April IETF] - Review of complete internet-draft of Response Team document at first WG meeting. Second WG meeting will develop the outline for the second document.

• June 1, 1995 - Reviewed, final version of Response Team document ready for Last Call.

• June 30, 1995 - Second document Internet-draft complete

• July 17, 1995 [July IETF] - Review second and comment second Internet-draft document.

• September 1, 1995 - Reviewed, final version of Vendor documend ready for Last Call.

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:

• Terms
  • Define these as roles:
    • Incidents
    • Response Teams
    • Sites
    • Users

  • Vendors - product/techology producers
    (Would be good to have a term less loaded than "vendor")

  • Shell Accounts

  • Security

  • Secure communications

  • Vulnerability

  • Network Service Provider
    (Internet, Shell Account)

  • Information service provider

• Functions
  • validate problem
  • technical assistance analysis to understand compromise
  • authenticate source?
  • notification of other involved entities
  • assistance
  • information provider
    • vulnerability archive
    • patches and resolutions
    • tools
  • education
  • audit and consulting
  • product evaluation

• Policies
  • disclosure - the response team should have a policy of disclosure how much to disclose, to whom and when. Does a response team contact another affected party, or the party's response team.
  • cooperation and interaction policies with other response teams
  • define kinds of incidents handled
  • define levels of support for various types of incidents
  • vulnerability handling
    • searching for them
    • handling reported ones

• Response team interactions
  • with other response teams
  • with those reporting incidents
  • with other involved users/sites
  • with law enforcement
  • with public/press
  • with vendors (that is technology producer or service providers)
  • with perpetrator or perpetrator's organization

• Procedures
  • Internal security
  • secure communications
  • authenticated information distribution
  • incident reporting
  • dealing with public relations

• Forming a response team
  • define constituency
  • define scope of authority / perimeter
  • identify other response teams
  • (how about an FYI to enumerate response teams)
  • operating procedures

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.)