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

33rd IETF, Stockholm, Schweden. - July 1995

Guidelines and Recommendations for Incident Processing (GRIP)

Due to many new participants which were unfamilar with the past activities of this working group a short overview of the activities of the working group was provided. The first meeting was spent reviewing the outline of the document on incident response teams and proposing material for the sections. The second meeting focused on the development of an outline for the document on vendor requirements.

Incident Response Team Document

Status of the document

After the discussion during the last IETF meeting there was supposed to be a draft for this meeting. Due to the time schedule of the editor he was unable to fullfill this role. A volunteer for the position of the editor was requested. Nevil Brownlee (n.brownlee@auckland.ac.nz) volunteered for this position later on during the meeting and he is now our new document editor for the response team document.

There was some discussion regarding the relationship of the template and the document itself. It was emphasized that the document serve two purposes: to provide guidance to organizations that want to form a response team so that they will be able to describe themselves in terms of the template. A second purpose to to help the reader (or client or potential client) of a team understand the content of a given team template.

One of the main primary purposes of the document is to help new teams. During the discussion a split of the IRT document into a document about forming an IRT and into another document about the team template was proposed. No decision was made by the group. There was discussion as to whether this document will provide to response teams, minimum community expectations. In earlier meetings, this was to be the case. At this meeting there was a difference of opinion. This is something that we will settle on the mailing list and in the worst cast at the next meeting.

One of the other purposes of this working group and its documents was named: to get other groups to use this template. This should be included in the introduction.

Short review of team template

During the review various issues came up. One of the discussions was devoted to the availability of the team templates:

A central repository is needed to provide easy access to the templates of (most) teams. It was thought that some of the existing archive areas could include such templates.

It was recommended that digital signatures be used to protect the provided template against modifications (This was also included in the team template).

Each team will be responsible for ensuring that its own template is available to its cooperating partners and its constituency.

Another discussion involved the meaning of several terms: "constituency", "sponsor" and "authorization". Due to many different situations for the teams it is important to allow a consistent description. Therefore, we will provide definitions of these terms within the context of the document. There should be included in the introductory section along with the others that have already been identified.

After reviewing the already discussed and outlined chapters, the discussion of the other chapters followed with the the goal to get more content and keywords which could help the editor of the document.

Discuss various topics of the document

During the last IETF the first chapters of the document ("Introduction" and "Defining a Charter") were discussed in more detail. During this meeting the remaining chapters were handled in detail.

Policies

The problem of incident reports and requests, and their handling was discussed in more detail. It was felt that each team has to choose its policy, but it should clearly stated in the team template. To avoid the "black hole" phenomenon a team might choose to provide a minimal feedback even to sites without their constituency.

Due to the impact on the team's constituency (incidents) reports from outside the constituency must be handled very carefully. We discussed that there are several ways that these reports may impact the response teams constituency:

reports from outside effecting inside inside hosts/sites
reports from outside that don't effect inside hosts/sites

Interestingly, there is also the possibility, that reports from inside the constituency only effect outside sites. A team must determine how they are going to handle these types of reports and make it known.

The item "reporting requirements" is confusing due to the relation to things like "quarterly reports". This item was reworded to "incident reporting requirements". Similar confusion arose from "points of contact". It was changed to "points of customer contacts". Standard bodies were added as possible cooperation partners.

A new important issue came up related to the team template itself. Changes of policy must be distributed to the constituency (and other relevant parties). Without that, it is clear that misunderstanding and misconceptions will arise, whenever policies are changed.

It was also felt by the group that vulnerabilities are sometimes not related to incidents and their handling needs to be addressed. As at the last, meeting the group decided to categorize vulnerability response as an optional service and this topic has to be analysed in more detail later. Vulnerability reports not related to actual incidents might be addressed to avoid possible incidents (this behavior is sometimes categorized under "proactive measures").

The next major topic addressed in the discussion was "disclosure". The group felt comfortable with the actual items and several other were added:

Vulnerabilities discovered in the process of handling an incident and the distribution of relevant information. There are several relationships have to be addressed here:
- to constituency
- to vendor
A team will normally collect statistics. If they are distributed, this should be stated in the policy section under this topic.
Because feedback to a reporter will disclose information this has to be handled, too. It is important to set the right expectations.
If conflicts of interests are identified for a single team which might interfere with the disclosure of information this must be handled here. The group felt it is unnecessary to address this issue within the template explicitely.
Legal requirements for disclosure might be different for the various teams. Due to the interference with user expectations these should be outlined.

One specific kind of request is related to contact information for other teams, organizations or parties. The distribution of this information might be important (e.g., contacts to the law enforcement) or it might be helpful to the reporter if a team will not deal with the request (because it is outside of the scope or the reporter is outside its constituency). Each team can decide to put other contact addresses into the appendix of its template. This topic will also fit under disclosure.

Services

During the first review a little confusion arose surrounding some of the items within this section. This was clarified later on:

"verification" was renamed to "verification of incident"
"optional" was renamed to "optional activities"

It was noted that all proactive services, if offered, are optional. It was suggested that the group be very careful in the wording of the section about optional services to avoid the misconception that such services are mandatory in order to be perceived as a "good" (or quality) IRT. Even legal conflicts can arise because of such misunderstanding.

Examples for other optional activities might include but are limited to:

firewall consulting
security tools packages
information about security software (e. g. tcp-wrapper)

One of the services during handling an incident is to help the victim to understand the problem and the extent of the impact and/or damage. This fits under "understanding of activity" as opposed to under an optional activity.

The group felt uncomfortable with the topic "coping". This was changed and divided into "eradication" and "recovery". Recovery may or may not include education.

The closing of an incident as an explicit service (i.e., letting all involved parties know, that the IRT considers an incident closed) is important and clearly an instance of the incident handling process. This also helps the IRT to avoid the black hole phenomenon.

Procedures

This section has no relevance for the team template. Policies stated in the template have to be implemented as procedures internally.

Some procedures were discussed in more detail.

Keeping statistics was already addressed under disclosure, but a team needs a procedure for doing this.
Keeping lessons learned seems trivial but is important to help the team when handling similar incidents more efficiently the next time.
It was decided that we shouldn't include too much guidance concerning securing a team's infrastructure since we can point them to The Site Security Handbook as a resource. There might exist IRT-specific security demands which are not usually considered for other sites and those might be important to handle in this section.
Another topic was the use of the network itself as an information resource for the teams. In using it they have to realize that they might be vulnerable to faked information which might lead to damage if it was used for part of the incident handling process by the team (e. g. wrong contact information for contacting involved sites).

After reviewing the first document and in lack of more input to the group the decision was to focus on the second document.

Vendor document

The discussion started with a kind of reality check. The original question was, what can be archieved through such a document. The users need something to point to. The community has to develop an understanding of can be expected from the vendor (technology producer) side. Leading the way to best current practise is a good description for the purpose of this document.

The discussion of experiences of the audience revealed the following thoughts:

Getting an understanding of what the larger community really needs is most important. The needs might be very different for users outside the more technical community of the IETF.
Users have to deal with a highly hierarchical system of vendor, seller and reseller.
The users will need a document in simple language, so that everybody can understand it and use it.
There is a special situation outside the US, where even the vendor, seller and reseller have no access to the technical information and the detailed knowledge. For example, it is a wrong assumption that every party has access to source code.

Scope of document

Get an understanding of what users can expect from a vendor when a product security problem is reported for:

software
hardware

Clearly this document therefore has to reflect the community's expectations of how vendors should respond to and handle reports of security problems in their products. The producers are the audience, but users will read it. This will lead to the use of the document to in some ways force the technology producer to a specific behavior.

A question was raised if the document will address the areas of secure:

packaging
distribution
installation
default configuration

Is the development of the software within the scope or not? The field of software engineering clearly does not fit into this document. But perhaps a document about "best current practise" for software developers is needed. This topic will probably not be included in this document and the decision to write yet another document will be decided after we have these two completed (or at least well under way). The distribution of software (especially in the public domain area) often leads to flaws and therefore advice in this area would be worthwhile.

The normal answer on a security hole is the suggestion to use an update/ revised version of the product. However, internal technology constraints may make this impossible to use or not advisable. Some vendors stop supporting patches for software products and the change to a new major version would force the victim organization to change the whole setup. Therefore the sites need updates (especially in complex system setups) not a new version. The question of how long a specific system is supported is important. Especially in case of large organizations the amount of work for "regular" updates is immense. Folks are interested in the length of time as measured in calendar time as opposed to versions. So, for example, some vendors state that they support the current versions and the two preceding ones. The problem is that the buyer doesn't know how long a period of time this might cover. From a strategic and financial planning point of view if would be very helpful to know, rather, how long in real time an organization can count on support for the product. What about products that are sold but are no longer supported or dropped from the list of supported products shortly after purchase. What are the implications for security patches in these cases?

The feeling was also that security problems have to be addressed, even without a service agreement. Security patches are expected to be free. However, this won't hold forever since vendors must be able to stop support on old products at some point in time. The point is that they need to clearly state what their support policy is so that a buyer can make informed decisions.

The distribution of security information has to be addressed, too. This is a sensitive subject but the group came up with a starting point for further discussions in this area. In general, enough information has to be shared so that it is possible to find out if a site is vulnerable.

This may be especially important if no patch is available and the knowledge about a security bug can be serious to a site. If informed, a site would perhaps decide to disconnect from the net.

It was brought up that there may be liability involved with the disclosure of such information and what is the responsibility for side effects of patches (like it is done on prescription medications).

The distribution of more detailed security related information to (major) customers was approached by at least one major vendor. Due to the transfer of the liability for misuse of this information to the customers no one was eager to sign the contract. One solution was proposed:

if no exploitation, company provide fix, but don't disclose before fix is available
if being exploited, disclose the information

It was quickly noted that we are not attorneys, and we can't possibly set policy. However the discussion was good because it pointed out the areas where vendors need to their policies.

Resellers are problematic, too. They might be responsible for security flaws the end user will contact the vendor of single components.

Network providers may claim to be technology provider (aka vendor), but they are not. Even if they are responsible for things like router configurations this has to be separated from the hardware and software component.

Purpose statement

Primary purposes

Reflect the community's expectations what consumers can expect from a vendor to address the security issues related to their products during the product's lifetime (excluding the software development process).

To include:

distribution
default configuration
optional components (e. g. debugging)
installation
normal use
response to security problems (to known by the vendor and reported by customers)
support for old versions, duration of support
documentation

Secondary purposes

Raise the awareness both on vendor and consumer sides that addressing security issues is worthwhile.

Outline of draft document

Suggestion for the title of the document:

"Internet Technology Producers Guide to good Security Practice"

Introduction

purpose
statement of intended audience
basic definitions
- vendor
- security bug
relationship to other documents
- site security handbook (SSH)
- vendor document (GRIP)

Distribution

Default configuration

Optional components

Installation

Normal use

Response to security problems

known by the vendor
reported by customers

Duration of support

Documentation

Discuss various topics of the document

Definitions

Vendor - entities that produce technology and are responsible for the technical content.
Security Bug - No definition was given during the 33rd IETF, if it is felt that there would be the need for such (maybe under a different term) we'll get a definition later.

Administrivia

Incident Response Teams Document

Sep 95: first draft
Nov 95: Internet draft
Dec 95: 34th IETF, review of draft
Jan 20, 1996: final draft
Mid of Feb 96: final call

Internet Technology Provider Document

Sep 95: draft outline

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