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


32nd IETF, Danvers, Mass. - April 1995

Guidelines and Recommendations for Incident Processing (GRIP)


The GRIP working group met twice during this IETF. A lot was accomplished and we hope to complete the work on the first document by the next IETF meeting.


Agenda for the two sessions

The change of the title was accepted. Team template, document outline and current material were covered in both meetings from different perspectives. At last the proposed milestone plan was revised.

To avoid any misunderstandings we refer to "security incident response team" or just "incident response team" (abbreviated as IRT) throughout all relevent documents. A definition for this term (see below) was proposed and accepted by the participants.


Team Template

It was decided that we would define a Team Template and use it to direct the development of the document. The working group agreed to proceed with the following template.

Name of the team

Date of last update

Charter

Policies

Services

Appendix

Contact Information

Information Services

Incident Reporting Forms

Disclaimers


Discussion of Team Template

During the last IETF a decision was made to provide a team information template within the document. Team descriptors which are of interest to constituencies and other parties interacting with a IRT should be covered there. A draft for this template was presented, discussed and improved. The template also served as the framework for the proposed outline of the document. To allow easier access for the working group the template is also available as a single document within the archive (see below).

The main interest during this discussion was the section about policies. The relationship between press and a IRT was identified as an additional area where at least the expactations for the constituency has to be set in the right way.

The goals and purpose of a team are especially important. In addition, there might exist different levels of support for different kinds of incidents, and this must be handled.

During the past meetings vulnerabilities were treated as separate topics (in addition to incidents). If a IRT handles isolated vulnerabilities, which are independent from incidents, it should be a decision made by the individual team itself. If so, it is considered an optional service not related to the core activities which were identified for IRTs. It was further decided that if a team does handle vulnerabilities, they should include a statement to that effect in the policy section.

Services can be split in two sections. The core activities (i.e., those included in the definition of a IRT) are the main interest for the scope of this document. All other services should be seen as optional services. To keep the document as clear as possible, the inclusion of information, not directly related to the mission of a team should be disregarded. The question was raised, if the service section can be used as a marketing tool. The bottom line is, that nobody can protect against this. But it is clearly not the intent of the working group to propse such a use. Services can be separated into incident response and proactive activities. Other services can be added as optional features. The document will provide discussions as to why a team might include or exclude particular services.

There was discussion concerning liability problems that might arise due to the information a team may provide. Although the document forms no contract, liability might arise due to the description of services and purposes. The inclusion of disclaimer at the end of the template was suggested. It should be up to the team as to how to handle this subject.

An expiration date for a team's template information was proposed. Discussing the tradeoff in having recent reviews or forged dates it was decided to incorporate a date of last update. This should be sufficient to allow the constituency to evaluate the currency of the document. The problem of storing and distributing the team information is still open. The question was raised to think about FYI or RFC mechanisms. Other approaches include the collecting of documents through a neutral organization like ISOC or FIRST.


Document Outline

After settling on a team template, the group then moved to a discussion of the document outline. The following outline was agreed upon by the group.

Introduction

Defining a Charter

Policies

Services

Procedures

Tips, Tricks and Pitfalls

(the name of the chapter should be changed later to something more suitable like "misc...")

Appendix


Discussion of Document Outline

For the document an RFC oriented text style should be used to allow a differentation for "must", "should" and "can". The rational for using a special mode must be given in the document, due to overall goal of this document in assisting persons not necessarily experts in the field of incident response.

An interesting topic was how teams would handle calls from a site within the constituency of a different team. We decided that this topic fits under disclosure and relationship in the policy section but it may also be necessary to include some statements in the procedures section. One aspect of this problem is, if the other team is told about the call thereafter. This should be covered as "reporting to other teams" and "handling incidents from sites outside a team's constituency".

Some policies outlined during the discussion:

Some chapters of the document are structured in the same way as the team template. "Procedures" is an additional section. It is not necesary to go into details about procedures within the template but it is important for the document.

The classification of data should be handled along with the internal procedures.

Which information about incidents is required must be handled in the procedures section. The template can focus on that in the services section and special forms for incident reporting can be included as appendices. The problem here is that commercial IRTs may choose a different perspective, therefore all this topics are "shoulds", but rationals for good practice must be provided.

Mimimum set of information for customer and/or incidents might be required. A rational should be included how to handle the problems related to that.

Under "Tips, Tricks and Pitfalls" all "mine fields" should be covered. The chapter will get a better name later. For example, the treatment of calls from people not within a specific constituency fits into this chapter.

John Wack (NIST) volunteered for writing some stuff about media under this section.

Some aspects of the document were further discussed and material for the various sections was collected. The outcome can be found in the relevant sections of the upcoming draft.


Purpose of the IRT document

The discussion revealed primary and secondary purposes, which should clearly separated.

The primary purposes are as follows:

Among the secondary purposes the following were mentioned:

Definitions

During the last meetings a lot of definitions were assumed necessary to be included in this document. But in relation to the purpose of the document only a limited list is really needed. This should help to keep the focus on the purpose of the document and prevent a duplication of other definitions or - even worser - a different definition. Some discussion was devoted to the term SECURITY which seems necessary for defining INCIDENT. A decision was made not to define security, but to include pointers to other definitions like the user glosary.

The audience agreed on the following list and definitions.

Constituency

Inherent to the purpose of a Security Incident Response Team is the existence of a constituency: the group of users, sites, networks or organizations served by the team.

Incident

For purpose of this document the term incident implies an incident related to computer and network security.

A computer security incident, is any event whereby some aspect of computer or network security is compromised.

The definition of an incident may vary for each organization depending on many factors. At least the following categories are generally applicable

Security Incident Response Team

Based on the two definitions given above, a Security Incident Response Team can be defined as:

A Security Incident Response Team should be capable of dealing with incidents that occur within its defined constituency. It should provide a means for reporting suspected incidents and offer technical assistance to help sites handle these incidents. Teams should also disseminate important incident-related information to relevant parties.

Site

A collection of equipment and personnel in a manner as to provide a point of contact for the handling of security incidents.

Vendor

Entities that produce technology in such a manner that they are responsible for the technical content.

Within the definition of an incident the statement "is compromised" is used. Sometimes an administrator may only "suspect" an incidents. During the handling of a call, it will be established whether or not an incident really occurred.

To avoid any problems with already existing definitions for site and vendor other references should be checked. The term "provider" was not defined, because there is not a real need given the purpose of the IRT document. In case there is an incident at a service provider it will be handled the same as it would be for any other type of site.

The definition of a vendor took quite a while and was not finished. The definition above should therefore be seen as a working statement, which has to be reviewed later. Nevertheless the audience felt that it is especially important to keep a close relation to the purpose of the document. There was discussion as to whether a supplier of a technology was the "vendor" of the technology. It was generally agreed that this wasn't the case. So, for example, if a network service provider provides Cisco routers to each of their customers, Cisco is determined to be the "vendor" and not the service provider (since, Cisco is the one responsible for the technical content of the product).


Defining a Charter

At the end of the second meeting this chapter was only shortly discussed. In regard to the constituency the following topics seems important:

Define the constituency to get a perimeter that defines to whom do you will provide the service. You may also get requests from other parties not within this border. How a IRT handles this should be covered in the policy section. Another problem is the fact, that people within the constituency have to learn, that there is a IRT for their purposes. The building of a trusted relationship to the constituency is an ongoing process which never ends.

The mission statement will have to focus on the core activities, already stated in the definition of an IRT. One point the group wants to emphasize is that in order to be considered a security incident response team, the team MUST provide incident response, by definition.

The sponsoring organization should be given next. In defining the affiliation it is simply stated "Who is your God?". Any kind of verification, that the IRT is really what it claims to be, is beyond the scope of this document.

Core activities are necessary to "be" a IRT. The "musts" are the real interesting ones.


Administrivia

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

Archives will be setup 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. Other documents of interest for the discussion of incident response teams and their tasks are available for AnonFtp. A collection might be found on: Some of the especially interesting documents are:

Milestones and next Meeting

The proposed milestones were revised. Up to now there are no changes necessary. In regard to the past month it seems the important to have at least two drafts until the next IETF. Proposed dates for that were the first of May and June. Peter Berger, editor of the document, will send out the next draft.

At the Stockholm IETF in July there should be two meetings, one for the review of the first document, one for the outline of the second one.


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