CURRENT_MEETING_REPORT_ Reported by Barbara Fraser/CERT Coordination Center Minutes of the Guidelines and Recommendations for Security Incident Processing Working Group (GRIP) The GRIP Working Group met twice during the 32nd IETF. A lot was accomplished and the group hopes to complete the work on the first document by the next IETF meeting. The agenda for the two sessions was: o Title change o Team template o Outline of document o Discuss current material o Update milestones and administrativia A new title for the document being written, ``Framework for Security Incident Response Teams,'' was suggested and 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 will refer to ``security incident response team'' or just ``incident response team'' (abbreviated as IRT) throughout all relevant documents. A definition for this term (see below) was proposed and accepted by the participants. Team Template It was decided that the group 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. o Name of the team o Date of last update o Charter - mission statement - constituency - sponsor/affiliation - authority o Policies - types of incidents - level of support - disclosure * of compromised site's information * the compromise of IRT site to constituency - cooperation/interaction with * incident response teams * vendors * investigative agencies * involved sites * press - communication/authentication - point of contacts - reporting requirements o Services - incident response * verification * understanding * coping * notification - proactive activities o Appendix o Contact Information - name - address - telephone - telefax - other telecommunication like STU-III - electronic mail - encryption methods for communication: PGP, PEM, MOSS, etc. - actual list of members on demand (optional) o Information Services - URL for team information (this document) - mailing lists - information servers o Incident Reporting Forms o 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 an 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 an IRT was identified as an additional area where at least the expectations 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 an 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 an 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 propose 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 a 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. o Introduction - purpose * statement of intended audience * pointers to background material - basic definitions * constituency * incident * security incident response team (IRT) * site * provider * vendor - relationship to other documents * site security handbook (SSH) * vendor document (GRIP) o Defining a Charter - constituency - core activities and mission statement - (functions necessary to be considered as IRT) - sponsoring organization/affiliation - authority * scope * perimeter o Policies - types of incidents and level of support - disclosure * reporting incidents to other teams * handling of incidents from sites outside the team's constituency - interaction with other organizations * incident response teams * vendors * investigative agencies * involved sites * press - communication/authentication - points of contact - reporting requirements o Services - direct incident response * verification * understanding of activity * coping * notification - optional - (describe other activities) o Procedures - external * support for incident response (e.g., registration service) * secure communication * information that a side must/should provide - internal * secure infrastructure * protecting information servers * protecting sensitive data * expiring sensitive data * disposal of sensitive data o Tips, Tricks and Pitfalls (the name of the chapter should be changed later to something more suitable like ``Miscellaneous...'') - handling the media - social engineering - cellular phones o Appendix - Team Template Discussion of Document Outline For the document, an RFC oriented text style should be used to allow a differentiation for ``must,'' ``should'' and ``can.'' The rational for using a special mode must be given in the document, due to the 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. The group 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: o It is a ``should'' to announce the compromise of an IRT (at least) to the constituency. o The authority about the IRT should also be covered here. Some chapters of the document are structured in the same way as the team template. ``Procedures'' is an additional section. It is not necessary 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 these topics are ``shoulds,'' but rationals for good practice must be provided. A minimum set of information for customer and/or incidents might be required. A rational should be included on 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 to write 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 be clearly separated. The primary purposes are as follows: o It is clearly a framework for IRTs to help them describe themselves and their services and functions. o It should improve the way IRTs operate and interface with their constituency in setting expectations and defining policies. o It should improve interactions between different IRTs and between IRTs and other organizations (e.g., vendors, investigative agencies). o Help new teams to understand what it takes to became or start a new team. Among the secondary purposes the following were mentioned: o As the document will provide a framework, which topics are covered, it will be usable for comparing different teams. It can be used as a marketing tool in comparing the services. It can also be used for setting customer's requirements. o It should be clearly stated that marketing use (or abuse) is not intended by the working group. o Users may find the document educational in helping them understand the purposes and activities of an IRT. They may also learn about the different policies and services which are possible. 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 worse -- 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 glossary. The audience agreed on the following list and definitions. o 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. o Incident For the 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: Loss of confidentiality Compromise of integrity Denial of service Misuse Damage o 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. o Site A collection of equipment and personnel in a manner as to provide a point of contact for the handling of security incidents. o 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 incident. 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 was not 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 briefly discussed. In regard to the constituency the following topics seem important: o Constituency means who you will provide service to. o This can be a company's employees or paid subscribers. o It may be defined in terms of a technological focus, e.g., a particular operating system. 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 an 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 an 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'' an IRT. The ``musts'' are the real interesting ones. Administrivia The mailing list will be updated to include the new people who attended these meetings. Mailing list: grip-wg@uu.net Subscription: grip-wg-request@uu.net Archives will be setup in the US and Europe. The document outline, the template and the definitions will be provided as separate information. The drafts will be available also. US: ftp://info.cert.org/pub/ietf/grip/ Europe: ftp://ftp.cert.dfn.de/pub/ietf/grip/ Access to the GRIP charter and minutes is possible via the World Wide Web, too. http://www.cert.dfn.de/eng/resource/ietf/grip/ Other documents of interest for the discussion of incident response teams and their tasks are available for anonymous FTP. A collection might be found on: ftp://ftp.cert.dfn.de/pub/csir/docs/ Some of the especially interesting documents are: o CERT-NL Framework ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt o FIRST Potential Members ftp://ftp.cert.dfn.de/pub/csir/docs/first.potential.members.txt ftp://ftp.cert.dfn.de/pub/csir/docs/first.members.profile.txt o Bibliography http://www.cert.dfn.de/eng/team/kpk/certbib.html Milestones and Next Meeting The proposed milestones were revised. Up to now there are no changes necessary. It was decided that we will strive to have two drafts between now and the next IETF. Proposed dates for the drafts were the first of May and the first of 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 document.