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
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.
suggestion: "Framework for Security Incident Response Teams"
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.
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.
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.
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.
(the name of the chapter should be changed later to something more suitable like "misc...")
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:
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.
The discussion revealed primary and secondary purposes, which should clearly separated.
The primary purposes are as follows:
It should be clearly stated that the marketing use (or abuse) is not intended by the working group.
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.
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.
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
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.
A collection of equipment and personnel in a manner as to provide a point of contact for the handling of security incidents.
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).
At the end of the second meeting this chapter was only shortly discussed. In regard to the constituency the following topics seems important:
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.
The mailing list will be updated to include the new persons who attended these meetings.
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.)