idnits 2.17.1 draft-ietf-grip-framework-irt-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 128 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1244 (Obsoleted by RFC 2196) ** Downref: Normative reference to an Informational RFC: RFC 1983 Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 3 Valid for six months Erik Guttman 4 Sun Microsystems 5 July 1997 7 Expectations for Security Incident Response 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. This Internet Draft is a 17 product of the GRIP Working Group of the IETF. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a 23 'working draft' or 'work in progress.' 25 To learn the current status of any Internet Draft, please check the 26 '1id-abstracts.txt' listing contained in the Internet Drafts shadow 27 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 The purpose of this document is to express the general Internet 34 community's expectations of Security Incident Response Teams (SIRTs). 35 It is not possible to define a set of requirements that would be 36 appropriate for all teams, but it is possible and helpful to list 37 and describe the general set of topics and issues which are of 38 concern and interest to constituent communities. 40 SIRT constituents have a legitimate need and right to fully 41 understand the policies and procedures of "their" Security Incident 42 Response Team. One way to support this understanding is to supply 43 detailed information which users may consider, in the form of a 44 formal template completed by the SIRT. An outline of such a 45 template and a filled in example are provided. 47 Expectations for Security Incident Response 20 July 97 49 Table of Contents 51 1 Introduction 1 53 2 Scope.............................................................3 54 2.1 Publishing SIRT Policies and Procedures ......................3 55 2.2 Relationships between different SIRTs ........................5 56 2.3 Establishing Secure Communications ...........................5 58 3 Information, Policies and Procedures..............................7 59 3.1 Obtaining the Document........................................8 60 3.2 Contact Information ..........................................9 61 3.3 Charter .....................................................10 62 3.3.1 Mission Statement......................................10 63 3.3.2 Constituency...........................................10 64 3.3.3 Sponsoring Organization / Affiliation..................11 65 3.3.4 Authority..............................................11 66 3.4 Policies ....................................................11 67 3.4.1 Types of Incidents and Level of Support................11 68 3.4.2 Co-operation, Interaction and Disclosure of 69 Information............................................12 70 3.4.3 Communication and Authentication.......................14 71 3.5 Services ....................................................14 72 3.5.1 Incident Response .....................................15 73 3.5.1.1 Incident Triate ...............................15 74 3.5.1.2 Incident Coordination .........................15 75 3.5.1.3 Incident Cure .................................15 76 3.5.2 Proactive Activities ..................................16 77 3.6 Incident Reporting Forms ....................................16 78 3.7 Disclaimers .................................................17 80 Appendix A: Glossary of Terms 17 82 Appendix B: Related Material 19 84 Appendix C: Known Security Incident Response Teams 20 86 Appendix D: Outline for SIRT Template 21 88 Appendix E: Example - 'filled-in' Template for a SIRT 22 90 4 Acknowlegments 34 92 5 References 34 94 6 Security Considerations 34 96 7 Authors' Addresses 35 98 Expectations for Security Incident Response 15 April 97 100 1 Introduction 102 The GRIP Working Group was formed to create a document that describes 103 the community's expectations of security incident response teams 104 (SIRTs). Although the need for such a document originated in the 105 general Internet community, the expectations expressed should also 106 closely match those of more restricted communities. 108 In the past there have been misunderstandings regarding what to 109 expect from SIRTs. The goal of this document is to provide a 110 framework for presenting the important subjects (related to incident 111 response) that are of concern to the community. 113 Before continuing, it is important to clearly understand what is 114 meant by the term "Security Incident Response Team." For the 115 purposes of this document, a SIRT is a team that performs, 116 coordinates, and supports the response to security incidents that 117 involve sites within a defined constituency (see Appendix A for a 118 more complete definition). Any group calling itself a SIRT for a 119 specific constituency must therefore react to reported security 120 incidents, and to threats to "their" constituency in ways which the 121 specific community agrees to be in its general interest. 123 Since it is vital that each member of a constituent community be 124 able to understand what is reasonable to expect of their team, a SIRT 125 should make it clear who belongs to their constituency and define the 126 services the team offers to the community. Additionally, each SIRT 127 should publish its policies and operating procedures. Similarly, 128 these same constituents need to know what is expected of them in 129 order for them to receive the services of their team. This requires 130 that the team also publish how and where to report incidents. 132 This document details a template which will be used by SIRTs to 133 communicate this information to their constituents. The constituents 134 should certainly expect a SIRT to provide the services they describe 135 in the completed template. 137 It must be emphasised that without active participation from users, 138 the effectiveness of the SIRT's services can be greatly diminished. 139 This is particularly the case with reporting. At a minimum, users 140 need to know that they should report security incidents, and know how 141 and to where they should report them. 143 Many computer security incidents originate outside local community 144 boundaries and affect inside sites, others originate inside the local 145 community and affect hosts or users on the outside. Often, 146 therefore, the handling of security incidents will involve multiple 147 sites and potentially multiple SIRTs. Resolving these incidents will 149 Expectations for Security Incident Response 15 April 97 151 require cooperation between individual sites and SIRTs, and between 152 SIRTs. 154 Constituent communities need to know exactly how their SIRT will be 155 working with other SIRTs and organizations outside their 156 constituency, and what information will be shared. 158 The rest of this document describes the set of topics and issues that 159 SIRTs need to elaborate for their constituents. However, there is no 160 attempt to specify the "correct" answer to any one topic area. 161 Rather, each topic is discussed in terms of what that topic means. 162 For example, five types of policy statements are listed (representing 163 those policies of interest to the community), but the content of any 164 one of them will necessarily be specific to a given team. 166 Chapter two provides an overview of three major areas: the 167 publishing of information by a response team, the definition of the 168 response team's relationship to other response teams, and the need 169 for secure communications. Chapter three describes in detail all the 170 types of information that the community needs to know about their 171 response team. 173 For ease of use by the community, these topics are condensed into an 174 outline template found in Appendix D. This template can be used 175 by constituents to elicit information from their SIRT. 177 It is the working group's sincere hope that through clarification 178 of the topics in this document, understanding between the community 179 and its SIRTs will be increased. 181 2 Scope 183 The interactions between an incident response team and its 184 constituent community response team require first that the community 185 understand the policies and procedures of the response team. Second, 186 since many response teams collaborate to handle incidents, the 187 community must also understand the relationship between their 188 response team and other teams. Finally, many interactions will take 189 advantage of existing public infrastructures, so the community needs 190 to know how those communications will be protected. Each of these 191 subjects will be described in more detail in the following three 192 sections. 194 2.1 Publishing SIRT Policies and Procedures 196 Each user who has access to a Security Incident Response Team should 197 know as much as possible about the services of and interactions with 198 this team long before he or she actually needs them. 200 Expectations for Security Incident Response 15 April 97 202 A clear statement of the policies and procedures of a SIRT helps the 203 constituent understand how best to report incidents and what support 204 to expect afterwards. Will the SIRT assist in resolving the 205 incident? Will it provide help in avoiding incidents in the 206 future? Clear expectations, particularly of the limitations of the 207 services provided by a SIRT, will make interaction with it more 208 efficient and effective. 210 There are different kinds of response teams: some have very broad 211 constituencies (e.g., CERT Coordination Center and the Internet), 212 others have more bounded constituencies (e.g., DFN-CERT, CIAC), 213 and still others have very restricted constituencies (e.g., 214 commercial response teams, corporate response teams). Regardless 215 of the type of response team, the constituency supported by it 216 must be knowledgeable about the team's policies and procedures. 217 Therefore, it is mandatory that response teams publish such 218 information to their constituency. 220 A SIRT should communicate all necessary information about its 221 policies and services in a form suitable to the needs of its 222 constituency. It is important to understand that not all policies 223 and procedures need be publicly available. For example, it is not 224 necessary to understand the internal operation of a team in order to 225 interact with it, as when reporting an incident or receiving guidance 226 on how to analyze or secure one's systems. 228 In the past, some teams supplied a kind of Operational Framework, 229 others provided a Frequently Asked Questions list (FAQ), while still 230 others wrote papers for distribution at user conferences or sent 231 newsletters. 233 We recommend that each SIRT publish its guidelines and procedures on 234 its own information server (e.g. a World Wide Web server). This 235 would allow constituents to easily access it, though the problem 236 remains of how a constituent can find "his" or "her" team; people 237 within the constituency have to discover that there is a SIRT "at 238 their disposal." 240 It is foreseen that completed SIRT templates will soon become 241 searchable by modern search engines, which will aid in distributing 242 information about the existence of SIRTs and basic information 243 required to approach them. 245 It would be very useful to have a central repository containing all 246 the completed SIRT templates. No such repository exists at the time 247 of writing, though this might change in the future. 249 Regardless of the source from which the information is retrieved, 250 the user of the template must check its authenticity. It is highly 251 recommended that such vital documents be protected by digital 252 signatures. These will allow the user to verify that the template 254 Expectations for Security Incident Response 15 April 97 256 was indeed published by the SIRT and that it has not been tampered 257 with. This document assumes the reader is familiar with the proper 258 use of digital signatures to determine whether a document is 259 authentic. 261 2.2 Relationships between different SIRTs 263 In some cases a SIRT may be able to operate effectively on its own 264 and in close cooperation with its constituency. But with today's 265 international networks it is much more likely that most of the 266 incidents handled by a SIRT will involve parties external to its 267 constituency. Therefore the team will need to interact with other 268 SIRTs and sites outside its constituency. 270 The constituent community should understand the nature and extent of 271 this collaboration, as very sensitive information about individual 272 constituents may be disclosed in the process. 274 Inter-SIRT interactions could include asking other teams for advice, 275 disseminating knowledge of problems, and working cooperatively to 276 resolve a security incident affecting one or more of the SIRTs' 277 constituencies. 279 In establishing relationships to support such interactions, SIRTs 280 must decide what kinds of agreements can exist between them so as to 281 share yet safeguard information, whether this relationship can be 282 disclosed, and if so to whom. 284 Note that there is a difference between a peering agreement, where 285 the SIRTs involved agree to work together and share information, and 286 simple co-operation, where a SIRT (or any other organization) simply 287 contacts another SIRT and asks for help or advice. 289 Although the establishment of such relationships is very important 290 and affects the ability of a SIRT to support its constituency, it is 291 up to the teams involved to decide about the details. It is beyond 292 the scope of this document to make recommendations for this process. 293 However, the same set of information used to set expectations for a 294 user community regarding sharing of information will help other 295 parties to understand the objectives and services of a specific 296 SIRT, supporting a first contact. 298 2.3 Establishing Secure Communications 300 Once one party has decided to share information with another party, 301 or two parties have agreed to share information or work together - as 302 required for the coordination of security incident response - all 303 parties involved need secure communications channels. (In this 304 context, "secure" refers to the protected transmission of information 306 Expectations for Security Incident Response 15 April 97 308 shared between different parties, and not to the appropriate use of 309 the information by the parties.) 311 The goals of secure communication are: 313 - Confidentiality: 314 Can somebody else access the content of the communication? 316 - Integrity: 317 Can somebody else manipulate the content of the communication? 319 - Authenticity: 320 Am I communicating with the "right" person? 322 It is very easy to send forged e-mail, and not hard to establish a 323 (false) identity by telephone. Cryptographic techniques, for 324 example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) 325 can provide effective ways of securing e-mail. With the correct 326 equipment it is also possible to secure telephone communication. 327 But before using such mechanisms, both parties need the "right" 328 infrastructure, which is to say preparation in advance. The 329 most important preparation is ensuring the authenticity of the 330 cryptographic keys used in secure communication: 332 - Public keys (for techniques like PGP and PEM): 333 Because they are accessible through the Internet, public keys must 334 be authenticated before use. While PGP relies on a "Web of Trust" 335 (where users sign the keys of other users), PEM relies on a 336 hierarchy (where certification authorities sign the keys of users). 338 - Secret keys (for techniques like DES and PGP/conventional 339 encryption): Because these must be known to both sender and 340 receiver, secret keys must be exchanged before the communication 341 via a secure channel. 343 Communication is critical to all aspects of incident response. A 344 team can best support the use of the above-mentioned techniques by 345 gathering all relevant information, in a consistent way. Specific 346 requirements (such as calling a specific number to check the 347 authenticity of keys) should be clear from the start. SIRT templates 348 provide a standardized vehicle for delivering this information. 350 It is beyond the scope of this document to address the technical 351 and administrative problems of secure communications. The point is 352 that response teams must support and use a method to secure the 353 communications between themselves and their constituents (or other 354 response teams). Whatever the mechanism is, the level of protection 355 it provides must be acceptable to the constituent community. 357 Expectations for Security Incident Response 15 April 97 359 3 Information, Policies and Procedures 361 In chapter 2 it was mentioned that the policies and procedures of a 362 response team need to be published to their constituent community. 363 In this chapter we will list all the types of information that the 364 community needs to receive from its response team. How this 365 information is communicated to a community will differ from team to 366 team, as will the specific information content. The intent here is 367 to clearly describe the various kinds of information that a 368 constituent community expects from its response team. 370 To make it easier to understand the issues and topics relevant to the 371 interaction of constituents with "their" SIRT, we suggest that a SIRT 372 publish all information, policies, and procedures addressing its 373 constituency as a document, following the template given in Appendix 374 D. The template structure arranges items, making it easy to supply 375 specific information; in Appendix E we provide an example of a 376 filled-out template for the fictitious XYZ University. While 377 no recommendations are made as to what a SIRT should adopt for its 378 policy or procedures, different possibilities are outlined to give 379 some examples. The most important thing is that a SIRT have a policy 380 and that that those who interact with the SIRT be able to obtain and 381 understand it. 383 As always, not every aspect for every environment and/or team can 384 be covered. This outline should be seen as a suggestion. Each team 385 should feel free to include whatever they think is necessary to 386 support its constituency. 388 Expectations for Security Incident Response 15 April 97 390 3.1 Obtaining the Document 392 Details of a SIRT change with time, so the completed template must 393 indicate when it was last changed. Additionally, information should 394 be provided concerning how to find out about future updates. Without 395 this, it is inevitable that misunderstandings and misconceptions will 396 arise over time; an outdated document can do more harm than good. 398 - Date of last update This should be sufficient to allow 399 anyone interested to evaluate the 400 currency of the template. 402 - Distribution list Mailing lists are a convenient 403 mechanism to distribute up-to-date 404 information to a large number of 405 users. A team can decide to use its 406 own or an already existing list to 407 notify users whenever the document 408 changes. The list might normally 409 cover the constituency and any other 410 groups the SIRT has frequent 411 interactions with. 413 Digital signatures should be used 414 for update messages sent by a SIRT. 416 - Location of the document The location where a current version 417 of the document is accessible 418 through a team's online information 419 services. Constituents can then 420 easily learn more about the team and 421 check for recent updates. 423 This online version should also be 424 accompanied by a digital signature. 426 Expectations for Security Incident Response 20 July 97 428 3.2 Contact Information 430 Full details of how to contact the SIRT should be listed here, 431 although this might be very different for different teams; for 432 example, some might choose not to publicize the names of their team 433 members. No further clarification is given when the meaning of the 434 item can be assumed. 436 - Name of the SIRT 438 - Mailing Address 440 - Time zone This is useful for coordinating 441 incidents which cross time zones. 443 - Telephone number 445 - Facsimile number 447 - Other telecommunication Some teams might provide secure 448 voice communication (e.g. STU III). 449 - Electronic mail address 451 - Public keys and encryption The use of specific techniques 452 depends on the ability of the 453 communication partners to have 454 access to programs, keys and so on. 455 Relevant information should be 456 given to enable users to determine 457 if and how they can make use of 458 encrypted communication while 459 interacting with the SIRT. 460 - Team members 462 - Operating Hours The operating hours and holiday 463 schedule should be provided here. 464 Is there a 24 hour hotline? 466 - Additional Contact Info Is there any specific customer 467 contact info? 469 More detailed contact information can be provided. This might 470 include different contacts for different services, or might be a 471 list of online information services. If specific procedures for 472 access to some services exist (for example addresses for mailing 473 list requests), these should be explained here. 475 Expectations for Security Incident Response 20 July 97 477 3.3 Charter 479 Every SIRT must have a charter which specifies what it is to do, and 480 the authority under which it will do it. The charter should include 481 at least the following items: 483 - Mission statement 484 - Constituency 485 - Sponsorship / affiliation 486 - Authority 488 3.3.1 Mission Statement 490 The mission statement should focus on the team's core activities, 491 already stated in the definition of a SIRT. In order to be 492 considered a Security Incident Response Team, the team must support 493 the reporting of incidents and support its constituency by dealing 494 with incidents. 496 The goals and purposes of a team are especially important, and 497 require clear, unambiguous definition. 499 3.3.2 Constituency 501 A SIRT's constituency can be determined in any of several ways. For 502 example it could be a company's employees or its paid subscribers, 503 or it could be defined in terms of a technological focus, such as 504 the users of a particular operating system. 506 The definition of the constituency should create a perimeter around 507 the group to whom the team will provide service. The policy section 508 of the document (see below) should explain how requests from outside 509 this perimeter will be handled. 511 If a SIRT decides not to disclose its constituency, it should 512 explain the reasoning behind this decision. For example, for-fee 513 SIRTs will not list their clients but will declare that they provide 514 a service to a large group of customers that are kept confidential 515 because of the clients' contracts. 517 Constituencies might overlap, as when an ISP provides a SIRT which 518 delivers services to customer sites that also have SIRTs. The 519 Authority section of the SIRT's description (see below) should 520 make such relationships clear. 522 Expectations for Security Incident Response 15 April 97 524 3.3.3 Sponsoring Organization / Affiliation 526 The sponsoring organization, which authorizes the actions of the 527 SIRT, should be given next. Knowing this will help the users to 528 understand the background and set-up of the SIRT, and it is vital 529 information for building trust between a constituent and a SIRT. 531 3.3.4 Authority 533 This section will vary greatly from one SIRT to another, based on 534 the relationship between the team and its constituency. While an 535 organizational SIRT will be given its authority by the management 536 of the organization, a community SIRT will be supported and chosen 537 by the community, usually in a advisory role. 539 A SIRT may or may not have the authority to intervene in the 540 operation of all of the systems within its perimeter. It should 541 identify the scope of its control as distinct from the perimeter of 542 its constituency. If other SIRTs operate hierarchically within its 543 perimeter, this should be mentioned here, and the related SIRTs 544 identified. 546 Disclosure of a team's authority may expose it to claims of 547 liability. Every team should seek legal advice on these matters. 548 (See section 3.7 for more on liability.) 550 3.4 Policies 552 It is critical that Incident Response Teams define their policies. 553 The following sections discuss communication of these policies to 554 the constituent community. 556 3.4.1 Types of Incidents and Level of Support 558 The types of incident which the team is able to address, and the 559 level of support which the team will offer when responding to each 560 type of incident, should be summarized here in list form. The 561 Services section (see below) provides the opportunity to give more 562 detailed descriptions, and to address non-incident-related topics. 564 The level of support may change depending on factors such as the 565 team's workload and the completeness of the information available. 566 Such factors should be outlined and their impact should be 567 explained. As a list of known types of incidents will be incomplete 568 with regard to possible or future incidents, a SIRT should also give 569 some background on the "default" support for incident types not 570 otherwise mentioned. 572 Expectations for Security Incident Response 15 April 97 574 The team should state whether it will act on information it receives 575 about vulnerabilities which create opportunities for future 576 incidents. A commitment to act on such information on behalf of its 577 constituency is regarded as an optional proactive service policy 578 rather than a core service requirement for a SIRT. 580 3.4.2 Co-operation, Interaction and Disclosure of Information 582 This section should make explicit which related groups the SIRT 583 routinely interacts with. Such interactions are not necessarily 584 related to the security incident response provided, but are used to 585 facilitate better cooperation on technical topics or services. By 586 no means need details about cooperation agreements be given out; the 587 main objective of this section is to give the constituency a basic 588 understanding of what kind of interactions are established and what 589 their purpose is. 591 The reporting and disclosure policy should make clear who will be 592 the recipients of a SIRT's report in each circumstance. It should 593 also note whether the team will expect to operate through another 594 SIRT or directly with a member of another constituency over matters 595 specifically concerning that member. 597 Important examples of related groups a SIRT will interact with are 598 listed below. 600 Incident Response Teams: 601 A SIRT will often need to interact with other SIRTs. For example 602 a SIRT within a large company may need to report incidents to a 603 national SIRT, and a national SIRT may need to report incidents 604 to national SIRTs in other countries to deal with all sites 605 involved in a large-scale attack. 607 Collaboration between SIRTs may lead to disclosure of 608 information. The following are examples of such disclosure, 609 but are not intended to be an exhaustive list: 611 - Reporting incidents within the constituency to other teams. 612 If this is done, site-related information may become public 613 knowledge, accessible to everyone, in particular the press. 615 - Handling incidents occurring within the constituency, but 616 reported from outside it (which implies that some information 617 has already been disclosed off-site). 619 - Reporting observations from within the constituency indicating 620 suspected or confirmed incidents outside it. 622 - Acting on reports of incidents occurring outside the 623 constituency. 625 Expectations for Security Incident Response 20 July 97 627 - Passing information about vulnerabilities to vendors, to 628 partner SIRTs or directly to affected sites lying within or 629 outside the constituency. 631 - Feedback to parties reporting incidents or vulnerabilities. 633 - The provision of contact information relating to members of 634 the constituency, members of other constituencies, other 635 SIRTs, or law-enforcement agencies. 637 Vendors: 638 Larger vendors have their own SIRTs, but smaller vendors may not. 639 In such cases a SIRT will need to work directly with a vendor to 640 suggest improvements or modifications, to analyse the technical 641 problem or to test provided solutions. 643 Law-enforcement agencies: 644 These include the police and other investigative agencies. SIRTs 645 and users of the template should be sensitive to local laws and 646 regulations, which may vary considerably in different countries. 647 A SIRT might advise on technical details of attacks or seek 648 advice on the legal implications of an incident. Local laws and 649 regulations may include specific reporting and confidentiality 650 requirements. 652 Press: 653 A SIRT may be approached by the press for information and comment 654 from time to time. 656 An explicit policy concerning disclosure to the press can be 657 helpful, particularly in clarifying the expectations of a SIRT's 658 constituency. The press policy will have to clarify the same 659 topics as above more specifically, as the constituency will 660 usually be very sensitive to press contacts. 662 Other: 663 This might include research activities or the relation to the 664 sponsoring organization. 666 The default status of any and all security-related information which 667 a team receives will usually be 'confidential,' but rigid adherence 668 to this makes the team to appear to be an informational 'black 669 hole,' which may reduce the likelihood of the team's obtaining 670 cooperation from clients and from other organizations. The SIRT's 671 template should define what information it will report or disclose, 672 to whom, and when. 674 Different teams are likely to be subject to different legal 675 restraints requiring or limiting disclosure, especially if they work 676 in different jurisdictions. In addition, they may have reporting 677 requirements imposed by their sponsoring organization. Each team's 679 Expectations for Security Incident Response 15 April 97 681 template should specify any such constraints, both to clarify users' 682 expectations and to inform other teams. 684 Conflicts of interest, particularly in commercial matters, may also 685 restrain disclosure by a team; this document does not recommend on 686 how such conflicts should be addressed. 688 A team will normally collect statistics. If statistical information 689 is distributed, the template's reporting and disclosure policy 690 should say so, and should describe how to obtain such statistics. 692 3.4.3 Communication and Authentication 694 Methods of secure and verifiable communication should be established. 695 This is necessary for communication between SIRTs and between a SIRT 696 and its constituents. The template should include public keys or 697 pointers to them, including key fingerprints, together with 698 guidelines on how to use this information to check authenticity and 699 how to deal with corrupted information (for example where to report 700 this fact). 702 At the moment it is recommended that as a minimum every SIRT have 703 (if possible), a PGP key available. A team may also 704 make other mechanisms available (for example PEM, MOSS, S/MIME), 705 according to its needs and the needs of its constituents. Note 706 however, that SIRTs and users should be sensitive to local laws and 707 regulations. Some countries do not allow strong encryption, or 708 enforce specific policies on the use of encryption technology. In 709 addition to encrypting sensitive information whenever possible, 710 correspondence should include digital signatures. (Please note that 711 in most countries, the protection of authenticity by using digital 712 signatures is not affected by existing encryption regulations.) 714 For communication via telephone or facsimile a SIRT may keep secret 715 authentication data for parties with whom they may deal, such as an 716 agreed password or phrase. Obviously, such secret keys must not be 717 published, though their existence may be. 719 3.5 Services 721 Services provided by a SIRT can be roughly divided into two 722 categories: real-time activities directly related to the main task of 723 incident response, and non-real-time proactive activities, supportive 724 of the incident response task. The second category and part of the 725 first category consist of services which are optional in the sense 726 that not all SIRTs will offer them. 728 Expectations for Security Incident Response 15 April 97 730 3.5.1 Incident Response 732 Incident response usually includes assessing incoming reports about 733 incidents ("Incident Triage") and following up on these with other 734 SIRTs, ISPs and sites ("Incident Coordination"). A third range of 735 services, helping a local site to recover from an incident ("Incident 736 Cure"), is comprised of typically optional services, which not all 737 SIRTs will offer. 739 3.5.1.1 Incident Triage 741 Incident triage usually includes: 743 - Report assessment Interpreting incoming incident 744 reports, prioritizing them,and 745 relating them to ongoing incidents 746 and trends. 748 - Verification Help in determining whether an 749 incident has really occurred, and 750 its scope. 752 3.5.1.2 Incident Coordination 754 Incident Coordination normally includes: 756 - Information categorization Categorization the incident related 757 information (logfiles, contact 758 information, etc.) with respect to 759 the information disclosure policy. 761 - Coordination Notification of other involved 762 parties on a need-to-know basis, as 763 per the information disclosure 764 policy. 766 3.5.1.3 Incident Cure 768 Usually additional or optional, incident cure services include: 770 - Technical Assistance This may include analysis of 771 compromised systems. 773 - Eradication Elimination of the cause of a 774 security incident (the vulnerability 775 exploited), and its effects (for 776 example, continuing access to the 777 system by an intruder). 779 Expectations for Security Incident Response 20 July 97 781 - Recovery Aid in restoring affected systems 782 and services to their status before 783 the security incident. 785 3.5.2. Proactive Activities 787 Usually additional or optional, proactive services might include: 789 - Information provision This might include an archive of 790 known vulnerabilities, patches or 791 resolutions of past problems, or 792 advisory mailing lists. 794 - Security Tools This may include tools for auditing 795 a Site's security. 797 - Education and training 799 - Product evaluation 801 - Site security auditing and consulting 803 3.6 Incident Reporting Forms 805 The use of reporting forms makes it simpler for both users and 806 teams to deal with incidents. The constituent can prepare answers to 807 various important questions before he or she actually contacts the 808 team, and can therefore come well prepared. The team gets all the 809 necessary information at once with the first report and can proceed 810 efficiently. 812 Depending on the objectives and services of a particular SIRT, 813 multiple forms may be used, for example a reporting form for a new 814 vulnerability may be very different from the form used for reporting 815 incidents. 817 It is most efficient to provide forms through the online information 818 services of the team. The exact pointers to them should be given in 819 the SIRT description document, together with statements about 820 appropriate use, and guidelines for when and how to use the forms. 821 If separate e-mail addresses are supported for form-based reporting, 822 they should be listed here again. 824 One example of such a form is the Incident Reporting Form provided by 825 the CERT Coordination Center: 827 - ftp://info.cert.org/incident_reporting_form 829 Expectations for Security Incident Response 20 July 97 831 3.7 Disclaimers 833 Although the SIRT description document does not constitute a 834 contract, liability may conceivably result from its descriptions of 835 services and purposes. The inclusion of a disclaimer at the end of 836 the template is therefore recommended and should warn the user about 837 possible limitations. 839 In situations where the original version of a document must be 840 translated into another language, the translation should carry a 841 disclaimer and a pointer to the original. For example: 843 Although we tried to carefully translate the original 844 document from German into English, we can not be certain 845 that both documents express the same thoughts in the same 846 level of detail and correctness. In all cases, where there 847 is a difference between both versions, the German version 848 will prevail. 850 The use of and protection by disclaimers is affected by local laws 851 and regulations, of which each SIRT should be aware. If in doubt 852 the SIRT should check the disclaimer with a lawyer. 854 Appendix A: Glossary of Terms 856 This glossary defines terms used in describing security incidents and 857 Security Incident Response Teams. Only a limited list is included. 858 For more definitions please refer to other sources, for example to 859 the Internet User's Glossary [RFC 1983]. 861 Constituency: 862 Implicit in the purpose of a Security Incident Response Team is 863 the existence of a constituency. This is the group of users, 864 sites, networks or organizations served by the team. The team 865 must be recognized by its constituency in order to be effective. 867 Security Incident: 868 For the purpose of this document, this term is a synonym of 869 Computer Security Incident: any adverse event which compromises 870 some aspect of computer or network security. 872 The definition of an incident may vary between organizations, but 873 at least the following categories are generally applicable: 875 - Loss of confidentiality of information. 876 - Compromise of integrity of information. 877 - Denial of service. 878 - Misuse of service, systems or information. 879 - Damage to systems. 881 Expectations for Security Incident Response 20 July 97 883 These are very general categories. For instance the replacement 884 of a system utility program by a Trojan Horse is an example of 885 'compromise of integrity,' and a successful password attack is an 886 example of 'loss of confidentiality.' Attacks, even if they 887 failed because of proper protection, can be regarded as 888 Incidents. 890 Within the definition of an incident the word 'compromised' is 891 used. Sometimes an administrator may only 'suspect' an incident. 892 During the response it must be established whether or not an 893 incident has really occurred. 895 Security Incident Response Team: 896 Based on two of the definitions given above, a SIRT is a team 897 that coordinates and supports the response to security incidents 898 that involve sites within a defined constituency. 900 In order to be considered a SIRT, a team must: 902 - Provide a (secure) channel for receiving reports about 903 suspected incidents. 904 - Provide assistance to members of its constituency in 905 handling these incidents. 906 - Disseminate incident-related information to its 907 constituency and to other involved parties. 909 Note that we are not referring here to police or other law 910 enforcement bodies which may investigate computer-related crime. 911 SIRT members, indeed, need not have any powers beyond 912 those of ordinary citizens. 914 Vendor: 915 A 'vendor' is any entity that produces networking or computing 916 technology, and is responsible for the technical content of that 917 technology. Examples of 'technology' include hardware (desktop 918 computers, routers, switches, etc.), and software (operating 919 systems, mail forwarding systems, etc.). 921 Note that the supplier of a technology is not necessarily the 922 'vendor' of that technology. As an example, an Internet Service 923 Provider (ISP) might supply routers to each of its customers, but 924 the 'vendor' is the manufacturer, since the manufacturer, rather 925 than the ISP, is the entity responsible for the technical content 926 of the router. 928 Vulnerability: 929 A 'vulnerability' is a characteristic of a piece of technology 930 which can be exploited to perpetrate a security incident. For 931 example, if a program unintentionally allowed ordinary users to 932 execute arbitrary operating system commands in privileged mode, 933 this "feature" would be a vulnerability. 935 Expectations for Security Incident Response 20 July 97 937 Appendix B: Related Material 939 Important issues in responding to security incidents on a site level 940 are contained in [RFC 1244], the Site Security Handbook, produced by 941 the Site Security Handbook Working Group (SSH). This document will 942 be updated by the SSH working group and will give recommendations 943 for local policies and procedures, mainly related to the avoidance 944 of security incidents. 946 Other documents of interest for the discussion of SIRTs and their 947 tasks are available by anonymous FTP. A collection can be found on: 949 - ftp://ftp.cert.dfn.de/pub/docs/csir/ 950 Please refer to file 01-README for further information about 951 the content of this directory. 953 Some especially interesting documents in relation to this document 954 are as follows: 956 - ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ 957 reports/R-92-01 958 This report contains the Operational Framework of CERT-NL, the 959 SIRT of SURFnet (network provider in the Netherlands). 961 - For readers interested in the operation of FIRST (Forum of 962 Incident Response and Security Teams) more information is 963 collected in Appendix C. 965 - http://hightop.nrl.navy.mil/news/incident.html 966 This document leads to the NRL Incident Response Manual. 968 - http://www.cert.dfn.de/eng/team/kpk/certbib.html 969 This document contains an annotated bibliography of available 970 material, documents and files about the operation of SIRTs 971 with links to many of the referenced items. 973 - ftp://info.cert.org/incident_reporting_form 974 This Incident Reporting Form is provided by the CERT 975 Coordination Center to gather incident information and to avoid 976 additional delays caused by the need to request more detailed 977 information from the reporting site. 979 - http://www.cert.org/cert.faqintro.html 980 A collection of frequently asked questions from the CERT 981 Coordination Center. 983 Expectations for Security Incident Response 20 July 97 985 Appendix C: Known Security Incident Response Teams 987 Today, there are many different SIRTs but no single source lists 988 every team. Most of the major and long established teams (the first 989 SIRT was founded in 1988) are nowadays members of FIRST, the 990 worldwide Forum of Incident Response and Security Teams. At the 991 time of writing, more than 55 teams are members (1 in Australia, 13 992 in Europe, all others in North America). Information about FIRST 993 can be found: 995 - http://www.first.org/ 997 The actual list of members is available also, with the relevant 998 contact information and some additional information provided by the 999 particular teams: 1001 - http://www.first.org/team-info/ 1003 For SIRTs which want to become members of this forum (please note 1004 that a team needs a sponsor - a team which is already a full member 1005 of FIRST - to be introduced), the following files contain more 1006 information: 1008 - http://www.first.org/about/op_frame.html 1009 The Operational Framework of FIRST. 1011 - http://www.first.org/docs/newmem.html 1012 Guidelines for teams which want to become members of FIRST. 1014 Many of the European teams, regardless of whether they are members 1015 of FIRST or not, are listed by countries on a page maintained by 1016 the German SIRT: 1018 - http://www.cert.dfn.de/eng/csir/europe/certs.html 1020 To learn about existing teams suitable to one's needs it is 1021 often helpful to ask either known teams or an Internet Service 1022 Provider for the "right" contact. 1024 Expectations for Security Incident Response 20 July 97 1026 Appendix D: Outline for SIRT Template 1028 This outline summarizes in point form the issues addressed in this 1029 document, and is the recommended template for a SIRT description 1030 document. Its structure is designed to facilitate the communication 1031 of a SIRT's policies, procedures, and other relevant information to 1032 its constituency and to outside organizations such as other SIRTs. 1033 A 'filled-in' example of this template is given as Appendix E. 1035 1. Document Information 1036 1.1 Date of Last Update 1037 1.2 Distribution List for Notifications 1038 1.3 Locations where this Document May Be Found 1040 2. Contact Information 1041 2.1 Name of the Team 1042 2.2 Address 1043 2.3 Time Zone 1044 2.4 Telephone Number 1045 2.5 Facsimile Number 1046 2.6 Other Telecommunication 1047 2.7 Electronic Mail Address 1048 2.8 Public Keys and Encryption Information 1049 2.9 Team Members 1050 2.10 Other Information 1051 2.11 Points of Customer Contact 1053 3. Charter 1054 3.1 Mission Statement 1055 3.2 Constituency 1056 3.3 Sponsorship and/or Affiliation 1057 3.4 Authority 1059 4. Policies 1060 4.1 Types of Incidents and Level of Support 1061 4.2 Co-operation, Interaction and Disclosure of Information 1062 4.3 Communication and Authentication 1064 5. Services 1065 5.1 Incident Response 1066 5.1.1. Incident Triage 1067 5.1.2. Incident Coordination 1068 5.1.3. Incident Cure 1069 5.2 Proactive Activities 1071 6. Incident Reporting Forms 1073 7. Disclaimers 1075 Expectations for Security Incident Response 20 July 97 1077 Appendix E: Example - 'filled-in' Template for a SIRT 1079 Below is an example of a filled-in template for a fictitious SIRT 1080 called XYZ-SIRT. This text is for example purposes only, and does 1081 not constitute endorsement by the working group or the IETF of any 1082 particular set of procedures or policies. While SIRTs are welcome 1083 to use any or all of this text if they wish, such use is of course 1084 not mandatory, or even appropriate in most cases. 1086 SIRT Description for XYZ-CERT 1087 ----------------------------- 1089 1. About this document 1091 1.1 Date of Last Update 1093 This is version 1.01, published 1997/03/31. 1095 1.2 Distribution List for Notifications 1097 Notifications of updates are submitted to our mailing list 1098 . Subscription requests for this 1099 list should be sent to the Majordomo at 1100 ; the body of the message 1101 should consist of the word "subscribe". Send the word "help" 1102 instead if you don't know how to use a Majordomo list manager. 1103 This mailing list is moderated. 1105 1.3 Locations where this Document May Be Found 1107 The current version of this SIRT description document is 1108 available from the XYZ-CERT WWW site; its URL is 1109 http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.txt 1110 Une version francaise de ce document est igalement disponible: 1111 http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.txt 1112 Please make sure you are using the latest version. 1114 1.4 Authenticating this Document 1116 Both the English and French versions of this document have 1117 been signed with the XYZ-CERT's PGP key. The signatures are 1118 also on our Web site, under: 1119 http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.asc 1120 http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.asc 1122 2. Contact Information 1124 2.1 Name of the Team 1126 "XYZ-CERT": the XYZ University Computer Emergency Response 1127 Team. 1129 Expectations for Security Incident Response 20 July 97 1131 2.2 Address 1133 XYZ-CERT 1134 XYZ University, Computing Services Department 1135 12345 Rue Principale 1136 UniversityTown, Quebec 1137 Canada H0H 0H0 1139 2.3 Time Zone 1141 Canada/Eastern (GMT-0500, and GMT-0400 from April to October) 1143 2.4 Telephone Number 1145 +1 234 567 7890 (ask for the XYZ-CERT) 1147 2.5 Facsimile Number 1149 +1 234 567 7899 (this is *not* a secure fax) 1151 2.6 Other Telecommunication 1153 None available. 1155 2.7 Electronic Mail Address 1157 This is a mail alias that relays mail 1158 to the human(s) on duty for the XYZ-CERT. 1160 2.8 Public Keys and Other Encryption Information 1162 The XYZ-CERT has a PGP key, whose KeyID is 12345678 and 1163 whose fingerprint is 1164 11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11. 1165 The key and its signatures can be found at the usual large 1166 public keyservers. 1168 Because PGP is still a relatively new technology at XYZ 1169 University, this key still has relatively few signatures; 1170 efforts are underway to increase the number of links to this 1171 key in the PGP "web of trust". In the meantime, since most 1172 fellow universities in Quebec have at least one staff member 1173 who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has 1174 signed the XYZ-CERT key, and will be happy to confirm its 1175 fingerprint and that of her own key to those people who know 1176 her, by telephone or in person. 1178 2.9 Team Members 1180 Zoe Doe of Computing Services is the XYZ-CERT coordinator. 1181 Backup coordinators and other team members, along with their 1183 Expectations for Security Incident Response 20 July 97 1185 areas of expertise and contact information, are listed in the 1186 XYZ-CERT web pages, at 1187 http://www.xyz-univ.ca/xyz-cert/teamlist.html 1189 Management, liaison and supervision are provided by Steve Tree, 1190 Assistant Director (Technical Services), Computing Services. 1192 2.10 Other Information 1194 General information about the XYZ-CERT, as well as links to 1195 various recommended security resources, can be found at 1196 http://www.xyz-univ.ca/xyz-cert/index.html 1198 2.11 Points of Customer Contact 1200 The preferred method for contacting the XYZ-CERT is via 1201 e-mail at ; e-mail sent to this address 1202 will "biff" the responsible human, or be automatically 1203 forwarded to the appropriate backup person, immediately. If 1204 you require urgent assistance, put "urgent" in your subject 1205 line. 1207 If it is not possible (or not advisable for security reasons) 1208 to use e-mail, the XYZ-CERT can be reached by telephone during 1209 regular office hours. Telephone messages are checked less 1210 often than e-mail. 1212 The XYZ-CERT's hours of operation are generally restricted to 1213 regular business hours (09:00-17:00 Monday to Friday except 1214 holidays). 1216 If possible, when submitting your report, use the form 1217 mentioned in section 6. 1219 3. Charter 1221 3.1 Mission Statement 1223 The purpose of the XYZ-CERT is, first, to assist members of XYZ 1224 University community in implementing proactive measures to 1225 reduce the risks of computer security incidents, and second, to 1226 assist XYZ community in responding to such incidents when they 1227 occur. 1229 3.2 Constituency 1231 The XYZ-CERT's constituency is the XYZ University community, 1232 as defined in the context of the "XYZ University Policy on 1233 Computing Facilities". This policy is available at 1234 http://www-compserv.xyz-univ.ca/policies/pcf.html 1236 Expectations for Security Incident Response 20 July 97 1238 However, please note that, notwithtanding the above, XYZ-CERT 1239 services will be provided for on-site systems only. 1241 3.3 Sponsorship and/or Affiliation 1243 The XYZ-CERT is currently completing the application process 1244 for membership in FIRST, the Forum of Incident Response and 1245 Security Teams. More information about FIRST is available 1246 from 1247 http://www.first.org/ 1249 3.4 Authority 1251 The XYZ-CERT operates under the auspices of, and with authority 1252 delegated by, the Department of Computing Services of XYZ 1253 University. For further information on the mandate and 1254 authority of the Department of Computing Services, please 1255 refer to the XYZ University "Policy on Computing Facilities", 1256 available at 1257 http://www-compserv.xyz-univ.ca/policies/pcf.html 1259 The XYZ-CERT expects to work cooperatively with system 1260 administrators and users at XYZ University, and, insofar as 1261 possible, to avoid authoritarian relationships. However, 1262 should circumstances warrant it, the XYZ-CERT will appeal to 1263 Computing Services to exert its authority, direct or indirect, 1264 as necessary. All members of the XYZ-CERT are members of the 1265 CCSA (Committee of Computer Systems Administrators), and have 1266 all of the powers and responsibilities assigned to Systems 1267 Administrators by the Policy on Computing Facilities, or are 1268 members of University management. 1270 Members of the XYZ University community who wish to appeal the 1271 actions of the XYZ-CERT should contact the Assistant Director 1272 (Technical Services), Computing Services. If this recourse is 1273 not satisfactory, the matter may be referred to the Director 1274 of Computing Services (in the case of perceived 1275 problems with existing policy), or to the the XYZ University 1276 Office of Rights and Responsibilities (in the case of perceived 1277 errors in the application of existing policy). 1279 4. Policies 1281 4.1 Types of Incidents and Level of Support 1283 The XYZ-CERT is authorized to address all types of computer 1284 security incidents which occur, or threaten to occur, at 1285 XYZ University. 1287 The level of support given by XYZ-CERT will vary depending on 1288 the type and severity of the incident or issue, the type of 1290 Expectations for Security Incident Response 20 July 97 1292 constituent, the size of the user community affected, and the 1293 XYZ-CERT's resources at the time, though in all cases some 1294 response will be made within one working day. Resources will 1295 be assigned according to the following priorities, listed in 1296 decreasing order: 1298 - Threats to the physical safety of human beings. 1299 - Root or system-level attacks on any Management Information 1300 System, or any part of the backbone network infrastructure. 1301 - Root or system-level attacks on any large public service 1302 machine, either multi-user or dedicated-purpose. 1303 - Compromise of restricted confidential service accounts or 1304 software installations, in particular those used for MIS 1305 applications containing confidential data, or those used 1306 for system administration. 1307 - Denial of service attacks on any of the above three items. 1308 - Any of the above at other sites, originating from XYZ 1309 University. 1310 - Large-scale attacks of any kind, e.g. sniffing attacks, 1311 IRC "social engineering" attacks, password cracking 1312 attacks. 1313 - Threats, harrassment, and other criminal offenses 1314 involving individual user accounts. 1315 - Compromise of individual user accounts on multi-user 1316 systems. 1317 - Compromise of desktop systems. 1318 - Forgery and misrepresentation, and other security-related 1319 violations of local rules and regulations, e.g. netnews 1320 and e-mail forgery, unauthorized use of IRC bots. 1321 - Denial of service on individual user accounts, e.g. 1322 mailbombing. 1324 Types of incidents other than those mentioned above will be 1325 prioritized according to their apparent severity and extent. 1327 Note that no direct support will be given to end users; they 1328 are expected to contact their system administrator, network 1329 administrator, or department head for assistance. The XYZ-CERT 1330 will support the latter people. 1332 While the XYZ-CERT understands that there exists great 1333 variation in the level of system administrator expertise at XYZ 1334 University, and while the XYZ-CERT will endeavor to present 1335 information and assistance at a level appropriate to each 1336 person, the XYZ-CERT cannot train system administrators on the 1337 fly, and it cannot perform system maintenance on their behalf. 1338 In most cases, the XYZ-CERT will provide pointers to the 1339 information needed to implement appropriate measures. 1341 The XYZ-CERT is committed to keeping the XYZ University system 1342 administration community informed of potential vulnerabilities, 1344 Expectations for Security Incident Response 20 July 97 1346 and where possible, will inform this community of such 1347 vulnerabilities before they are actively exploited. 1349 4.2 Co-operation, Interaction and Disclosure of Information 1351 While there are legal and ethical restrictions on the flow of 1352 information from XYZ-CERT, many of which are also outlined in 1353 the XYZ University Policy on Computing Facilities, and all of 1354 which will be respected, the XYZ-CERT acknowledges its 1355 indebtedness to, and declares its intention to contribute to, 1356 the spirit of cooperation that created the Internet. 1357 Therefore, while appropriate measures will be taken to protect 1358 the identity of members of our constituency and members of 1359 neighbouring sites where necessary, the XYZ-CERT will otherwise 1360 share information freely when this will assist others in 1361 resolving or preventing security incidents. 1363 In the paragraphs below, "affected parties" refers to the 1364 legitimate owners, operators, and users of the relevant 1365 computing facilities. It does not refer to unauthorized 1366 users, including otherwise authorized users making 1367 unauthorized use of a facility; such intruders may have no 1368 expectation of confidentiality from the XYZ-CERT. They may or 1369 may not have legal rights to confidentiality; such rights will 1370 of course be respected where they exist. 1372 Information being considered for release will be classified as 1373 follows: 1375 - Private user information is information about particular 1376 users, or in some cases, particular applications, which 1377 must be considered confidential for legal, contractual, 1378 and/or ethical reasons. 1380 Private user information will be not be released in 1381 identifiable form outside the XYZ-CERT, except as provided 1382 for below. If the identity of the user is disguised, then 1383 the information can be released freely (for example to show 1384 a sample .cshrc file as modified by an intruder, or to 1385 demonstrate a particular social engineering attack). 1387 - Intruder information is similar to private user 1388 information, but concerns intruders. 1390 While intruder information, and in particular identifying 1391 information, will not be released to the public (unless it 1392 becomes a matter of public record, for example because 1393 criminal charges have been laid), it will be exchanged 1394 freely with system administrators and SIRTs tracking an 1395 incident. 1397 Expectations for Security Incident Response 20 July 97 1399 - Private site information is technical information about 1400 particular systems or sites. 1402 It will not be released without the permission of the site 1403 in question, except as provided for below. 1405 - Vulnerability information is technical information about 1406 vulnerabilities or attacks, including fixes and 1407 workarounds. 1409 Vulnerability information will be released freely, though 1410 every effort will be made to inform the relevant vendor 1411 before the general public is informed. 1413 - Embarrassing information includes the statement that an 1414 incident has occurred, and information about its extent or 1415 severity. Embarrassing information may concern a site or 1416 a particular user or group of users. 1418 Embarrassing information will not be released without the 1419 permission of the site or users in question, except as 1420 provided for below. 1422 - Statistical information is embarrassing information with 1423 the identifying information stripped off. 1425 Statistical information will be released at the discretion 1426 of the Computing Services Department. 1428 - Contact information explains how to reach system 1429 administrators and SIRTs. 1431 Contact information will be released freely, except where 1432 the contact person or entity has requested that this not 1433 be the case, or where XYZ-CERT has reason to believe that 1434 the dissemination of this information would not be 1435 appreciated. 1437 Potential recipients of information from the XYZ-CERT will be 1438 classified as follows: 1440 - Because of the nature of their responsibilities and 1441 consequent expectations of confidentiality, members of XYZ 1442 University management are entitled to receive whatever 1443 information is necessary to facilitate the handling of 1444 computer security incidents which occur in their 1445 jurisdictions. 1447 - Members of the Office of Rights and Responsibilities are 1448 entitled to receive whatever information they request 1449 concerning a computer security incident or related matter 1450 Expectations for Security Incident Response 20 July 97 1452 which has been referred to them for resolution. The same is 1453 true for the XYZ Security Department, when its assistance in 1454 an investigation has been enlisted, or when the investigation 1455 has been instigated at its request. 1457 - System administrators at XYZ University who are members of 1458 the CCSA are also, by virtue of their responsibilities, 1459 trusted with confidential information. However, unless such 1460 people are also members of XYZ-CERT, they will be given only 1461 that confidential information which they must have in order 1462 to assist with an investigation, or in order to secure their 1463 own systems. 1465 - Users at XYZ University are entitled to information which 1466 pertains to the security of their own computer accounts, 1467 even if this means revealing "intruder information", or 1468 "embarrasssing information" about another user. For 1469 example, if account aaaa is cracked and the intruder attacks 1470 account bbbb, user bbbb is entitled to know that aaaa was 1471 cracked, and how the attack on the bbbb account was 1472 executed. User bbbb is also entitled, if she or he requests 1473 it, to information about account aaaa which might enable 1474 bbbb to investigate the attack. For example, if bbbb was 1475 attacked by someone remotely connected to aaaa, bbbb should 1476 be told the provenance of the connections to aaaa, even 1477 though this information would ordinarily be considered 1478 private to aaaa. Users at XYZ University are entitled to be 1479 notified if their account is believed to have been 1480 compromised. 1482 - The XYZ University community will receive no restricted 1483 information, except where the affected parties have given 1484 permission for the information to be disseminated. 1485 Statistical information may be made available to the general 1486 XYZ community. There is no obligation on the part of the 1487 XYZ-CERT to report incidents to the community, though it may 1488 choose to do so; in particular, it is likely that the 1489 XYZ-CERT will inform all affected parties of the ways in 1490 which they were affected, or will encourage the affected site 1491 to do so. 1493 - The public at large will receive no restricted information. 1494 In fact, no particular effort will be made to communicate 1495 with the public at large, though the XYZ-CERT recognizes 1496 that, for all intents and purposes, information made 1497 available to the XYZ University community is in effect made 1498 available to the community at large, and will tailor the 1499 information in consequence. 1501 - The computer security community will be treated the same way 1502 the general public is treated. While members of XYZ-CERT may 1503 Expectations for Security Incident Response 20 July 97 1505 participate in discussions within the computer security 1506 community, such as newsgroups, mailing lists (including the 1507 full-disclosure list "bugtraq"), and conferences, they will 1508 treat such forums as though they were the public at large. 1509 While technical issues (including vulnerabilities) may be 1510 discussed to any level of detail, any examples taken from 1511 XYZ-CERT experience will be disguised to avoid identifying 1512 the affected parties. 1514 - The press will also be considered as part of the general 1515 public. The XYZ-CERT will not interact directly with the 1516 Press concerning computer security incidents, except to point 1517 them toward information already released to the general 1518 public. If necessary, information will be provided to the 1519 XYZ University Public Relations Department, and to the 1520 Customer Relations group of the Computing Services 1521 Department. All incident-related queries will be referred to 1522 these two bodies. The above does not affect the ability of 1523 members of XYZ-CERT to grant interviews on general computer 1524 security topics; in fact, they are encouraged to do to, as a 1525 public service to the community. 1527 - Other sites and SIRTs, when they are partners in the 1528 investigation of a computer security incident, will in some 1529 cases be trusted with confidential information. This will 1530 happen only if the foreign site's bona fide can be verified, 1531 and the information transmitted will be limited to that which 1532 is likely to be helpful in resolving the incident. Such 1533 information sharing is most likely to happen in the case of 1534 sites well known to XYZ-CERT (for example, several other 1535 Quebec universities have informal but well-established 1536 working relationships with XYZ University in such mattters). 1538 For the purposes of resolving a security incident, otherwise 1539 semi-private but relatively harmless user information such as 1540 the provenance of connections to user accounts will not be 1541 considered highly sensitive, and can be transmitted to a 1542 foreign site without excessive precautions. "Intruder 1543 information" will be transmitted freely to other system 1544 administrators and SIRTs. "Embarrassing information" can be 1545 transmitted when there is reasonable assurance that it will 1546 remain confidential, and when it is necessary to resolve an 1547 incident. 1549 - Vendors will be considered as foreign SIRTs for most intents 1550 and purposes. The XYZ-CERT wishes to encourage vendors of 1551 all kinds of networking and computer equipment, software, and 1552 services to improve the security of their products. In aid 1553 of this, a vulnerability discovered in such a product will be 1554 reported to its vendor, along with all technical details 1555 needed to identify and fix the problem. Identifying details 1556 Expectations for Security Incident Response 20 July 97 1558 will not be given to the vendor without the permission of the 1559 affected parties. 1561 - Law enforcement officers will receive full cooperation from 1562 the XYZ-CERT, including any information they require to 1563 pursue an investigation, in accordance with the Policy on 1564 Computing Facilities. 1566 4.3 Communication and Authentication 1568 In view of the types of information that the XYZ-CERT will 1569 likely be dealing with, telephones will be considered 1570 sufficiently secure to be used even unencrypted. Unencrypted 1571 e-mail will not be considered particularly secure, but will be 1572 sufficient for the transmission of low-sensitivity data. If 1573 it is necessary to send highly sensitive data by e-mail, PGP 1574 will be used. Network file transfers will be considered to 1575 be similar to e-mail for these purposes: sensitive data should 1576 be encrypted for transmission. 1578 Where it is necessary to establish trust, for example before 1579 relying on information given to the XYZ-CERT, or before 1580 disclosing confidential information, the identity and bona 1581 fide of the other party will be ascertained to a reasonable 1582 degree of trust. Within XYZ University, and with known 1583 neighbor sites, referrals from known trusted people will 1584 suffice to identify someone. Otherwise, appropriate methods 1585 will be used, such as a search of FIRST members, the use of 1586 WHOIS and other Internet registration information, etc, along 1587 with telephone call-back or e-mail mail-back to ensure that 1588 the party is not an impostor. Incoming e-mail whose data must 1589 be trusted will be checked with the originator personally, or 1590 by means of digital signatures (PGP in particular is 1591 supported). 1593 Expectations for Security Incident Response 20 July 97 1595 5. Services 1597 5.1 Incident Response 1599 XYZ-CERT will assist system administrators in handling the 1600 technical and organizational aspects of incidents. In 1601 particular, it will provide assistance or advice with respect 1602 to the following aspects of incident management: 1603 - Determining the extent of the incident. 1604 - Determining the initial cause of the incident 1605 (vulnerability exploited). 1606 - Facilitating contact with other sites which may be 1607 involved. 1608 - Removing the vulnerability. 1609 - Securing the system from the effects of the incident. 1610 - Evaluating whether certain actions are likely to reap 1611 results in proportion to their cost and risk, in 1612 particular those actions aimed at an eventual prosecution 1613 or disciplinary action: collection of evidence after the 1614 fact, observation of an incident in progress, setting 1615 traps for intruders, etc. 1616 - Collecting evidence where criminal prosecution, or 1617 University disciplinary action, is contemplated. 1618 - Facilitating contact with XYZ University Security and/or 1619 appropriate law enforcement officials, if necessary. 1620 - Making reports to other SIRTs. 1621 - Composing announcements to users, if applicable. 1623 In addition, XYZ-CERT will collect statistics concerning 1624 incidents which occur within or involve the XYZ University 1625 community, and will notify the community as necessary to 1626 assist it in protecting against known attacks. 1628 To make use of XYZ-CERT's incident response services, please 1629 send e-mail as per section 2.11 above. Please remember that 1630 the amount of assistance available will vary according to 1631 the parameters described in section 4.1. 1633 5.2 Proactive Activities 1635 The XYZ-CERT coordinates and maintains the following 1636 services to the extent possible depending on its resources: 1637 - Information services 1638 - List of departmental security contacts, administrative 1639 and technical. These lists will be available to the 1640 general public, via commonly-available channels such as 1641 the World Wide Web and/or the Domain Name Service. 1642 - Mailing lists to inform security contacts of new 1643 information relevant to their computing environments. 1644 These lists will be available only to XYZ University 1645 system administrators. 1647 Expectations for Security Incident Response 20 July 97 1649 - Repository of vendor-provided and other security-related 1650 patches for various operating systems. This repository 1651 will be available to the general public wherever 1652 license restrictions allow it, and will be provided via 1653 commonly-available channels such as the World Wide Web 1654 and/or ftp. 1655 - Repository of security tools and documentation for 1656 use by sysadmins. Where possible, precompiled 1657 ready-to-install versions will be supplied. These will 1658 be supplied to the general public via www or ftp as 1659 above. 1660 - "Clipping" service for various existing resources, such 1661 as major mailing lists and newsgroups. The resulting 1662 clippings will be made available either on the 1663 restricted mailing list or on the web site, depending 1664 on their sensitivity and urgency. 1665 - Training services 1666 - Members of the XYZ-CERT will give periodic seminars on 1667 computer security related topics; these seminars will 1668 be open to XYZ University system administrators. 1669 - Auditing services 1670 - Central file integrity checking service for Unix 1671 machines, and for any other platforms capable of 1672 running "tripwire". 1673 - Security level assignments; machines and subnetworks 1674 at XYZ University will be audited and assigned a 1675 security level. This security level information will be 1676 available to the XYZ University community, to facilitate 1677 the setting of appropriate access privileges. However, 1678 details of the security analyses will be confidential, 1679 and available only to the concerned parties. 1680 - Archiving services 1681 - Central logging service for machines capable of 1682 Unix-style remote logging. Incoming log entries will 1683 be watched by an automated log analysis program, and 1684 events or trends indicative of a potential security 1685 problem will be reported to the affected system 1686 administrators. 1687 - Records of security incidents handled will be kept. 1688 While the records will remain confidential, periodic 1689 statistical reports will be made available to the XYZ 1690 University community. 1692 Detailed descriptions of the above services, along with 1693 instructions for joining mailing lists, downloading 1694 information, or participating in certain services such as the 1695 central logging and file integrity checking services, are 1696 available on the XYZ-CERT web site, as per section 2.10 1697 above. 1699 Expectations for Security Incident Response 20 July 97 1701 6. Incident Reporting Forms 1703 There are no local forms developed yet for reporting incidents 1704 to XYZ-CERT. If possible, please make use of the Incident 1705 Reporting Form of the CERT Coordination Center (Pittsburgh, 1706 PA). The actual version is available from: 1707 ftp://info.cert.org/incident_reporting_form 1709 7. Disclaimers 1711 While every precaution will be taken in the preparation of 1712 information, notifications and alerts, XYZ-CERT assumes no 1713 responsibility for errors or omissions, or for damages 1714 resulting from the use of the information contained within. 1716 4 Acknowlegements 1718 The editors gratefully acknowledge the contributed material and 1719 editorial scrutiny of Anne Bennett. Thanks also to Don Stikvoort 1720 for assistance reworking the description of Incident Response Team 1721 services. 1723 5 References 1725 [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. - 1726 July 23, 1991. - 101 pages. - FYI 8. 1728 [RFC 1983] G. Malkin / Internet Users' Glossary. - 1729 August 16, 1996. - 62 pages. - FYI 18. 1731 6 Security Considerations 1733 This document discusses the operation of Security Incident Response 1734 Teams, and the teams' interactions with their constituencies and 1735 with other organizations. It is, therefore, not directly concerned 1736 with the security of protocols, applications, or network systems 1737 themselves. It is not even concerned with particular responses and 1738 reactions to security incidents, but only with the appropriate 1739 description of the responses provided by SIRTs. 1741 Nonetheless, it is vital that the SIRTs themselves operate securely, 1742 which means that they must establish secure communication channels 1743 with other teams, and with members of their constituency. They must 1744 also secure their own systems and infrastructure, to protect the 1745 interests of their constituency and to maintain the confidentiality 1746 of the identity of victims and reporters of security incidents. 1748 Expectations for Security Incident Response 20 July 97 1750 7 Authors' Addresses 1752 Nevil Brownlee ITSS Technology Development 1753 The University of Auckland 1755 Phone: +64 9 373 7599 x8941 1756 E-mail: n.brownlee@auckland.ac.nz 1758 Erik Guttman 1759 Sun Microsystems, Inc. 1760 Gaisbergstr. 6 1761 69115 Heidelberg Germany 1763 Phone: +49 6221 601649 1764 E-Mail: eguttman@eng.sun.com 1766 This document expires January 20, 1998.