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

30th IETF, Toronto, Canada. - July 1994

Guidelines and Recommendations for Incident Processing (GRIP) BOF

Purpose

The GRIP BOF meet to discuss forming a working group which would produce guidelines and recommendations for use when dealing with security related incidents. The scope was to produce recommendations suitable for use by response teams (RTs), Internet users and vendors of hardware and software products.

The participants decided that the scope of the BOF would address only security related issues rather than, e.g., legal issues such as use of the Internet for the commission of crimes and how to interact with law enforcement agencies. This should be thought about, and perhaps another effort can be spun off in a year when the issues in that area are better understood.

We need to define what an ``incident'' is (e.g., break-ins, denial of service attacks, etc). If we consider the attributes of integrity, confidentiality and availability, loss or attack on any one of these might be considered a ``security incident.''

The BOF felt that a working group should address response to incidents and what response teams (RTs) should do, rather than an education or prevention effort. It was felt that the Site Security effort would address this, and there there was already plenty of response activities going on.

Response Teams

• How is a response team established (for example, an in-house response team)? How does one response team interact with others?

• What sort of information is needed for a response team to respond?

• How about mandatory auditing and other tools which users can be expected to have? Should there be recommendations made in the site security handbook?

• Should have response team recommendations vs. external procedures; that is, the team itself rather than how one response team interacts with another response team.

• Need a single framework for a response team; this could make it easier for one RT to communicate with another like group since the expectations and procedures could be similar.

• Include expectations on RT capabilities, e.g., secure communications.

• It might be useful to have a government entity maintain a registry of identified, certified or somehow blessed response teams. This could provide liability protection. ``Launder your liability.''

• Should a security organization hierarchy be defined or referenced? This would include a site security officer, organizational-wide security people. Should investigate existing organizations and structures, such as those in place for the DDN, for further ideas.

• A response team acts as a proxy for their constituency, and need to have some authority to do so. The mandate and authority need to come from high enough in the organization.

• ``Vendors'' would include entities such as Internet service providers, and other things which can have broken security.

• There are, perhaps, multiple classes of vendors and RTs.

• Advice to software authors: how to package software with signatures.

• Should describe methods for users and vendors interact on security issues.

• Should describe methods for response teams and vendors to interact on security issues.

• Response teams should have secure communications at their disposal for communicating with other response teams and their users.

• How should incidents which are submitted from outside be handled; that is, how does an incident get handed off to another response team.

• Need to define constituency of a response team - the users which they are to address and the technology (hardware, operating systems, etc.) which they can support.

• Define a plan of action and procedures for escalation of security incidents.

• RTs have to have sufficient resources available to be able to function effectively.

• RTs need to somehow establish credibility.

• Each response team needs to define its authority to operate on behalf of a constituency, and the responsibility that it has.

• User's are expected to know their RT contact.

• Should list some recommended tools for RT use.

• Need to document RT contact procedures and opportunities (i.e., 9-5 or complete 24x7 coverage) and what sort of responses are expected.

Vendor Response Guidelines

• Are ISPs ``vendors''?

• Define a scale of security incident severity which can be used to label a particular incident and which can be used to gauge an appropriate response.

• What about ``network harm'' issues, where a site has been compromised and is a source of further attacks. When do you pull the plug?

• Need a system to measure vendor response to security incidents at a particular severity level.

• Software packages (commercial, freely available) need to have strong signature verification. This can be use to detect versions of software which have been tampered with. One approach might be to approach FTP archive sites and other software distribution points and have them require or attach signatures.

• Software documentation should include security contact points and procedures in their documentation. Should this documentation, where appropriate, also include RT information and procedures?

• This should include hardware and software vendors, as well as ``free'' software authors.

• Need to develop a scale or table for relating RT timing for their actions vs. vendor response timing. That is, once a vendor has been notified, a sequence of events is might be set into motion which will occur even if a vendor doesn't respond in time.

Administrivia

The participants of the BOF agreed that there was sufficient interest in the issues discussed to establish a working group.

A mailing list, grip-wg@uunet.uu.net, will be set up. Requests to be added or removed should be sent to grip-wg-request@uunet.uu.net. Any requests which are sent to the whole mailing list, rather than the request mailbox, will be cheerfully ignored. The attendees of this meeting will be automatically added to the mailing list.

The first order of business is to produce a charter for the working group and a schedule of milestones. This will be discussed on the mailing list.

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