idnits 2.17.1 draft-ietf-grip-framework-irt-04.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 26) being 78 lines 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (March 1997) is 9902 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Nevil Brownlee 3 INTERNET-DRAFT The University of Auckland 4 Valid for six months Erik Guttman 5 Sun Microsystems 6 March 1997 8 Expectations for Security Incident Response 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute working 17 documents as Internet Drafts. This Internet Draft is a product of the 18 GRIP Working Group of the IETF. 20 Internet Drafts are draft documents valid for a maximum of six months. 21 Internet Drafts may be updated, replaced, or obsoleted by other 22 documents at any time. It is not appropriate to use Internet Drafts as 23 reference material or to cite them other than as a 'working draft' or 24 'work in progress.' 26 To learn the current status of any Internet Draft, please check the 27 '1id-abstracts.txt' listing contained in the Internet Drafts shadow 28 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 The purpose of this document is to express the general Internet 35 community's expectations of Security Incident Response Teams. It 36 is not possible to define a set of requirements that would be 37 appropriate for all teams, but it is possible and helpful to 38 list and describe the general set of topics and issues which 39 are of concern and interest to constituent communities. 41 SIRT constituents have a legitimate need and right to fully understand 42 the policies and procedures of "their" Security Incident Response Team. 43 One way to support this understanding is to supply detailed information 44 which users may consider, in the form of a formal template completed by 45 the SIRT. An outline of such a template and a filled in example is 46 provided. 48 Expectations for Security Incident Response 26 March 97 50 Table of Contents 52 1 Introduction 1 54 2 Scope..............................................................3 55 2.1 Publishing a SIRT Policies and Procedures .....................4 56 2.2 Relationships between different SIRTs .........................5 57 2.3 Establishing Secure Communications ............................6 59 3 Information, Policies and Procedures...............................7 60 3.1 Contact Information ...........................................8 61 3.2 Document Updates ..............................................9 62 3.3 Charter .......................................................9 63 3.3.1 Mission Statement.......................................10 64 3.3.2 Constituency............................................10 65 3.3.3 Sponsoring Organization / Affiliation...................10 66 3.3.4 Authority...............................................11 67 3.4 Policies .....................................................11 68 3.4.1 Types of Incidents and Level of Support.................11 69 3.4.2 Co-operation and Interaction with other Organizations...12 70 3.4.3 Reporting and Disclosure................................13 71 3.4.4 Communication and Authentication........................14 72 3.4.5 Point of Customer Contacts..............................14 73 3.5 Services .....................................................15 74 3.6 Incident Reporting Forms .....................................15 75 3.7 Disclaimers ..................................................16 77 4 Appendix A: Glossary of Terms 17 79 5 Appendix B: Related Material 18 81 6 Appendix C: Known Security Incident Response Teams 19 83 7 Appendix D: Outline for SIRT Template 21 85 8 Appendix E: Example - 'filled-in' Template for a SIRT 22 87 9 References 29 89 10 Security Considerations 29 91 11 Authors' Addresses 29 92 Expectations for Security Incident Response 26 March 97 94 1 Introduction 96 The GRIP Working Group was formed to create a document that describes 97 the community's expectations of security incident response teams 98 (SIRTs). Although the need for such a document originated in the 99 general Internet community, the expectations expressed should also 100 closely match those of more restricted communities. 102 In the past there have been misunderstandings regarding what to expect 103 from SIRTs. The goal of this document is to provide a framework for 104 presenting the important subjects (related to incident response) that 105 are of concern to the community. 107 Before continuing, it is important to clearly understand what is meant 108 by the term "Security Incident Response Team." For the purposes of 109 this document, a SIRT is a team that performs, coordinates, and supports 110 the response to security incidents that involve sites within a defined 111 constituency (see Appendix A for a more complete definition). Any 112 group calling itself a SIRT for a specific constituency must therefore 113 react to reported security incidents, and to threats to "their" 114 constituency in ways which the specific community agrees to be in its 115 general interest. 117 Since it is vital that each member of a constituent community be 118 able to understand what is reasonable to expect of their team, A SIRT 119 should make it clear who belongs to their constituency and define the 120 services the team offers to the community. Additionally, each SIRT 121 should publish its policies and operating procedures. Similarly, these 122 same constituents need to know what is expected of them in order for 123 them to receive the services of their team. This requires that the 124 team also publish how and where incidents should be reported. 126 This document details a template which will be used by SIRTs to 127 communicate this information to their constituents. The constituents 128 should certainly expect a SIRT to provide the services they describe in 129 the completed template. 131 It must be emphasised that without active participation from users, the 132 effectiveness of the SIRT's services can be greatly diminished. This 133 is particularly the case with reporting. At a minimum, users need to 134 know that they should report security incidents, and know how and where 135 they should report them to. 137 Many computer security incidents originate outside local community 138 boundaries and affect inside sites, others originate inside the local 139 community and affect hosts or users on the outside. Often, therefore, 140 Expectations for Security Incident Response 26 March 97 142 the handling of security incidents will involve the cooperation of 143 multiple sites and potentially multiple SIRTs. The coordination of 144 activities across communities and organization requires that the 145 parties understand who they are dealing with, and what sort of policies 146 they have in place. 148 Many computer security incidents originate outside local community 149 boundaries and affect inside sites, others originate inside the local 150 community and affect hosts or users on the outside. Often, therefore, 151 the handling of security incidents will involve multiple sites and 152 potentially multiple SIRTs. Resolving these incidents will require 153 cooperation between individual sites and SIRTs, and between SIRTs. 154 Constituent communities need to know exactly how their SIRT will be 155 working with other SIRTs and organizations outside their constituency, 156 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. Rather, 161 each topic is discussed it terms of what that topic means. For example, 162 five types of policy statements are listed (representing those policies 163 of interest to the community), but the content of any one of them will 164 necessarily be specific to a given team. 166 Chapter two provides an overview of three major areas: The publishing 167 of information by a response team, the definition of the response 168 team's relationship to other response teams and the need for secure 169 communications. Chapter three describes in detail all the types of 170 information that the community needs to know about their response team. 171 These topics are condensed into an outline template for ease of use by 172 the community, and is found in Appendix D. This template can be used 173 by constituents to elicit information from their SIRT, and it provides 174 criteria with which to measure their team's performance. 176 It is the working group's sincere hope that through the clarification 177 of the topics in this document, understanding between the community 178 and its SIRTs will be increased. 180 2 Scope 182 The interactions between a constituent community and an incident 183 response team require first that the community understands the 184 policies and procedures of the response team. Second, since many 185 response teams collaborate to handle incidents, the community must 186 also understand the relationship between their response team and 187 Expectations for Security Incident Response 26 March 97 189 other teams. Finally, many interactions will take advantage of 190 existing public infrastructures and the community needs to know how 191 those communications are going to be protected. Each of these subjects 192 will be described in more detail in the following three sections. 194 2.1 Publishing a SIRT Policies and Procedures 196 Each user who has access to a Security Incident Response Team should 197 know as much as possible about services of and interactions with this 198 team long before he or she actually needs them. 200 A clear statement of the policies and procedures of a SIRT helps the 201 constituent understand how best to report incidents and what support to 202 expect afterwards. Will the SIRT assist in resolving the incident? 203 Will it provide help in avoiding incidents in the future? Clear 204 expectations, particularly of the limitations of the services provided 205 by a SIRT, will make interaction with it more efficient and effective. 207 There are different kinds of response teams. Some that have very 208 broad constituencies (e.g., CERT Coordination Center and the Internet), 209 others that have more bounded constituencies (e.g., DFN-CERT, CIAC), 210 and still others that have very restricted constituencies (e.g., 211 commercial response teams, corporate response teams). Regardless of 212 the type of response team, the constituency supported by it must be 213 knowledgeable about the team's policies and procedures. Therefore, it 214 is mandatory that response teams publish such information to their 215 constituency. 217 As a SIRT provides a service to a this clearly defined constituency, 218 it should communicate all necessary information about its policies 219 and services in a suitable form. It is important to understand that 220 not all policies and procedures must be publicly available. For 221 example, it is not necessary to understand the internal operation of 222 a team in order to interact with it, as when reporting an incident or 223 receiving guidance on how to analyze or secure one's systems. 225 In the past, some teams supplied a kind of Operational Framework, 226 others provided Frequently Asked Questions (FAQ), while still 227 others wrote papers for distribution at user conferences or sent 228 newsletters. 230 Another efficient way to communicate the relevant information to all 231 concerned, not only constituents but also other teams or organizations, 232 would be for each SIRT to publish its guidelines and procedures on its 233 own information server. This would allow constituents to easily access 234 Expectations for Security Incident Response 26 March 97 236 it, although this does not address the problem of how a constituent or 237 will find "his" or "her" team. People within the constituency have to 238 discover that there is a SIRT "at their disposal." It is foreseen that 239 completed SIRT templates will soon become searchable by modern search 240 engines. This will aid in distributing information about the existence 241 of SIRTs and basic information required to approach them. 243 It would be very useful to have a central repository containing all the 244 completed SIRT templates. No such repository presently exists. This 245 might change in the future. 247 Regardless of the source from which the information is retrieved, 248 the user of the template must check its authenticity. It is highly 249 recommended that such vital documents be protected by digital 250 signatures. These will allow user can verify that the template 251 was indeed published by the SIRT and that it has not been modified 252 thereafter. This document assumes the reader has familiarity with 253 the proper use of digital signatures to determine whether a document 254 is authentic. 256 2.2 Relationships between different SIRTs 258 In some cases a SIRT may be able to operate effectively on its own 259 and in close cooperation with its constituency. But with todays 260 international networks it is much more likely that most of the 261 incidents handled by a SIRT will involve parties external to its 262 constituency. Therefore the team will need to interact with other 263 SIRTs and sites outside their constituency. 265 The constituent community should be clear about the nature and 266 extent of this collaboration, as very sensitive information about 267 individual constituents may be disclosed in the process. 269 Such interactions could include asking other teams for advice, 270 disseminating knowledge of problems and working cooperatively 271 to resolve a security incident effecting one or more of the SIRTs' 272 constituencies. 274 In establishing relationships to support such interactions, SIRTs will 275 need to decide what kinds of agreements can exist between them so as to 276 share yet safeguard information, whether this relationship can be 277 disclosed, and if so to whom. 279 Expectations for Security Incident Response 26 March 97 281 Note that there is a difference between a peering agreement, where the 282 SIRTs involved agree to work together and share information, and simple 283 co-operation, where a SIRT (or any other organization) simply contacts 284 another SIRT and asks for help or advice. 286 Although the establishing of such relationships is very important and 287 affect the ability of a SIRT to support its constituency, it is up to 288 the teams involved to decide about the details. It is beyond the scope 289 of this document to make recommendations for this process. But the 290 same set of information used to set expectations for a user community 291 regarding sharing of information will help other parties to understand 292 the objectives and services of a specific SIRT, supporting a first 293 contact. 295 2.3 Establishing Secure Communications 297 Once one party has decided to share information with another party, or 298 two parties have agreed to share information or work together - as 299 required for the coordination of Security Incident Response - all 300 parties involved need secure communications channels. ("Secure" hereby 301 relates to the protected transmission of information shared between 302 different parties and not the appropriate use of the information by the 303 parties.) 305 The goals of secure communication are: 307 - Confidentiality: 308 Can somebody else access the content of the communication? 310 - Integrity: 311 Can somebody else manipulate the content of the communication? 313 - Authenticity: 314 Am I communicating with the "right" person? 316 It is very easy to send forged e-mail, and not hard to establish a 317 (false) identity by telephone. Cryptographic techniques, for example 318 Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) can provide 319 effective ways of securing e-mail. With the correct equipment it is 320 also possible to secure telephone communication. But before using such 321 mechanisms, both parties need the "right" infrastructure, which is to 322 say preparation in advance. The most important preparation is ensuring 323 the authenticity of the cryptographic keys used in secure communication: 325 Expectations for Security Incident Response 26 March 97 327 - Public keys (for techniques like PGP and PEM): 328 Because they are accessible through the internet, they must be 329 authenticated before usage. While PGP relies on a 330 "Web of Trust" - users sign the keys of other users - PEM relies 331 on a hierarchy - certification authorities sign the keys of users. 333 - Secret keys (for techniques like DES and PGP/conventional 334 encryption): Because they must be known to sender and receiver, 335 they must be exchanged before the communication via a secure 336 channel. 338 Communication is critical for all aspects of incident response. A team 339 can best support the use of the above-mentioned techniques by gathering 340 all relevant information, in a consistent way. Specific requirements 341 (like calling a specific number for checking the authenticity 342 of keys) should be explained right away. SIRT templates provide a 343 standardized vehicle for delivering this information. 345 It is beyond the scope of this document to address all the technical 346 and administrative problems of secure communications. The point is 347 that response teams must support and use a method to secure the 348 communications between themselves and their constituents (or other 349 response teams). Whatever the mechanism is, the level of protection 350 it provides must be acceptable to the constituent community. 352 3 Information, Policies and Procedures 354 In chapter 2, it was mentioned that the policies and procedures of a 355 response team need to be published to their constituent community. 356 In this chapter we will list all the types of information that the 357 community needs to receive from its response team. How this 358 information is communicated to a community will differ from team to 359 team, as will the specific information content. The intent here is 360 to clearly describe the various kinds of information that a 361 constituent community expects from its response team. 363 To make it easier to understand all issues and topics relevant to the 364 interaction of constituents with "their" SIRT, we suggest that a SIRT 365 publish all information, policies and procedures addressing their 366 constituency as a document, following template given in Appendix D. 367 The template structure arranges items, making it easy to supply 368 specific information, was done for the example in Appendix E. While 369 no recommendations are made as to what a SIRT should adopt for their 370 policy or procedures, different possibilities are outlined to give some 371 examples. The most important thing is that a SIRT has a policy and that 372 Expectations for Security Incident Response 26 March 97 374 that those who interact with the SIRT can obtain and understand it. 376 As always, not every aspect for every environment and/or team can 377 be covered. This outline should be seen as a suggestion. Each team 378 should feel free to include whatever they think is necessary for 379 supporting their constituency. 381 3.1 Contact Information 383 Full details of how to contact the SIRT should be listed here, although 384 this might be very different for different teams. Some might choose to 385 restrict the availability of names of all team members. No further 386 clarification is given when the meaning of the item can be assumed. 388 - Name of the SIRT 390 - Mailing Address 392 - Time zone This is useful for coordinating 393 incidents which cross time zones. 395 - Telephone number 397 - Facsimile number 399 - Other telecommunication Some teams might provide secure 400 voice communication (e.g. STU III). 401 - Electronic mail address 403 - Public keys and encryption The use of specific techniques 404 depends on the ability of the 405 communication partners to have 406 access to programs, keys and so on. 407 Relevant information should be 408 outlined so users can determine 409 if and how they can make use of 410 secure communication while 411 interacting with the SIRT. 412 - Team members 414 - Other information The operating hours and holiday 415 schedule should be provided here. 416 Is there a 24 hour hotline? Is 417 there any specific customer contact 418 info? (See also section 3.4.5). 420 Expectations for Security Incident Response 26 March 97 422 3.2 Document Updates 424 Details of a SIRT change with time, so the completed template must 425 indicate when it was last changed. Additionally, information should be 426 provided to learn about how to find out about future updates. Without 427 this, it is inevitable that misunderstandings and misconceptions will 428 arise over time; an outdated document will do more harm than good. 430 - Date of last update This should be sufficient to allow 431 anyone interested to evaluate the 432 currency of the template. 434 - Distribution list Mailing lists are a convenient 435 mechanism to distribute up-to-date 436 information to a large number of 437 users. A team can decide to use its 438 own or an already existing list to 439 notify users whenever the document 440 changes. The list might normally 441 cover the constituency and any other 442 groups the SIRT has frequent 443 interactions with. 445 Digital signatures should be used 446 for update messages sent by a SIRT. 448 - Location of the document The location where a current version 449 of the document should be accessible 450 through a team's online information 451 services. Constituents can then 452 easily learn more about the team and 453 check for recent updates. 455 This online version should also be 456 accompanied by a digital signature, 458 3.3 Charter 460 Every SIRT must have a charter which specifies what it is to do, and 461 the authority under which it will do it. The charter should include 462 at least the following statements: 464 - Mission statement 465 - Constituency 466 - Sponsor / affiliation 467 - Authority 469 Expectations for Security Incident Response 26 March 97 471 3.3.1 Mission Statement 473 The mission statement should focus on the team's core activities, 474 already stated in the definition of a SIRT. In order to be considered 475 a Security Incident Response Team, the team must support the reporting 476 of incidents and support its constituency by dealing with incidents. 478 The goals and purposes of a team are especially important, and require 479 clear, unambiguous definitions. 481 3.3.2 Constituency 483 A SIRT's constituency can be determined in many ways. For example it 484 could be a company's employees or its paid subscribers, or it could be 485 defined in terms of a technological focus, such as the users of a 486 particular operating system. 488 The definition of constituency should create a perimeter around the 489 group to whom the team will provide service. The policy section of 490 the document (see below) should explain how requests from outside the 491 perimeter will be handled. 493 If a SIRT decide, not to disclosure their constituency, they should 494 explain the reasoning behind this decision. For example for-fee 495 SIRTs will not list their clients but declare that they provide 496 a service to a large group of customers that are kept confidential 497 because of the clients' contract. 499 Constituencies might overlap, as when an ISP provides a SIRT, but 500 delivers services to customer sites which also have SIRTs. The 501 Authority section of the document (see below) should make such 502 relationships clear. 504 3.3.3 Sponsoring Organization / Affiliation 506 The sponsoring organization, which authorizes the actions of the SIRT, 507 should be given next. Knowing this will help the users to understand 508 the background and setup of the SIRT. It is vital information for 509 building up trust between a constituent and a SIRT. 511 Expectations for Security Incident Response 26 March 97 513 3.3.4 Authority 515 Based on the relationship between team and constituency this section 516 will be very different from one team to another. While an 517 organizational SIRT will be given its authority by the management, 518 a community SIRT will be supported and chosen by the community, 519 usually in a advisory role. 521 SIRTs may not have authority to intervene in the operation of all the 522 systems within their perimeter. They should identify the scope of 523 their control as distinct from the perimeter of their constituency; if 524 other SIRTs operate hierarchically within their perimeter, these should 525 be identified and addressed here. 527 A disclosure of a team's authority may expose it to claims of 528 liability. Every team should seek legal advice on these matters. 529 (See section 3.7 for more on liability.) 531 3.4 Policies 533 3.4.1 Types of Incidents and Level of Support 535 The types of incident which the team is able to address and the 536 level of support which the team will offer when responding to each 537 type of incident should be summarized here in list form. The Services 538 section (see below) provides opportunity for more detailed definition 539 and to address non-incident related topics. 541 The level of support might change, depending on factors like workload 542 or completeness of information available. Such factors should be 543 outlined and their impact should be explained. As a list of known 544 types of incidents will be incomplete with regard to possible or future 545 incidents, a SIRT should also give some background on the "default" 546 support for each reported incident. 548 The team should state whether it will act on information it receives 549 about vulnerabilities which create opportunities for future incidents. 550 A commitment to act on such information on behalf of its constituency is 551 regarded as an optional pro-active service policy rather than a core 552 service requirement for a SIRT. 554 Expectations for Security Incident Response 26 March 97 556 3.4.2 Co-operation and Interaction with other Organizations 558 This section should make explicit which related groups with which the 559 SIRT routinely interacts with. Such interactions are not related to 560 the Security Incident Response provided, but are used to facilitate 561 better cooperation on technical topics or services. By no means should 562 details about cooperation agreements be given out, the main objective 563 of this section is to give the constituency a basic understanding 564 what kind of interactions are established and what their purpose is. 565 Examples of these are listed below. 567 Incident Response Teams: 568 A SIRT will often need to interact with other SIRTs. For example 569 a SIRT within a large company may need to report incidents to a 570 national SIRT, and a national SIRT may need to report incidents 571 to national SIRTs in other countries to deal with all sites 572 involved in a large-scale attack. 574 Vendors: 575 Larger vendors have their own SIRTs, but smaller vendors may not. 576 In such cases a SIRT will need to work directly with a vendor to 577 suggest improvements or modifications, to analyse the technical 578 problem or to test provided solutions. 580 Law-enforcement agencies: 581 These include the police and other investigative agencies. SIRTs 582 and users of the template should be sensitive to local laws and 583 regulations, which may vary considerably in different countries. 584 A SIRT might advise on technical details of attacks or seek advice 585 on the legal implications of an incident. Local laws and 586 regulations may include specific reporting and confidentiality 587 requirements. 589 Press: 590 A SIRT may be approached by the Press for information and comment 591 from time to time. This is discussed in more detail immediately 592 below. 594 Other: 595 This might include research activities or the relation to the 596 sponsoring organization. 598 Expectations for Security Incident Response 26 March 97 600 3.4.3 Reporting and Disclosure 602 The default status of any and all security-related information which a 603 team receives will usually be 'confidential,' but rigid adherence to 604 this makes the team to appear as a 'black hole.' Its template should 605 define what information it will report or disclose, to whom, and when. 607 Different teams are likely to be subject to different legal restraints 608 requiring or limiting disclosure, especially if they work in different 609 jurisdictions. In addition, they may have reporting requirements 610 imposed by their sponsoring organization. Each team's template should 611 specify any such restraints, both to clarify users' expectations and to 612 inform other teams. 614 Conflicts of interest, particularly in commercial matters, may also 615 restrain disclosure by a team; this document does not recommend on 616 how such conflicts should be addressed. 618 'Disclosure' includes (but is maybe not limited to): 620 - Reporting incidents within the constituency to other teams. By 621 this, site related information might become public knowledge, 622 accessible for everybody, especially the press. 624 - Handling incidents occurring within the constituency, but 625 reported from outside it. 627 - Reporting observations from within the constituency indicating 628 suspected or confirmed incidents outside it. 630 - Acting on reports of incidents occurring outside the constituency. 632 - Passing information about vulnerabilities to vendors, to Partner 633 SIRTs or directly to affected sites lying within or outside the 634 constituency. 636 - Feed-back to parties reporting incidents or vulnerabilities. 638 - The provision of contact information relating to members of the 639 constituency, members of other constituencies, other SIRTs or 640 law-enforcement agencies. 642 An explicit policy concerning disclosure to the Press can be helpful, 643 particularly in clarifying the expectations of a SIRT's constituency. 644 The press policy will have to clarify the same topics as above more 645 specifically, as the constituency will usually be very sensitive 646 Expectations for Security Incident Response 26 March 97 648 towards press contacts. 650 The reporting and disclosure policy should make clear who will be the 651 recipients of a SIRT's report in each circumstance. It should also 652 note whether the team will expect to deal through another SIRT 653 or directly with a member of another constituency over matters directly 654 involving that member. 656 A team will normally collect statistics. If such information are 657 distributed, the template's reporting and disclosure policy should 658 say so, and should list methods to obtain such statistics. 660 3.4.4 Communication and Authentication 662 Methods of secure and verifiable communication should be established. 663 This is necessary for communication between SIRTs and between a SIRT 664 and its constituents. The template should include public keys or 665 pointers to them, including key fingerprints, together with guidelines 666 on how to use this information to check authenticity and how to deal 667 with corrupted information (for example where to report this fact to). 669 At the moment it is recommended that every SIRT has - if possible - as 670 a minimum, a PGP key available. Teams may also make other mechanisms 671 available (for example PEM, MOSS, S/MIME), according to its needs and 672 the needs of its constituents. Note however, that SIRTs and users 673 should be sensitive to local laws and regulations. Some countries do 674 not allow strong encryption or enforce specific policies on the use of 675 encryption technology. In addition to encrypting sensitive information 676 whenever possible, correspondence should include digitally signatures. 677 (Please note, that in most countries, the protection of authenticity 678 by using digital signatures is not affected by existing encryption 679 regulations.) 681 For communication via telephone or facsimile a SIRT may keep secret 682 authentication data for parties with whom they may deal, such as an 683 agreed password or phrase. 685 3.4.5 Point of Customer Contacts 687 More detailed contact information might be provided. This might 688 include different contacts for different services or might be a list 689 of online information services. If specific procedures for access to 690 some services exist (like addresses for mailing list requests) these 691 should be explained here. 693 Expectations for Security Incident Response 26 March 97 695 3.5 Services 697 Services provided by each SIRT can be differentiated by whether they 698 relate to the main task, which is incident response, or are provided 699 in addition (optional in regard to the definition of a SIRT). 701 Incident response, which usually includes: 703 - Verification Help with the verification of 704 incidents, as well as their scope. 706 - Technical Assistance This may include analysis of 707 compromised systems. 709 - Eradication Elimination of the effects of a 710 security incident. 712 - Recovery Aid in restoring affected systems 713 and services to their status before 714 the security incident. 716 - Notification of other involved parties 718 Additional or optional services, which might include: 720 - Information provision This might include an archive of 721 known vulnerabilities, patches or 722 resolutions of past problems. 723 - Security Tools 725 - Education and training 727 - Product evaluation 729 - Site security auditing and consulting 731 3.6 Incident Reporting Forms 733 The use of reporting forms makes it simplier for both sides, users and 734 teams, to deal with incidents. The constituent may prepare answers to 735 various important questions before he or she actually contacts the team 736 and therefore come well prepared. The team gets all the necessary 737 information at once with the first report and can proceed efficiently. 739 Expectations for Security Incident Response 26 March 97 741 Depending on the objectives and services of a single SIRT, multiple 742 forms may be used, for example a reporting form for a new vulnerability 743 will be very different for the form used for reporting incidents. 745 It is most efficient to provide forms through the online information 746 services of the team. The exact pointers to them should be given in 747 the document, together with statements about appropriate use and 748 guidelines, for when and how to use the forms. If separate e-mail 749 addresses are supported for form based reporting, they should be 750 listed here again. 752 One example for such form is the Incident Reporting Form provided by 753 the CERT Coordination Center: 755 - ftp://info.cert.org/incident_reporting_form 757 3.7 Disclaimers 759 Although the document does not constitute a contract, liability might 760 conceivably result from its descriptions of services and purposes. The 761 inclusion of a disclaimer at the end of the template is therefore 762 recommended and should warn the user about possible limitations. 764 It should be noted that some forms of reporting or disclosure relating 765 to specific incidents or vulnerabilities can also imply liability, and 766 SIRTs should consider the inclusion of disclaimers in such material. 768 In situations where the original version of a document must be 769 translated into another language, the translation should carry a 770 disclaimer and a pointer to the original. For example: 772 Although we tried to carefully translate the original 773 document from German into English, we can not be certain 774 that both documents express the same thoughts in the same 775 level of detail and correctness. In all cases, where there 776 is a difference between both versions, the German version 777 is the binding version. 779 The use of and protection by disclaimers is effected by local laws and 780 regulations. Therefore each SIRT should be sensitive and if in doubt 781 should check the disclaimer with a lawyer. 783 Expectations for Security Incident Response 26 March 97 785 4 Appendix A: Glossary of Terms 787 This glossary defines terms used in describing security incidents and 788 Security Incident Response Teams. Only a limited list is included. 789 For more definitions please refer to other sources, for example to the 790 [RFC 1983]. 792 Constituency: 793 Implicit in the purpose of a Security Incident Response Team is 794 the existence of a constituency. This is the group of users, 795 sites, networks or organizations served by the team. The team 796 must be recognized by its constituency to be effective. 798 Security Incident: 799 For the purpose of this document this term is synonym to Computer 800 Security Incident: Any adverse event which compromises some aspect 801 of computer or network security. 803 The definition of an incident may vary between organizations, but 804 at least the following categories are generally applicable: 806 - Loss of confidentiality of information. 807 - Compromise of integrity of information. 808 - Denial of service. 809 - Misuse of service, systems or information. 810 - Damage of systems. 812 These are very general categories. For instance the replacement 813 of a system utility program by a Trojan Horse is an example of 814 'compromise of integrity,' and a successful password attack is an 815 example of 'loss of confidentiality.' Attacks, even if they 816 failed because of proper protection, might be regarded as an 817 Incident. 819 Within the definition of an incident the word 'compromised' is 820 used. Sometimes an administrator may only 'suspect' an incident. 821 During the response it must be established whether or not an 822 incident really occurred. 824 Security Incident Response Team: 825 Based on two of the definitions given above, a SIRT is a team 826 that coordinates and supports the response to security incidents 827 that involve sites within a defined constituency. 829 Expectations for Security Incident Response 26 March 97 831 In order to be considered a SIRT, a team must: 833 - Provide a (secure) channel for receiving reports about 834 suspected incidents. 835 - Provide assistance to members of its constituency in 836 handling these incidents. 837 - Disseminate incident-related information to its 838 constituency and to other involved parties. 840 Note that we are not referring here to police or other law 841 enforcement bodies which may investigate computer-related crime. 842 SIRT members, indeed, should not need to have any powers beyond 843 those of ordinary citizens. 845 Vendor: 846 A 'vendor' is any entity that produces networking or computing 847 technology, and is responsible for the technical content of that 848 technology. Examples of 'technology' include hardware (desktop 849 computers, routers, switches, etc.), and software (operating 850 systems, mail forwarding systems, etc.). 852 Note that the supplier of a technology is not necessarily the 853 'vendor' of that technology. As an example, an Internet Services 854 Provider (ISP) might supply routers to each of its customers, but 855 the 'vendor' is the manufacturer, being the entity responsible for 856 the technical content of the router, rather than the ISP. 858 Vulnerability: 859 A 'vulnerability' is a characteristic of a piece of technology 860 which can be exploited to perpetrate a security incident. For 861 example, if a program unintentionally allowed ordinary users to 862 execute arbitrary operating system commands in privileged mode, 863 this "feature" would be a vulnerability. 865 5 Appendix B: Related Material 867 Important issues in responding to security incidents on a site level 868 are contained in [RFC 1244], the Site Security Handbook, produced by 869 the Site Security Handbook Working Group (SSH). This document will 870 be updated by the SSH working group and will give recommendations for 871 local policies and procedures, mainly related to the avoidance of 872 security incidents. 874 Other documents of interest for the discussion of SIRTs and their 875 tasks are available by anonymous FTP. A collection can be found on: 877 Expectations for Security Incident Response 26 March 97 879 - ftp://ftp.cert.dfn.de/pub/docs/csir/ 880 Please refer to file 01-README for further information about 881 the content of this directory. 883 Some especially interesting documents in relation to this document are 884 as follows: 886 - ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ 887 reports/R-92-01 888 This report contains the Operational Framework of CERT-NL, the 889 SIRT of SURFnet (network provider in the Netherlands). 891 - For readers interested in the operation of FIRST (Forum of 892 Incident Response and Security Teams) more information is 893 collected in Appendix C. 895 - http://hightop.nrl.navy.mil/news/incident.html 896 This document leads to the NRL Incident Response Manual. 898 - http://www.cert.dfn.de/eng/team/kpk/certbib.html 899 This document contains an annotated bibliography of available 900 material, documents and files about the operation of SIRTs 901 with links to many of the referenced. 903 - ftp://info.cert.org/incident_reporting_form 904 This Incident Reporting Form is provided by the CERT 905 Coordination Center to gather incident information and to avoid 906 additional delays by requesting the sites for more detailed 907 information. 909 - http://www.cert.org/cert.faqintro.html 910 A collection of frequently asked questions from the CERT 911 Coordination Center. 913 6 Appendix C: Known Security Incident Response Teams 915 Today, there are many different SIRTs but no single source list every 916 team. Most of the major and long established teams (the first SIRT was 917 founded in 1988) are nowadays member of FIRST, the worldwide Forum of 918 Incident Response and Security Teams. Actually more than 55 teams are 919 members (1 in Australia, 13 in Europe, all others from America). 920 Information about FIRST can be found: 922 - http://www.first.org/ 924 Expectations for Security Incident Response 26 March 97 926 The actual list of members is available also, with the relevant contact 927 information and some additional information provided by the single 928 teams: 930 - http://www.first.org/team-info/ 932 For SIRTs which want to become members of this forum (please note, that 933 a team needs a sponsor - a team already full member of FIRST - to be 934 introduced), the following files contain more information: 936 - http://www.first.org/about/op_frame.html 937 The Operational Framework of FIRST. 939 - http://www.first.org/docs/newmem.html 940 Guidelines for teams which want to become member of FIRST. 942 Many of the European teams, regardless if they are members of FIRST or 943 not, are listed by countries on a page maintained by the German SIRT: 945 - http://www.cert.dfn.de/eng/csir/europe/certs.html 947 To learn about existing teams and maybe more suitable teams for one's 948 need it is always a good approach, to ask either existing teams or an 949 Internet Service Provider for the "right" contact. 951 Expectations for Security Incident Response 26 March 97 953 7 Appendix D: Outline for SIRT Template 955 This outline summarizes the issues addressed in this document in a logical 956 structure suitable to communicate the policies and procedures for the 957 interaction with SIRTs easily to the team's constituency. A 'filled-in' 958 example of this template is given as Appendix E. 960 1. Contact Information 961 1.1 Name of the Team 962 1.2 Address 963 1.3 Time Zone 964 1.4 Telephone Number 965 1.5 Facsimile Number 966 1.6 Other Telecommunication 967 1.7 Electronic Mail Address 968 1.8 Public Keys and Encryption Information 969 1.9 Team Members 970 1.10 Other Information 972 2. Document Updates 973 2.1 Date of Last Update 974 2.2 Distribution List for Notifications 975 2.3 Locations where this Document May Be Found 977 3. Charter 978 3.1 Mission Statement 979 3.2 Constituency 980 3.3 Sponsors and/or Affiliation 981 3.4 Authority 983 4. Policies 984 4.1 Types of Incidents and Level of Support 985 4.2 Cooperation and Interaction with Other Entities 986 4.3 Disclosure of Information 987 4.4 Communication and Authentication 988 4.5 Points of Customer Contacts 990 5. Services 991 5.1 Incident Response 992 5.2 Proactive Activities 994 6. Incident Reporting Forms 996 7. Disclaimers 998 Expectations for Security Incident Response 26 March 97 1000 8 Appendix E: Example - 'filled-in' Template for a SIRT 1002 Below is an example, a filled-in template for a SIRT called XYZ 1003 to avoid any confusion with existing teams. By no means does this 1004 example imply, that a new founded SIRT should reuse this text. 1005 It is for example purposes only. 1007 SIRT Template for XYZ-SIRT 1008 -------------------------- 1010 Note: no digital signature is currently available for this SIRT 1011 Template. We'll put one up as soon as the technology is adopted 1012 by XYZ Enterprises. 1014 1. Contact Information 1016 1.1 Name of the Team 1017 "XYZ-SIRT": the XYZ Computer Emergency Response Team. 1019 1.2 Address 1020 XYZ SIRT 1021 XYZ Enterprises 1022 Private Bag 12-345 1023 MyTown 1024 MyCountry 1026 1.3 Time Zone 1027 MyCountry/Eastern (GMT-0500, and GMT-0400 from April to October) 1029 1.4 Telephone Number 1030 +1 234 567 7890 (ask for the XYZ-SIRT) 1032 1.5 Facsimile Number 1033 +1 234 567 7654 (this is *not* a secure fax) 1035 1.6 Other Telecommunication 1036 None available. 1038 1.7 Electronic Mail Address 1039 1041 1.8 Public Keys and Other Encryption Information 1042 Encryption is not currently available, but we plan to install 1043 PGP as soon as possible. Our PGP public key will appear here 1044 as soon as it is available. 1046 Expectations for Security Incident Response 26 March 97 1048 1.9 Team Members 1049 Jane Doe of Computing Services is the XYZ-SIRT 1050 coordinator. Other team members will be listed here once 1051 their participation is confirmed. 1053 2. Document Updates 1055 2.1 Date of Last Update 1056 Please see the bottom of this Web page for this information. 1058 2.2 Distribution List for Notifications 1059 Notifications of updates are submitted to our mailing list 1060 . (Subscription request should 1061 go to .) 1063 2.3 Locations where this Document May Be Found 1064 This template is available from the XYZ SIRT WWW 1065 site; its URL is 1066 http://www.sirt.xyz.org/op_frame.html 1067 The template will be signed with the XYZ-SIRT's PGP 1068 key. 1070 3. Charter 1072 3.1 Mission Statement 1073 The purpose of the XYZ-SIRT is, first, to assist members of 1074 XYZ community in implementing proactive measures to reduce 1075 the risks of computer security incidents, and second, to 1076 assist XYZ community in responding to such incidents when 1077 they occur. 1079 3.2 Constituency 1080 The XYZ-SIRT's constituency is the XYZ SIRT community, 1081 as defined in the context of the "XYZ Policy on Computing 1082 Facilities". 1084 3.3 Sponsors and/or Affiliation 1085 None. 1087 3.4 Authority 1089 The XYZ-SIRT operates under the auspices of, and with 1090 authority delegated by, the Department of Computing Services 1091 of XYZ Enterprises. The Department in turn receives its 1092 authority from the formal ruling bodies of XYZ, as 1093 set out in the "Policy on Computing Facilities". The XYZ-SIRT 1095 Expectations for Security Incident Response 26 March 97 1097 has no direct authority over systems at XYZ Enterprises 1098 at large. However, it benefits from the direct authority of 1099 Computing Services with respect to systems managed by this 1100 Department. Also, because Computing Services manages the 1101 XYZ Enterprises Network, and is responsible for connectivity 1102 to it, the Department has indirect authority over systems 1103 in other departments, inasmuch as the Department can order 1104 such systems to be disconnected from the network should 1105 circumstances warrant it. 1107 The XYZ-SIRT expects to work cooperatively with system 1108 administrators and users at XYZ, and, insofar as 1109 possible, to avoid authoritarian relationships. However, 1110 should circumstances warrant it, the XYZ-SIRT will appeal to 1111 Computing Services to exert its authority, direct or indirect, 1112 as necessary. 1114 4. Policies 1116 4.1 Types of Incidents and Level of Support 1118 The XYZ-SIRT is authorized to address all types of computer 1119 security incidents which occur, or risk occurring, at 1120 XYZ Enterprises. 1122 The level of support given by XYZ-SIRT will vary depending on 1123 the type and severity of the incident or issue, the type of 1124 consituent, the size of the user community affected, and the 1125 XYZ-SIRT's resources at the time. 1127 No direct support will be given to end users; they are 1128 expected to contact their system administrator, network 1129 administrator, or department head for assistance. The 1130 XYZ-SIRT will support the latter people. 1132 While the XYZ-SIRT understands that there exists great 1133 variation in the level of system administrator expertise at 1134 XYZ, and while the XYZ-SIRT will endeavor to present 1135 information and assistance at a level appropriate to 1136 each person, the XYZ-SIRT cannot train system administrators, 1137 and it cannot perform system maintenance on their behalf. 1138 In most cases, the XYZ-SIRT will provide pointers to the 1139 information needed to implement appropriate measures. 1141 Expectations for Security Incident Response 26 March 97 1143 4.2 Cooperation and Interaction with Other Entities 1145 - Other sites: 1146 The XYZ-SIRT will cooperate with other SIRTs (security 1147 incident response teams) and with system administrators at 1148 other sites, to the extent that their bona fide can be 1149 verified. Should provincial or national SIRTs be 1150 constituted, XYZ-SIRT will explore the possibility of peer 1151 relationships with them. The possibility of peer 1152 relationships with close neighbors will also be explored; 1153 unofficial cooperative climates already exist between XYZ 1154 and several nearby universities and large corporations. 1155 While there are no legal requirements that XYZ-SIRT provide 1156 any information to any body outside XYZ (aside from 1157 law enforcement agencies), XYZ-SIRT will provide such 1158 information when the good of the community justifies it. 1159 However, unless identifying information is needed to track 1160 an incident in progress, such information will be stripped 1161 from the report (unless the affected department gives its 1162 permission that the real information be used). 1163 - Vendors: 1164 The XYZ-SIRT wishes to encourage vendors of all kinds of 1165 networking and computer equipment, software, and services 1166 to improve the security of their products. In aid of 1167 this, a vulnerability discovered in such a product will be 1168 reported to its vendor, along with all technical details 1169 needed to identify and fix the problem. Identifying 1170 details will not be given to the vendor without the 1171 permission of the affected parties. 1172 - Law enforcement: 1173 XYZ has its own Security Department. ( I NEED TO LOOK UP 1174 THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ 1175 SECURITY, AND OUTSIDE POLICE FORCES. ) Informal working 1176 relationships already exist between some system 1177 administrators at XYZ and the local police; interest 1178 has been expressed by all parties in formalizing these 1179 relationships. Any progress 1180 made in that area will be reflected in this section. 1181 In the meantime, authorized and unauthorized users of the 1182 XYZ Computing Facilities should be aware that the 1183 XYZ-SIRT will cooperate fully with law enforcement 1184 agencies in detecting, reporting, documenting, and 1185 prosecuting violations of the law; users concerned about 1186 confidentiality are referred to the XYZ "Policy on 1187 Computing Facilities". 1189 Expectations for Security Incident Response 26 March 97 1191 - The Press: 1192 The XYZ-SIRT will not interact directly with the Press. 1193 If necessary, information will be provided to the 1194 XYZ Public Relations Department, and to the 1195 Customer Relations group of the Computing Services 1196 Department. All queries will be referred to these two 1197 bodies. 1198 - The XYZ SIRT community: 1199 Details of incidents may be released to Computing Services 1200 management, XYZ management, or the Computer 1201 Resources Committee; these bodies will be charged with 1202 maintaining the confidentiality of the information. General 1203 report of incidents, summaries of multiple incidents, and 1204 statistics may be made available to the general XYZ 1205 community, with identifying information stripped (except 1206 where permission has been obtained from the affected 1207 parties). There is no obligation on the part of the 1208 XYZ-SIRT to report incidents to the community, though it 1209 may choose to do so; in particular, it is likely that the 1210 XYZ-SIRT will inform all affected parties of the ways in 1211 which they were affected. 1212 - The public at large: 1213 In general, no particular efforts will be made to 1214 communicate with the public at large, though the XYZ-SIRT 1215 recognizes that, for all intents and purposes, information 1216 made available to the XYZ community is in effect 1217 made available to the community at large, and will tailor 1218 the information in consequence. 1219 - The computer security community: 1220 While members of XYZ-SIRT may participate in discussions 1221 within the computer security community, such as newsgroups, 1222 mailing lists (including the full-disclosure list 1223 "bugtraq"), and conferences, they will treat such forums 1224 as though they were the public at large. While technical 1225 issues (including vulnerabilities) may be discussed to any 1226 level of detail, any examples taken from XYZ-SIRT 1227 experience will be disguised to avoid identifying the 1228 affected parties. 1230 In the paragraphs above, the "affected parties" refers to the 1231 legitimate owners, operators, and users of the relevant 1232 computing facilities. It does not refer to unauthorized 1233 users, including otherwise authorized users making 1234 unauthorized usage of a facility; such intruders may have no 1235 expectation of confidentiality from the XYZ-SIRT. They may or 1236 may not have legal rights to confidentiality; such rights will 1237 of course be respected where they exist. 1239 4.3 Disclosure of Information 1241 The following types of information will be stored and handled 1242 by XYZ-SIRT: 1243 - Contact info for constituents. 1244 - Technical info about a vulnerability. 1245 - Technical info about XYZ facilities. 1246 - Information about incidents: 1247 - Statistical summaries 1248 - Admission of incident of certain type 1249 - Admission of root compromise 1250 - Admission of packet sniffing attack 1251 - Admission that user accounts were compromised 1252 - Description of incident 1253 - Identity of affected systems 1254 - Identity of affected people 1255 - Identity of perpetrator 1257 Recipients of information are - depending on the need to 1258 know - are as follows: 1259 - XYZ management 1260 - Computing Services management 1261 - Affected sysadmin at XYZ 1262 - Affected sysadmin (or SIRT) at another site 1264 Expectations for Security Incident Response 26 March 97 1266 - Affected user(s) at XYZ 1267 - All sysadmins potentially concerned (potentially 1268 vulnerable) at XYZ 1269 - All sysadmins at XYZ 1270 - All users potentially concerned at XYZ 1271 (information will leak to general public) 1272 - All users at XYZ (ditto) 1273 - Computer security community 1274 - Peer sysadmins and SIRTs 1275 - Vendors 1276 - Law enforcement 1278 4.4 Communication and Authentication 1280 In view of the types of information that the XYZ-SIRT will 1281 likely be dealing with, telephones will be considered 1282 sufficiently secure to be used even unencrypted. Unencrypted 1283 e-mail will not be considered particularly secure, but will be 1284 sufficient for the transmission of low-sensitivity data. If 1285 it is necessary to send highly sensitive data by e-mail, PGP 1286 will be used. Network file transfers will be considered to 1287 be similar to e-mail for these purposes. 1289 Where it is necessary to establish trust, for example before 1290 relying on information given to the XYZ-SIRT, or before 1291 disclosing confidential information, the identity and bona 1292 fide of the other party will be ascertained to a reasonable 1293 degree of trust. Within XYZ, and with known 1294 neighbor sites, referrals from known trusted people will 1295 suffice to identify someone. Otherwise, appropriate methods 1296 will be used, such as a search of FIRST members, the use of 1297 WHOIS and other Internet registration information, etc, along 1298 with telephone call-back or e-mail mail-back to ensure that 1299 the party is not an impostor. Incoming e-mail whose data must 1300 be trusted will be checked with the originator personally, or 1301 by means of digital signatures. 1303 4.5 Points of Customer Contact 1305 The preferred method for contacting the XYZ-SIRT will be 1306 e-mail. If this is not possible, or not advisable for 1307 security reasons, the XYZ-SIRT can be reached by telephone 1308 during regular office hours. 1310 Expectations for Security Incident Response 26 March 97 1312 5. Services 1314 5.1 Incident Response 1316 XYZ-SIRT will help users and administrators to handle the 1317 technical and organizational aspects of incidents. By that, 1318 it will provide and facilitate: 1319 - to understand the extend of the incident 1320 - ... 1322 5.2 Proactive Activities 1324 The XYZ-SIRT will coordinate and maintain the following 1325 services to the extent possible depending on its resources: 1326 - Information services 1327 - List of departmental security contacts, administrative 1328 and technical. 1329 - Mailing lists to inform security contacts of new 1330 information relevant to their computing environments. 1331 - Repository of vendor-provided and other security-related 1332 patches for various operating systems. 1333 - Repository of security tools for use by sysadmins. 1334 - "Clipping" service for various existing resources, such 1335 as major mailing lists and newsgroups. 1336 - Auditing services 1337 - Central file integrity checking service for Unix 1338 machines. 1339 - Security level assignments; machines at XYZ 1340 will be audited and assigned a security level. 1341 - Archiving services 1342 - Records of security incidents handled. 1344 6. Incident Reporting Forms 1346 There are no own forms developed yet for reporting incidents 1347 to XYZ-SIRT. If possible, please make us of the Incident 1348 Reporting Form of the CERT Coordination Center (Pittsburgh, PA). 1349 The actual version is available from: 1350 ftp://info.cert.org/incident_reporting_form 1352 7. Disclaimers 1354 While every precaution will be taken in the preparation of 1355 information, notifications and alerts, XYZ-SIRT assumes no 1356 responsibility for errors or omissions, or for damages 1357 resulting from the use of the information contained within. 1359 Expectations for Security Incident Response 26 March 97 1361 9 References 1363 [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. - July 23, 1364 1991. - 101 pages. - FYI 8. 1366 [RFC 1983] G. Malkin / Internet Users' Glossary. - August 16, 1996. - 1367 62 pages. - FYI 18. 1369 10 Security Considerations 1371 This document discusses issues of the operation of Security Incident 1372 Response Teams, and the teams interactions with their constituency. 1373 It is therefore not directly concerned with the security of protocols, 1374 applications or network systems themselves. It is not even concerned 1375 about the response and reaction to security incidents. 1377 Nonetheless, it is vital that SIRTs establish secure communication 1378 channels with other teams, and with members of their constituency. 1379 They must also secure their own systems and infrastructure, to protect 1380 the interests of their constituency and to maintain the confidentiality 1381 of the identity of victims and reporters of security incidents. 1383 11 Authors' Addresses 1385 Nevil Brownlee 1386 ITSS Technology Development 1387 The University of Auckland 1389 Phone: +64 9 373 7599 x8941 1390 E-mail: n.brownlee@auckland.ac.nz 1392 Erik Guttman 1393 Sun Microsystems, Inc. 1394 Gaisbergstr. 6 1395 69115 Heidelberg Germany 1397 Phone: +49 6221 601649 1398 E-Mail: eguttman@eng.sun.com 1400 This document expires September 26, 1997.