Internet Engineering Task Force Nevil Brownlee INTERNET-DRAFT The University of Auckland Valid for six months Erik Guttman Sun Microsystems Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-04.txt><draft-ietf-grip-framework-irt-05.txt> Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. This Internet Draft is a product of the GRIP Working Group of the IETF. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a 'working draft' or 'work in progress.' To learn the current status of any Internet Draft, please check the '1id-abstracts.txt' listing contained in the Internet Drafts shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The purpose of this document is to express the general Internet community's expectations of Security Incident Response Teams.Teams (SIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. SIRT constituents have a legitimate need and right to fully understand the policies and procedures of "their" Security Incident Response Team. One way to support this understanding is to supply detailed information which users may consider, in the form of a formal template completed by the SIRT. An outline of such a template and a filled in example isare provided. Expectations for Security Incident Response 26 March28 April 97 Table of Contents 1 Introduction 1 2 Scope..............................................................3Scope.............................................................3 2.1 Publishing aSIRT Policies and Procedures .....................4......................3 2.2 Relationships between different SIRTs .........................5........................4 2.3 Establishing Secure Communications ............................6...........................5 3 Information, Policies and Procedures...............................7Procedures..............................6 3.1 Obtaining the Document........................................7 3.2 Contact Information ...........................................8 3.2 Document Updates ..............................................9..........................................8 3.3 Charter .......................................................9......................................................9 3.3.1 Mission Statement.......................................10Statement.......................................9 3.3.2 Constituency............................................10Constituency............................................9 3.3.3 Sponsoring Organization / Affiliation...................10Affiliation...................9 3.3.4 Authority...............................................11Authority...............................................9 3.4 Policies .....................................................11....................................................10 3.4.1 Types of Incidents and Level of Support.................11Support................10 3.4.2 Co-operation andCo-operation, Interaction with other Organizations...12 3.4.3 Reportingand Disclosure................................13 3.4.4Disclosure of Information............................................11 3.4.3 Communication and Authentication........................14 3.4.5 Point of Customer Contacts..............................14Authentication.......................13 3.5 Services .....................................................15....................................................14 3.6 Incident Reporting Forms .....................................15....................................14 3.7 Disclaimers ..................................................16 4.................................................15 Appendix A: Glossary of Terms 17 515 Appendix B: Related Material 18 617 Appendix C: Known Security Incident Response Teams 19 718 Appendix D: Outline for SIRT Template 21 819 Appendix E: Example - 'filled-in' Template for a SIRT 22 920 4 Acknowlegments 31 5 References 29 1032 6 Security Considerations 29 1132 7 Authors' Addresses 29 Expectations for Security Incident Response 26 March 9732 1 Introduction The GRIP Working Group was formed to create a document that describes the community's expectations of security incident response teams (SIRTs). Although the need for such a document originated in the general Internet community, the expectations expressed should also closely match those of more restricted communities. Expectations for Security Incident Response 15 April 97 In the past there have been misunderstandings regarding what to expect from SIRTs. The goal of this document is to provide a framework for presenting the important subjects (related to incident response) that are of concern to the community. Before continuing, it is important to clearly understand what is meant by the term "Security Incident Response Team." For the purposes of this document, a SIRT is a team that performs, coordinates, and supports the response to security incidents that involve sites within a defined constituency (see Appendix A for a more complete definition). Any group calling itself a SIRT for a specific constituency must therefore react to reported security incidents, and to threats to "their" constituency in ways which the specific community agrees to be in its general interest. Since it is vital that each member of a constituent community be able to understand what is reasonable to expect of their team, Aa SIRT should make it clear who belongs to their constituency and define the services the team offers to the community. Additionally, each SIRT should publish its policies and operating procedures. Similarly, these same constituents need to know what is expected of them in order for them to receive the services of their team. This requires that the team also publish how and where incidents should be reported.to report incidents. This document details a template which will be used by SIRTs to communicate this information to their constituents. The constituents should certainly expect a SIRT to provide the services they describe in the completed template. It must be emphasised that without active participation from users, the effectiveness of the SIRT's services can be greatly diminished. This is particularly the case with reporting. At a minimum, users need to know that they should report security incidents, and know how and to where they should report them to. Many computer security incidents originate outside local community boundaries and affect inside sites, others originate inside the local community and affect hosts or users on the outside. Often, therefore, Expectations for Security Incident Response 26 March 97 the handling of security incidents will involve the cooperation of multiple sites and potentially multiple SIRTs. The coordination of activities across communities and organization requires that the parties understand who they are dealing with, and what sort of policies they have in place.them. Many computer security incidents originate outside local community boundaries and affect inside sites, others originate inside the local community and affect hosts or users on the outside. Often, therefore, the handling of security incidents will involve multiple sites and potentially multiple SIRTs. Resolving these incidents will require cooperation between individual sites and SIRTs, and between SIRTs. Constituent communities need to know exactly how their SIRT will be working with other SIRTs and organizations outside their constituency, and what information will be shared. The rest of this document describes the set of topics and issues that SIRTs need to elaborate for their constituents. However, there is no attempt to specify the "correct" answer to any one topic area. Rather, each topic is discussed itin terms of what that topic means. For example, five types of policy statements are listed Expectations for Security Incident Response 15 April 97 (representing those policies of interest to the community), but the content of any one of them will necessarily be specific to a given team. Chapter two provides an overview of three major areas: Thethe publishing of information by a response team, the definition of the response team's relationship to other response teamsteams, and the need for secure communications. Chapter three describes in detail all the types of information that the community needs to know about their response team. TheseFor ease of use by the community, these topics are condensed into an outline template for ease of use by the community, and isfound in Appendix D. This template can be used by constituents to elicit information from their SIRT, and it provides criteria with which to measure their team's performance.SIRT. It is the working group's sincere hope that through theclarification of the topics in this document, understanding between the community and its SIRTs will be increased. 2 Scope The interactions between a constituent community andan incident response team and its constituent community response team require first that the community understandsunderstand the policies and procedures of the response team. Second, since many response teams collaborate to handle incidents, the community must also understand the relationship between their response team and Expectations for Security Incident Response 26 March 97other teams. Finally, many interactions will take advantage of existing public infrastructures andinfrastructures, so the community needs to know how those communications are going towill be protected. Each of these subjects will be described in more detail in the following three sections. 2.1 Publishing aSIRT Policies and Procedures Each user who has access to a Security Incident Response Team should know as much as possible about the services of and interactions with this team long before he or she actually needs them. A clear statement of the policies and procedures of a SIRT helps the constituent understand how best to report incidents and what support to expect afterwards. Will the SIRT assist in resolving the incident? Will it provide help in avoiding incidents in the future? Clear expectations, particularly of the limitations of the services provided by a SIRT, will make interaction with it more efficient and effective. There are different kinds of response teams. Some thatteams: some have very broad constituencies (e.g., CERT Coordination Center and the Internet), others thathave more bounded constituencies (e.g., DFN-CERT, CIAC), and still others thathave very restricted constituencies (e.g., Expectations for Security Incident Response 15 April 97 commercial response teams, corporate response teams). Regardless of the type of response team, the constituency supported by it must be knowledgeable about the team's policies and procedures. Therefore, it is mandatory that response teams publish such information to their constituency. As aA SIRT provides a service to a this clearly defined constituency, itshould communicate all necessary information about its policies and services in a form suitable form.to the needs of its constituency. It is important to understand that not all policies and procedures mustneed be publicly available. For example, it is not necessary to understand the internal operation of a team in order to interact with it, as when reporting an incident or receiving guidance on how to analyze or secure one's systems. In the past, some teams supplied a kind of Operational Framework, others provided a Frequently Asked Questions list (FAQ), while still others wrote papers for distribution at user conferences or sent newsletters. Another efficient way to communicate the relevant information to all concerned, not only constituents but also other teams or organizations, would be forWe recommend that each SIRT topublish its guidelines and procedures on its own information server.server (e.g. a World Wide Web server). This would allow constituents to easily access Expectations for Security Incident Response 26 March 97it, although this does not addressthough the problem remains of how a constituent or willcan find "his" or "her" team. Peopleteam; people within the constituency have to discover that there is a SIRT "at their disposal." It is foreseen that completed SIRT templates will soon become searchable by modern search engines. Thisengines, which will aid in distributing information about the existence of SIRTs and basic information required to approach them. It would be very useful to have a central repository containing all the completed SIRT templates. No such repository presently exists. Thisexists at the time of writing, though this might change in the future. Regardless of the source from which the information is retrieved, the user of the template must check its authenticity. It is highly recommended that such vital documents be protected by digital signatures. These will allow the user canto verify that the template was indeed published by the SIRT and that it has not been modified thereafter.tampered with. This document assumes the reader has familiarityis familiar with the proper use of digital signatures to determine whether a document is authentic. 2.2 Relationships between different SIRTs In some cases a SIRT may be able to operate effectively on its own and in close cooperation with its constituency. But with todaystoday's international networks it is much more likely that most of the incidents handled by a SIRT will involve parties external to its constituency. Therefore the team will need to interact with other Expectations for Security Incident Response 15 April 97 SIRTs and sites outside theirits constituency. The constituent community should be clear aboutunderstand the nature and extent of this collaboration, as very sensitive information about individual constituents may be disclosed in the process. SuchInter-SIRT interactions could include asking other teams for advice, disseminating knowledge of problemsproblems, and working cooperatively to resolve a security incident effectingaffecting one or more of the SIRTs' constituencies. In establishing relationships to support such interactions, SIRTs will need tomust decide what kinds of agreements can exist between them so as to share yet safeguard information, whether this relationship can be disclosed, and if so to whom. Expectations for Security Incident Response 26 March 97Note that there is a difference between a peering agreement, where the SIRTs involved agree to work together and share information, and simple co-operation, where a SIRT (or any other organization) simply contacts another SIRT and asks for help or advice. Although the establishingestablishment of such relationships is very important and affectaffects the ability of a SIRT to support its constituency, it is up to the teams involved to decide about the details. It is beyond the scope of this document to make recommendations for this process. ButHowever, the same set of information used to set expectations for a user community regarding sharing of information will help other parties to understand the objectives and services of a specific SIRT, supporting a first contact. 2.3 Establishing Secure Communications Once one party has decided to share information with another party, or two parties have agreed to share information or work together - as required for the coordination of Security Incident Responsesecurity incident response - all parties involved need secure communications channels. ("Secure" hereby relates(In this context, "secure" refers to the protected transmission of information shared between different partiesparties, and not to the appropriate use of the information by the parties.) The goals of secure communication are: - Confidentiality: Can somebody else access the content of the communication? - Integrity: Can somebody else manipulate the content of the communication? - Authenticity: Am I communicating with the "right" person? Expectations for Security Incident Response 15 April 97 It is very easy to send forged e-mail, and not hard to establish a (false) identity by telephone. Cryptographic techniques, for example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) can provide effective ways of securing e-mail. With the correct equipment it is also possible to secure telephone communication. But before using such mechanisms, both parties need the "right" infrastructure, which is to say preparation in advance. The most important preparation is ensuring the authenticity of the cryptographic keys used in secure communication: Expectations for Security Incident Response 26 March 97- Public keys (for techniques like PGP and PEM): Because they are accessible through the internet, theyInternet, public keys must be authenticated before usage.use. While PGP relies on a "Web of Trust" -(where users sign the keys of other users -users), PEM relies on a hierarchy -(where certification authorities sign the keys of users.users). - Secret keys (for techniques like DES and PGP/conventional encryption): Because theythese must be known to both sender and receiver, theysecret keys must be exchanged before the communication via a secure channel. Communication is critical forto all aspects of incident response. A team can best support the use of the above-mentioned techniques by gathering all relevant information, in a consistent way. Specific requirements (like(such as calling a specific number for checkingto check the authenticity of keys) should be explained right away.clear from the start. SIRT templates provide a standardized vehicle for delivering this information. It is beyond the scope of this document to address allthe technical and administrative problems of secure communications. The point is that response teams must support and use a method to secure the communications between themselves and their constituents (or other response teams). Whatever the mechanism is, the level of protection it provides must be acceptable to the constituent community. 3 Information, Policies and Procedures In chapter 2,2 it was mentioned that the policies and procedures of a response team need to be published to their constituent community. In this chapter we will list all the types of information that the community needs to receive from its response team. How this information is communicated to a community will differ from team to team, as will the specific information content. The intent here is to clearly describe the various kinds of information that a constituent community expects from its response team. To make it easier to understand allthe issues and topics relevant to the interaction of constituents with "their" SIRT, we suggest that a SIRT publish all information, policiespolicies, and procedures addressing theirits constituency as a document, following the template given in Appendix D. The template structure arranges items, making it easy to supply specific information, was doneExpectations for the exampleSecurity Incident Response 15 April 97 specific information; in Appendix E.E we provide an example of a filled-out template for the fictitious XYZ University. While no recommendations are made as to what a SIRT should adopt for theirits policy or procedures, different possibilities are outlined to give some examples. The most important thing is that a SIRT hashave a policy and that Expectations for Security Incident Response 26 March 97that those who interact with the SIRT canbe able to obtain and understand it. As always, not every aspect for every environment and/or team can be covered. This outline should be seen as a suggestion. Each team should feel free to include whatever they think is necessary for supporting theirto support its constituency. 3.1 Contact Information Full details of how to contactObtaining the Document Details of a SIRT change with time, so the completed template must indicate when it was last changed. Additionally, information should be listed here, although this might be very different for different teams. Some might chooseprovided concerning how to restrict the availability of names of all team members. No further clarification is given when the meaning of the item can be assumed. - Name of the SIRT - Mailing Address - Time zone This is useful for coordinating incidents which cross time zones. - Telephone number - Facsimile number - Other telecommunication Some teams might provide secure voice communication (e.g. STU III). - Electronic mail address - Public keys and encryption The use of specific techniques depends on the ability of the communication partners to have access to programs, keys and so on. Relevant information should be outlined so users can determine if and how they can make use of secure communication while interacting with the SIRT. - Team members - Other information The operating hours and holiday schedule should be provided here. Is there a 24 hour hotline? Is there any specific customer contact info? (See also section 3.4.5). Expectations for Security Incident Response 26 March 97 3.2 Document Updates Details of a SIRT change with time, so the completed template must indicate when it was last changed. Additionally, information should be provided to learn about how to find out about future updates. Without this, itfind out about future updates. Without this, it is inevitable that misunderstandings and misconceptions will arise over time; an outdated document willcan do more harm than good. - Date of last update This should be sufficient to allow anyone interested to evaluate the currency of the template. - Distribution list Mailing lists are a convenient mechanism to distribute up-to-date information to a large number of users. A team can decide to use its own or an already existing list to notify users whenever the document changes. The list might normally cover the constituency and any other groups the SIRT has frequent interactions with. Digital signatures should be used for update messages sent by a SIRT. - Location of the document The location where a current version of the document should beis accessible through a team's online information services. Constituents can then easily learn more about the team and check for recent updates. This online version should also be accompanied by a digital signature, 3.3 Charter Every SIRT must have a charter which specifies what it is to do, and the authority under which it will do it. The charter should include at least the following statements: - Mission statement - Constituency - Sponsor / affiliation - Authoritysignature. Expectations for Security Incident Response 26 March15 April 97 3.3.1 Mission Statement The mission statement should focus on the team's core activities, already stated in the definition3.2 Contact Information Full details of a SIRT. In orderhow to be considered a Security Incident Response Team, the team must supportcontact the reporting ofSIRT should be listed here, although this might be very different for different teams; for example, some might choose not to publicize the names of their team members. No further clarification is given when the meaning of the item can be assumed. - Name of the SIRT - Mailing Address - Time zone This is useful for coordinating incidents which cross time zones. - Telephone number - Facsimile number - Other telecommunication Some teams might provide secure voice communication (e.g. STU III). - Electronic mail address - Public keys and encryption The use of specific techniques depends on the ability of the communication partners to have access to programs, keys and so on. Relevant information should be given to enable users to determine if and how they can make use of encrypted communication while interacting with the SIRT. - Team members - Operating Hours The operating hours and holiday schedule should be provided here. Is there a 24 hour hotline? - Additional Contact Info Is there any specific customer contact info? More detailed contact information can be provided. This might include different contacts for different services, or might be a list of online information services. If specific procedures for access to some services exist (for example addresses for mailing list requests), these should be explained here. Expectations for Security Incident Response 28 April 97 3.3 Charter Every SIRT must have a charter which specifies what it is to do, and the authority under which it will do it. The charter should include at least the following items: - Mission statement - Constituency - Sponsorship / affiliation - Authority 3.3.1 Mission Statement The mission statement should focus on the team's core activities, already stated in the definition of a SIRT. In order to be considered a Security Incident Response Team, the team must support the reporting of incidents and support its constituency by dealing with incidents. The goals and purposes of a team are especially important, and require clear, unambiguous definition. 3.3.2 Constituency A SIRT's constituency can be determined in any of several ways. For example it could be a company's employees or its paid subscribers, or it could be defined in terms of a technological focus, such as the users of a particular operating system. The definition of the constituency should create a perimeter around the group to whom the team will provide service. The policy section of the document (see below) should explain how requests from outside this perimeter will be handled. If a SIRT decides not to disclose its constituency, it should explain the reasoning behind this decision. For example, for-fee SIRTs will not list their clients but will declare that they provide a service to a large group of customers that are kept confidential because of the clients' contracts. Constituencies might overlap, as when an ISP provides a SIRT which delivers services to customer sites that also have SIRTs. The Authority section of the SIRT's description (see below) should make such relationships clear. 3.3.3 Sponsoring Organization / Affiliation The sponsoring organization, which authorizes the actions of the SIRT, should be given next. Knowing this will help the users to Expectations for Security Incident Response 28 April 97 understand the background and set-up of the SIRT, and it is vital information for building trust between a constituent and a SIRT. 3.3.4 Authority This section will vary greatly from one SIRT to another, based on the relationship between the team and its constituency. While an organizational SIRT will be given its authority by the management of the organization, a community SIRT will be supported and chosen by the community, usually in a advisory role. A SIRT may or may not have the authority to intervene in the operation of all of the systems within its perimeter. It should identify the scope of its control as distinct from the perimeter of its constituency. If other SIRTs operate hierarchically within its perimeter, this should be mentioned here, and the related SIRTs identified. Disclosure of a team's authority may expose it to claims of liability. Every team should seek legal advice on these matters. (See section 3.7 for more on liability.) 3.4 Policies It is critical that Incident Response Teams define their policies. The following sections discuss communication of these policies to the constituent community. 3.4.1 Types of Incidents and Level of Support The types of incident which the team is able to address, and the level of support which the team will offer when responding to each type of incident, should be summarized here in list form. The Services section (see below) provides the opportunity to give more detailed descriptions, and to address non-incident-related topics. The level of support may change depending on factors such as the team's workload and the completeness of the information available. Such factors should be outlined and their impact should be explained. As a list of known types of incidents will be incomplete with regard to possible or future incidents, a SIRT should also give some background on the "default" support for incident types not otherwise mentioned. The team should state whether it will act on information it receives about vulnerabilities which create opportunities for future incidents. A commitment to act on such information on behalf of its constituency by dealing with incidents. The goalsis regarded as an optional proactive service policy rather than a core service requirement for a SIRT. Expectations for Security Incident Response 15 April 97 3.4.2 Co-operation, Interaction and purposesDisclosure of Information This section should make explicit which related groups the SIRT routinely interacts with. Such interactions are not necessarily related to the security incident response provided, but are used to facilitate better cooperation on technical topics or services. By no means need details about cooperation agreements be given out; the main objective of this section is to give the constituency a teambasic understanding of what kind of interactions are especially important,established and require clear, unambiguous definitions. 3.3.2 Constituency A SIRT's constituency canwhat their purpose is. The reporting and disclosure policy should make clear who will be determinedthe recipients of a SIRT's report in many ways.each circumstance. It should also note whether the team will expect to operate through another SIRT or directly with a member of another constituency over matters specifically concerning that member. Important examples of related groups a SIRT will interact with are listed below. Incident Response Teams: A SIRT will often need to interact with other SIRTs. For example it could bea company's employees or its paid subscribers, or it could be definedSIRT within a large company may need to report incidents to a national SIRT, and a national SIRT may need to report incidents to national SIRTs in other countries to deal with all sites involved in terms ofa technological focus, such as the userslarge-scale attack. Collaboration between SIRTs may lead to disclosure of a particular operating system.information. The definitionfollowing are examples of constituency should create a perimeter aroundsuch disclosure, but are not intended to be an exhaustive list: - Reporting incidents within the groupconstituency to whomother teams. If this is done, site-related information may become public knowledge, accessible to everyone, in particular the team will provide service. The policy section ofpress. - Handling incidents occurring within the document (see below) should explain how requestsconstituency, but reported from outside it (which implies that some information has already been disclosed off-site). - Reporting observations from within the perimeter will be handled. If a SIRT decide, not to disclosure their constituency, they should explainconstituency indicating suspected or confirmed incidents outside it. - Acting on reports of incidents occurring outside the reasoning behind this decision. For example for-feeconstituency. - Passing information about vulnerabilities to vendors, to partner SIRTs will not listor directly to affected sites lying within or outside the constituency. - Feedback to parties reporting incidents or vulnerabilities. - The provision of contact information relating to members of Expectations for Security Incident Response 15 April 97 the constituency, members of other constituencies, other SIRTs, or law-enforcement agencies. Vendors: Larger vendors have their clientsown SIRTs, but declare that they providesmaller vendors may not. In such cases a serviceSIRT will need to work directly with a large group of customers that are kept confidential because ofvendor to suggest improvements or modifications, to analyse the clients' contract. Constituencies might overlap, as when an ISP provides a SIRT, but delivers servicestechnical problem or to customer sites which also have SIRTs. The Authority sectiontest provided solutions. Law-enforcement agencies: These include the police and other investigative agencies. SIRTs and users of the document (see below)template should make such relationships clear. 3.3.3 Sponsoring Organization / Affiliation The sponsoring organization,be sensitive to local laws and regulations, which authorizesmay vary considerably in different countries. A SIRT might advise on technical details of attacks or seek advice on the actionslegal implications of an incident. Local laws and regulations may include specific reporting and confidentiality requirements. Press: A SIRT may be approached by the SIRT, shouldpress for information and comment from time to time. An explicit policy concerning disclosure to the press can be given next. Knowing thishelpful, particularly in clarifying the expectations of a SIRT's constituency. The press policy will helphave to clarify the userssame topics as above more specifically, as the constituency will usually be very sensitive to understandpress contacts. Other: This might include research activities or the background and setup ofrelation to the SIRT. It is vital information for building up trust between a constituentsponsoring organization. The default status of any and all security-related information which a SIRT. Expectations for Security Incident Response 26 March 97 3.3.4 Authority Based on the relationship betweenteam and constituency this sectionreceives will usually be very different from one'confidential,' but rigid adherence to this makes the team to another. While an organizational SIRT willappear to be given its authority byan informational 'black hole,' which may reduce the management, a community SIRTlikelihood of the team's obtaining cooperation from clients and from other organizations. The SIRT's template should define what information it will be supportedreport or disclose, to whom, and chosen by the community, usuallywhen. Different teams are likely to be subject to different legal restraints requiring or limiting disclosure, especially if they work in a advisory role. SIRTsdifferent jurisdictions. In addition, they may nothave authority to intervene in the operation of all the systems withinreporting requirements imposed by their perimeter. Theysponsoring organization. Each team's template should identify the scope of their control as distinct from the perimeter of their constituency; ifspecify any such constraints, both to clarify users' expectations and to inform other SIRTs operate hierarchically within their perimeter, theseteams. Conflicts of interest, particularly in commercial matters, may also restrain disclosure by a team; this document does not recommend on how such conflicts should be identified and addressed here.addressed. A disclosure of a team's authority may expose it to claims of liability. Everyteam should seek legal advice on these matters. (See section 3.7will normally collect statistics. If statistical information Expectations for more on liability.) 3.4 Policies 3.4.1 Types of Incidents and Level of Support The types of incident which the teamSecurity Incident Response 28 April 97 is able to address and the level of support whichdistributed, the team will offer when respondingtemplate's reporting and disclosure policy should say so, and should describe how to each typeobtain such statistics. 3.4.3 Communication and Authentication Methods of incidentsecure and verifiable communication should be summarized here in list form. The Services section (see below) provides opportunityestablished. This is necessary for more detailed definitioncommunication between SIRTs and to address non-incident related topics.between a SIRT and its constituents. The level of support might change, depending on factors like workloadtemplate should include public keys or completeness ofpointers to them, including key fingerprints, together with guidelines on how to use this information available. Such factors should be outlinedto check authenticity and their impact should be explained. As a list of known types of incidents will be incompletehow to deal with regardcorrupted information (for example where to possible or future incidents,report this fact). At the moment it is recommended that as a minimum every SIRT shouldhave (if possible), a PGP key available. A team may also give some background onmake other mechanisms available (for example PEM, MOSS, S/MIME), according to its needs and the "default" support for each reported incident. The teamneeds of its constituents. Note however, that SIRTs and users should state whether it will act on information it receives about vulnerabilities which create opportunities for future incidents. A commitmentbe sensitive to actlocal laws and regulations. Some countries do not allow strong encryption, or enforce specific policies on the use of encryption technology. In addition to encrypting sensitive information whenever possible, correspondence should include digital signatures. (Please note that in most countries, the protection of authenticity by using digital signatures is not affected by existing encryption regulations.) For communication via telephone or facsimile a SIRT may keep secret authentication data for parties with whom they may deal, such information on behalf of its constituency is regardedas an optional pro-active service policy rather than a core service requirement for a SIRT.agreed password or phrase. Obviously, such secret keys must not be published, though their existence may be. Expectations for Security Incident Response 26 March15 April 97 3.4.2 Co-operation and Interaction with other Organizations This section should make explicit which related groups with which the3.5 Services Services provided by a SIRT routinely interacts with. Such interactions are not relatedcan be differentiated according to the Security Incident Response provided, but are usedwhether they relate to facilitate better cooperation on technical topics or services. By no means should details about cooperation agreements be given out,the main objective of this sectiontask, which is incident response, or are provided in addition to it, i.e. are optional in regard to givethe constituencydefinition of a basic understanding what kindSIRT. Incident response usually includes: - Verification Help in determining whether an incident has really occurred, and its scope. - Technical Assistance This may include analysis of interactions are establishedcompromised systems. - Eradication Elimination of the cause of a security incident (the vulnerability exploited), and whatits effects (for example, continuing access to the system by an intruder). - Recovery Aid in restoring affected systems and services to their purpose is. Examplesstatus before the security incident. - Coordination Notification of these are listed below. Incident Response Teams: A SIRT will often need to interact withother SIRTs. For example a SIRT within a large companyinvolved parties. Additional or optional services might include: - Information provision This might include an archive of known vulnerabilities, patches or resolutions of past problems, or advisory mailing lists. - Security Tools This may need to report incidents toinclude tools for auditing a national SIRT,Site's security. - Education and a national SIRT may need to report incidents to national SIRTs in other countriestraining - Product evaluation - Site security auditing and consulting 3.6 Incident Reporting Forms The use of reporting forms makes it simpler for both users and teams to deal with all sites involved in a large-scale attack. Vendors: Larger vendors have their own SIRTs, but smaller vendors may not. In such cases a SIRT will need to work directly with a vendor to suggest improvements or modifications,incidents. The constituent can prepare answers to analyse the technical problemvarious important questions before he or to test provided solutions. Law-enforcement agencies: These includeshe actually contacts the police and other investigative agencies. SIRTsteam, and users ofcan therefore come well prepared. The team gets all the template should be sensitive to local lawsExpectations for Security Incident Response 15 April 97 necessary information at once with the first report and regulations, which may vary considerably in different countries. A SIRT might advise on technical details of attacks or seek advicecan proceed efficiently. Depending on the legal implications of an incident. Local lawsobjectives and regulationsservices of a particular SIRT, multiple forms may include specificbe used, for example a reporting and confidentiality requirements. Press: A SIRTform for a new vulnerability may be approached byvery different from the Pressform used for reporting incidents. It is most efficient to provide forms through the online information and comment from timeservices of the team. The exact pointers to time. This is discussedthem should be given in more detail immediately below. Other: This might include research activities orthe relationSIRT description document, together with statements about appropriate use, and guidelines for when and how to use the sponsoring organization. Expectationsforms. If separate e-mail addresses are supported for Securityform-based reporting, they should be listed here again. One example of such a form is the Incident Response 26 March 97 3.4.3Reporting Form provided by the CERT Coordination Center: - ftp://info.cert.org/incident_reporting_form 3.7 Disclaimers Although the SIRT description document does not constitute a contract, liability may conceivably result from its descriptions of services and Disclosurepurposes. The default statusinclusion of anya disclaimer at the end of the template is therefore recommended and all security-related information whichshould warn the user about possible limitations. In situations where the original version of a team receives will usuallydocument must be 'confidential,' but rigid adherence to this makestranslated into another language, the team to appear as a 'black hole.' Its templatetranslation should define what information it will report or disclose, to whom,carry a disclaimer and when. Different teams are likelya pointer to be subjectthe original. For example: Although we tried to different legal restraints requiring or limiting disclosure, especially if they workcarefully translate the original document from German into English, we can not be certain that both documents express the same thoughts in different jurisdictions.the same level of detail and correctness. In addition, they may have reporting requirements imposed by their sponsoring organization. Each team's template should specify any such restraints,all cases, where there is a difference between both to clarify users' expectations and to inform other teams. Conflictsversions, the German version will prevail. The use of interest, particularly in commercial matters, may also restrain disclosureand protection by a team; this document does not recommend on how such conflictsdisclaimers is affected by local laws and regulations, of which each SIRT should be addressed. 'Disclosure' includes (but is maybe not limited to): - Reporting incidents withinaware. If in doubt the constituencySIRT should check the disclaimer with a lawyer. Appendix A: Glossary of Terms This glossary defines terms used in describing security incidents and Security Incident Response Teams. Only a limited list is included. For more definitions please refer to other teams. By this, site related information might become public knowledge, accessiblesources, for everybody, especially the press. - Handling incidents occurring withinexample to the constituency, but reported from outside it. - Reporting observations from withinInternet User's Glossary [RFC 1983]. Expectations for Security Incident Response 28 April 97 Constituency: Implicit in the constituency indicating suspected or confirmed incidents outside it. - Acting on reportspurpose of incidents occurring outsidea Security Incident Response Team is the existence of a constituency. - Passing information about vulnerabilities to vendors, to Partner SIRTsThis is the group of users, sites, networks or directlyorganizations served by the team. The team must be recognized by its constituency in order to affected sites lying withinbe effective. Security Incident: For the purpose of this document, this term is a synonym of Computer Security Incident: any adverse event which compromises some aspect of computer or outsidenetwork security. The definition of an incident may vary between organizations, but at least the constituency.following categories are generally applicable: - Feed-back to parties reporting incidents or vulnerabilities.Loss of confidentiality of information. - The provisionCompromise of contact information relating to membersintegrity of the constituency, membersinformation. - Denial of other constituencies, other SIRTsservice. - Misuse of service, systems or law-enforcement agencies. An explicit policy concerning disclosureinformation. - Damage to systems. These are very general categories. For instance the Pressreplacement of a system utility program by a Trojan Horse is an example of 'compromise of integrity,' and a successful password attack is an example of 'loss of confidentiality.' Attacks, even if they failed because of proper protection, can be helpful, particularly in clarifyingregarded as Incidents. Within the expectationsdefinition of a SIRT's constituency. The press policy will have to clarifyan incident the same topics as above more specifically, asword 'compromised' is used. Sometimes an administrator may only 'suspect' an incident. During the constituency will usuallyresponse it must be very sensitive Expectations forestablished whether or not an incident has really occurred. Security Incident Response 26 March 97 towards press contacts. The reporting and disclosure policy should make clear who will be the recipientsTeam: Based on two of a SIRT's report in each circumstance. It should also note whetherthe team will expect to deal through anotherdefinitions given above, a SIRT or directly withis a member of another constituency over matters directly involving that member. Ateam will normally collect statistics. If such information are distributed, the template's reporting and disclosure policy should say so,that coordinates and should list methodssupports the response to obtain such statistics. 3.4.4 Communication and Authentication Methods of secure and verifiable communication should be established. This is necessary for communication between SIRTs and betweensecurity incidents that involve sites within a SIRT and its constituents. The template should include public keys or pointersdefined constituency. In order to them, including key fingerprints, together with guidelines on howbe considered a SIRT, a team must: - Provide a (secure) channel for receiving reports about suspected incidents. - Provide assistance to use thismembers of its constituency in handling these incidents. - Disseminate incident-related information to check authenticityits constituency and howto deal with corrupted information (for example whereother involved parties. Note that we are not referring here to report this fact to). At the moment itpolice or other law enforcement bodies which may investigate computer-related crime. SIRT members, indeed, need not have any powers beyond those of ordinary citizens. Expectations for Security Incident Response 28 April 97 Vendor: A 'vendor' is recommendedany entity that every SIRT has - if possible - as a minimum, a PGP key available. Teams may also make other mechanisms available (for example PEM, MOSS, S/MIME), according to its needsproduces networking or computing technology, and is responsible for the needstechnical content of its constituents. Note however,that SIRTs and users should be sensitive to local lawstechnology. Examples of 'technology' include hardware (desktop computers, routers, switches, etc.), and regulations. Some countries dosoftware (operating systems, mail forwarding systems, etc.). Note that the supplier of a technology is not allow strong encryption or enforce specific policies onnecessarily the use'vendor' of encryptionthat technology. In additionAs an example, an Internet Service Provider (ISP) might supply routers to encrypting sensitive information whenever possible, correspondence should include digitally signatures. (Please note, that in most countries,each of its customers, but the 'vendor' is the protectionmanufacturer, since the manufacturer, rather than the ISP, is the entity responsible for the technical content of authenticity by using digital signaturesthe router. Vulnerability: A 'vulnerability' is not affected by existing encryption regulations.) For communication via telephone or facsimilea SIRT may keep secret authentication data for parties with whom they may deal, such as an agreed password or phrase. 3.4.5 Pointcharacteristic of Customer Contacts More detailed contact information might be provided. This might include different contacts for different services or might bea listpiece of online information services. If specific procedures for accesstechnology which can be exploited to some services exist (like addresses for mailing list requests) these shouldperpetrate a security incident. For example, if a program unintentionally allowed ordinary users to execute arbitrary operating system commands in privileged mode, this "feature" would be explained here. Expectations fora vulnerability. Appendix B: Related Material Important issues in responding to security incidents on a site level are contained in [RFC 1244], the Site Security Incident Response 26 March 97 3.5 Services Services providedHandbook, produced by each SIRT canthe Site Security Handbook Working Group (SSH). This document will be differentiatedupdated by whether they relate tothe main task, which is incident response, or are provided in addition (optional in regardSSH working group and will give recommendations for local policies and procedures, mainly related to the definitionavoidance of a SIRT). Incident response, which usually includes:security incidents. Other documents of interest for the discussion of SIRTs and their tasks are available by anonymous FTP. A collection can be found on: - Verification Help withftp://ftp.cert.dfn.de/pub/docs/csir/ Please refer to file 01-README for further information about the verificationcontent of incidents, as wellthis directory. Some especially interesting documents in relation to this document are as their scope.follows: - Technical Assistanceftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ reports/R-92-01 This may include analysis of compromised systems. - Eradication Eliminationreport contains the Operational Framework of CERT-NL, the effectsSIRT of a security incident. - Recovery AidSURFnet (network provider in restoring affected systems and services to their status beforethe security incident. - Notification of other involved parties Additional or optional services, which might include:Netherlands). - Information provision This might include an archiveFor readers interested in the operation of known vulnerabilities, patches or resolutionsFIRST (Forum of past problems. - Security Tools - Education and training - Product evaluation - Site security auditing and consulting 3.6Incident Reporting Forms The use of reporting forms makes it simplier for both sides, users and teams, to deal with incidents. The constituent may prepare answers to various important questions before he or she actually contacts the teamResponse and therefore come well prepared. The team gets all the necessarySecurity Teams) more information at once withis collected in Appendix C. - http://hightop.nrl.navy.mil/news/incident.html This document leads to the first report and can proceed efficiently.NRL Incident Response Manual. Expectations for Security Incident Response 26 March28 April 97 Depending on the objectives and services of a single SIRT, multiple forms may be used, for example a reporting form for a new vulnerability will be very different for the form used for reporting incidents. It is most efficient to provide forms through the online information services- http://www.cert.dfn.de/eng/team/kpk/certbib.html This document contains an annotated bibliography of available material, documents and files about the team. The exact pointers to them should be given in the document, togetheroperation of SIRTs with statements about appropriate use and guidelines, for when and howlinks to use the forms. If separate e-mail addresses are supported for form based reporting, they should be listed here again. One example for such form ismany of the referenced items. - ftp://info.cert.org/incident_reporting_form This Incident Reporting Form is provided by the CERT Coordination Center: - ftp://info.cert.org/incident_reporting_form 3.7 Disclaimers AlthoughCenter to gather incident information and to avoid additional delays caused by the document does not constitute a contract, liability might conceivably resultneed to request more detailed information from its descriptionsthe reporting site. - http://www.cert.org/cert.faqintro.html A collection of services and purposes. The inclusionfrequently asked questions from the CERT Coordination Center. Appendix C: Known Security Incident Response Teams Today, there are many different SIRTs but no single source lists every team. Most of a disclaimer atthe endmajor and long established teams (the first SIRT was founded in 1988) are nowadays members of FIRST, the template is therefore recommendedworldwide Forum of Incident Response and should warnSecurity Teams. At the usertime of writing, more than 55 teams are members (1 in Australia, 13 in Europe, all others in North America). Information about possible limitations. It shouldFIRST can be noted that some formsfound: - http://www.first.org/ The actual list of reporting or disclosure relating to specific incidents or vulnerabilities can also imply liability,members is available also, with the relevant contact information and some additional information provided by the particular teams: - http://www.first.org/team-info/ For SIRTs should considerwhich want to become members of this forum (please note that a team needs a sponsor - a team which is already a full member of FIRST - to be introduced), the inclusionfollowing files contain more information: - http://www.first.org/about/op_frame.html The Operational Framework of FIRST. - http://www.first.org/docs/newmem.html Guidelines for teams which want to become members of FIRST. Many of disclaimers in such material. In situations wherethe original versionEuropean teams, regardless of whether they are members of FIRST or not, are listed by countries on a document must be translated into another language,page maintained by the translation should carry a disclaimer and a pointerGerman SIRT: - http://www.cert.dfn.de/eng/csir/europe/certs.html To learn about existing teams suitable to the original. For example: Although we triedone's needs it is Expectations for Security Incident Response 28 April 97 often helpful to carefully translate the original document from German into English, we can not be certain that both documents expressask either known teams or an Internet Service Provider for the same thoughts"right" contact. Appendix D: Outline for SIRT Template This outline summarizes in point form the same level of detailissues addressed in this document, and correctness. In all cases, where thereis the recommended template for a difference between both versions,SIRT description document. Its structure is designed to facilitate the German versioncommunication of a SIRT's policies, procedures, and other relevant information to its constituency and to outside organizations such as other SIRTs. A 'filled-in' example of this template is given as Appendix E. 1. Document Information 1.1 Date of Last Update 1.2 Distribution List for Notifications 1.3 Locations where this Document May Be Found 2. Contact Information 2.1 Name of the binding version. The useTeam 2.2 Address 2.3 Time Zone 2.4 Telephone Number 2.5 Facsimile Number 2.6 Other Telecommunication 2.7 Electronic Mail Address 2.8 Public Keys and Encryption Information 2.9 Team Members 2.10 Other Information 2.11 Points of Customer Contact 3. Charter 3.1 Mission Statement 3.2 Constituency 3.3 Sponsorship and/or Affiliation 3.4 Authority 4. Policies 4.1 Types of Incidents and protection by disclaimers is effected by local lawsLevel of Support 4.2 Co-operation, Interaction and regulations. Therefore each SIRT should be sensitiveDisclosure of Information 4.3 Communication and if in doubt should check the disclaimer with a lawyer.Authentication 5. Services 5.1 Incident Response 5.2 Proactive Activities 6. Incident Reporting Forms 7. Disclaimers Expectations for Security Incident Response 26 March28 April 97 4Appendix A: Glossary of Terms This glossary defines terms used in describing security incidents and Security Incident Response Teams. OnlyE: Example - 'filled-in' Template for a limited listSIRT Below is included. For more definitions please refer to other sources, foran example to the [RFC 1983]. Constituency: Implicit in the purposeof a Security Incident Response Team is the existence offilled-in template for a constituency.fictitious SIRT called XYZ-SIRT. This text is for example purposes only, and does not constitute endorsement by the working group of users, sites, networksor organizations served bythe team. The team must be recognized by its constituencyIETF of any particular set of procedures or policies. While SIRTs are welcome to be effective. Security Incident: For the purposeuse any or all of this document this termtext if they wish, such use is synonym to Computer Security Incident: Any adverse event which compromises some aspectof computercourse not mandatory, or network security. The definitioneven appropriate in most cases. SIRT Description for XYZ-CERT ----------------------------- 1. About this document 1.1 Date of an incident may vary between organizations, butLast Update This is version 1.01, published 1997/03/31. 1.2 Distribution List for Notifications Notifications of updates are submitted to our mailing list <firstname.lastname@example.org>. Subscription requests for this list should be sent to the Majordomo at least<email@example.com>; the following categories are generally applicable: - Loss of confidentiality of information. - Compromise of integrity of information. - Denial of service. - Misuse of service, systems or information. - Damagebody of systems. These are very general categories. For instancethe replacementmessage should consist of the word "subscribe". Send the word "help" instead if you don't know how to use a system utility program by a Trojan HorseMajordomo list manager. This mailing list is an example of 'compromisemoderated. 1.3 Locations where this Document May Be Found The current version of integrity,' and a successful password attackthis SIRT description document is an example of 'loss of confidentiality.' Attacks, even if they failed becauseavailable from the XYZ-CERT WWW site; its URL is http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.txt Une version francaise de ce document est igalement disponible: http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.txt Please make sure you are using the latest version. 1.4 Authenticating this Document Both the English and French versions of proper protection, might be regarded as an Incident. Withinthis document have been signed with the definitionXYZ-CERT's PGP key. The signatures are also on our Web site, under: http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.asc http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.asc 2. Contact Information 2.1 Name of an incidentthe word 'compromised' is used. Sometimes an administrator may only 'suspect' an incident. DuringTeam "XYZ-CERT": the response it must be established whether or not an incident really occurred.XYZ University Computer Emergency Response Team. Expectations for Security Incident Response Team: Based28 April 97 2.2 Address XYZ-CERT XYZ University, Computing Services Department 12345 Rue Principale UniversityTown, Quebec Canada H0H 0H0 2.3 Time Zone Canada/Eastern (GMT-0500, and GMT-0400 from April to October) 2.4 Telephone Number +1 234 567 7890 (ask for the XYZ-CERT) 2.5 Facsimile Number +1 234 567 7899 (this is *not* a secure fax) 2.6 Other Telecommunication None available. 2.7 Electronic Mail Address <firstname.lastname@example.org> This is a mail alias that relays mail to the human(s) on two ofduty for the definitions given above,XYZ-CERT. 2.8 Public Keys and Other Encryption Information The XYZ-CERT has a SIRTPGP key, whose KeyID is a team that coordinates12345678 and supportswhose fingerprint is 11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11. The key and its signatures can be found at the response to security incidents that involve sites withinusual large public keyservers. Because PGP is still a defined constituency. Expectations for Security Incident Response 26 March 97 In orderrelatively new technology at XYZ University, this key still has relatively few signatures; efforts are underway to be considered a SIRT, a team must: - Provide a (secure) channel for receiving reports about suspected incidents. - Provide assistanceincrease the number of links to membersthis key in the PGP "web of its constituencytrust". In the meantime, since most fellow universities in handling these incidents. - Disseminate incident-related informationQuebec have at least one staff member who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has signed the XYZ-CERT key, and will be happy to confirm its constituencyfingerprint and to other involved parties. Notethat we are not referring here to police or other law enforcement bodies which may investigate computer-related crime. SIRT members, indeed, should not needof her own key to have any powers beyondthose people who know her, by telephone or in person. 2.9 Team Members Zoe Doe of ordinary citizens. Vendor: A 'vendor'Computing Services is any entity that produces networking or computing technology,the XYZ-CERT coordinator. Backup coordinators and is responsibleother team members, along with their Expectations for the technical content of that technology. ExamplesSecurity Incident Response 28 April 97 areas of 'technology' include hardware (desktop computers, routers, switches, etc.),expertise and software (operating systems, mail forwarding systems, etc.). Note that the supplier of a technology is not necessarilycontact information, are listed in the 'vendor' of that technology. As an example, an Internet Services Provider (ISP) might supply routersXYZ-CERT web pages, at http://www.xyz-univ.ca/xyz-cert/teamlist.html Management, liaison and supervision are provided by Steve Tree, Assistant Director (Technical Services), Computing Services. 2.10 Other Information General information about the XYZ-CERT, as well as links to eachvarious recommended security resources, can be found at http://www.xyz-univ.ca/xyz-cert/index.html 2.11 Points of its customers, butCustomer Contact The preferred method for contacting the 'vendor'XYZ-CERT is via e-mail at <email@example.com>; e-mail sent to this address will "biff" the manufacturer, being the entityresponsible forhuman, or be automatically forwarded to the technical content ofappropriate backup person, immediately. If you require urgent assistance, put "urgent" in your subject line. If it is not possible (or not advisable for security reasons) to use e-mail, the router, ratherXYZ-CERT can be reached by telephone during regular office hours. Telephone messages are checked less often than e-mail. The XYZ-CERT's hours of operation are generally restricted to regular business hours (09:00-17:00 Monday to Friday except holidays). If possible, when submitting your report, use the ISP. Vulnerability: A 'vulnerability' is a characteristicform mentioned in section 6. 3. Charter 3.1 Mission Statement The purpose of a piecethe XYZ-CERT is, first, to assist members of technology which can be exploitedXYZ University community in implementing proactive measures to perpetrate areduce the risks of computer security incident. For example, if a program unintentionally allowed ordinary usersincidents, and second, to execute arbitrary operating system commands in privileged mode, this "feature" would be a vulnerability. 5 Appendix B: Related Material Important issuesassist XYZ community in responding to securitysuch incidents on a site level are contained in [RFC 1244], the Site Security Handbook, produced by the Site Security Handbook Working Group (SSH). This document will be updated by the SSH working group and will give recommendations for local policies and procedures, mainly related towhen they occur. 3.2 Constituency The XYZ-CERT's constituency is the avoidance of security incidents. Other documents of interest forXYZ University community, as defined in the discussion of SIRTs and their tasks arecontext of the "XYZ University Policy on Computing Facilities". This policy is available by anonymous FTP. A collection canat http://www-compserv.xyz-univ.ca/policies/pcf.html However, please note that, notwithtanding the above, XYZ-CERT services will be found on:provided for on-site systems only. Expectations for Security Incident Response 26 March28 April 97 - ftp://ftp.cert.dfn.de/pub/docs/csir/ Please refer to file 01-README for further information about the content of this directory. Some especially interesting documents in relation to this document are as follows: - ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ reports/R-92-01 This report contains the Operational Framework of CERT-NL, the SIRT of SURFnet (network provider in3.3 Sponsorship and/or Affiliation The XYZ-CERT is currently completing the Netherlands). - For readers interestedapplication process for membership in FIRST, the operation of FIRST (ForumForum of Incident Response and Security Teams) moreTeams. More information about FIRST is collected in Appendix C. - http://hightop.nrl.navy.mil/news/incident.html This document leads to the NRL Incident Response Manual. - http://www.cert.dfn.de/eng/team/kpk/certbib.html This document contains an annotated bibliography ofavailable material, documentsfrom http://www.first.org/ 3.4 Authority The XYZ-CERT operates under the auspices of, and files aboutwith authority delegated by, the operationDepartment of SIRTs with links to manyComputing Services of XYZ University. For further information on the referenced. - ftp://info.cert.org/incident_reporting_form This Incident Reporting Form is provided bymandate and authority of the CERT Coordination CenterDepartment of Computing Services, please refer to gather incident informationthe XYZ University "Policy on Computing Facilities", available at http://www-compserv.xyz-univ.ca/policies/pcf.html The XYZ-CERT expects to work cooperatively with system administrators and users at XYZ University, and, insofar as possible, to avoid additional delays by requesting the sites for more detailed information. - http://www.cert.org/cert.faqintro.html A collection of frequently asked questions from the CERT Coordination Center. 6 Appendix C: Known Security Incident Response Teams Today, there are many different SIRTs but no single source list every team. Mostauthoritarian relationships. However, should circumstances warrant it, the XYZ-CERT will appeal to Computing Services to exert its authority, direct or indirect, as necessary. All members of the major and long established teams (the first SIRT was founded in 1988)XYZ-CERT are nowadays membermembers of FIRST,the worldwide ForumCCSA (Committee of Incident ResponseComputer Systems Administrators), and Security Teams. Actually more than 55 teams are members (1 in Australia, 13 in Europe,have all others from America). Information about FIRST can be found: - http://www.first.org/ Expectations for Security Incident Response 26 March 97 The actual listof members is available also, withthe relevant contact informationpowers and some additional information providedresponsibilities assigned to Systems Administrators by the single teams: - http://www.first.org/team-info/ For SIRTs which want to becomePolicy on Computing Facilities, or are members of this forum (please note, that a team needs a sponsor - a team already full memberUniversity management. Members of FIRST - to be introduced),the following files contain more information: - http://www.first.org/about/op_frame.html The Operational Framework of FIRST. - http://www.first.org/docs/newmem.html Guidelines for teams which wantXYZ University community who wish to become member of FIRST. Many ofappeal the European teams, regardless if they are membersactions of FIRST or not, are listed by countries on a page maintained by the German SIRT: - http://www.cert.dfn.de/eng/csir/europe/certs.html To learn about existing teams and maybe more suitable teams for one's need it is always a good approach, to ask either existing teams or an Internet Service Provider forthe "right" contact. Expectations for Security Incident Response 26 March 97 7 Appendix D: Outline for SIRT Template This outline summarizesXYZ-CERT should contact the issues addressed inAssistant Director (Technical Services), Computing Services. If this document in a logical structure suitablerecourse is not satisfactory, the matter may be referred to communicatethe policies and procedures forDirector of Computing Services (in the interactioncase of perceived problems with SIRTs easilyexisting policy), or to the team's constituency. A 'filled-in' examplethe XYZ University Office of this template is given as Appendix E. 1. Contact Information 1.1 NameRights and Responsibilities (in the case of perceived errors in the Team 1.2 Address 1.3 Time Zone 1.4 Telephone Number 1.5 Facsimile Number 1.6 Other Telecommunication 1.7 Electronic Mail Address 1.8 Public Keys and Encryption Information 1.9 Team Members 1.10 Other Information 2. Document Updates 2.1 Dateapplication of Last Update 2.2 Distribution List for Notifications 2.3 Locations where this Document May Be Found 3. Charter 3.1 Mission Statement 3.2 Constituency 3.3 Sponsors and/or Affiliation 3.4 Authorityexisting policy). 4. Policies 4.1 Types of Incidents and Level of Support 4.2 Cooperation and Interaction with Other Entities 4.3 Disclosure of Information 4.4 Communication and Authentication 4.5 Points of Customer Contacts 5. Services 5.1 Incident Response 5.2 Proactive Activities 6. Incident Reporting Forms 7. Disclaimers Expectations for Security Incident Response 26 March 97 8 Appendix E: Example - 'filled-in' Template for a SIRT BelowThe XYZ-CERT is an example, a filled-in template for a SIRT called XYZauthorized to avoid any confusion with existing teams. By no means does this example imply, that a new founded SIRT should reuse this text. It is for example purposes only. SIRT Template for XYZ-SIRT -------------------------- Note: no digital signature is currently available for this SIRT Template. We'll put one up as soon as the technology is adopted byaddress all types of computer security incidents which occur, or threaten to occur, at XYZ Enterprises. 1. Contact Information 1.1 NameUniversity. The level of support given by XYZ-CERT will vary depending on the Team "XYZ-SIRT": the XYZ Computer Emergency Response Team. 1.2 Address XYZ SIRT XYZ Enterprises Private Bag 12-345 MyTown MyCountry 1.3 Time Zone MyCountry/Eastern (GMT-0500,type and GMT-0400 from April to October) 1.4 Telephone Number +1 234 567 7890 (ask forseverity of the incident or issue, the type of constituent, the size of the XYZ-SIRT) 1.5 Facsimile Number +1 234 567 7654 (this is *not* a secure fax) 1.6 Other Telecommunication None available. 1.7 Electronic Mail Address <firstname.lastname@example.org> 1.8 Public Keysuser community affected, and Other Encryption Information Encryption is not currently available, but we plan to install PGP as soon as possible. Our PGP public keythe XYZ-CERT's resources at the time, though in all cases some response will be made within one working day. Resources will appear here as soon as it is available.Expectations for Security Incident Response 26 March28 April 97 1.9 Team Members Jane Doe of Computing Services is the XYZ-SIRT coordinator. Other team members willbe assigned according to the following priorities, listed here once their participation is confirmed. 2. Document Updates 2.1 Datein decreasing order: - Threats to the physical safety of human beings. - Root or system-level attacks on any Management Information System, or any part of Last Update Please seethe bottombackbone network infrastructure. - Root or system-level attacks on any large public service machine, either multi-user or dedicated-purpose. - Compromise of this Web pagerestricted confidential service accounts or software installations, in particular those used for this information. 2.2 Distribution ListMIS applications containing confidential data, or those used for Notifications Notificationssystem administration. - Denial of service attacks on any of updates are submitted to our mailing list <email@example.com>. (Subscription request should go to <firstname.lastname@example.org>.) 2.3 Locations where this Document May Be Found This template is available fromthe XYZ SIRT WWW site; its URL is http://www.sirt.xyz.org/op_frame.html The template will be signed withabove three items. - Any of the XYZ-SIRT's PGP key. 3. Charter 3.1 Mission Statement The purposeabove at other sites, originating from XYZ University. - Large-scale attacks of any kind, e.g. sniffing attacks, IRC "social engineering" attacks, password cracking attacks. - Threats, harrassment, and other criminal offenses involving individual user accounts. - Compromise of individual user accounts on multi-user systems. - Compromise of desktop systems. - Forgery and misrepresentation, and other security-related violations of local rules and regulations, e.g. netnews and e-mail forgery, unauthorized use of IRC bots. - Denial of the XYZ-SIRT is, first, to assist membersservice on individual user accounts, e.g. mailbombing. Types of XYZ community in implementing proactive measuresincidents other than those mentioned above will be prioritized according to reduce the risks of computer security incidents,their apparent severity and second, to assist XYZ community in respondingextent. Note that no direct support will be given to such incidents whenend users; they occur. 3.2 Constituency The XYZ-SIRT's constituency is the XYZ SIRT community, as defined in the context of the "XYZ Policy on Computing Facilities". 3.3 Sponsors and/or Affiliation None. 3.4 Authorityare expected to contact their system administrator, network administrator, or department head for assistance. The XYZ-SIRT operates underXYZ-CERT will support the auspices of, and with authority delegated by,latter people. While the Department of Computing Services of XYZ Enterprises. The DepartmentXYZ-CERT understands that there exists great variation in turn receives its authority fromthe formal ruling bodieslevel of XYZ, as set out in the "Policy on Computing Facilities". The XYZ-SIRT Expectations for Security Incident Response 26 March 97 has no direct authority over systemssystem administrator expertise at XYZ Enterprises at large. However, it benefits fromUniversity, and while the direct authority of Computing Services with respectXYZ-CERT will endeavor to systems managed by this Department. Also, because Computing Services manages the XYZ Enterprises Network,present information and is responsible for connectivity to it, the Department has indirect authority over systems in other departments, inasmuch as the Department can order such systemsassistance at a level appropriate to be disconnected fromeach person, the network should circumstances warrant it. The XYZ-SIRT expects to work cooperatively withXYZ-CERT cannot train system administrators on the fly, and users at XYZ, and, insofar as possible,it cannot perform system maintenance on their behalf. In most cases, the XYZ-CERT will provide pointers to avoid authoritarian relationships. However, should circumstances warrant it,the XYZ-SIRT will appealinformation needed to Computing Servicesimplement appropriate measures. The XYZ-CERT is committed to exert its authority, direct or indirect, as necessary. 4. Policies 4.1 Typeskeeping the XYZ University system administration community informed of Incidentspotential vulnerabilities, and Levelwhere possible, will inform this community of Support The XYZ-SIRT is authorized to address all typessuch vulnerabilities before they are actively exploited. Expectations for Security Incident Response 28 April 97 4.2 Co-operation, Interaction and Disclosure of Information While there are legal and ethical restrictions on the flow of information from XYZ-CERT, many of computer security incidentswhich occur, or risk occurring, atare also outlined in the XYZ Enterprises. The levelUniversity Policy on Computing Facilities, and all of support given by XYZ-SIRTwhich will vary depending onbe respected, the typeXYZ-CERT acknowledges its indebtedness to, and severitydeclares its intention to contribute to, the spirit of cooperation that created the incident or issue,Internet. Therefore, while appropriate measures will be taken to protect the typeidentity of consituent, the sizemembers of our constituency and members of neighbouring sites where necessary, the user community affected,XYZ-CERT will otherwise share information freely when this will assist others in resolving or preventing security incidents. In the paragraphs below, "affected parties" refers to the legitimate owners, operators, and users of the XYZ-SIRT's resources atrelevant computing facilities. It does not refer to unauthorized users, including otherwise authorized users making unauthorized use of a facility; such intruders may have no expectation of confidentiality from the time. No direct supportXYZ-CERT. They may or may not have legal rights to confidentiality; such rights will of course be given to end users;respected where they are expected to contact their system administrator, network administrator,exist. Information being considered for release will be classified as follows: - Private user information is information about particular users, or department headin some cases, particular applications, which must be considered confidential for assistance. The XYZ-SIRTlegal, contractual, and/or ethical reasons. Private user information will support the latter people. While the XYZ-SIRT understands that there exists great variationbe not be released in identifiable form outside the levelXYZ-CERT, except as provided for below. If the identity of system administrator expertise at XYZ, and whilethe XYZ-SIRT will endeavoruser is disguised, then the information can be released freely (for example to presentshow a sample .cshrc file as modified by an intruder, or to demonstrate a particular social engineering attack). - Intruder information is similar to private user information, but concerns intruders. While intruder information, and assistance at a level appropriatein particular identifying information, will not be released to each person,the XYZ-SIRT cannot train system administrators, andpublic (unless it cannot performbecomes a matter of public record, for example because criminal charges have been laid), it will be exchanged freely with system maintenance on their behalf. In most cases, the XYZ-SIRTadministrators and SIRTs tracking an incident. - Private site information is technical information about particular systems or sites. It will provide pointers tonot be released without the information needed to implement appropriate measures.permission of the site in question, except as provided for below. Expectations for Security Incident Response 26 March28 April 97 4.2 Cooperation and Interaction with Other Entities- Other sites: The XYZ-SIRT will cooperate with other SIRTs (security incident response teams) and with system administrators at other sites, to the extent that their bona fide can be verified. Should provincialVulnerability information is technical information about vulnerabilities or national SIRTs be constituted, XYZ-SIRTattacks, including fixes and workarounds. Vulnerability information will explore the possibility of peer relationships with them. The possibility of peer relationships with close neighborsbe released freely, though every effort will alsobe explored; unofficial cooperative climates already exist between XYZ and several nearby universities and large corporations. While there are no legal requirementsmade to inform the relevant vendor before the general public is informed. - Embarrassing information includes the statement that XYZ-SIRT provide anyan incident has occurred, and information about its extent or severity. Embarrassing information may concern a site or a particular user or group of users. Embarrassing information to any body outside XYZ (aside from law enforcement agencies), XYZ-SIRTwill provide such information whennot be released without the goodpermission of the community justifies it. However, unless identifyingsite or users in question, except as provided for below. - Statistical information is neededembarrassing information with the identifying information stripped off. Statistical information will be released at the discretion of the Computing Services Department. - Contact information explains how to track an incident in progress, suchreach system administrators and SIRTs. Contact information will be stripped fromreleased freely, except where the report (unlesscontact person or entity has requested that this not be the affected department gives its permissioncase, or where XYZ-CERT has reason to believe that the realdissemination of this information would not be appreciated. Potential recipients of information from the XYZ-CERT will be used).classified as follows: - Vendors: The XYZ-SIRT wishes to encourage vendorsBecause of all kindsthe nature of networking and computer equipment, software,their responsibilities and servicesconsequent expectations of confidentiality, members of XYZ University management are entitled to improvereceive whatever information is necessary to facilitate the securityhandling of computer security incidents which occur in their products. In aidjurisdictions. - Members of this, a vulnerability discovered in suchthe Office of Rights and Responsibilities are entitled to receive whatever information they request concerning a product will be reportedcomputer security incident or related matter which has been referred to them for resolution. The same is true for the XYZ Security Department, when its vendor, along with all technical details needed to identify and fixassistance in an investigation has been enlisted, or when the problem. Identifying detailsinvestigation has been instigated at its request. - System administrators at XYZ University who are members of the CCSA are also, by virtue of their responsibilities, Expectations for Security Incident Response 28 April 97 trusted with confidential information. However, unless such people are also members of XYZ-CERT, they will notbe given only that confidential information which they must have in order to the vendor without the permission of the affected parties. - Law enforcement: XYZ has itsassist with an investigation, or in order to secure their own Security Department. ( I NEED TO LOOK UP THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ SECURITY, AND OUTSIDE POLICE FORCES. ) Informal working relationships already exist between some system administratorssystems. - Users at XYZ andUniversity are entitled to information which pertains to the local police; interest has been expressed by all parties in formalizing these relationships. Any progress made in that area will be reflected insecurity of their own computer accounts, even if this section. In the meantime, authorizedmeans revealing "intruder information", or "embarrasssing information" about another user. For example, if account aaaa is cracked and unauthorized users ofthe XYZ Computing Facilities should be awareintruder attacks account bbbb, user bbbb is entitled to know that the XYZ-SIRT will cooperate fully with law enforcement agencies in detecting, reporting, documenting,aaaa was cracked, and prosecuting violations of the law; users concerned about confidentiality are referred tohow the XYZ "Policyattack on Computing Facilities". Expectations for Security Incident Response 26 March 97 - The Press: The XYZ-SIRT will not interact directly withthe Press. If necessary,bbbb account was executed. User bbbb is also entitled, if she or he requests it, to information will be providedabout account aaaa which might enable bbbb to investigate the XYZ Public Relations Department, andattack. For example, if bbbb was attacked by someone remotely connected to aaaa, bbbb should be told the Customer Relations groupprovenance of the Computing Services Department. All queries willconnections to aaaa, even though this information would ordinarily be referredconsidered private to these two bodies. - Theaaaa. Users at XYZ SIRT community: Details of incidents mayUniversity are entitled to be releasednotified if their account is believed to Computing Services management,have been compromised. - The XYZ management, or the Computer Resources Committee; these bodiesUniversity community will be charged with maintainingreceive no restricted information, except where the confidentiality ofaffected parties have given permission for the information. General report of incidents, summaries of multiple incidents, and statisticsinformation to be disseminated. Statistical information may be made available to the general XYZ community, with identifying information stripped (except where permission has been obtained from the affected parties).community. There is no obligation on the part of the XYZ-SIRTXYZ-CERT to report incidents to the community, though it may choose to do so; in particular, it is likely that the XYZ-SIRTXYZ-CERT will inform all affected parties of the ways in which they were affected.affected, or will encourage the affected site to do so. - The public at large:large will receive no restricted information. In general,fact, no particular effortseffort will be made to communicate with the public at large, though the XYZ-SIRTXYZ-CERT recognizes that, for all intents and purposes, information made available to the XYZ University community is in effect made available to the community at large, and will tailor the information in consequence. - The computer security community:community will be treated the same way the general public is treated. While members of XYZ-SIRTXYZ-CERT may participate in discussions within the computer security community, such as newsgroups, mailing lists (including the full-disclosure list "bugtraq"), and conferences, they will treat such forums as though they were the public at large. While technical issues (including vulnerabilities) may be discussed to any level of detail, any examples taken from XYZ-SIRTXYZ-CERT experience will be disguised to avoid identifying the affected parties. InExpectations for Security Incident Response 28 April 97 - The press will also be considered as part of the paragraphs above,general public. The XYZ-CERT will not interact directly with the "affected parties" refersPress concerning computer security incidents, except to point them toward information already released to the legitimate owners, operators,general public. If necessary, information will be provided to the XYZ University Public Relations Department, and usersto the Customer Relations group of the relevant computing facilities. ItComputing Services Department. All incident-related queries will be referred to these two bodies. The above does not refer to unauthorized users, including otherwise authorized users making unauthorized usageaffect the ability of members of XYZ-CERT to grant interviews on general computer security topics; in fact, they are encouraged to do to, as a facility; such intruders may have no expectationpublic service to the community. - Other sites and SIRTs, when they are partners in the investigation of confidentiality froma computer security incident, will in some cases be trusted with confidential information. This will happen only if the XYZ-SIRT. They may or may not have legal rights to confidentiality; such rightsforeign site's bona fide can be verified, and the information transmitted will of coursebe respected where they exist. 4.3 Disclosurelimited to that which is likely to be helpful in resolving the incident. Such information sharing is most likely to happen in the case of Information The following typessites well known to XYZ-CERT (for example, several other Quebec universities have informal but well-established working relationships with XYZ University in such mattters). For the purposes of resolving a security incident, otherwise semi-private but relatively harmless user information such as the provenance of connections to user accounts will not be storedconsidered highly sensitive, and handled by XYZ-SIRT: - Contact info for constituents. - Technical info aboutcan be transmitted to a vulnerability. - Technical info about XYZ facilities. - Information about incidents: - Statistical summaries - Admission of incident of certain type - Admission of root compromise - Admission of packet sniffing attack - Admissionforeign site without excessive precautions. "Intruder information" will be transmitted freely to other system administrators and SIRTs. "Embarrassing information" can be transmitted when there is reasonable assurance that user accounts were compromised - Description of incidentit will remain confidential, and when it is necessary to resolve an incident. - IdentityVendors will be considered as foreign SIRTs for most intents and purposes. The XYZ-CERT wishes to encourage vendors of affected systems - Identityall kinds of affected people - Identitynetworking and computer equipment, software, and services to improve the security of perpetrator Recipientstheir products. In aid of information are - depending on the need to know - are as follows: - XYZ management - Computing Services management - Affected sysadmin at XYZ - Affected sysadmin (or SIRT) at another site Expectations for Security Incident Response 26 March 97 - Affected user(s) at XYZ - All sysadmins potentially concerned (potentially vulnerable) at XYZ - All sysadmins at XYZ - All users potentially concerned at XYZ (informationthis, a vulnerability discovered in such a product will leakbe reported to general public) - All users at XYZ (ditto) - Computer security community - Peer sysadminsits vendor, along with all technical details needed to identify and SIRTs - Vendorsfix the problem. Identifying details will not be given to the vendor without the permission of the affected parties. - Law enforcement 4.4officers will receive full cooperation from the XYZ-CERT, including any information they require to pursue an investigation, in accordance with the Policy on Computing Facilities. Expectations for Security Incident Response 28 April 97 4.3 Communication and Authentication In view of the types of information that the XYZ-SIRTXYZ-CERT will likely be dealing with, telephones will be considered sufficiently secure to be used even unencrypted. Unencrypted e-mail will not be considered particularly secure, but will be sufficient for the transmission of low-sensitivity data. If it is necessary to send highly sensitive data by e-mail, PGP will be used. Network file transfers will be considered to be similar to e-mail for these purposes.purposes: sensitive data should be encrypted for transmission. Where it is necessary to establish trust, for example before relying on information given to the XYZ-SIRT,XYZ-CERT, or before disclosing confidential information, the identity and bona fide of the other party will be ascertained to a reasonable degree of trust. Within XYZ,XYZ University, and with known neighbor sites, referrals from known trusted people will suffice to identify someone. Otherwise, appropriate methods will be used, such as a search of FIRST members, the use of WHOIS and other Internet registration information, etc, along with telephone call-back or e-mail mail-back to ensure that the party is not an impostor. Incoming e-mail whose data must be trusted will be checked with the originator personally, or by means of digital signatures. 4.5 Points of Customer Contact The preferred method for contacting the XYZ-SIRT will be e-mail. If thissignatures (PGP in particular is not possible, or not advisable for security reasons, the XYZ-SIRT can be reached by telephone during regular office hours. Expectations for Security Incident Response 26 March 97supported). 5. Services 5.1 Incident Response XYZ-SIRTXYZ-CERT will help users andassist system administrators to handlein handling the technical and organizational aspects of incidents. By that,In particular, it will provide and facilitate: -assistance or advice with respect to understandthe extendfollowing aspects of incident management: - Determining the extent of the incident. - Determining the initial cause of the incident (vulnerability exploited). - Facilitating contact with other sites which may be involved. - Removing the vulnerability. - Securing the system from the effects of the incident. - Evaluating whether certain actions are likely to reap results in proportion to their cost and risk, in particular those actions aimed at an eventual prosecution or disciplinary action: collection of evidence after the fact, observation of an incident in progress, setting traps for intruders, etc. - Collecting evidence where criminal prosecution, or University disciplinary action, is contemplated. Expectations for Security Incident Response 28 April 97 - Facilitating contact with XYZ University Security and/or appropriate law enforcement officials, if necessary. - ...Making reports to other SIRTs. - Composing announcements to users, if applicable. In addition, XYZ-CERT will collect statistics concerning incidents which occur within or involve the XYZ University community, and will notify the community as necessary to assist it in protecting against known attacks. To make use of XYZ-CERT's incident response services, please send e-mail as per section 2.11 above. Please remember that the amount of assistance available will vary according to the parameters described in section 4.1. 5.2 Proactive Activities The XYZ-SIRT will coordinateXYZ-CERT coordinates and maintainmaintains the following services to the extent possible depending on its resources: - Information services - List of departmental security contacts, administrative and technical. These lists will be available to the general public, via commonly-available channels such as the World Wide Web and/or the Domain Name Service. - Mailing lists to inform security contacts of new information relevant to their computing environments.their computing environments. These lists will be available only to XYZ University system administrators. - Repository of vendor-provided and other security-related patches for various operating systems. This repository will be available to the general public wherever license restrictions allow it, and will be provided via commonly-available channels such as the World Wide Web and/or ftp. - Repository of security tools and documentation for use by sysadmins. Where possible, precompiled ready-to-install versions will be supplied. These will be supplied to the general public via www or ftp as above. - "Clipping" service for various existing resources, such as major mailing lists and newsgroups. The resulting clippings will be made available either on the restricted mailing list or on the web site, depending on their sensitivity and urgency. - Training services - Members of the XYZ-CERT will give periodic seminars on computer security related topics; these seminars will be open to XYZ University system administrators. - Auditing services - Central file integrity checking service for Unix machines.machines, and for any other platforms capable of running "tripwire". Expectations for Security Incident Response 28 April 97 - Security level assignments; machines and subnetworks at XYZ University will be audited and assigned a security level. This security level information will be available to the XYZ University community, to facilitate the setting of appropriate access privileges. However, details of the security analyses will be confidential, and available only to the concerned parties. - Archiving services - Central logging service for machines capable of Unix-style remote logging. Incoming log entries will be watched by an automated log analysis program, and events or trends indicative of a potential security problem will be reported to the affected system administrators. - Records of security incidents handled.handled will be kept. While the records will remain confidential, periodic statistical reports will be made available to the XYZ University community. Detailed descriptions of the above services, along with instructions for joining mailing lists, downloading information, or participating in certain services such as the central logging and file integrity checking services, are available on the XYZ-CERT web site, as per section 2.10 above. 6. Incident Reporting Forms There are no ownlocal forms developed yet for reporting incidents to XYZ-SIRT.XYZ-CERT. If possible, please make ususe of the Incident Reporting Form of the CERT Coordination Center (Pittsburgh, PA). The actual version is available from: ftp://info.cert.org/incident_reporting_form 7. Disclaimers While every precaution will be taken in the preparation of information, notifications and alerts, XYZ-SIRTXYZ-CERT assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained within. 4 Acknowlegements The editors gratefully acknowledge the contributed material and editorial scrutiny of Anne Bennett. Expectations for Security Incident Response 26 March28 April 97 95 References [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. - July 23, 1991. - 101 pages. - FYI 8. [RFC 1983] G. Malkin / Internet Users' Glossary. - August 16, 1996. - 62 pages. - FYI 18. 106 Security Considerations This document discusses issues ofthe operation of Security Incident Response Teams, and the teamsteams' interactions with their constituency.constituencies and with other organizations. It is thereforeis, therefore, not directly concerned with the security of protocols, applicationsapplications, or network systems themselves. It is not even concerned about the responsewith particular responses and reactionreactions to security incidents.incidents, but only with the appropriate description of the responses provided by SIRTs. Nonetheless, it is vital that the SIRTs themselves operate securely, which means that they must establish secure communication channels with other teams, and with members of their constituency. They must also secure their own systems and infrastructure, to protect the interests of their constituency and to maintain the confidentiality of the identity of victims and reporters of security incidents. 117 Authors' Addresses Nevil Brownlee ITSS Technology Development The University of Auckland Phone: +64 9 373 7599 x8941 E-mail: email@example.com Erik Guttman Sun Microsystems, Inc. Gaisbergstr. 6 69115 Heidelberg Germany Phone: +49 6221 601649 E-Mail: firstname.lastname@example.org This document expires September 26,October 28, 1997.