idnits 2.17.1 draft-ietf-grip-framework-irt-02.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-20) 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. ** Expected the document's filename to be given on the first page, but didn't find any == 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.) ** There are 23 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 27 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 424: '...e Team, the team MUST provide incident...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 1996) is 10232 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 April 1996 6 Expectations for Security Incident Response 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute working 13 documents as Internet Drafts. This Internet Draft is a product of the 14 Internet Accounting Working Group of the IETF. 16 Internet Drafts are draft documents valid for a maximum of six months. 17 Internet Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet Drafts as 19 reference material or to cite them other than as a 'working draft' or 20 'work in progress.' 22 Please check the I-D abstract listing contained in the Internet-drafts 23 Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 24 ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or 25 any other Internet Draft. 27 Abstract 29 This document is intended to facilitate the setting of expectations 30 regarding the operation of Security Incicident Response Teams (SIRTs). 31 It describes the various important topics in the form of a 'template,' 32 through which every SIRT should describe itself and its functions. 34 SIRT clients have a legitimate need and right to fully understand the 35 policies and procedures of their Security Incident Response Team. A 36 SIRT's template supplies details for the various important topics which 37 clients must consider when selecting a SIRT. 39 Contents 41 1 Introduction 2 42 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 1.2 Publishing SIRT Templates . . . . . . . . . . . . . . . . . . 5 44 1.3 Establishing Peering Between SIRTs . . . . . . . . . . . . . . 6 45 2 Description Template: Security Incident Response Team 6 47 3 Purpose of the Template 8 48 3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 8 50 4 The Security Incident Response Team Template 9 51 4.1 Contact Information . . . . . . . . . . . . . . . . . . . . . 9 52 4.2 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10 53 4.2.1Date of last update . . . . . . . . . . . . . . . . . . . . 10 54 4.2.2Distribution list for Template Updates . . . . . . . . . . 10 55 4.3 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 4.3.1Mission Statement . . . . . . . . . . . . . . . . . . . . . 10 57 4.3.2Constituency . . . . . . . . . . . . . . . . . . . . . . . 11 58 4.3.3Sponsoring organisation / affiliation . . . . . . . . . . . 11 59 4.3.4Authority . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.4 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 4.4.1Types of incidents and level of support . . . . . . . . . . 12 62 4.4.2Co-operation and interaction with other organizations . . . 12 63 4.4.3Reporting and Disclosure . . . . . . . . . . . . . . . . . 13 64 4.4.4Communication and authentication . . . . . . . . . . . . . 14 65 4.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.6 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 15 67 4.7 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 5 Secondary Purposes of this Document 16 71 6 Appendix A: Note on procedure definitions 16 73 7 Appendix B: Known Incident Response Teams 17 75 8 Appendix C: Sample Incident Reporting Form 17 77 9 Security Considerations 25 79 10 Editor's Address 25 81 1 Introduction 83 The GRIP Working Group was formed to produce guidelines and 84 recommendations to facilitate the consistent handling of security 85 incidents in the Internet community. Although it is focused on the 86 Internet, many of the concepts discussed will also be useful for other 87 forms of local- and wide-area networks and internets. 89 Many computer security incidents either originate outside local 90 community boundaries and affect other 'outside' sites, or originate 91 outside the local community and affect hosts or users within it. The 92 handling of security incidents will therefore often involve multiple 93 Security Incident Response Teams. Because of this characteristic it is 94 important for every community to have a good security policy, and to 95 have a Security Incident Response Team (SIRT) in place to manage 96 communications across community boundaries in a consistent way. 98 In the past there have been misunderstandings regarding expectations of 99 response teams. The goal of this document is to provide a framework in 100 which to set expectations. By defining such a framework the community 101 can express areas and topics that need to addressed by any SIRT. 103 'Consistent handling' implies that any group calling itself a SIRT must 104 react to security incidents or to threats of them in ways which the 105 Internet community agrees to be in its general interest. Every SIRT 106 needs to define clearly the services they offer and the level at which 107 they are offered to the client. Such definitions will be particularly 108 important in contracts and/or agreements which SIRTs make with their 109 clients. 111 The "Expectations for Security Incident Response" document is seen as 112 resting on the work of individual SIRTs and the cooperation between 113 them. It recommends a 'template' through which every SIRT should 114 describe itself and its functions. It further recommends that templates 115 should be accessible among teams, to make possible a fully effective 116 cooperative response framework for incidents or threats across the 117 entire domain affected by them. 119 1.1 Definitions 121 This section defines terms used in describing security incidents and 122 response teams. For the purpose of the GRIP documents only a limited 123 list is really needed. This should help maintain focus on the purpose 124 of the documents, and prevent a duplication of other definitions or - 125 even worse - a proliferation of competing definitions. 127 Constituency 128 ------------ 130 Implicit in the purpose of a Security Incident Response Team is the 131 existence of a constituency. This is the group of clients, sites, 132 networks or organizations served by the team. 134 Security Incident 135 ----------------- 137 For the purpose of this document: 139 'A computer security incident is any event which compromises 140 some aspect of computer or network security.' 142 The definition of an incident may vary between organizations, but at 143 least the following categories are generally applicable: 145 * loss of confidentiality, 146 * compromise of integrity, 147 * denial of service, 148 * misuse, 149 * damage. 151 These are very general categories. For instance the forging of an 152 electronic mail message and a successful password attack are two 153 examples of 'compromise of integrity.' 155 Within the definition of an incident the word 'compromised' is used. 156 Sometimes an administrator may only 'suspect' an incident. During the 157 handling of a call it must be established whether or not an incident 158 really occurred. 160 Security Incident Response Team 161 ------------------------------- 163 Based on two of the definitions given above: 165 'A Security Incident Response Team is a group authorized to 166 manage response to security incidents that involve sites within 167 its defined constituency.' 169 In order to be considered a SIRT, a group must: 171 * provide a channel for receiving reports about suspected incidents, 172 * provide assistance to members of its constituency in handling these 173 incidents, 175 * disseminate incident-related information to its constituency and to 176 other related parties. 178 Vendor 179 ------ 181 A 'vendor' is any entity that produces networking or computing 182 technology, and is responsible for the technical content of that 183 technology. Examples of 'technology' include hardware (desktop 184 computers, routers, switches, etc.), and software (operating systems, 185 mail forwarding systems, etc.). 187 Note that the supplier of a technology is not necessarily the 'vendor' 188 of that technology. As an example, an Internet Services Provider (ISP) 189 might supply routers to each of its customers, but the 'vendor' is the 190 manufacturer, being the entity responsible for the technical content of 191 the router, rather than the ISP. 193 Vulnerability 194 ------------- 196 A 'vulnerability' is a characteristic of a piece of technology which can 197 be exploited to perpetrate a security incident. For example, if a 198 program allowed ordinary userss to execute operating system commands in 199 privileged mode, this "feature" would be a vulnerability. 201 1.2 Publishing SIRT Templates 203 Every SIRT should publish information about its policies and services in 204 the form of a completed template. The simplest way for a SIRT to make 205 its template widely available is to publish it on its own information 206 server so that clients in its constituency can easily find it. 207 Templates published as pages in the World Wide Web should include the 208 phrase 'SIRT Template' in their title - this will allow Web search 209 engines to find them easily. 211 Whether or not templates are published in a repository, clients - and 212 potential clients - of a SIRT will need to be able to authenticate a 213 template (verify that it was indeed published by the SIRT) and check 214 that it has not been modified (for example by verifying a digital 215 signature for it). 217 To facilitate interaction between SIRTs, it would be useful to have a 218 central repository for them. The GRIP Working Group believe that some 219 of the existing Internet archive areas could be used for this purpose. 220 The keeper of each template repository will be responsibly for verifying 221 the identity of each SIRT lodging a template in the repository. 223 1.3 Establishing Peering Between SIRTs 225 When a SIRT (SIRT A) wishes to establish a working relationship with 226 another SIRT (SIRT B), a responsible person from SIRT A will need to 227 contact a similarly responsible person at SIRT B. The SIRT B person then 228 has the problem: "how do I know who I'm talking to?" 230 It is very easy to send forged e-mail, and not hard to establish a 231 (false) identity by telephone. PGP provides an effective way of 232 securing e-mail, but securing voice communications is much harder. At 233 present call-back is probably the only simple authentication method. 234 This may change as technologies such as scrambled telephones, or 235 PGP-phone on the Internet become available. 237 PGP relies on a 'web of trust,' built up by having known (and trusted) 238 people sign PGP keys. This model could also be used for SIRTs. To 239 achieve this each SIRT should publish a list of the SIRTs they have 240 peering arrangements (i.e. working relationships) with, including PGP 241 public keys for them. 243 Note that there is a difference between a peering agreement, where the 244 SIRTs involved agree to work together and share information, and simple 245 co-operation, where SIRT B (or any other client) simply contacts SIRT A 246 and asks for help or advice. Note also that any client wanting direct 247 help in tracking an incident must be prepared to provide sufficient 248 information about the incident to make tracking possible. 250 2 Description Template: Security Incident Response Team 252 The Template is summarized in the section immediately below, and the 253 remainder of the document describes its components. 255 Contact Information 256 ------------------- 257 * name of the team 258 * address 259 * time zone 260 * telephone number 261 * facsimile number 262 * other telecommunication like STU-III, secure facsimile 263 * electronic mail address 264 * encryption methods for communication: PGP, PEM, MOSS, .. 265 * PGP public key (if PGP used) 267 Template Updates 268 ---------------- 269 * date of last update 270 * locations where this template may be found 272 Charter 273 ------- 274 * mission statement 275 * constituency 276 * sponsor / affiliation 277 * authority 279 Policies 280 -------- 281 * types of incidents 282 * level of support 283 * disclosure 284 - of compromised site's information 285 - the compromise of SIRT site to constituency 286 - incident reporting requirements 287 * cooperation & interaction with 288 - incident response teams 289 - vendors 290 - investigative agencies 291 - involved sites 292 - press 293 * communication & authentication 294 * point of customer contacts 296 Services 297 -------- 298 * incident response 299 - verification 300 - understanding 301 - coping 302 - notification 303 * proactive activities 305 Incident Reporting Forms 306 ------------------------ 308 Disclaimers 309 ----------- 311 3 Purpose of the Template 313 The Template which this document proposes is expected to be used by a 314 response team to describe what it does, and in the process create 315 criteria against which its performance can be measured. The Template 316 does not attempt to specify a "correct" way for the team to operate, but 317 does recommend on specific policies and functions seen as necessary for 318 such a team to play a consistent role with other SIRTs throughout the 319 networking community. It also comments on additional roles a team might 320 include in the ambit of its operations. 322 The primary purposes of the Template are: 324 - to help SIRTs improve the way they operate; 326 - to improve interactions between different SIRTs, and between SIRTs 327 and other organizations such as vendors and law-enforcement 328 agencies; 330 - to note necessary interactions with their constituencies in setting 331 expectations and defining policies; 333 - to help new groups understand what it takes to "be" a SIRT. 335 A Template might appear to provide a marketing tool for comparing 336 different teams, but this kind of marketing use (or abuse) is strongly 337 discouraged by the GRIP Working Group. 339 3.1 Other Related Material 341 This 'Framework for Response Teams' document is the first produced by 342 the GRIP Working Group. A second document will set out guide-lines for 343 technology vendors to help them handle security incidents. The 344 definition of terms given in the next section applies to both documents. 346 Another relevant IETF document is RFC 1244, the Site Security Handbook, 347 produced by (and being updated by) the Site Security Handbook Working 348 Group (SSH). Site requirements and recommendations are covered by the 349 Handbook, while response team expectations and procedures are addressed 350 by the GRIP documents. 352 Other documents of interest for the discussion of incident response 353 teams and their tasks are available by anonymous FTP. A collection can 354 be found on: 356 * ftp://ftp.nic.surfnet.nl/surfnet/net-security/ 357 cert-nl/docs/reports/R-92-01 359 Some especially interesting documents are: 361 * CERT-NL Framework 362 ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt 364 * FIRST potential members 365 ftp://ftp.first.org/pub/first/newmemlt.txt 366 ftp://ftp.first.org/pub/first/profile.txt 367 ftp://ftp.first.org/pub/first/op`frame.txt 368 http://www.first.org/first 370 * NRL Incident Response Manual 371 http://hightop.nrl.navy.mil/news/incident.html 373 * Bibliography 374 http://www.cert.dfn.de/eng/team/kpk/certbib.html 376 4 The Security Incident Response Team Template 378 This material which follows is addressed to those responsible for 379 Security Incident Response Teams. 381 4.1 Contact Information 383 Full details of how to contact the SIRT should be listed here. 385 4.2 Template Updates 387 Details of a Security IRT change with time, so the template must 388 indicate when it was last changed, who will be informed of future 389 changes, and (by implication) who will not. Without this, it is 390 inevitable that misunderstandings and misconceptions will arise over 391 time. 393 4.2.1 Date of last update 395 This should be sufficient to allow anyone interested to evaluate the 396 currency of the template. 398 4.2.2 Distribution list for Template Updates 400 Persons on this list are notified automatically whenever the template is 401 changed. The list might normally cover the constituency and any other 402 groups the SIRT has frequent interactions with. Readers not on the list 403 can then recognise that they should check the central repository (above) 404 for possible updates. 406 Digital signatures should be used for update messages sent by a SIRT to 407 those on its distribution list. 409 4.3 Charter 411 Every SIRT must have a charter which specifying what it is to do, and 412 the authority under which it will do it. The charter should include at 413 least the following: 415 * mission statement 416 * constituency 417 * sponsor / affiliation 418 * authority 420 4.3.1 Mission Statement 422 The mission statement should focus on the team's core activities, 423 already stated in the definition of a SIRT. In order to be considered a 424 Security Incident Response Team, the team MUST provide incident 425 response, as defined in section 1.1. 427 The goals and purposes of a team are especially important, and require 428 clear, succinct definition. 430 4.3.2 Constituency 432 A SIRT's constituency (as defined above) can be determined in many ways. 433 For example it could be a company's employees or its paid subscribers, 434 or it could be defined in terms of a technological focus, such as the 435 users of a particular operating system. 437 The definition of constituency should create a perimeter around the 438 group to whom the team will provide service. The policy section (below) 439 should explain how requests from outside the perimeter will be handled. 441 Constituencies might overlap, as when an ISP supports a SIRT, but 442 delivers services to customer sites which also have SIRTs. The 443 Authority section (below) should make such relationships clear. 445 People within the constituency have to learn that there is a Security 446 IRT for their purposes; the building of a trusted relationship with the 447 constituency is an on-going process which never ends. 449 4.3.3 Sponsoring organisation / affiliation 451 Any sponsoring organisations or affiliations, if they exist, must be 452 disclosed to constituents. For example, the CERT Coordination Centre's 453 sponsoring organisation is the Software Engineering Institute, Carnegie 454 Mellon University; the sponsoring organisation for a SIRT within a large 455 coprporation would be the corporation itself. SIRTs within smaller 456 organisations may have no sponsoring organisation, in which case they 457 should specify 'none.' 459 4.3.4 Authority 461 SIRTs may not have authority to intervene in the operation of all the 462 systems within their perimeters. Each should identify the scope of its 463 control as distinct from the perimeter of its constituency; if other 464 SIRTs operate hierachically within this perimeter, they should be 465 identified. 467 For example, a corporate SIRT may have authority to force the 468 installation of software patches as the result of an incident. Other 469 SIRTs, such as a national SIRT, may only be able to advise that such 470 patches should be installed. 472 4.4 Policies 474 4.4.1 Types of incidents and level of support 476 The types of incident which the team is authorised to address and the 477 level of support the team will contribute in assisting with each type of 478 incident should be summarized here in list form. The Services section 479 (later) provides opportunity for more detailed definition. 481 The team should state whether it will act on information it receives 482 about vulnerabilities which create opportunities for future incidents. 483 A commitment to act on such information on behalf of its constituency is 484 regarded as an optional pro-active service policy rather than a core 485 service requirement for a SIRT. 487 4.4.2 Co-operation and interaction with other organizations 489 This section should make explicit the related groups with which the SIRT 490 routinely interacts. Examples of these are listed below. 492 Incident Response Teams: A SIRT will often need to interact with 493 other SIRTs. For example a SIRT within a large company may need to 494 report incidents to a national SIRT, and a national SIRT may need to 495 report incidents to national SIRTs in other countries. 497 Vendors: The interaction here is in reporting vulnerabilities 498 discovered during an incident. If your SIRT has relationships with 499 product vendors, these should be described here. Larger vendors have 500 their own SIRTs, but smaller vendors may not. In such cases a SIRT will 501 need to work directly with a vendor. 503 Law-enforcement agencies: These include the police and other 504 investigative agencies. SIRTs and users of the template should be 505 sensitive to local laws and regulations, which may vary considerably in 506 different countries. 508 Press: A SIRT may be approached by the Press for information and 509 comment from time to time. This is discussed in more detail below 510 (Reporting and Disclosure). 512 4.4.3 Reporting and Disclosure 514 The default status of any and all security-related information which a 515 team receives can only be 'confidential,' but rigid adherence to this 516 makes the team a 'black hole.' Its template should define what 517 information it will report or disclose, to whom, and under what 518 circumstances. 520 Different teams are likely to be subject to different legal restraints 521 requiring or limiting disclosure, especially if they work in different 522 jurisdictions. In addition, they mave have reporting requirements 523 imposed by their sponsoring organisation, or they may be required by law 524 to report certain kinds of security incident. Each team's template 525 should specify any such restraints and requirements, both to clarify 526 clients' expectations and to inform other teams. As an example of such 527 restraints, the Dutch equivalent of the U.S. Federal Bureau of 528 Investigation (FBI) has some kinds of documents which may NOT be 529 recorded electronically. 531 Conflicts of interest, particularly in commercial matters, may also 532 restrain disclosure by a team; this document does not recommend on how 533 such conflicts should be addressed. 535 An explicit policy concerning disclosure to the Press can be helpful, 536 particularly in clarifying the expectations of a SIRT's constituency. 538 'Disclosure' includes: 540 - reporting incidents within the constituency to other teams; 542 - handling incidents occurring within the constituency, but reported 543 from outside it. 545 - reporting observations from within the constituency indicating 546 suspected or confirmed incidents outside it; 548 - acting on reports of incidents occurring outside the constituency; 550 - passing information about vulnerabilities to vendors, to Partner 551 SIRTs or directly to affected sites lying within or outside the 552 constituency; 554 - feed-back to parties reporting incidents or vulnerabilities; 556 - the provision of contact information relating to members of the 557 constituency, members of other constituencies, other SIRTs or 558 law-enforcement agencies. 560 The reporting and disclosure policy should make clear who will be the 561 recipients of a SIRT's reports in each circumstance. It should also 562 note whether the team will expect to deal through another Security IRT 563 or directly with a member of another constituency over matters directly 564 involving that member. 566 A team will normally collect statistics. If they are distributed, the 567 template's reporting and disclosure policy should say so, and should 568 list the recipients. 570 4.4.4 Communication and authentication 572 Methods of secure and verifiable communication should be established. 573 This is necessary for communication between SIRTs and between a SIRT and 574 its constituents. The template should include public keys or pointers 575 to them, including key fingerprints, together with guidelines on how to 576 use this information to check authenticity. 578 At the moment it is recommended that every SIRT have, as a minimum, a 579 PGP key available, since PGP is available world-wide. Teams may also 580 make other mechanisms available, for example PEM. 582 For communication via telephone or facsimile a SIRT may keep secret 583 authentication data for parties with whom they may deal, such as an 584 agreed password or phrase. 586 4.5 Services 588 Services should be defined in two sections, as listed below. 590 * direct incident response 591 + verification of the incident, i.e. help in determining whether 592 the problem really is caused by a security compromise 593 + technical analysis assistance to understand the nature of the 594 compromise 595 + notification of other involved parties 596 + guidance with eradication of the incident, i.e. steps 597 to eliminate the compromise and prevent it recurring 598 + guidance in recovery from the incident 600 * optional 601 + vulnerability analysis outside of direct incident activity 602 + information provision 603 - maintaining a vulnerability archive 604 - developing and supplying patches and resolutions 606 + tool development and distribution 607 + education 608 + audit and consulting 609 + product evaluation 611 Security Incident response Teams may provide different kinds of services 612 to different sub-constituencies; this needs to be spelled out. For 613 example, 'we are willing to provide direct incident response to other 614 communities as follows ..' 616 4.6 Incident reporting Forms 618 Samples of reporting forms used by the SIRT (or pointers to them) should 619 be included at this point in a template. As an example, the CERT 620 Coordination Centre's incident reporting form is attached as Appendix C. 622 4.7 Disclaimers 624 Although the template does not constitute a contract, liability might 625 conceivably result from its descriptions of services and purposes. The 626 inclusion of a disclaimer at the end of the template is recommended. 628 It should be noted that some forms of reporting or disclosure relating 629 to specific incidents or vulnerabilities can imply liability, and SIRTs 630 should consider the inclusion of disclaimers in such material. 632 In situations where the original version of a template must be 633 translated into another language, the translation should carry a 634 disclaimer and a pointer to the original. For example: 636 Although we tried to carefully translate our German template 637 into English, we can not be certain that both documents express 638 the same thoughts in the same level of detail and correctness. 639 In all cases, where there is a difference between both 640 versions, the German version is the binding version for our 641 operation. 643 5 Secondary Purposes of this Document 645 The primary audience of this document are the administrators responsible 646 for communities of users, i.e. 'constituencies.' This section provides 647 some brief notes on what SIRT clients should expect of their teams. 649 An incident response team exists primarily to support the clients in its 650 constituency. It is vital that those clients understand what they 651 should expect of their team. Provided that a SIRT has published its 652 template, a constituent/client should be able to read the template and 653 discover what to expect, for example in such areas as privacy and 654 confidentiality of information, and whether the response team will be 655 contacting downstream sites. Clients should certainly expect a SIRT to 656 provide the services they detail in their template. 658 An important aspect of incident response is the 'follow through' - every 659 incident should be investigated and appropriate actions taken. Clients 660 should be encouraged by their SIRT to report incidents so they can be 661 acted upon. It must be emphasised that without active participation 662 (especially reporting) from clients the effectiveness of the services 663 they depend on can be greatly diminished. As a minimum, clients need to 664 know that they should report security incidents, and know how and where 665 they should report them. 667 Individual users (i.e. those who are not part of an organisation which 668 provides a SIRT for its members) who observe a security incident should 669 ask their Internet Service Provider for details of the most suitable 670 SIRT to report it to. 672 Appendix B (below) provides some pointers to SIRTs which were known when 673 this document was published. 675 6 Appendix A: Note on procedure definitions 677 Policies and statements of services in the template have to be 678 implemented as procedures, but descriptions of those procedures should 679 not be included in the template. 681 The following notes are intended to assist those seeking to form or to 682 improve their SIRTs. 684 * External 685 + identify other response teams 686 + define supported clients: 687 - by domain, through registration system, other means 688 + establish secure communication practices 689 - use of network, cell-phones, etc 691 + define information that a client site must/should provide 692 - use of reporting forms 694 * Internal 695 + secure the team's infrastructure 696 + protect information servers 697 + protect sensitive data 698 + define expiry of sensitive data 699 + define disposal practice for sensitive data 700 + establish methods for gathering and keeping statistics 701 + establish 'knowledge base' of lessons learned from past incidents 702 + create practical implementations of disclosure policies 703 + document explicit practices for disclosure to the Press 705 The Site Security Handbook is a first resource to consult in securing a 706 team's infrastructure. SIRT-specific security measures may evolve 707 later. 709 7 Appendix B: Known Incident Response Teams 711 FIRST is the Forum of Incident Response and Security Teams. Information 712 about FIRST can be found via their World Wide Web home page: 714 http://www.first.org/first 716 This page contains pointers to 'Team Contact Information' for SIRTs who 717 are FIRST members, and to 'Teams with WWW Servers.' 719 8 Appendix C: Sample Incident Reporting Form 721 The following is the form which clients should use to report incidents 722 to the CERT Co-ordination Centre: 724 version 3.0 725 February 28, 1996 727 CERT(sm) Coordination Center 728 Incident Reporting Form 730 The CERT Coordination Center (CERT/CC) has developed the following 731 form in an effort to gather incident information. We would appreciate 732 your completing the form below in as much detail as possible. The 733 information is optional, but from our experience we have found that 734 having the answers to all the questions enables us to provide the best 735 assistance. Completing the form also helps avoid delays while we get 736 back to you requesting the information we need in order to help you. 737 Sites have told us, as well, that filling out the form has helped them 738 work through the incident. 740 Note that our policy is to keep any information specific to your site 741 confidential unless we receive your permission to release that 742 information. 744 Please feel free to duplicate any section as required. Please return 745 this form to cert@cert.org. If you are unable to email this form, 746 please send it by FAX. The CERT/CC FAX number is 748 +1 412 268 6989 750 Thank you for your cooperation and help. 751 ............................................................................ 753 1.0. General Information 755 1.1. Incident number (to be assigned by the CERT/CC): CERT# 757 1.2. Reporting site information 759 1.2.1. Name (e.g., CERT Coordination Center): 760 1.2.2. Domain Name (e.g., cert.org): 761 1.2.3. Brief description of the organization: 762 1.2.4. Is your site an Internet Service Provider (Yes/No): 764 2.0. Contact Information 766 2.1. Your contact information 768 2.1.1. Name: 769 2.1.2. Email address: 770 2.1.3. Telephone number: 771 2.1.4. FAX number: 772 2.1.5. Pager number: 773 2.1.6. Home telephone number (for CERT/CC internal use 774 only): 775 2.1.7. Secure communication channel (e.g., PGP, PEM, DES, 776 secure telephone/FAX) [NOTE -- we will call to 777 obtain the secure communication channel 778 information] (Yes/No): 780 2.2. Additional contact information (if available) 782 2.2.1. Name: 783 2.2.2. Email address: 784 2.2.3. Telephone number: 785 2.2.4. FAX number: 786 2.2.5. Pager number: 787 2.2.6. Home telephone number (for CERT/CC internal use 788 only): 789 2.2.7. Secure communication channel (Yes/No): 791 2.3. Site security contact information (if applicable) 793 2.3.1. Name: 794 2.3.2. Email address: 795 2.3.3. Telephone number: 796 2.3.4. FAX number: 797 2.3.5. Pager number: 798 2.3.6. Home telephone number (for our internal use only): 799 2.3.7. Secure communication channel (Yes/No): 801 2.4. Contact information for other site(s) involved in this 802 incident (if available) 804 2.4.1. Site name: 805 2.4.2. Contact person name: 806 2.4.3. Email address: 807 2.4.4. Telephone number: 808 2.4.5. FAX number: 809 2.4.6. Pager number: 810 2.4.7. Home telephone number (for CERT/CC internal use 811 only): 812 2.4.8. Secure communication channel (Yes/No): 814 2.5. Contact information for any other incident response team(s) 815 (IRTs) that has/have been notified (if available) 817 2.5.1. IRT name: 818 2.5.2. Constituency domain: 819 2.5.3. Contact person name: 820 2.5.4. Email address: 821 2.5.5. Telephone number: 822 2.5.6. FAX number: 823 2.5.7. Pager number: 824 2.5.8. Home telephone number (for CERT/CC internal use 825 only): 826 2.5.9. Secure communication channel (Yes/No): 827 2.5.10. IRT reference number: 829 2.6. Contact information for any law enforcement agency(ies) that 830 has/have been notified (if available) 832 2.6.1. Law enforcement agency name: 833 2.6.2. Contact person name: 834 2.6.3. Email address: 835 2.6.4. Telephone number: 836 2.6.5. FAX number: 837 2.6.6. Pager number: 838 2.6.7. Home telephone number (for CERT/CC internal use 839 only): 840 2.6.8. Secure communication channel (Yes/No): 841 2.6.9. Law enforcement agency reference number: 843 3.0. Contacting Sites Involved 845 3.1. We ask that reporting sites contact other sites involved in 846 incident activity. Please let us know if you need assistance 847 in obtaining contact information for the site(s) involved. 849 When contacting the other sites, we would very much 850 appreciate a cc to the "cert@cert.org" alias. This helps 851 us identify connections between incidents and understand 852 the scope of intruder activity. We would also appreciate 853 your including our incident number in the subject line of 854 any correspondence relating to this incident if one 855 has been assigned (see item 1.1.). 857 If you are unable to contact the involved sites, please get 858 in touch with us to discuss how we can assist you. 860 3.2. Disclosure information -- may we give the following types of 861 information to 863 3.2.1. the sites involved in this incident 865 3.2.1.1. your domain (Yes/No): 866 3.2.1.2. your host(s) involved (Yes/No): 867 3.2.1.3. your contact information (Yes/No): 869 3.2.2. incident response teams, for sites from their 870 constituencies involved in this incident 872 3.2.2.1. your domain (Yes/No): 873 3.2.2.2. your host(s) involved (Yes/No): 874 3.2.2.3. your contact information (Yes/No): 876 3.2.3. law enforcement agency(ies) if there is a legal 877 investigation 878 3.2.3.1. your domain (Yes/No): 879 3.2.3.2. your host(s) involved (Yes/No): 880 3.2.3.3. your contact information (Yes/No): 882 4.0. Host Information 884 4.1. Host(s) involved at your site. Please provide information 885 on all host(s) involved in this incident at the time of the 886 incident (one entry per host please) 888 4.1.1. Hostname: 889 4.1.2. IP address(es): 890 4.1.3. Vendor hardware, OS, and version: 891 4.1.4. Security patches applied/installed as currently 892 recommended by the vendor and the CERT/CC 893 (Yes/No/Unknown): 894 4.1.5. Function(s) of the involved host 896 4.1.5.1. Router (Yes/No): 897 4.1.5.2. Terminal server (Yes/No): 898 4.1.5.3. Other (e.g. mail hub, information server, 899 DNS [external or internal], etc.): 901 4.1.6. Where on the network is the involved host (e.g. 902 backbone, subnet): 903 4.1.7. Nature of the information at risk on the involved 904 host (e.g. router configuration, proprietary, 905 personnel, financial, etc.): 906 4.1.8. Timezone of the involved host (relative to GMT): 907 4.1.9. In the attack, was the host the source, the victim, 908 or both: 909 4.1.10. Was this host compromised as a result of this attack 910 (Yes/No): 912 4.2. Host(s) involved at other other sites (one entry per host 913 please) 915 4.2.1. Hostname: 916 4.2.2. IP address(es): 917 4.2.3. Vendor hardware, OS, and version: 918 4.2.4. Has the site been notified (Yes/No): 919 4.2.5. In the attack, was the host the source, the victim, or 920 both: 921 4.2.6. Was this host compromised as a result of this attack 922 (Yes/No): 924 5.0. Incident Categories 926 5.1. Please mark as many categories as are appropriate to 927 this incident 929 5.1.1. Probe(s): 930 5.1.2. Scan(s): 931 5.1.3. Prank: 932 5.1.4. Scam: 933 5.1.5. Email Spoofing: 934 5.1.6. Email bombardment: 936 5.1.6.1. was this denial-of-service attack successful 937 (Yes/No): 939 5.1.7. Sendmail attack: 941 5.1.7.1. did this attack result in a compromise 942 (Yes/No): 944 5.1.8. Break-in 946 5.1.8.1. Intruder gained root access (Yes/No): 947 5.1.8.2. Intruder installed Trojan horse program(s) 948 (Yes/No): 949 5.1.8.3. Intruder installed packet sniffer (Yes/No): 951 5.1.8.3.1. What was the full pathname(s) of 952 the sniffer output file(s): 953 5.1.8.3.2. How many sessions did the sniffer 954 log (use "grep -c 'DATA' 955 " to obtain this 956 information): 958 5.1.8.4. NIS (yellow pages) attack (Yes/No): 959 5.1.8.5. NFS attack (Yes/No): 960 5.1.8.6. TFTP attack (Yes/No): 961 5.1.8.7. FTP attack (Yes/No): 962 5.1.8.8. Telnet attack (Yes/No): 963 5.1.8.9. Rlogin or rsh attack (Yes/No): 964 5.1.8.10. Cracked password (Yes/No): 965 5.1.8.11. Easily-guessable password (Yes/No): 967 5.1.9. Anonymous FTP abuse (Yes/No): 968 5.1.10. IP spoofing (Yes/No): 969 5.1.11. Product vulnerability (Yes/No): 971 5.1.11.1. Vulnerability exploited: 973 5.1.12. Configuration error (Yes/No): 975 5.1.12.1. Type of configuration error: 977 5.1.13. Misuse of host(s) resources (Yes/No): 979 5.1.14. Worm (Yes/No): 980 5.1.15. Virus (Yes/No): 981 5.1.16. Other (please specify): 983 6.0. Security Tools 985 6.1. At the time of the incident, were you any using the following 986 security tools (Yes/No; How often) 988 Network Monitoring tools 989 6.1.1. Argus: 990 6.1.2. netlog (part of the TAMU Security Package): 992 Authentication/Password tools 993 6.1.3. Crack: 994 6.1.4. One-time passwords: 995 6.1.5. Proactive password checkers: 996 6.1.6. Shadow passwords: 997 6.1.7. Kerberos: 999 Service filtering tools 1000 6.1.8. Host access control via modified daemons or 1001 wrappers: 1002 6.1.9. Drawbridge (part of the TAMU Security Package): 1003 6.1.10. Firewall (what product): 1004 6.1.11. TCP access control using packet filtering: 1006 Tools to scan hosts for known vulnerabilities 1007 6.1.12. ISS: 1008 6.1.13. SATAN: 1010 Multi-purpose tools 1011 6.1.14. C2 security: 1012 6.1.15. COPS: 1013 6.1.16. Tiger (part of the TAMU Security Package): 1015 File Integrity Checking tools 1016 6.1.17. MD5: 1017 6.1.18. Tripwire: 1019 Other tools 1020 6.1.19. lsof: 1021 6.1.20. cpm: 1022 6.1.21. smrsh: 1023 6.1.22. append-only file systems: 1025 Additional tools (please specify): 1027 6.2. At the time of the incident, which of the following logs were 1028 you using, if any (Yes/No) 1029 6.2.1. syslog: 1030 6.2.2. utmp: 1031 6.2.3. wtmp: 1032 6.2.4. TCP wrapper: 1033 6.2.5. process accounting: 1035 6.3. What do you believe to be the reliability and integrity of 1036 these logs (e.g., are the logs stored offline or on a 1037 different host): 1039 7.0. Detailed description of the incident 1041 7.1. Please complete in as much detail as possible 1043 7.1.1. Date and duration of incident: 1044 7.1.2. How you discovered the incident: 1045 7.1.3. Method used to gain access to the affected host(s): 1046 7.1.4. Details of vulnerabilities exploited that are 1047 not addressed in previous sections: 1048 7.1.5. Other aspects of the "attack": 1049 7.1.6. Hidden files/directories: 1050 7.1.7. The source of the attack (if known): 1051 7.1.8. Steps taken to address the incident (e.g., binaries 1052 reinstalled, patches applied): 1053 7.1.9. Planned steps to address the incident (if any): 1054 7.1.10. Do you plan to start using any of the tools listed 1055 above in question 6.0 (please list tools expected 1056 to use): 1057 7.1.11. Other: 1059 7.2. Please append any log information or directory listings and 1060 timezone information (relative to GMT). 1062 7.3. Please indicate if any of the following were left on your 1063 system by the intruder (Yes/No): 1065 7.3.1. intruder tool output (such as packet sniffer output 1066 logs): 1067 7.3.2. tools/scripts to exploit vulnerabilities: 1068 7.3.3. source code programs (such as Trojan horse programs, 1069 sniffer programs): 1070 7.3.4. binary code programs (such as Trojan horse programs, 1071 sniffer programs): 1072 7.3.5. other files: 1074 If you answered yes to any of the last 5 questions, please 1075 call the CERT/CC hotline (+1 412 268 7090) for instructions 1076 on uploading files to us by FTP. Thanks. 1078 7.4. What assistance would you like from the CERT/CC? 1080 Copyright 1996 Carnegie Mellon University. 1081 This form may be reproduced and distributed without permission 1082 provided it is used for noncommercial purposes and the CERT 1083 Coordination Center is acknowledged. 1085 CERT is a service mark of Carnegie Mellon University. 1087 9 Security Considerations 1089 This document discusses the operation of Security Incident Response 1090 Teams, and is therefore not directly concerned with the security of 1091 protocols or network systems themselves. 1093 Nonetheless, it is vital that SIRTs establish secure communication 1094 channels with other teams, and with members of their constituency. They 1095 must also secure their own systems and infrastructure. 1097 10 Editor's Address 1099 Nevil Brownlee 1100 ITSS Technology Developmenta 1101 The University of Auckland 1103 Phone: +64 9 373 7599 x8941 1104 E-mail: n.brownlee@auckland.ac.nz