idnits 2.17.1 draft-ietf-grip-framework-irt-01.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-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack 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 393: '...e Team, the team MUST provide incident...' 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 (Feb 1996) is 10297 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: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 3 Feb 1996 4 Expires in six months 6 Expectations for Security Incident Response 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. This Internet Draft is a product of the 15 Internet Accounting Working Group of the IETF. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts as 20 reference material or to cite them other than as a 'working draft' or 21 'work in progress.' 23 Please check the I-D abstract listing contained in the Internet-drafts 24 Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 25 ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or 26 any other Internet Draft. 28 Abstract 30 This document explains what is expected of Incident Response Teams 31 (IRTs), provides guidelines for IRTs, and recommends a "template" 32 through which every IRT should describe itself and its functions. It 33 was produced by the GRIP Working Group of the IETF. 35 Contents 37 1 Introduction 2 38 1.1 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 3 39 1.2 Publishing IRT Templates . . . . . . . . . . . . . . . . . . . 3 41 2 Description Template: Security Incident Response Team 4 43 3 Purpose of the Template 5 44 3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 6 45 4 Definitions 7 47 5 The Security Incident Response Team Template 9 48 5.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 9 49 5.1.1 Date of last update . . . . . . . . . . . . . . . . . . . . 9 50 5.1.2 Distribution list for Template Updates . . . . . . . . . . 9 51 5.2 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 52 5.2.1 Mission Statement . . . . . . . . . . . . . . . . . . . . . 10 53 5.2.2 Constituency . . . . . . . . . . . . . . . . . . . . . . . 10 54 5.2.3 Sponsoring organization / affiliation . . . . . . . . . . . 10 55 5.2.4 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 11 56 5.3 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 5.3.1 Types of incidents and level of support . . . . . . . . . . 11 58 5.3.2 Co-operation and interaction with other organizations . . . 11 59 5.3.3 Reporting and Disclosure . . . . . . . . . . . . . . . . . 12 60 5.3.4 Communication and authentication . . . . . . . . . . . . . 13 61 5.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 5.5 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 14 63 5.6 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 6 Appendix A: Note on procedure definitions 14 67 7 Appendix B: Known Incident Response Teams 15 69 8 Security Considerations 15 71 9 Author's Address 16 73 1 Introduction 75 The Working Group was formed to provide guidelines and recommendations 76 to facilitate the consistent handling of security incidents in the 77 Internet community. Although it is focused on the Internet, many of the 78 concepts discussed will also be useful for other forms of local- and 79 wide-area networks and internets. 81 Security incidents and potential threats of them usually extend beyond 82 institutional or local community boundaries. "Consistent handling" 83 implies that any group calling itself an Incident Response Team (IRT) 84 must react to security incidents or to threats of them in ways which the 85 general Internet community agrees to be in its general interest. 87 The "Expectations for Security Incident Response" is seen as resting on 88 the work of individual IRTs and the cooperation between them. 90 This document therefore recommends a "template" through which every IRT 91 should describe itself and its functions. It further recommends that 92 templates should be accessible among teams, to make possible a fully 93 effective cooperative response framework for incidents or threats across 94 the entire domain affected by them. 96 1.1 User Expectations 98 This document provides a detailed discussion of all aspects of incident 99 response. It is also intended to provide a common understanding of what 100 is involved in, and implied by, each section of an IRT's template. 102 An incident response team exists primarily to support the users in its 103 constituency. It is vital that those users understand what they should 104 expect of their team. Provided that an IRT has published its template, 105 a constituent/customer should be able to read the template and discover 106 what to expect, for example in such areas as privacy and confidentiality 107 of information, and whether the response team will be contacting 108 downstream sites. Users should certainly expect an IRT to provide the 109 services they detail in their IRT. 111 An important aspect of incident response is the 'follow through' - every 112 incident should be investigated and appropriate actions taken. Users 113 should be encouraged by their IRT to report incidents so they can be 114 acted upon. It must be emphasised that without active participation 115 (especially reporting) from users the effectiveness of the services they 116 depend on can be greatly diminished. As a minimum, users need to know 117 that they should report security incidents, and know how and where they 118 should report them. 120 1.2 Publishing IRT Templates 122 If templates are to be accessible between IRTs, a central repository 123 will be needed for them. The GRIP Working Group believe that some of 124 the existing Internet archive areas could be used for this purpose. 126 Digital signatures should be used to protect the completed templates 127 against modifications. The keeper of each template repository will be 128 responsibly for verifying the identity of each IRT lodging a template in 129 the repository. 131 Each team should be responsible for ensuring that its own template is 132 available to at least its own constituency and to any other groups it 133 needs to interact with frequently. These groups will include any 134 'up-stream' sites and/or IRTs which the team needs to report to. 136 Whether or not an IRT lodges a copy of its template in a repository, it 137 should publish one on its own information server so that users in its 138 constituency can easily find it. Templates published as pages in the 139 World Wide Web should include the phrase 'IRT Template' in their title; 140 this will allow Web search engines to find them easily. 142 Individual users who observe a security incident should ask their 143 Internet Service Provider for details of the most suitable IRT to report 144 it to. 146 Appendix B (below) provides some pointers to IRTs which were known when 147 this document was published. 149 2 Description Template: Security Incident Response Team 151 The Template is summarized in the section immediately below, and the 152 remainder of the document describes its components. 154 Contact Information 155 ------------------- 156 * name of the team 157 * address 158 * telephone 159 * facsimile 160 * other telecommunication like STU-III 161 * electronic mail 162 * encryption methods for communication: PGP, PEM, MOSS, .. 163 * actual list of members on demand (optional) 165 Template Updates 166 ---------------- 167 * Date of last update 168 * Distribution list for template updates 170 Charter 171 ------- 172 * mission statement 173 * constituency 174 * sponsor / affiliation 175 * authority 177 Policies 178 -------- 179 * types of incidents 180 * level of support 181 * disclosure 182 - of compromised site's information 183 - the compromise of IRT site to constituency 184 * cooperation & interaction with 185 - incident response teams 186 - vendors 187 - investigative agencies 188 - involved sites 189 - press 190 * communication & authentication 191 * point of customer contacts 192 * incident reporting requirements 194 Services 195 -------- 196 * incident response 197 - verification 198 - understanding 199 - coping 200 - notification 201 * proactive activities 203 Incident Reporting Forms 204 ------------------------ 206 Disclaimers 207 ----------- 209 3 Purpose of the Template 211 The Template which this document proposes is expected to be used by a 212 response team to describe what it does, and in the process create 213 criteria against which its performance can be measured. The Template 214 does not attempt to specify a "correct" way for the team to operate, but 215 does recommend on specific policies and functions seen as necessary for 216 such a team to play a consistent role in the overall security framework. 217 It also comments on additional roles a team might include in the ambit 218 of its operations. 220 The primary purposes of the Template are: 222 - to help IRTs improve the way they operate; 223 - to improve interactions between different IRTs, and between IRTs 224 and other organizations such as vendors and law-enforcement 225 agencies; 227 - to note necessary interactions with their constituencies in setting 228 expectations and defining policies; 230 - to help new groups understand what it takes to "be" an IRT. 232 A Template might appear to provide a marketing tool for comparing 233 different teams, but this kind of marketing use (or abuse) is strongly 234 discouraged by the GRIP Working Group. 236 3.1 Other Related Material 238 This 'Framework for Response Teams' document is the first produced by 239 the GRIP Working Group. A second document will set out guide-lines for 240 technology vendors to help them handle security incidents. The 241 definition of terms given in the next section applies to both documents. 243 Another relevant IETF document is RFC 1244, the Site Security Handbook, 244 produced by (and being updated by) the Site Security Handbook Working 245 Group (SSH). Site requirements and recommendations are covered by the 246 Handbook, while response team expectations and procedures are addressed 247 by the GRIP documents. 249 Other documents of interest for the discussion of incident response 250 teams and their tasks are available by anonymous FTP. A collection can 251 be found on: 253 * ftp://ftp.nic.surfnet.nl/surfnet/net-security/ 254 cert-nl/docs/reports/R-92-01 256 Some especially interesting documents are: 258 * CERT-NL Framework 259 ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt 261 * FIRST potential members 262 ftp://ftp.first.org/pub/first/newmemlt.txt 263 ftp://ftp.first.org/pub/first/profile.txt 264 ftp://ftp.first.org/pub/first/op`frame.txt 265 http://www.first.org/first 267 * NRL Incident Response Manual 268 http://hightop.nrl.navy.mil/news/incident.html 270 * Bibliography 271 http://www.cert.dfn.de/eng/team/kpk/certbib.html 273 4 Definitions 275 This section defines terms used in describing security incidents and 276 response teams. For the purpose of the GRIP documents only a limited 277 list is really needed. This should help maintain focus on the purpose 278 of the documents, and prevent a duplication of other definitions or - 279 even worse - a proliferation of competing definitions. 281 Constituency 282 ------------ 284 Implicit in the purpose of a Security Incident Response Team is the 285 existence of a constituency. This is the group of users, sites, 286 networks or organizations served by the team. 288 Security Incident 289 ----------------- 291 For the purpose of this document: 293 'A computer security incident is any event which compromises 294 some aspect of computer or network security.' 296 The definition of an incident may vary between organizations, but at 297 least the following categories are generally applicable: 299 * loss of confidentiality, 300 * compromise of integrity, 301 * denial of service, 302 * misuse, 303 * damage. 305 These are very general categories. For instance the forging of an 306 electronic mail message and a successful password attack are two 307 examples of 'compromise of integrity.' 309 Within the definition of an incident the word 'compromised' is used. 310 Sometimes an administrator may only 'suspect' an incident. During the 311 handling of a call it must be established whether or not an incident 312 really occurred. 314 Security Incident Response Team 315 ------------------------------- 317 Based on two of the definitions given above: 319 'A Security Incident Response Team is a group authorized to deal 320 with security incidents that occur within its defined constituency.' 322 It should provide a channel for receiving reports about suspected 323 incidents and for disseminating incident-related information to its 324 constituency and to other related parties; it should also provide 325 assistance to members of its constituency in handling these incidents. 327 Vendor 328 ------ 330 A 'vendor' is any entity that produces networking or computing 331 technology, and is responsible for the technical content of that 332 technology. Examples of 'technology' include hardware (routers, 333 switches, etc.), and software (operating systems, mail forwarding 334 systems, etc.). 336 Note that the supplier of a technology is not necessarily the 'vendor' 337 of that technology. As an example, an Internet Services Provider (ISP) 338 might supply routers to each of its customers, but the 'vendor' is the 339 manufacturer, being the entity responsible for the technical content of 340 the router, rather than the ISP. 342 Vulnerability 343 ------------- 345 A 'vulnerability' is a characteristic of a piece of technology which can 346 be exploited to perpetrate a security incident. For example, if a 347 program allowed ordinary users to execute operating system commands in 348 privileged mode, this "feature" would be a vulnerability. 350 5 The Security Incident Response Team Template 352 This material which follows is addressed to those responsible for 353 Security Incident Response Teams. 355 5.1 Template Updates 357 Details of an IRT change with time, so the template must indicate when 358 it was last changed, who will be informed of future changes, and (by 359 implication) who will not. Without this, it is inevitable that 360 misunderstandings and misconceptions will arise over time. 362 5.1.1 Date of last update 364 This should be sufficient to allow anyone interested to evaluate the 365 currency of the template. 367 5.1.2 Distribution list for Template Updates 369 Persons on this list are notified automatically whenever the template is 370 changed. The list might normally cover the constituency and any other 371 groups the IRT has frequent interactions with. Readers not on the list 372 can then recognise that they should check the central repository (above) 373 for possible updates. 375 Digital signatures should be used for update messages sent by an IRT to 376 those on its distribution list. 378 5.2 Charter 380 Every IRT must have a charter which specifying what it is to do, and the 381 authority under which it will do it. The charter should include at 382 least the following: 384 * mission statement 385 * constituency 386 * sponsor / affiliation 387 * authority 389 5.2.1 Mission Statement 391 The mission statement should focus on the team's core activities, 392 already stated in the definition of an IRT. In order to be considered a 393 Security Incident Response Team, the team MUST provide incident 394 response, by definition. 396 The goals and purposes of a team are especially important, and require 397 clear, succinct definition. 399 5.2.2 Constituency 401 An IRT's constituency (as defined above) can be determined in many ways. 402 For example it could be a company's employees or its paid subscribers, 403 or it could be defined in terms of a technological focus, such as the 404 users of a particular operating system. 406 The definition of constituency should create a perimeter around the 407 group to whom the team will provide service. The policy section (below) 408 should explain how requests from outside the perimeter will be handled. 410 Constituencies might overlap, as when an ISP supports an IRT, but 411 delivers services to customer sites which also have IRTs. The Authority 412 section (below) should make such relationships clear. 414 People within the constituency have to learn that there is an IRT for 415 their purposes; the building of a trusted relationship with the 416 constituency is an on-going process which never ends. 418 5.2.3 Sponsoring organization / affiliation 420 The sponsoring organization, which authorises the actions of the IRT, 421 should be given next. Defining the affiliation amounts to stating: 422 "Who is your God?". 424 5.2.4 Authority 426 IRTs may not have authority to intervene in the operation of all the 427 systems within their perimeter. They should identify the scope of their 428 control as distinct from the perimeter of their constituency; if other 429 IRTs operate hierachically within their perimeter, these should be 430 identified. 432 5.3 Policies 434 5.3.1 Types of incidents and level of support 436 The types of incident which the team is authorised to address and the 437 level of support the team will contribute in assisting with each type of 438 incident should be summarized here in list form. The Services section 439 (later) provides opportunity for more detailed definition. 441 The team should state whether it will act on information it receives 442 about vulnerabilities which create opportunities for future incidents. 443 A commitment to act on such information on behalf of its constituency is 444 regarded as an optional pro-active service policy rather than a core 445 service requirement for an IRT. 447 5.3.2 Co-operation and interaction with other organizations 449 This section should make explicit the related groups with which the IRT 450 routinely interacts. Examples of these are listed below. 452 Incident Response Teams: An IRT will often need to interact with 453 other IRTs. For example an IRT within a large company may need to 454 report incidents to a national IRT, and a national IRT may need to 455 report incidents to national IRTs in other countries. 457 Vendors: Larger vendors have their own IRTs, but smaller vendors may 458 not. In such cases an IRT will need to work directly with a vendor. 460 Law-enforcement agencies: These include the police and other 461 investigative agencies. IRTs and users of the template should be 462 sensitive to local laws and regulations, which may vary considerably in 463 different countries. 465 Press: An IRT may be approached by the Press for information and 466 comment from time to time. This is discussed in more detail below 467 (Reporting and Disclosure). 469 5.3.3 Reporting and Disclosure 471 The default status of any and all security-related information which a 472 team receives can only be 'confidential,' but rigid adherence to this 473 makes the team a 'black hole.' Its template should define what 474 information it will report or disclose, to whom, and when. 476 Different teams are likely to be subject to different legal restraints 477 requiring or limiting disclosure, especially if they work in different 478 jurisdictions. Each team's template should specify any such restraints, 479 both to clarify users' expectations and to inform other teams. 481 Conflicts of interest, particularly in commercial matters, may also 482 restrain disclosure by a team; the present Draft does not recommend on 483 how such conflicts should be addressed. 485 An explicit policy concerning disclosure to the Press can be helpful, 486 particularly in clarifying the expectations of an IRT's constituency. 488 'Disclosure' includes: 490 - reporting incidents within the constituency to other teams; 492 - handling incidents occurring within the constituency, but reported 493 from outside it. 495 - reporting observations from within the constituency indicating 496 suspected or confirmed incidents outside it; 498 - acting on reports of incidents occurring outside the constituency; 500 - passing information about vulnerabilities to vendors, to Partner 501 IRTs or directly to affected sites lying within or outside the 502 constituency; 504 - feed-back to parties reporting incidents or vulnerabilities; 506 - the provision of contact information relating to members of the 507 constituency, members of other constituencies, other IRTs or law- 508 enforcement agencies. 510 The reporting and disclosure policy should make clear who will be the 511 recipients of an IRT's reports in each circumstance. It should also 512 note whether the team will expect to deal through another IRT or 513 directly with a member of another constituency over matters directly 514 involving that member. 516 A team will normally collect statistics. If they are distributed, the 517 template's reporting and disclosure policy should say so, and should 518 list the recipients. 520 5.3.4 Communication and authentication 522 Methods of secure and verifiable communication should be established. 523 This is necessary for communication between IRTs and between an IRT and 524 its constituents. The template should include public keys or pointers 525 to them, including key fingerprints, together with guidelines on how to 526 use this information to check authenticity. 528 At the moment it is recommended that every IRT have, as a minimum, a PGP 529 key available, since PGP is available world-wide. Teams may also make 530 other mechanisms available, for example PEM. 532 For communication via telephone or facsimile an IRT may keep secret 533 authentication data for parties with whom they may deal, such as an 534 agreed password or phrase. 536 5.4 Services 538 Services should be defined in two sections, as listed below. 540 * direct incident response 541 + verification of incident 542 + technical assistance analysis to understand compromise 543 + notification of other involved parties 544 + eradication 545 + recovery 547 * optional 548 + information provision 549 - vulnerability archive 550 - patches and resolutions 551 + tools 552 + education 553 + audit and consulting 554 + product evaluation 556 5.5 Incident reporting Forms 558 Samples of reporting forms used by the IRT (or pointers to them) should 559 be included at this point in a template. 561 5.6 Disclaimers 563 Although the template does not constitute a contract, liability might 564 conceivably result from its descriptions of services and purposes. The 565 inclusion of a disclaimer at the end of the template is recommended. 567 It should be noted that some forms of reporting or disclosure relating 568 to specific incidents or vulnerabilities can imply liability, and IRTs 569 should consider the inclusion of disclaimers in such material. 571 In situations where the original version of a template must be 572 translated into another language, the translation should carry a 573 disclaimer and a pointer to the original. For example: 575 Although we tried to carefully translate our German template 576 into English, we can not be certain that both documents express 577 the same thoughts in the same level of detail and correctness. 578 In all cases, where there is a difference between both 579 versions, the German version is the binding version for our 580 operation. 582 6 Appendix A: Note on procedure definitions 584 Policies and statements of services in the template have to be 585 implemented as procedures, but descriptions of those procedures should 586 not be included in the template. 588 The following notes are intended to assist those seeking to form or to 589 improve their IRTs. 591 * External 592 + identify other response teams 593 + define supported clients: 594 - by domain, through registration system, other means 595 + establish secure communication practices 596 - use of network, cell-phones, etc 597 + define information that a client site must/should provide 598 - use of reporting forms 600 * Internal 601 + secure the team's infrastructure 602 + protect information servers 603 + protect sensitive data 604 + define expiry of sensitive data 605 + define disposal practice for sensitive data 606 + establish methods for gathering and keeping statistics 607 + establish 'knowledge base' of lessons learned from past incidents 608 + create practical implementations of disclosure policies 609 + document explicit practices for disclosure to the Press 611 The Site Security Handbook is a first resource to consult in securing a 612 team's infrastructure. IRT-specific security measures may evolve later. 614 7 Appendix B: Known Incident Response Teams 616 FIRST is the Forum of Incident Response and Security Teams. Information 617 about FIRST can be found via their World Wide Web home page: 619 http://www.first.org/first 621 This page contains pointers to 'Team Contact Information' for IRTs who 622 are FIRST members, and to 'Teams with WWW Servers.' 624 8 Security Considerations 626 This document discusses the operation of Security Incident Response 627 Teams, and is therefore not directly concerned with the security of 628 protocols or network systems themselves. 630 Nonetheless, it is vital that IRTs establish secure communication 631 channels with other teams, and with members of their constituency. 632 They must also secure their own systems and infrastructure. 634 9 Author's Address 636 Nevil Brownlee 637 The University of Auckland 639 Phone: +64 9 373 7599 x8941 640 E-mail: n.brownlee@auckland.ac.nz