Internet Engineering Task Force Nevil Brownlee INTERNET-DRAFT The University of Auckland
November 1996Valid for six months Erik Guttman Sun Microsystems Expectations for Security Incident Response <draft-ietf-grip-framework-irt-03.txt><draft-ietf-grip-framework-irt-04.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 Internet AccountingGRIP 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 ThisThe purpose of this document is intendedto facilitateexpress the setting ofgeneral Internet community's expectations regarding the operationof Security IncicidentIncident Response Teams (SIRTs).Teams. It describes the various important topics inis 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 formgeneral set of a 'template,' throughtopics and issues which every SIRT should describe itselfare of concern and its functions.interest to constituent communities. SIRT clientsconstituents have a legitimate need and right to fully understand the policies and procedures of their"their" Security Incident Response Team. A SIRT's template supplies details for the various important topicsOne way to support this understanding is to supply detailed information which clients must consider when selectingusers may consider, in the form of a formal template completed by the SIRT. An outline of such a template and a filled in example is provided. Expectations for Security Incident Response 26 March 97 Table of Contents 1 Introduction 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.21 2 Scope..............................................................3 2.1 Publishing a SIRT Templates . . . . . . . . . . . . . . . . . . 6 1.3Policies and Procedures .....................4 2.2 Relationships between different SIRTs . . . . . . . . . . . . . . . . . 6 1.4.........................5 2.3 Establishing Secure Communications between SIRTs . . . . . . . . . . 7 2 Description Template: Security Incident Response Team 7............................6 3 Purpose of the Template 8Information, Policies and Procedures...............................7 3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 9 4 The Security Incident Response Team Template 10 4.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1Date of last update . . . . . . . . . . . . . . . . . . . . 10 4.1.2Distribution list for TemplateContact Information ...........................................8 3.2 Document Updates . . . . . . . . . . 10 4.2..............................................9 3.3 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1Mission Statement . . . . . . . . . . . . . . . . . . . . . 11 4.2.2Constituency . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.3Sponsoring organization.......................................................9 3.3.1 Mission Statement.......................................10 3.3.2 Constituency............................................10 3.3.3 Sponsoring Organization / affiliation . . . . . . . . . . . 12 4.2.4Authority . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3Affiliation...................10 3.3.4 Authority...............................................11 3.4 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1Types.....................................................11 3.4.1 Types of incidentsIncidents and levelLevel of support . . . . . . . . . . 12 4.3.2Co-operationSupport.................11 3.4.2 Co-operation and interactionInteraction with other organizations . . . 12 4.3.3ReportingOrganizations...12 3.4.3 Reporting and Disclosure . . . . . . . . . . . . . . . . . 13 4.3.4CommunicationDisclosure................................13 3.4.4 Communication and authentication . . . . . . . . . . . . . 14 4.4Authentication........................14 3.4.5 Point of Customer Contacts..............................14 3.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.....................................................15 3.6 Incident reportingReporting Forms . . . . . . . . . . . . . . . . . . . 15 4.6.....................................15 3.7 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 Secondary Purposes of this Document 15 6..................................................16 4 Appendix A: Note on procedure definitions 16 7Glossary of Terms 17 5 Appendix B: Related Material 18 6 Appendix C: Known Security Incident Response Teams 1719 7 Appendix D: Outline for SIRT Template 21 8 Appendix C: Example: aE: Example - 'filled-in' template 17Template for a SIRT 22 9 References 29 10 Security Considerations 25 10 Author's Address 25 1 Introduction The GRIP Working29 11 Authors' Addresses 29 Expectations for Security Incident Response 26 March 97 1 Introduction The GRIP Working Group was formed to produce guidelines and recommendations to facilitatecreate a document that describes the consistent handlingcommunity's expectations of security incidents in the Internet community.incident response teams (SIRTs). Although it is focused onthe Internet, many of the concepts discussed will also be usefulneed for other forms of local- and wide-area networks and internets. Many computer security incidents orginate outside local community boundaries and affect other 'outside' sites, and others orignate outsidesuch a document originated in the local community and affect hosts or users within it. Often, therefore,general Internet community, the handling of security incidents will involve multiple Security Incident Response Teams. Becauseexpectations expressed should also closely match those of this characteristic it is important for every community to have a good security policy, and to have a Security Incident Response Team (SIRT) in place to manage communications across community boundaries in a consistent way.more restricted communities. In the past there have been misunderstandings regarding expectations of response teams.what to expect from SIRTs. The goal of this document is to provide a framework in which to set expectations. By defining such a frameworkfor presenting the community can express areas and topicsimportant subjects (related to incident response) that needare of concern to addressedthe community. Before continuing, it is important to clearly understand what is meant by any SIRT. 'Consistent handling' impliesthe term "Security Incident Response Team." For the purposes of this document, a SIRT is a team that anyperforms, 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 orincidents, and to threats of themto "their" constituency in ways which the Internetspecific community agrees to be in its general interest. EverySince it is vital that each member of a constituent community be able to understand what is reasonable to expect of their team, A SIRT needsshould make it clear who belongs to their constituency and define clearlythe services they offer andthe level at which they are offeredteam offers to clients. Such definitions will be particularly importantthe community. Additionally, each SIRT should publish its policies and operating procedures. Similarly, these same constituents need to know what is expected of them in contracts and/or agreements which SIRTs make with their clients. The "Expectationsorder for Security Incident Response" is seen as resting onthem to receive the workservices of individual SIRTs andtheir team. This requires that the cooperation between them.team also publish how and where incidents should be reported. This document therefore recommendsdetails a 'template' throughtemplate which every SIRT should describe itself and its functions. It further recommends that templates shouldwill be accessible among teams,used by SIRTs to make possiblecommunicate this information to their constituents. The constituents should certainly expect a fully effective cooperative response framework for incidents or threats acrossSIRT to provide the entire domain affected by them. 1.1 Definitions This section defines terms usedservices they describe in describing security incidents and response teams. Forthe purposecompleted template. It must be emphasised that without active participation from users, the effectiveness of the GRIP documents only a limited list is really needed.SIRT's services can be greatly diminished. This should help maintain focus onis particularly the purpose ofcase with reporting. At a minimum, users need to know that they should report security incidents, and know how and where they should report them to. Many computer security incidents originate outside local community boundaries and affect inside sites, others originate inside the documents,local community and prevent a duplication of other definitionsaffect hosts or - even worse - a proliferation of competing definitions. Constituency ------------ Implicit inusers on the purpose of aoutside. Often, therefore, Expectations for Security Incident Response Team is26 March 97 the existencehandling of a constituency. This issecurity incidents will involve the groupcooperation of clients, sites, networks or organizations served by the team. Security Incident ----------------- Formultiple sites and potentially multiple SIRTs. The coordination of activities across communities and organization requires that the purposeparties understand who they are dealing with, and what sort of this document: 'Apolicies they have in place. Many computer security incident is any event which compromises some aspect of computerincidents originate outside local community boundaries and affect inside sites, others originate inside the local community and affect hosts or network security.' The definitionusers on the outside. Often, therefore, the handling of an incident may varysecurity incidents will involve multiple sites and potentially multiple SIRTs. Resolving these incidents will require cooperation between organizations, but at leastindividual 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 following categories are generally applicable: * lossset of confidentiality, * compromisetopics 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 it terms of integrity, * denialwhat that topic means. For example, five types of service, * misuse, * damage. Thesepolicy statements are very general categories. For instance the replacementlisted (representing those policies of a system utility program by a Trojan Horse is an exampleinterest to the community), but the content of 'lossany one of integrity,' andthem will necessarily be specific to a successful password attack isgiven team. Chapter two provides an exampleoverview of 'lossthree major areas: The publishing of confidentiality.' Withininformation by a response team, the definition of an incidentthe word 'compromised' is used. Sometimes an administrator may only 'suspect' an incident. Duringresponse team's relationship to other response teams and the handling of a call it must be established whether or not an incident really occurred. Security Incident Response Team ------------------------------- Based on twoneed for secure communications. Chapter three describes in detail all the types of information that the definitions given above: 'A Security Incident Response Team is a group authorizedcommunity needs to manageknow about their response to security incidents that involve sites within its defined constituency.' In order to be considered a SIRT, a group must: * provide a channelteam. These topics are condensed into an outline template for receiving reports about suspected incidents, * provide assistance to membersease of its constituencyuse by the community, and is found in handling these incidents, * disseminate incident-related informationAppendix D. This template can be used by constituents to its constituencyelicit information from their SIRT, and to other related parties. Note that we are not referring here to police or other law enforcement bodiesit provides criteria with which may investigate computer-related crime. SIRT members, indeed, should not needto have any powers beyond those of ordinary citizens. Vendor ------ A 'vendor' is any entity that produces networking or computing technology, andmeasure their team's performance. It is responsible forthe technical content ofworking group's sincere hope that technology. Examplesthrough the clarification of 'technology' include hardware (desktop computers, routers, switches, etc.),the topics in this document, understanding between the community and software (operating systems, mail forwarding systems, etc.). Noteits SIRTs will be increased. 2 Scope The interactions between a constituent community and an incident response team require first that the supplier of a technology is not necessarilycommunity understands the 'vendor'policies and procedures of that technology. As an example, an Internet Services Provider (ISP) might supply routersthe response team. Second, since many response teams collaborate to each of its customers, buthandle incidents, the 'vendor' is the manufacturer, beingcommunity must also understand the entity responsiblerelationship between their response team and Expectations for the technical contentSecurity Incident Response 26 March 97 other teams. Finally, many interactions will take advantage of existing public infrastructures and the router, rather than the ISP. Vulnerability ------------- A 'vulnerability' is a characteristic of a piece of technology which can be exploitedcommunity needs to perpetrate a security incident. For example, if a program unintentionally allowed ordinary usersknow how those communications are going to execute arbitrary operating system commands in privileged mode, this "feature" wouldbe a vulnerability. 1.2protected. Each of these subjects will be described in more detail in the following three sections. 2.1 Publishing a SIRT Templates Every SIRTPolicies and Procedures Each user who has access to a Security Incident Response Team should publish informationknow as much as possible about its policies andservices inof and interactions with this team long before he or she actually needs them. A clear statement of the formpolicies and procedures of a completed template. The simplest way for aSIRT helps the constituent understand how best to make its template widely available isreport incidents and what support to publishexpect afterwards. Will the SIRT assist in resolving the incident? Will it on its own information server so that clientsprovide help in its constituency can easily find it. Templates published as pagesavoiding incidents in the World Wide Web should includefuture? Clear expectations, particularly of the phrase 'SIRT Template' in their title - this will allow Web search engines to find them easily. Whether or not templates are published in a repository, clients - and potential clients -limitations of a SIRT will need to be able to authenticate a template (verify that it was indeed published bythe SIRT) and check that it has not been modified (for exampleservices provided by verifyinga digital signature for it). To facilitateSIRT, will make interaction between SIRTs,with it would be useful tomore efficient and effective. There are different kinds of response teams. Some that have a central repository for them. The GRIP Working Group believevery broad constituencies (e.g., CERT Coordination Center and the Internet), others that somehave more bounded constituencies (e.g., DFN-CERT, CIAC), and still others that have very restricted constituencies (e.g., commercial response teams, corporate response teams). Regardless of the existing Internet archive areas could be used for this purpose. The keepertype of each template repository will be responsibly for verifyingresponse team, the identity of each SIRT lodging a template inconstituency supported by it must be knowledgeable about the repository. 1.3 Relationships between SIRTs In some casesteam's policies and procedures. Therefore, it is mandatory that response teams publish such information to their constituency. As a SIRT may be ableprovides a service to operate effectively ona this clearly defined constituency, it should communicate all necessary information about its own.policies and services in a suitable form. It is much more likely, however,important to understand that not all policies and procedures must be publicly available. For example, it is not necessary to understand the internal operation of a SIRT will needteam in order to interact with other SIRTs. Such interactions could include: * Respondingit, as when reporting an incident or receiving guidance on how to requests for advice (e.g. "have you seen this problem before?") * Reportinganalyze or secure one's systems. In the past, some teams supplied a kind of problems (for onward referal to other SIRTs, to service providersOperational Framework, others provided Frequently Asked Questions (FAQ), while still others wrote papers for distribution at user conferences or sent newsletters. Another efficient way to vendors) * Working co-operatively to resolve a security incident Note that there is a difference between a peering agreement, wherecommunicate the SIRTs involved agreerelevant information to work together and share information, and simple co-operation, where a SIRT (or anyall concerned, not only constituents but also other client) simply contacts another SIRT and asks for helpteams or advice. Note also that any client wanting direct help in tracking an incident mustorganizations, would be preparedfor each SIRT to provide sufficientpublish its guidelines and procedures on its own information about the incident to make tracking possible. In establishing relationships to support such interactions, SIRTs will need to decide what kinds of agreements can exist between themselves so asserver. This would allow constituents to share yet safeguard information, whethereasily access Expectations for Security Incident Response 26 March 97 it, although this relationship can be disclosed, and if so to whom? 1.4 Establishing Communications between SIRTs Once two SIRTs have agreed to work together - as outlined above - they need to establish secure communications channels. This section outlines some ofdoes not address the issues involved in this. When a SIRT (SIRT A) wishes to establish a working relationship with another SIRT (SIRT B),problem of how a responsible person from SIRT Aconstituent or will needfind "his" or "her" team. People within the constituency have to contactdiscover that there is a similarly responsible person atSIRT B. The"at their disposal." It is foreseen that completed SIRT B person then hastemplates will soon become searchable by modern search engines. This will aid in distributing information about the problem: "how do I know who I'm talking to?"existence of SIRTs and basic information required to approach them. It iswould be very easy to send forged e-mail, and not harduseful to establishhave a (false) identity by telephone. PGP and PEM provide effective ways of securing e-mail, but securing voice communications is much harder. At present call-back is probablycentral repository containing all the only simple authentication method.completed SIRT templates. No such repository presently exists. This maymight change as technologies such as scrambled telephones, or PGP-phone onin the Internet become available. PGP relies on a 'web of trust,' built up by having known (and trusted) people sign PGP keys. This model could also be used for SIRTs. To achieve this each SIRT should publish a listfuture. Regardless of the SIRTs they have peering arrangements (i.e. working relationships) with, including PGP public keys for them andsource from which the expiry dates of those keys. 2 Description Template: Security Incident Response Team The Templateinformation is summarized in the section immediately below, andretrieved, the remainderuser of the document describes its components. A 'filled-in' example of atemplate must check its authenticity. It is given as Appendix C. 1. Contact Information ---------------------- 1.1 Name ofhighly recommended that such vital documents be protected by digital signatures. These will allow user can verify that the Team 1.2 Address 1.3 Time Zone 1.4 Telephone Number 1.5 Facsimile Number 1.6 Other Telecommunication (STU-III, secure facsimile...) 1.7 Electronic Mail Address 1.8 Public Keys and Other Encryption Information 1.9 Team Members 2. Template Updates ------------------- 2.1 Date of Last Update 2.2 Locations where this Template May Be Found 3. Charter ---------- 3.1 Mission Statement 3.2 Constituency 3.3 Sponsors and/or Affiliation 3.4 Authority 4. Policies ----------- 4.1 Types of Incidents 4.2 Level of Support 4.3 Disclosure of Information 4.4 Cooperationtemplate was indeed published by the SIRT and Interactionthat it has not been modified thereafter. This document assumes the reader has familiarity with Other Entities 4.5 Communication and Authentication 4.6 Points of Customer Contact 5. Services ----------- 5.1 Incident Response 5.2 Proactive Activities 6. Incident Reporting Forms --------------------------- 7. Disclaimers -------------- 3 Purpose ofthe Template The Template which thisproper use of digital signatures to determine whether a document proposesis expected to be used byauthentic. 2.2 Relationships between different SIRTs In some cases a response teamSIRT may be able to describe what it does,operate effectively on its own and in the process create criteria against whichclose cooperation with its performance can be measured. The Template does not attempt to specify a "correct" way forconstituency. But with todays 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 operate, but does recommend on specific policiesinteract with other SIRTs and functions seensites outside their constituency. The constituent community should be clear about the nature and extent of this collaboration, as necessary for such a team to play a consistent rolevery sensitive information about individual constituents may be disclosed in the overall security framework. It also comments on additional roles a team mightprocess. Such interactions could include in the ambitasking other teams for advice, disseminating knowledge of its operations. The primary purposesproblems and working cooperatively to resolve a security incident effecting one or more of the Template are: -SIRTs' constituencies. In establishing relationships to helpsupport such interactions, SIRTs improve the way they operate; -will need to improve interactionsdecide what kinds of agreements can exist between different SIRTs,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 97 Note 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 organizations such as vendorsorganization) simply contacts another SIRT and law-enforcement agencies; - to note necessary interactions with their constituencies in setting expectationsasks for help or advice. Although the establishing of such relationships is very important and defining policies; -affect the ability of a SIRT to help new groups understand whatsupport its constituency, it takesis up to "be" a SIRT. A Template might appearthe teams involved to provide a marketing tooldecide about the details. It is beyond the scope of this document to make recommendations for comparing different teams, butthis kind of marketing use (or abuse) is strongly discouraged byprocess. But the GRIP Working Group. 3.1 Other Related Material This 'Framework for Response Teams' document is the first produced by the GRIP Working Group. A second document willsame set out guide-lines for technology vendorsof information used to help them handle security incidents. The definitionset expectations for a user community regarding sharing of terms given in the next section appliesinformation will help other parties to both documents. Another relevant IETF document is RFC 1244, the Site Security Handbook, produced by (and being updated by) the Site Security Handbook Working Group (SSH). Site requirements and recommendations are covered byunderstand the Handbook, while response team expectationsobjectives and procedures are addressed by the GRIP documents. Other documentsservices of interesta 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 discussioncoordination of incident response teams and their tasks are available by anonymous FTP. A collection can be found on: * ftp://ftp.nic.surfnet.nl/surfnet/net-security/ cert-nl/docs/reports/R-92-01 Some especially interesting documents are: * CERT-NL Framework ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt * FIRST potential members ftp://ftp.first.org/pub/first/newmemlt.txt ftp://ftp.first.org/pub/first/profile.txt ftp://ftp.first.org/pub/first/op`frame.txt http://www.first.org/first * NRL Incident Response Manual http://hightop.nrl.navy.mil/news/incident.html * Bibliography http://www.cert.dfn.de/eng/team/kpk/certbib.html 4 TheSecurity Incident Response Team Template This material which follows is addressed- all parties involved need secure communications channels. ("Secure" hereby relates to those responsible for Security Incident Response Teams. 4.1 Template Updates Details of a Securty IRT change with time, sothe template must indicate when it was last changed, who will be informedprotected transmission of future changes, and (by implication) who will not. Without this, it is inevitable that misunderstandingsinformation shared between different parties and misconceptions will arise over time. 4.1.1 Date of last update This should be sufficient to allow anyone interested to evaluatenot the currencyappropriate use of the template. 4.1.2 Distribution list for Template Updates Persons on this list are notified automatically wheneverinformation by the template is changed.parties.) The list might normally covergoals of secure communication are: - Confidentiality: Can somebody else access the constituency and any other groupscontent of the SIRT has frequent interactions with. Readers not oncommunication? - Integrity: Can somebody else manipulate the list can then recognise that they should checkcontent of the central repository (above) for possible updates. Digital signatures should be used for update messages sent by a SIRTcommunication? - Authenticity: Am I communicating with the "right" person? It is very easy to those on its distribution list. 4.2 Charter Every SIRT must havesend forged e-mail, and not hard to establish a charter which specifies what(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 do, andsecure telephone communication. But before using such mechanisms, both parties need the authority under"right" infrastructure, which it will do it.is to say preparation in advance. The charter should include at leastmost important preparation is ensuring the following: * mission statement * constituency * sponsor / affiliation * authority 4.2.1 Mission Statement The mission statement should focus onauthenticity of the team's core activities, already statedcryptographic keys used in the definition of a SIRT. In order to be considered asecure communication: Expectations for Security Incident Response Team, the team MUST provide incident response, by definition. The goals26 March 97 - Public keys (for techniques like PGP and purposes of a teamPEM): Because they are especially important, and require clear, succinct definition. 4.2.2 Constituency A SIRT's constituency (as defined above) can be determined in many ways. For example it couldaccessible through the internet, they must be authenticated before usage. While PGP relies on a company's employees or its paid subscribers, or it could be defined in terms"Web of a technological focus, such as theTrust" - users sign the keys of other users - PEM relies on a particular operating system. The definition of constituency should create a perimeter aroundhierarchy - certification authorities sign the group to whom the team will provide service. The policy section (below) should explain how requests from outside the perimeter willkeys of users. - Secret keys (for techniques like DES and PGP/conventional encryption): Because they must be handled. Constituencies might overlap, as when an ISP supports a SIRT, but delivers servicesknown to customer sites which also have SIRTs. The Authority section (below) should make such relationships clear. People withinsender and receiver, they must be exchanged before the constituency have to learn that there iscommunication via a Security IRTsecure channel. Communication is critical for their purposes; the buildingall aspects of a trusted relationship with the constituency is an on-going process which never ends. 4.2.3 Sponsoring organization / affiliation The sponsoring organization, which authorisesincident response. A team can best support the actionsuse of the SIRT, should be given next. Defining the affiliation amounts to stating: "Who is your God?". 4.2.4 Authority SIRTs may not have authority to interveneabove-mentioned techniques by gathering all relevant information, in a consistent way. Specific requirements (like calling a specific number for checking the operationauthenticity of all the systems within their perimeter. Theykeys) should identifybe explained right away. SIRT templates provide a standardized vehicle for delivering this information. It is beyond the scope of their control as distinct fromthis document to address all the perimeter of their constituency; if other SIRTs operate hierachically within their perimeter, these should be identified. 4.3 Policies 4.3.1 Types of incidentstechnical and leveladministrative problems of supportsecure communications. The types of incident which the teampoint is authorisedthat response teams must support and use a method to addresssecure the communications between themselves and their constituents (or other response teams). Whatever the mechanism is, the level of support whichprotection it provides must be acceptable to the team will contribute when assisting with each typeconstituent community. 3 Information, Policies and Procedures In chapter 2, it was mentioned that the policies and procedures of incident shoulda response team need to be summarized here in list form. The Services section (later) provides opportunity for more detailed definition. The team should state whether itpublished to their constituent community. In this chapter we will act onlist all the types of information it receives about vulnerabilities which create opportunities for future incidents. A commitmentthat the community needs to act on such information on behalf ofreceive from its constituencyresponse team. How this information is regarded as an optional pro-active service policy rather than a core service requirement forcommunicated to a SIRT. 4.3.2 Co-operation and interaction with other organizations This section should make explicitcommunity will differ from team to team, as will the related groups with whichspecific information content. The intent here is to clearly describe the SIRT routinely interacts. Examplesvarious kinds of these are listed below. Incident Response Teams: A SIRT will often needinformation that a constituent community expects from its response team. To make it easier to interactunderstand all issues and topics relevant to the interaction of constituents with other SIRTs. For example"their" SIRT, we suggest that a SIRT withinpublish all information, policies and procedures addressing their constituency as a large company may needdocument, following template given in Appendix D. The template structure arranges items, making it easy to report incidentssupply specific information, was done for the example in Appendix E. While no recommendations are made as to what a national SIRT, and a nationalSIRT may need to report incidents to national SIRTs in other countries. Vendors: Larger vendors haveshould adopt for their own SIRTs, but smaller vendors may not. In such casespolicy or procedures, different possibilities are outlined to give some examples. The most important thing is that a SIRT will need to work directly withhas a vendor. Law-enforcement agencies: These include the policepolicy and other investigative agencies. SIRTs and users ofthat Expectations for Security Incident Response 26 March 97 that those who interact with the template should be sensitive to local laws and regulations, which may vary considerably in different countries. Press: ASIRT may be approached by the Press for information and comment from time to time. This is discussed in more detail immediately below. 4.3.3 Reporting and Disclosure The default status of anycan obtain and all security-related information which aunderstand it. As always, not every aspect for every environment and/or team receivescan onlybe 'confidential,' but rigid adherence to this makes the team a 'black hole.' Its templatecovered. This outline should define what information it will report or disclose, to whom, and when. Different teams are likely tobe subject to different legal restraints requiring or limiting disclosure, especially if they work in different jurisdictions.seen as a suggestion. Each team's templateteam should specify any such restraints, both to clarify clients' expectations andfeel free to inform other teams. Conflictsinclude whatever they think is necessary for supporting their constituency. 3.1 Contact Information Full details of interest, particularly in commercial matters, may also restrain disclosure by a team; the present Draft does not recommend onhow such conflictsto contact the SIRT should be addressed. An explicit policy concerning disclosurelisted here, although this might be very different for different teams. Some might choose to restrict the Press can be helpful, particularly in clarifyingavailability of names of all team members. No further clarification is given when the expectationsmeaning of a SIRT's constituency. 'Disclosure' includes: - reporting incidents withinthe constituency to other teams;item can be assumed. - handling incidents occurring withinName of the constituency, but reported from outside it.SIRT - reporting observations from within the constituency indicating suspected or confirmed incidents outside it;Mailing Address - acting on reports ofTime zone This is useful for coordinating incidents occurring outside the constituency;which cross time zones. - passing information about vulnerabilities to vendors, to Partner SIRTs or directly to affected sites lying within or outside the constituency;Telephone number - feed-back to parties reporting incidents or vulnerabilities;Facsimile number - the provision of contact information relating to members of the constituency, members of other constituencies, other SIRTs or law-enforcement agencies. The reportingOther telecommunication Some teams might provide secure voice communication (e.g. STU III). - Electronic mail address - Public keys and disclosure policy should make clear who will be the recipientsencryption The use of a SIRT's reports in each circumstance. It should also note whetherspecific techniques depends on the team will expect to deal through another Security IRT or directly with a memberability of another constituency over matters directly involving that member. A team will normally collect statistics. If they are distributed,the template's reporting and disclosure policy should say so,communication partners to have access to programs, keys and so on. Relevant information should list the recipients. 4.3.4 Communicationbe outlined so users can determine if and authentication Methodshow they can make use of secure and verifiablecommunication while interacting with the SIRT. - Team members - Other information The operating hours and holiday schedule should be established. This is necessaryprovided here. Is there a 24 hour hotline? Is there any specific customer contact info? (See also section 3.4.5). Expectations for communication between SIRTs and betweenSecurity Incident Response 26 March 97 3.2 Document Updates Details of a SIRT and its constituents. Thechange with time, so the completed template must indicate when it was last changed. Additionally, information should include public keys or pointersbe provided to them, including key fingerprints, together with guidelines onlearn about how to use this information to check authenticity. At the momentfind out about future updates. Without this, it is recommendedinevitable that every SIRT have, as a minimum, a PGP key available, since PGP is available world-wide. Teams may also make other mechanisms available, for example PEM. For communication via telephone or facsimile a SIRT may keep secret authentication data for parties with whom they may deal, such asmisunderstandings and misconceptions will arise over time; an agreed password or phrase. 4.4 Services Servicesoutdated document will do more harm than good. - Date of last update This should be defined in two sections, as listed below. * direct incident response + verification of incident + technical assistance and analysissufficient to understandallow anyone interested to evaluate the compromisecurrency of the template. - Distribution list Mailing lists are a system + notification of other involved parties + eradication + recovery * optional +convenient mechanism to distribute up-to-date information provision - vulnerability archive - patches and resolutions + tools + education + audit and consulting + product evaluation 4.5 Incident reporting Forms Samplesto a large number of reporting forms used byusers. 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 (or pointers to them)has frequent interactions with. Digital signatures should be included at this point in a template. 4.6 Disclaimers Although the template does not constituteused for update messages sent by a contract, liability might conceivably result from its descriptionsSIRT. - Location of services and purposes.the document The inclusion oflocation where a disclaimer at the endcurrent version of the template is recommended. Itdocument should be noted that some forms of reporting or disclosure relating to specific incidents or vulnerabilitiesaccessible through a team's online information services. Constituents can imply liability, and SIRTs should consider the inclusion of disclaimers in such material. In situations wherethen easily learn more about the originalteam and check for recent updates. This online version of a template must be translated into another language, the translationshould carryalso be accompanied by a disclaimer anddigital signature, 3.3 Charter Every SIRT must have a pointercharter which specifies what it is to do, and the original. For example: Although we tried to carefully translate our German template into English, we can not be certain that both documents expressauthority under which it will do it. The charter should include at least the same thoughtsfollowing statements: - Mission statement - Constituency - Sponsor / affiliation - Authority Expectations for Security Incident Response 26 March 97 3.3.1 Mission Statement The mission statement should focus on the team's core activities, already stated in the same leveldefinition of detail and correctness.a SIRT. In all cases, where there isorder to be considered a difference between both versions,Security Incident Response Team, the German version isteam must support the binding version for our operation. 5 Secondary Purposesreporting of this Documentincidents and support its constituency by dealing with incidents. The primary audiencegoals and purposes of this documenta team are especially important, and require clear, unambiguous definitions. 3.3.2 Constituency A SIRT's constituency can be determined in many 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 administrators responsible for communitiesusers of users, i.e. 'constituencies.' This section provides some brief notes on what SIRT clients should expecta particular operating system. The definition of their teams. An incident response team exists primarilyconstituency should create a perimeter around the group to supportwhom the clients in its constituency. It is vital that those clients understand what they should expectteam will provide service. The policy section of their team. Provided that a SIRT has published its template, a constituent/client should be able to readthe template and discover what to expect, for example in such areas as privacy and confidentiality of information, and whetherdocument (see below) should explain how requests from outside the response teamperimeter will be contacting downstream sites. Clients should certainly expecthandled. If a SIRT decide, not to provide the services they detail indisclosure their template. An important aspect of incident response is the 'follow through' - every incident should be investigated and appropriate actions taken. Clientsconstituency, they should be encouraged byexplain the reasoning behind this decision. For example for-fee SIRTs will not list their SIRT to report incidents so that they can be acted upon. It must be emphasised that without active participation (especially reporting) fromclients the effectiveness of the servicesbut declare that they depend on can be greatly diminished. Asprovide a minimum, clients needservice to knowa large group of customers that they should report security incidents, and know how and where they should report them. Individual users (i.e. those whoare not partkept confidential because of the clients' contract. Constituencies might overlap, as when an organisation whichISP provides a SIRT for its members) who observe a security incident should ask their Internet Service Provider for details of the most suitable SIRT to report it to. Appendix B (below) provides some pointersSIRT, but delivers services to SIRTscustomer sites which were known when thisalso have SIRTs. The Authority section of the document was published. 6 Appendix A: Note on procedure definitions Policies and statements(see below) should make such relationships clear. 3.3.3 Sponsoring Organization / Affiliation The sponsoring organization, which authorizes the actions of services inthe template have toSIRT, should be implemented as procedures, but descriptions of those procedures should not be included ingiven next. Knowing this will help the template. The following notes are intended to assist those seeking to form orusers to improve their SIRTs. * External + identify other response teams + define supported clients: - by domain, through registration system, other means + establish secure communication practices - use of network, cell-phones, etc + define information that a client site must/should provide - useunderstand the background and setup of reporting forms * Internal + securethe team's infrastructure + protectSIRT. It is vital information servers + protect sensitive data + define expiry of sensitive data + define disposal practicefor sensitive data + establish methodsbuilding up trust between a constituent and a SIRT. Expectations for gatheringSecurity Incident Response 26 March 97 3.3.4 Authority Based on the relationship between team and keeping statistics + establish 'knowledge base' of lessons learnedconstituency this section will be very different from past incidents + create practical implementations of disclosure policies + document explicit practices for disclosureone team to another. While an organizational SIRT will be given its authority by the Press The Site Security Handbook ismanagement, a first resource to consultcommunity SIRT will be supported and chosen by the community, usually in securinga team's infrastructure. SIRT-specific security measuresadvisory role. SIRTs may evolve later. 7 Appendix B: Known Incident Response Teams FIRST isnot have authority to intervene in the Forumoperation of Incident Response and Security Teams. Information about FIRST can be found viaall the systems within their World Wide Web home page: http://www.first.org/first This page contains pointers to 'Team Contact Information' forperimeter. They should identify the scope of their control as distinct from the perimeter of their constituency; if other SIRTs who are FIRST members,operate hierarchically within their perimeter, these should be identified and to 'Teams with WWW Servers.' 8 Appendix C: Example:addressed here. A disclosure of a 'filled-in' template <HTML> <HEAD> <TITLE>SIRT Templateteam's authority may expose it to claims of liability. Every team should seek legal advice on these matters. (See section 3.7 for XYZ SIRT</TITLE> </HEAD> <P> Note: no digital signature is currentlymore on liability.) 3.4 Policies 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 opportunity for more detailed definition and to address non-incident related topics. The level of support might change, depending on factors like workload or completeness of 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 each reported incident. 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 is regarded as an optional pro-active service policy rather than a core service requirement for a SIRT. Expectations for Security Incident Response 26 March 97 3.4.2 Co-operation and Interaction with other Organizations This section should make explicit which related groups with which the SIRT routinely interacts with. Such interactions are not related to the Security Incident Response provided, but are used 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 section is to give the constituency a basic understanding what kind of interactions are established and what their purpose is. Examples of these are listed below. Incident Response Teams: A SIRT will often need to interact with other SIRTs. For example a SIRT 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 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, to analyse the technical problem or to test provided solutions. Law-enforcement agencies: These include the police and other investigative agencies. SIRTs and users of the template should be sensitive to local laws and regulations, which may vary considerably in different countries. A SIRT might advise on technical details of attacks or seek advice on the legal implications of an incident. Local laws and regulations may include specific reporting and confidentiality requirements. Press: A SIRT may be approached by the Press for information and comment from time to time. This is discussed in more detail immediately below. Other: This might include research activities or the relation to the sponsoring organization. Expectations for Security Incident Response 26 March 97 3.4.3 Reporting and Disclosure The default status of any and all security-related information which a team receives will usually be 'confidential,' but rigid adherence to this makes the team to appear as a 'black hole.' Its template should define what information it will report or disclose, to whom, and when. Different teams are likely to be subject to different legal restraints requiring or limiting disclosure, especially if they work in different jurisdictions. In addition, they may have reporting requirements imposed by their sponsoring organization. Each team's template should specify any such restraints, both to clarify users' expectations and to inform other teams. 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 addressed. 'Disclosure' includes (but is maybe not limited to): - Reporting incidents within the constituency to other teams. By this, site related information might become public knowledge, accessible for everybody, especially the press. - Handling incidents occurring within the constituency, but reported from outside it. - Reporting observations from within the constituency indicating suspected or confirmed incidents outside it. - Acting on reports of incidents occurring outside the constituency. - Passing information about vulnerabilities to vendors, to Partner SIRTs or directly to affected sites lying within or outside the constituency. - Feed-back to parties reporting incidents or vulnerabilities. - The provision of contact information relating to members of the constituency, members of other constituencies, other SIRTs or law-enforcement agencies. An explicit policy concerning disclosure to the Press can be helpful, particularly in clarifying the expectations of a SIRT's constituency. The press policy will have to clarify the same topics as above more specifically, as the constituency will usually be very sensitive Expectations for Security Incident Response 26 March 97 towards press contacts. The reporting and disclosure policy should make clear who will be the recipients of a SIRT's report in each circumstance. It should also note whether the team will expect to deal through another SIRT or directly with a member of another constituency over matters directly involving that member. A team will normally collect statistics. If such information are distributed, the template's reporting and disclosure policy should say so, and should list methods 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 between a SIRT and its constituents. The template should include public keys or pointers to them, including key fingerprints, together with guidelines on how to use this information to check authenticity and how to deal with corrupted information (for example where to report this fact to). At the moment it is recommended 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 needs and the needs of its constituents. Note however, that SIRTs and users should be sensitive to local 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 digitally 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 as an agreed password or phrase. 3.4.5 Point of Customer Contacts More detailed contact information might 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 (like addresses for mailing list requests) these should be explained here. Expectations for Security Incident Response 26 March 97 3.5 Services Services provided by each SIRT can be differentiated by whether they relate to the main task, which is incident response, or are provided in addition (optional in regard to the definition of a SIRT). Incident response, which usually includes: - Verification Help with the verification of incidents, as well as their scope. - Technical Assistance This may include analysis of compromised systems. - Eradication Elimination of the effects of a security incident. - Recovery Aid in restoring affected systems and services to their status before the security incident. - Notification of other involved parties Additional or optional services, which might include: - Information provision This might include an archive of known vulnerabilities, patches or resolutions of past problems. - Security Tools - Education and training - Product evaluation - Site security auditing and consulting 3.6 Incident 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 team and therefore come well prepared. The team gets all the necessary information at once with the first report and can proceed efficiently. Expectations for Security Incident Response 26 March 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 of the team. The exact pointers to them should be given in the document, together with statements about appropriate use and guidelines, for when and how 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 is the Incident Reporting Form provided by the CERT Coordination Center: - ftp://info.cert.org/incident_reporting_form 3.7 Disclaimers Although the document does not constitute a contract, liability might conceivably result from its descriptions of services and purposes. The inclusion of a disclaimer at the end of the template is therefore recommended and should warn the user about possible limitations. It should be noted that some forms of reporting or disclosure relating to specific incidents or vulnerabilities can also imply liability, and SIRTs should consider the inclusion of disclaimers in such material. In situations where the original version of a document must be translated into another language, the translation should carry a disclaimer and a pointer to the original. For example: Although we tried to carefully translate the original document from German into English, we can not be certain that both documents express the same thoughts in the same level of detail and correctness. In all cases, where there is a difference between both versions, the German version is the binding version. The use of and protection by disclaimers is effected by local laws and regulations. Therefore each SIRT should be sensitive and if in doubt should check the disclaimer with a lawyer. Expectations for Security Incident Response 26 March 97 4 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 sources, for example to the [RFC 1983]. Constituency: Implicit in the purpose of a Security Incident Response Team is the existence of a constituency. This is the group of users, sites, networks or organizations served by the team. The team must be recognized by its constituency to be effective. Security Incident: For the purpose of this document this term is synonym to Computer Security Incident: Any adverse event which compromises some aspect of computer or network security. The definition of an incident may vary between organizations, but at least 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. - Damage of systems. These are very general categories. For instance the replacement 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, might be regarded as an Incident. Within the definition of an incident the word 'compromised' is used. Sometimes an administrator may only 'suspect' an incident. During the response it must be established whether or not an incident really occurred. Security Incident Response Team: Based on two of the definitions given above, a SIRT is a team that coordinates and supports the response to security incidents that involve sites within a defined constituency. Expectations for Security Incident Response 26 March 97 In order to be considered a SIRT, a team must: - Provide a (secure) channel for receiving reports about suspected incidents. - Provide assistance to members of its constituency in handling these incidents. - Disseminate incident-related information to its constituency and to other involved parties. Note that we are not referring here to police or other law enforcement bodies which may investigate computer-related crime. SIRT members, indeed, should not need to have any powers beyond those of ordinary citizens. Vendor: A 'vendor' is any entity that produces networking or computing technology, and is responsible for the technical content of that technology. Examples of 'technology' include hardware (desktop computers, routers, switches, etc.), and software (operating systems, mail forwarding systems, etc.). Note that the supplier of a technology is not necessarily the 'vendor' of that technology. As an example, an Internet Services Provider (ISP) might supply routers to each of its customers, but the 'vendor' is the manufacturer, being the entity responsible for the technical content of the router, rather than the ISP. Vulnerability: A 'vulnerability' is a characteristic of a piece of technology which can be exploited to perpetrate 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 a vulnerability. 5 Appendix B: Related Material Important issues in responding to security 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 to the avoidance of 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: Expectations for Security Incident Response 26 March 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 in the Netherlands). - For readers interested in the operation of FIRST (Forum of Incident Response and Security Teams) more information 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 of available material, documents and files about the operation of SIRTs with links to many of the referenced. - ftp://info.cert.org/incident_reporting_form This Incident Reporting Form is provided by the CERT Coordination Center to gather incident information and 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. Most of the major and long established teams (the first SIRT was founded in 1988) are nowadays member of FIRST, the worldwide Forum of Incident Response and Security Teams. Actually more than 55 teams are members (1 in Australia, 13 in Europe, all others from America). Information about FIRST can be found: - http://www.first.org/ Expectations for Security Incident Response 26 March 97 The actual list of members is available also, with the relevant contact information and some additional information provided by the single teams: - http://www.first.org/team-info/ For SIRTs which want to become members of this forum (please note, that a team needs a sponsor - a team already full member 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 want to become member of FIRST. Many of the European teams, regardless if they are members 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 for the "right" contact. Expectations for Security Incident Response 26 March 97 7 Appendix D: Outline for SIRT Template This outline summarizes the issues addressed in this document in a logical structure suitable to communicate the policies and procedures for the interaction with SIRTs easily to the team's constituency. A 'filled-in' example of this template is given as Appendix E. 1. Contact Information 1.1 Name of 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 Date 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 Authority 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 Below is an example, a filled-in template for a SIRT called XYZ 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 by XYZ Enterprises. <P> <XMP>1. Contact Information ----------------------1.1 Name of 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, and GMT-0400 from April to October) 1.4 Telephone Number +1 234 567 7890 (ask for 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 Keys and Other Encryption Information Encryption is not currently available, but we plan to install PGP as soon as possible. Our PGP public key will appear here as soon as it is available. Expectations for Security Incident Response 26 March 97 1.9 Team Members >> Jane Doe of Computing Services is the XYZ-SIRT coordinator. Other team members will be listed here once their participation is confirmed. 2. Template Updates ------------------- 2.1 Date of Last Update Please see the bottom of this Web page for this information. 2.2 Locations where this Template May Be Found This template is available from the XYZ SIRT WWW site; its URL is http://www.xyz.org/THIS-INFORMATION-NOT-YET-AVAILABLE >> The template will be signed with the XYZ-SIRT's private PGP >> key. (WHAT TO DO? Sign just the template? The whole Web >> page? Try ASCII armor? Or have the signature separate?) There are no plans for the automatic distribution of fresh copies of this template after updates; please make sure that you are using the latest version by checking our Web site. 3. Charter ---------- 3.1 Mission Statement The purpose of the XYZ-SIRT is, first, to assist members of XYZ community in implementing proactive measures to reduce the risks of computer security incidents, and second, to assist XYZ community in responding to such incidents when they occur. 3.2 Constituency The XYZ-SIRT's contituency 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 Authority The XYZ-SIRT operates under the auspices of, and with authority delegated by, the Department of Computing Services of XYZ Enterprises. The Department in turn receives its authority from the formal ruling bodies of XYZ, as set out in the "Policy on Computing Facilities". The XYZ-SIRT has no direct authority over systems at XYZ Enterprises at large. However, it benefits from the direct authority of Computing Services with respect to systems managed by this Department. Also, becauseJane Doe of Computing Services manages the XYZ Enterprises Network, andis responsible for connectivity to it, the Department has indirect authority over systems in other departments, inasmuch asthe Department can order such systems toXYZ-SIRT coordinator. Other team members will be disconnected fromlisted here once their participation is confirmed. 2. Document Updates 2.1 Date of Last Update Please see the network should circumstances warrant it. The XYZ-SIRT expects to work cooperatively with system administrators and users at XYZ, and, insofar as possible,bottom of this Web page for this information. 2.2 Distribution List for Notifications Notifications of updates are submitted to avoid authoritarian relationships. However,our mailing list <email@example.com>. (Subscription request should circumstances warrant it, the XYZ-SIRT will appeal to Computing Servicesgo to exert its authority, direct or indirect, as necessary. 4. Policies ----------- 4.1 Types of Incidents The XYZ-SIRT<firstname.lastname@example.org>.) 2.3 Locations where this Document May Be Found This template is authorized to address all types of computer security incidents which occur, or risk occurring, atavailable from the XYZ Enterprises. 4.2 Level of SupportSIRT WWW site; its URL is http://www.sirt.xyz.org/op_frame.html The level of support given by XYZ-SIRTtemplate will vary depending onbe signed with the type and severityXYZ-SIRT's PGP key. 3. Charter 3.1 Mission Statement The purpose of the incident or issue, the typeXYZ-SIRT is, first, to assist members of consituent,XYZ community in implementing proactive measures to reduce the sizerisks of the user community affected,computer security incidents, and the XYZ-SIRT's resources at the time. No direct support will be givensecond, to end users; they are expectedassist XYZ community in responding to contact their system administrator, network administrator, or department head for assistance.such incidents when they occur. 3.2 Constituency The XYZ-SIRT will support the latter people. WhileXYZ-SIRT's constituency is the XYZ-SIRT understands that there exists great variationXYZ SIRT community, as defined in the levelcontext of system administrator expertise at XYZ, and whilethe "XYZ Policy on Computing Facilities". 3.3 Sponsors and/or Affiliation None. 3.4 Authority The XYZ-SIRT will endeavour to present information and assistance at a level appropriate to each person,operates under the XYZ-SIRT cannot train system administrators,auspices of, and it cannot perform system maintenance on their behalf. In most cases,with authority delegated by, the XYZ-SIRT will provide pointers toDepartment of Computing Services of XYZ Enterprises. The Department in turn receives its authority from the information needed to implement appropriate measures. 4.3 Disclosureformal ruling bodies of Information >> &&&&&&&&&&&&&&&&&&&& >> Difficult section; not done yet. Also,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 systems at XYZ Enterprises at large. However, it overlaps heavily >> withbenefits from the section below; I'm not suredirect authority of the best wayComputing Services with respect to >> separate them. Questions not yet addressed: - reporting incidents withinsystems managed by this Department. Also, because Computing Services manages the constituencyXYZ Enterprises Network, and is responsible for connectivity to it, the Department has indirect authority over systems in other teams; - handling incidents occurring withindepartments, inasmuch as the constituency, but reported from outside it. - reporting observationsDepartment can order such systems to be disconnected from within the constituency indicating suspected or confirmed incidents outside it; - acting on reports of incidents occurring outsidethe constituency; - passing information about vulnerabilities to vendors,network should circumstances warrant it. The XYZ-SIRT expects to Partner SIRTs or directlywork cooperatively with system administrators and users at XYZ, and, insofar as possible, to affected sites lying within or outsideavoid authoritarian relationships. However, should circumstances warrant it, the constituency; - feed-backXYZ-SIRT will appeal to parties reporting incidentsComputing Services to exert its authority, direct or vulnerabilities; - the provisionindirect, as necessary. 4. Policies 4.1 Types of contact information relating to membersIncidents and Level of the constituency, membersSupport The XYZ-SIRT is authorized to address all types of other constituencies, other SIRTscomputer security incidents which occur, or law-enforcement agencies. Food for thought: Types of info: - Contact info for constituents. - Technical info about a vulnerability. - Technical info aboutrisk occurring, at XYZ facilities. - Information about incidents: - Statistical summaries - Admission of incidentEnterprises. The level of certainsupport given by XYZ-SIRT will vary depending on the type - Admission of root compromise - Admission of packet sniffing attack - Admission that user accounts were compromised - Descriptionand severity of the incident - Identity of affected systems - Identity of affected people - Identityor issue, the type of perpetrator Recipientsconsituent, the size of info: - XYZ management - Computing Services management - Affected sysadmin at XYZ - Affected sysadmin (or SIRT) at another site - Affected user(s) at XYZ - All sysadmins potentially concerned (potentially vulnerable) at XYZ - All sysadminsthe user community affected, and the XYZ-SIRT's resources at XYZ - All users potentially concernedthe time. No direct support will be given to end users; they are expected to contact their system administrator, network administrator, or department head for assistance. The XYZ-SIRT will support the latter people. While the XYZ-SIRT understands that there exists great variation in the level of system administrator expertise at XYZ (informationXYZ, and while the XYZ-SIRT will leakendeavor to general public) - All userspresent information and assistance at XYZ (ditto) - Computer security community - Peer sysadminsa level appropriate to each person, the XYZ-SIRT cannot train system administrators, and SIRTs - Vendors - Law enforcement 4.4it cannot perform system maintenance on their behalf. In most cases, the XYZ-SIRT will provide pointers to the information needed to implement appropriate measures. Expectations for Security Incident Response 26 March 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 provincial or national SIRTs be constituted, XYZ-SIRT will explore the possibility of peer relationships with them. The possibility of peer relationships with close neighboursneighbors will also be explored; unofficial cooperative climates already exist between XYZ and several nearby universities and large corporations. While there are no legal requirements that XYZ-SIRT provide enyany information to any body outside XYZ (aside from law enforcement agencies), XYZ-SIRT will provide such information when the good of the community justifies it. However, unless identifying information is needed to track an incident in progress, such information will be stripped from the report (unless the affected department gives its permission that the real information be used). - Vendors: The XYZ-SIRT wishes to encourage vendors of all kinds of networking and computer equipment, software, and services to improve the security of their products. In aid of this, a vulnerability discovered in such a product will be reported to its vendor, along with all technical details needed to identify and fix the problem. Identifying details will not be given to the vendor without the permission of the affected parties. - Law enforcement: >>XYZ has its 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 administrators at XYZ and the local police; interest has been expressed by all parties in formalisingformalizing these relationships. Any progress made in that area will be reflected in this section. In the meantime, authorized and unauthorized users of the XYZ Computing Facilities should be aware that the XYZ-SIRT will cooperate fully with law enforcement agencies in detecting, reporting, documenting, and prosecuting violations of the law; users concerned about confidentiality are referred to the XYZ "Policy on Computing Facilities". Expectations for Security Incident Response 26 March 97 - The Press: The XYZ-SIRT will not interectinteract directly with the Press. If necessary, information will be provided to the XYZ Public Relations Department, and to the Customer Relations group of the Computing Services Department. All queries will be referred to these two bodies. - The XYZ SIRT community: Details of incidents may be released to Computing Services management, XYZ management, or the Computer Resources Committee; these bodies will be charged with maintaining the confidentiality of the information. General report of incidents, summaries of multiple incidents, and statistics may be made available to the general XYZ community, with identifying information stripped (except where permission has been obtained from the affected parties). There is no obligation on the part of the XYZ-SIRT to report incidents to the community, though it may choose to do so; in particular, it is likely that the XYZ-SIRT will inform all affected parties of the ways in which they were affected. - The public at large: In general, no particular efforts will be made to communicate with the public at large, though the XYZ-SIRT recognizes that, for all intents and purposes, information made available to the XYZ community is in effect made available to the community at large, and will tailor the information in consequence. - The computer security community: While members of XYZ-SIRT 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-SIRT experience will be disguised to avoid identifying the affected parties. In the paragraphs above, the "affected parties" refers to the legitimate owners, operators, and users of the relevant computing facilities. It does not refer to unauthorized users, including otherwise authorized users making unauthorized usage of a facility; such intruders may have no expectation of confidentiality from the XYZ-SIRT. They may or may not have legal rights to confidentiality; such rights will of course be respected where they exist. 4.54.3 Disclosure of Information The following types of information will be stored and handled by XYZ-SIRT: - Contact info for constituents. - Technical info about 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 - Admission that user accounts were compromised - Description of incident - Identity of affected systems - Identity of affected people - Identity of perpetrator Recipients 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 (information will leak to general public) - All users at XYZ (ditto) - Computer security community - Peer sysadmins and SIRTs - Vendors - Law enforcement 4.4 Communication and Authentication In view of the types of information that the XYZ-SIRT 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. Where it is necessary to establish trust, for example before relying on information given to the XYZ-SIRT, 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, and with known neighbourneighbor 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.64.5 Points of Customer Contact The preferred method for contacting the XYZ-SIRT will be e-mail. If this 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 97 5. Services -----------5.1 Incident Response >> &&&&&&&&&&&&&&&&&&&&&&&7 >> This section requires a lotXYZ-SIRT will help users and administrators to handle the technical and organizational aspects of incidents. By that, it will provide and facilitate: - to understand the extend of thought.the incident - ... 5.2 Proactive Activities The XYZ-SIRT will coordinate and maintain the following services to the extent possible depending on its resources: - Information services - List of departmental security contacts, administrative and technical. - Mailing lists to inform security contacts of new information relevant to their computing environments. - Repository of vendor-provided and other security-related patches for various operating systems. - Repository of security tools for use by sysadmins. - "Clipping" service for various existing resources, such as major mailing lists and newsgroups; important issues of relevance to operating environments in use at the XYZ will be reported and archived.newsgroups. - Auditing services - Central file integrity checking service for Unix machines. - "Tiger teams". -Security level assignments; machines at XYZ will be audited and assigned a security level: not all machines require or can attain the same level of security, but it is important to know which ones are reasonably secure and which are not.level. - Archiving services - Central logging services for Unix machines. -Records of security incidents handled. 6. Incident Reporting Forms --------------------------- >> &&&&&&&& Not done yet; I'll probably use an existing >> one from somewhere initially. 7. Disclaimers -------------- >> -- resp. for technical disclosures (bugtraq) etc.? >> -- resp. for resultsThere are no own forms developed yet for XYZ-SIRT advice? >> &&&&&&&&&&&&&&&&&&&7 >> WILL NEED XYZ LEGAL COUNSEL ON THIS? 8. Additional Information -------------------------reporting incidents to XYZ-SIRT. If possible, please make us of the Incident Reporting Form of the CERT Coordination Center (Pittsburgh, PA). The actual version of this template published in this RFCis available from: ftp://info.cert.org/incident_reporting_form 7. Disclaimers While every precaution will undoubtedlybe out of date bytaken in the time you see it; it is intended as an example only. Please pick up a fresh copypreparation of information, notifications and alerts, XYZ-SIRT assumes no responsibility for errors or omissions, or for damages resulting from our Web site if you actually need information about XYZ-SIRT. Historythe use of this template: 1996/07/29 Jane Doe, version 1.0 THIS VERSION HAS ABSOLUTELY NO MANAGEMENT APPROVAL! </XMP> </BODY> </HTML>the information contained within. Expectations for Security Incident Response 26 March 97 9 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. 10 Security Considerations This document discusses issues of the operation of Security Incident Response Teams, and the teams interactions with their constituency. It is therefore not directly concerned with the security of protocolsprotocols, applications or network systems themselves. It is not even concerned about the response and reaction to security incidents. Nonetheless, it is vital that SIRTs establish secure communication channels with other teams, and with members of their constituency. They must also secure their own systems and infrastructure. 10 Author's Addressinfrastructure, to protect the interests of their constituency and to maintain the confidentiality of the identity of victims and reporters of security incidents. 11 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, 1997.