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

34th IETF, Dallas, Texas. - December 1995

Guidelines and Recommendations for Incident Processing (GRIP)

Agenda for the session

The GRIP working group met once during this IETF. The agenda for the meeting was the following:

Audience of the document

The group spent the first 15 minutes or so discussing the audience for the document. The goal is to provide a document that accomplishes several things:

So, the audience is primarily response teams even though members of the Internet community will also find it useful. The descriptions in the document should help set a constituent's/customer's expectations of the team. This document discusses all the many aspects of incident response that need to be defined. Therefore, a constituent/customer should be able to read a team's template and discover what to expect, for example, in such areas as privacy and confidentiality of information, and if the response team will be contacting downstream sites.

In terms of expectations, the discussion was in terms of "what should I expect of my own IRT?" and how does this differ from what I expect from other organizations and groups. The basic philosophy will have to be "If you tell us things (in the filled out template), we will expect you to follow through with what was stated.

Another point that was brought up about follow-through was that users should be encouraged by their IRT to report incidents so that appropriate actions can be taken. Without active participation (ie. reporting) from users, IRTs can't do much good. Thus, the users need to know how and when to report. There was considerable discussion about the definition of an incident. Another way of stating this is what should users be trained to do?

Review the current Internet Draft

In a review of Section 4.4 it was asked if we should continue to keep the document OS neutral. Folks agreed but decided that it would be helpful to provide examples when needed for clarification. For example "root compromise" and "writable FTP area" when distinguishing between types of violations. These examples are rathery UNIX specific. There was no clear resolution on this, but we agreed to keep the OS neutrality in mind whenever possible.

The difference between inappropriate disclosure and unauthorized use got discussed: The two categories entail different loss of confidentiality. Inappropriate disclosure would be to grab stuff and make it more visible than originally intended. Text is needed to bring out the differences. The disclosure issue is further complicated by the fact that disclosure could be intentional or unintentional.

There was some discussion as to whether the document should discuss what is out of the scope of an IRT? It was decided that it is easier to say things are definitely in the scope/charter of an IRT.

It is important to define what the IRT considers worth their involvement, or at least to put bounds on what they consider to be an incident. A VULNERABILITY is important to know about and an IRT may provide analysis of the vulnerability. On the other hand it may only do this if the vulnerability was discovered during a security breach, etc. It was reaffirmed that vulnerability analysis isn't required of IRTs but the analysis of vulnerabilities which do not occur within the framework of an incident may or may not be a service provided by IRTs.

Examples include pc viruses and malicious programs. These are not really an incident on 1 or 2 machines. But if they are brought in deliberately they can become full scale incidents. If merely an accident, generally no. But, the decision is ultimately with the IRT.

Some IRTs handle all virus cases, etc. This seemed to be the case in private IRT set ups (within one corporation.) Others, like the CERT Coordination Center have traditionally not handled viruses.

There was discussion about nailing down the expectations questions:

Corporate network and physical security should be coordinated. An IRT may be called when a computer is physically taken/broken into, the watchmen may be called due to a computer security intrusion.
While we aren't providing an end-user's document we do need to grapple with the work that an IRT does as well as it's interface to the outside. One person suggested we could look at it as different management: managing inward and outward. Lots of the discussion focused on the differences between commercial incident response and incident response defined by a particular entity. There were member of the working group from both categories and the discussion was interesting. For example, if the policy is clear (as in a corporate case) it should not be necessary to think. You should CONTACT SO AND SO as your whole range of choices. This is harder when it comes to commercial enterprises like Internet service providers, value-added service providers, and commercial IRTs.

It seems the outward side comes down to:

"As a user you should read this and that policy document. This will make clear what we will provide you with and what you need to deal with on your own."

The document must be clear(er) about what effects the user community vs. what is addressed directly to the user community
Upshot to consituents is:

Read your filled in IRT template and "Do that first"!

IRTs can set up a policy which says:

If you have ignored my advice, my future commitment may be limited.

It was also restated that many IRTs have no prosecuting authority to get people to follow advice when they give it.

Defining what constituencies are is out of the scope of the RFC, it will be done by the IRT or corporate policy in a very individual way.
Then there was discussion about what we should include concerning the question: How do you find your IRT?

IRTs have a responsibility to advertise themselves to users/IRTs Dissemination of info about IRTs: First my constituents then outward. Since there is a trust issue (is this really an IRT?) it makes sense to send information out in a 'tree' like manner, using trust along the way of the direct source of info. It was mentioned that the trust model for IRTs is the same as that for PGP, a web of trust. The most challeging piece is to find the first entity that you truly trust.
The info about IRTs and IR techniques needs to be in the hands of tech support, as they will be faced with incidents on the front lines.

Most important is that IRTs publish to their constituencies. This is really according to a "push model," as they will not be in a position to really ask until it is too late.

There was discussion about a central repository, but the bottom line is that the IRT in question needs to make it's information available. First, it should publish its template on its own information server. Everyone also acknowledged that the FIRST repository is a good thing, but that there may be teams that aren't members of FIRST so we can't count on that 100%. We might point folks to the FIRST archives, their Internet service provider, and other known response centers. One of the primary jobs an IRT must succeed in is making upstream sites aware of how to contact them.

International audience: The IRTs and users of the template should/must work sensitively to local laws and regulations.

It is probably important to clarify any local regulations which will effect the primary operation of the IRT to those who may have very different expectations in different countries, etc.

It is very possible that a team will want to have internal and external versions of their policy. One may be for corporate use only on the one hand, and the other for general consumption/cooperation guidelines on the other.

Getting back to knowing who the response teams are brought out some further discussion. We decided that we would provide a list of the current IRTs in the document as a starting point, along with a pointer to FIRST (Forum of Incident Response & Security Teams -

In general the idea of a central repository presents some challenges. The repository may be very difficult to keep current and to keep filled with accurate information. (Bad guys can create 'IRT' facades, etc.)

Who will 'vet' the response teams/classify them officially? Note this is a very sticky area that will have liability issues associated with it, as business will claim to be able to do this. Who will have the right or claim to have the right to deny them? There was even discussion as to whether someone could go to an investigative agency in their country to see if a particular team was legitimate. May be valuable to enlist the aid of a national (law enforcement) agency to maintain a list of contacts and act as a clearing house. Right now, the list of members in FIRST is a good start, but some mentioned that there will inevitably be IRTs that are really just an individual who has contracted with some organizations to provide incident response services. So, we need to be sensitive to future needs.

There was some discussion concerning categories of vulnerabilities, and one member of the group suggested there are 3 general kinds:

The first may or may not be an incident. It will be if it was exploited. Otherwise it falls into the category of a vulnerability. If it is wide- spread in consequences it should be dealt with.

If it is a 1:1 or 1:many incident you deal with them and or their IRT, as well as local law enforcement since there may be a concern for liabilities if you don't and the downstream sites find out later.

If it is an internal compromise, it should be dealt with internal security mechanisms in place.

Commercial response teams will broaden the field of who should be tracked.

The quality of sources may not be all good or bad, there is a gray area.

Teams have the template to:

use a 'keytag' to classify the document so that yahoo/infoseek/etc info directory scans will make them available to the network community. The search engines out there will help the incident sufferer. Alternatively the list at FIRST should be on the web...

There was some discussion as to whether to change the title to "Expectations for Internet Security Incident Response" . We'll decide on the list.

The following were some specific edits:

add "dealing with internet but concepts apply to closed nets."
add "formulate expectations"

Section 1.1:
rename Template Repository to Central Repository

pg 4:
"distribution of template updates" tell you where to get new templates

Section 3, pg 5:
primary purpose: set expectations of constituents & customers

"A second document...vendors to help them with security incidents"

Actually it is much broader than that: should we really have this pointer here?

Section 4.2, pg 6:
"Partner Team" what is this? Omit it.

Section 4.3:
Goes away

Section 4.4:
Incident should be Incident Response


At this point in time, the time alotted to the working group session was about over and we didn't have time to do any real work on the second document. The following are some comments on the outline.

Next Steps

  1. Nevil will create a new draft by mid-January for everyone to review before the March meeting. We hope to have a stable document by then so that only small editorial changes will be needed before we can advance it.

  2. We'll discuss the vendor document on the list. We are working on selecting the document editor(s) for that document.

  3. We are planning two sessions in Los Angeles, 1 to complete the IRT document, and a second one to work on the vendor document.


The mailing list will be updated to include the new persons who attended these meetings.

Archives are available in the US and Europe. The document outline, the template and the definitons will be provided as separate information. The drafts will be available also. Access to the GRIP charter and minutes is possible via World Wide Web, too.

Please send questions, comments, and/or suggestions regarding the GRIP working group to the open mailing list

All issues regarding these web pages should be directed to

These pages are hosted on 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.)