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

39th IETF, Munich, Germany. - August 1997

Guidelines and Recommendations for Incident Processing (GRIP)

The GRIP working group met once during the Munich IETF. The following agenda was used.


Expectations for CSIR

It was suggested by the chairs, that the title and use of SIRT throughout of the text will be changed. Within the last year, Computer Security Incident Response Team (CSIRT) is becoming the standard. The group agreed.

One person (from a vendor organization) pointed out that there is no text expressing the expectations the vendor community has with regards to CSIRTs. Suggestion was that it doesn't fit into the document with the scope on the broad user community. It can be handled within the upcoming vendor document.

In section 1 (page 3, 3rd paragraph) the last sentence is misleads the reader into expecting that he will find lists of many examples within the document. We will remove the sentence.

The heading of section 2 is now "Scope" but this is not the objective of this section any longer as it gives an overview about three different areas. The group decided to ask for ideas on the list and tasked the editors to fix it.

When discussing 2.2 the notion of tracking numbers came up. Bill Woodcock agreed to send some text to the list that might fit under the Triage function where more technical details are handled.

In 3.3.2 more examples for defining the constituency should be given. Bill will send some text.

In 3.4.2 the text about vendors (page 13) needs some clarifications. Not only does the text suggest that only vendors with an IRT are "large", but the interaction between other IRTs and vendors is not clear. It also jumps to vulnerability handling instead of covering the actions necessary to assist in the response to an incident.

The section 3.4.3 isn't strong enough to address the need for secure communication and authenticity. The "should" in the first sentence will be changed to "must". Additionally it will be included that appropriate policies must be established too. (Erik suggested one sentence to address both problems and will fix it.)

In 3.5.1,its subsections, and Appendix D the word "cure" should be changed to "resolution".

It was pointed out that the living example in Appendix E wasn't adjusted to the new outline of Incident Response Services (Triage, Coordination, Resolution). This will be fixed.

In Appendix E the example included an erroneous statement for 3.3 Affiliation and Sponsorship, since FIRST membership is interesting but not what we meant. Text from 3.4 could be used, but there should be some reporting requirements also included.

Barbara will check on the appropriate use of the CERT Incident Reporting Form to see if it is okay - even for a commercial IRT - to point towards it. If not, it should be mentioned within the document.

Discussing the outline for the vendor document

Before discussion started, the question for volunteers to edit the document was raised by the chairs. Barbara will talk to anyone interested in being a document author.

First question was about the audience for this document and why it was bounded to the vendor community. Barbara explained the relation to the Site Security Handbook work and answered the question.

Some other folk pointed out that the OpenGroup document about Baseline protection (ABSS) should be read and referenced. URL is xxx

Another issues brought up was the scope of the product. As products might be developed for a specific environment, and the product might be used within a different environment, the security might be very different. Boundaries should be given and the documentation should explain, what ports are used or what files are accessed. The security level by default should be documented. This whole topic will fit into section G Documentation. Andreas Siegert will send some text about it.

Within the scope/purpose section, it must be defined what kind of products we are addressing (do we want to handle cables?). To help the reader, it would be easier to address classes of products which share the same characteristics.

Computer virus checking should be added to the section A. Discussion was about the "must" for the out of band verification mechanism for the signatures. There might be total different kind of mechanisms used for the protection of the customer, so different classes might come in handy here again.

As packaging can be carried out by other parties (on behalf of the producer) different responsibilities might arise. This should be addressed somehow. Even worse, their actions might impact the authenticity and security of the product and might change the provided checksums.

Going on to section B a question was asked as to how to address the security quality of default configurations. What about vendors distributing an unsecure setup after a bug was published on the net? Security Engineering is beyond this document and there is an effort under way to address such issues.

New input was added to advise vendors to give version numbers within the documentation about products used. As the vendor is not responsible for the content of additional third party programs he is providing, it is even more important to know which programs are not covered by the vendor. It would be even beneficial to the vendor, as the reporting of problems would be more specific. This should be covered within section C.

Whenever there are choices between security and insecurity, the security version should be used by default. However, it has to be a decision of the user. There was no resolution during the meeting, the group need some examples to list.

Customer must be made aware about the problem of default configurations. systems, This was supported since users tend not to read documentation and would therefore be provided with guidance up front as to how to change default settings to improve security. Ideally, this will encourage the vendor to avoid such weak default configurations in the first place.

There has also been a problem with knowing the exact release version for products. Sometimes the vendor will make security changes but not increment the release version. The group felt that vendors should be required to provide unique version numbers for any changes.

For section D, people would like to see a frozen configuration to avoid future problems later on.

In section E, a question was asked if we expect the security fixes to be free. It was clear, that it is a contractual agreement. Media cost should be reasonable and it is expected that only the owner of the product (not anyone) will receive the patches/fixes.

Section H actually deals mostly with security engineering and hence much of it may be removed or modified.

All in attendance felt the document should be written and volunteers were encouraged to contact Barbara directly (

Discussing of ISP document

Only two or three of the participants have read the outline sent around by Nevil Brownlee on the list. Barbara briefly explained the history of the document.

The outline will be made available on the GRIP WWW pages by the 15th of August as:

Tom Killalea will submit a first draft in October.

Schedule and Actions

31. August 1997:
New draft of IRT document
16. September 1997:
Last call to working group ends, thereafter submit to IESG thereafter
15. October 1997:
First draft of ISP document
25. November 1997:
First draft of Vendor document

Barbara will take an action item to update the mailing list with the new participants.

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