idnits 2.17.1 draft-ietf-inch-requirements-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 434. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 402), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 25, 2006) is 6512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2828 (ref. '4') (Obsoleted by RFC 4949) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INCH Working Group Glenn M Keeni 3 Internet-Draft Cyber Solutions Inc. 4 Category: Informational Roman Danyliw 5 Expires: December 24, 2006 CERT/CC 6 Yuri Demchenko 7 University of Amsterdam 9 June 25, 2006 11 Requirements for the Format for Incident Information Exchange (FINE) 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is a product of the inch Working Group. Comments should 37 be addressed to the authors or the mailing list at 38 inch@nic.surfnet.nl 40 This Internet-Draft will expire on December 24, 2006 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). All Rights Reserved. 46 Abstract 48 This document describes the high-level functional requirements of an 49 abstract format, the Format for Incident information Exchange (FINE), 50 which will facilitate the exchange of incident information among 51 computer security incident response teams (CSIRTs) and involved 52 parties. A common and well-defined format will help in the exchange 53 of incident related information across different administrative 54 domains such as organizations, regions, and countries. 55 Implementations of FINE will also be useful for reactionary analysis 56 of current threats and support the proactive identification of trends 57 that can lead to incident prevention. 59 Table of Contents 61 1. Introduction ............................................... 3 62 2. Incident Handling Framework ................................ 3 63 3. General Requirements ....................................... 5 64 4. Format Requirements ........................................ 6 65 5. Communication Mechanism Requirements ....................... 7 66 6. Content Requirements ....................................... 7 67 7. Security Considerations .................................... 8 68 8. IANA Considerations ........................................ 8 69 9. References ................................................. 9 70 10. Acknowledgements ........................................... 10 71 11. Authors' Addresses ......................................... 10 72 Full Copyright Statement ....................................... 11 73 Appendix: History of Changes 75 1. Introduction 77 Computer security incidents occur across administrative domains, 78 often spanning different organizations and national borders. Hence, 79 a response requires coordination and collaboration between the 80 involved parties and the responsible computer security incident 81 response teams (CSIRTs). The basis for this interaction is often 82 data and statistics describing the nature of the incident. This 83 information, referred to as an incident report in this document, will 84 not only support response activity to the specific incident, but may 85 also be used for historical analysis or proactive responses. 87 This document defines the high-level functional requirements for a 88 format that can support the exchange of incident reports. The 89 abstract format being discussed is referred to as the Format for 90 INcident information Exchange (FINE). The implementation of the 91 requirements, the format itself, is out of the scope of this 92 document. 94 The intent of FINE is to enable rapid and effective response to 95 incidents by improving the ability of CSIRTs to exchange and process 96 incident reports. This will be achieved by ensuring that 97 implementations of FINE require: 98 + unambiguous semantics for the data; 99 + a well-defined syntax for the data; and 100 + support end-user processing (e.g., categorization and 101 statistical analysis). 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14, RFC 2119 [1]. 108 2. Incident Handling Framework 110 2.1. Descriptive Terms 111 For the purpose of clarity, certain commonly used terms from the 112 operational domain of CSIRTs are defined here. These are based on 113 related documents [3, 4, 5, 6, 7] 115 2.1.1. Event 116 An event is an occurrence in a system or network that may be of 117 interest and warrant attention. An event is not necessarily malicious 118 or deliberate. 120 2.1.2. Attack 121 An attack is a series of events caused either directly or indirectly 122 by a source that violates the security policy of the target. These 123 violations may include a compromise of a user account, denial of 124 service, information theft, etc. 126 2.1.3. Source 127 The origin of an attack as described by a host, user account, 128 computer program, network address, person, or organization. 130 2.1.4. Target 131 The target of an attack as described by a host, user account, 132 computer program, network address, person, or organization. 134 2.1.5. Computer security incident 135 A computer security incident, referred to as an incident, is a set of 136 one or more related attacks. 138 2.1.6. Incident report 139 An incident report is the collection of information describing an 140 incident. In this document the terms "incident report" and "incident 141 information" are used interchangeably. 143 2.1.7. CSIRT 144 A computer security incident response team, CSIRT, is an individual 145 or a group of individuals that has the responsibility to coordinate 146 and support the response to incidents in a defined constituency [6]. 147 A CSIRT creates, receives, processes, and maintains incident reports. 149 2.1.8. Impact 150 An impact describes the consequence of an incident on a target 151 expressed in terms relevant to a user community. 153 2.2 The Operational Model 155 Incident reports are an important subset of information exchanged 156 between a CSIRT and its constituency or other CSIRTs. These reports 157 form the basis for resolving and understanding activity in a 158 constituency. A CSIRT may create an incident report when an incident 159 is reported, receive a report from another CSIRT, or send a report to 160 a CSIRT. As investigation into the incident progresses, new 161 information about an incident may be discovered. New information may 162 trigger subsequent information exchange. 164 The creation and exchange of incident reports is often driven by a 165 work-flow process that prioritizes and manages the information flow 166 in a CSIRT. These systems often associate CSIRT personnel with 167 particular incidents or maintain status onto a given investigation. 168 FINE does not provide a representation for these internal processes. 170 FINE is a representation for the data exchanged between different 171 parties. In order to integrate FINE into the operational processes of 172 CSIRTS, the parties will have to use an interface to convert to and 173 from the internal data representation (of a propriety work-flow 174 application or database) and FINE. Hence, the sender of an incident 175 report must convert from the local format to FINE, while the 176 recipient must translate FINE back into its own local format. The 177 communicating CSIRTs need not have the same local format for storing 178 incident reports. This information exchange is depicted in Figure 1. 180 CSIRT CSIRT 181 +------------------+ +------------------+ 182 | | | | 183 | +--------+ +---------+ +---------+ +--------+ | 184 | | |<--|Interface|<--Incident-->|Interface|-->| | | 185 | |Incident| +---------+ Report +---------+ |Incident| | 186 | | Report | | | | Report | | 187 | |Database| | |=== FINE ===| | |Database| | 188 | | | | | | | | 189 | +--------+ | | +--------+ | 190 | | | | 191 +------------------+ +------------------+ 193 Fig. 1 Operational Model for FINE 195 3. General Requirements 197 3.1 FINE SHALL reference and use previously published RFCs where 198 possible. 200 3.2 FINE MUST have well-defined semantics and specify a standard 201 mechanism for extensibility. 203 The data elements of the various components of FINE should be typed, 204 and the meaning should be well specified. Likewise, there should be 205 a standardized method to address representing data not defined in the 206 data model. 208 4. Format Requirements 210 4.1 FINE SHALL support full internationalization and localization. 212 A significant part of the incident report may consist of natural 213 language text. Since some incidents may involve CSIRTs from different 214 countries, FINE must have provisions for using local character sets 215 and encodings. 217 In cases where local (non-standard) character sets and encodings are 218 used, the data elements that carry encoding-sensitive information 219 should be clearly indicated. 221 4.2 FINE MUST allow multilingual reports. 223 Different parts of the incident report may be written in a different 224 natural language. FINE must support multiple translations of the 225 same data element. 227 4.3 FINE MUST support aggregation and filtering of incident report data. 229 The structure of the FINE data elements and their associated 230 semantics must lend themselves to aggregation and filtering by 231 applications. 233 4.4 FINE MUST be able to document the evolution of an incident report. 235 As incidents are investigated new information may become available or 236 old information may be invalidated. FINE must support the ability to 237 convey this track record of an incident report. 239 4.5 FINE MUST support a granular access restriction policy 240 on subsets of the incident report. 242 Different parts of an incident report may have information of varying 243 degrees of sensitivity. It must be possible to label subsets of the 244 incident report with their appropriate sensitivity. With this 245 information, applications can then implement different levels of 246 access restrictions for the different components of the incident 247 report. 249 4.6 FINE SHOULD allow the application of external mechanisms to 250 support authenticity, integrity, and non-repudiation checks of 251 incident reports. 253 FINE itself need not guarantee authenticity, integrity, or non- 254 repudiation. However, the specification must detail a standardized 255 mechanism to ensure these properties. 257 5. Communication Mechanism Requirements 259 5.1 The security properties of FINE reports SHOULD be 260 independent of the communication mechanism. 262 The exchange of incident reports is typically conducted using 263 standard communication protocols (e.g., SMTP, HTTP, FTP, XML Web 264 Services). The security properties of FINE MUST NOT be tied to a 265 particular communications protocol. Provisions for authenticity, 266 integrity, and confidentiality should be made in FINE. 268 6. Content Requirements 270 6.1 FINE MUST be flexible enough to support various degrees of 271 completeness, while still clearly defining the minimal 272 information required for describing an incident. 274 6.2 FINE MUST support globally unique identifiers for each incident 275 report. 277 It should be possible to reference an incident report unambiguously 278 using a globally unique identifier. Furthermore, it should be 279 possible to derive the constituency of the incident report from this 280 identifier. 282 6.3 FINE MUST support the naming of the source and target. 284 6.4 FINE MUST support the description of various aspects of the 285 source and target. 287 6.5 FINE MUST support the description of the methodology used by 288 the attacker. 290 Well-known classifications or enumeration schemes should be used to 291 describe the attack. 293 6.6 FINE SHOULD support the identification of the sender of the 294 incident report. 296 FINE should indicate the source of each component of the incident 297 report if it is different from the sender (e.g., the team handling 298 the incident). 300 6.7 FINE SHOULD support the inclusion or referencing of information 301 external to the incident report. 303 6.8 FINE MUST support natural language descriptions of the incident. 305 6.9 FINE SHOULD support references to the appropriate security advisories 306 from coordination and analysis centers. 308 6.10 FINE SHOULD support a description of the impact of the incident. 310 6.11 FINE SHOULD support a description of the actions taken during the 311 course of handling the incident. 313 6.12 FINE MUST use a standardized time specification. 315 Incident reports should represent time in such a way that it is 316 possible to easily compare information reported from different time 317 zones. 319 7. Security Considerations 321 There are no explicit security considerations for this document, 322 since no protocol or information model is specified. However, a 323 number of security relevant requirements are outlined for FINE 324 implementers. By its nature, FINE will represent sensitive 325 information. Hence, implementers should ensure support for access 326 restriction (requirement 4.5), confidentiality, integrity, and non- 327 repudiation (requirement 4.6) all through transport independent 328 approaches (requirement 5.1). 330 8. IANA Considerations 332 This document requires no action from IANA. 334 9. References 336 9.1 Normative References 338 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 339 Levels." BCP 14, RFC 2119. March 1997. 341 9.2 Informative References 343 [2] Arvidsson, J., Cormack, A., Demchenko, Y. and Meijer J., 344 "TERENA's Incident Object Description and Exchange Format 345 Requirements." RFC 3067. February 2001. 347 [3] Brownlee, N., Guttman, E., "Expectations for Computer 348 Security Incident Response." BCP 21, RFC 2350. June 1998. 350 [4] Shirey, R., "Internet Security Glossary." FYI 36, RFC 2828. 351 May 2000. 353 [5] "Establishing a Computer Security Incident Response Capability 354 (CSIRC)." NIST Special Publication. 800-3. November 1991. 356 [6] West-Brown, M., Stikvoort, D., Kossakowski, K., Killcrece G., 357 Ruefle, R., Zajicek, M., "Handbook for Computer Security Incident 358 Response Teams (CSIRTs)." CMU/SEI-98-HB-002. Carnegie Mellon 359 University, Pittsburgh, PA. April 2003. 361 [7] Howard, J. and Longstaff, A., "A Common Language for Computer 362 Security Incidents." Sandia Report: SAND98-8667. Sandia National 363 Laboratories. Albuquerque, NM. October 1998. 365 10. Acknowledgments 367 The precursor of this document is "RFC3067 TERENA's Incident Object 368 Description Exchange Format Requirements" [2], which is based on the 369 work done in the Incident Object Description Exchange Format Working 370 Group at TERENA. Subsequent work and discussion have been carried 371 out in the INCH-WG and in the WIDE-WG on Network Management and 372 Security. 374 The following individuals, in alphabetic order, have made a 375 substantial contribution to this document: 376 Hiroyuki Kido 377 Hiroyuki Ohno 378 Kathleen M. Moriarty 379 Jan Meijer 381 11. Authors' Addresses: 383 Glenn Mansfield Keeni 384 Cyber Solutions Inc. 385 Sendai, Japan 386 Email: glenn@cysols.com 388 Roman Danyliw 389 CERT Coordination Center 390 4500 Fifth Ave. 391 Pittsburgh, PA 15213 392 USA 393 Email: rdd@cert.org 395 Yuri Demchenko 396 University of Amsterdam, The Netherlands 397 Email: demch@chello.nl 398 Full Copyright Statement 400 Copyright (C) The Internet Society (2006). This document is subject 401 to the rights, licenses and restrictions contained in BCP 78, and 402 except as set forth therein, the authors retain all their rights. 404 This document and the information contained herein are provided on an 405 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 406 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 407 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 408 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 409 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 410 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 412 Intellectual Property 414 The IETF takes no position regarding the validity or scope of any 415 Intellectual Property Rights or other rights that might be claimed 416 to pertain to the implementation or use of the technology 417 described in this document or the extent to which any license 418 under such rights might or might not be available; nor does 419 represent that it has made any independent effort to identify any 420 such rights. Information on the procedures with respect to 421 rights in RFC documents can be found in BCP 78 and BCP 79. 423 Copies of IPR disclosures made to the IETF Secretariat and any 424 assurances of licenses to be made available, or the result of an 425 attempt made to obtain a general license or permission for the use 426 of such proprietary rights by implementers or users of this 427 specification can be obtained from the IETF on-line IPR repository 428 at http://www.ietf.org/ipr. 430 The IETF invites any interested party to bring to its attention 431 any copyrights, patents or patent applications, or other 432 proprietary rights that may cover technology that may be required 433 to implement this standard. Please address the information to the 434 IETF at ietf-ipr@ietf.org. 436 Acknowledgment 438 Funding for the RFC Editor function is currently provided by the 439 Internet Society. 441 Appendix - non-normative. 443 Major Changes (reverse count) 444 Information about changes to the document since publishing -00 445 version will be documented here. 447 Major changes in version-08 448 1) Editorial changes 450 Major changes in version-07 451 1) References [4], [5] (in -06) have been removed. 452 2) Editorial nits have been fixed 453 3) Authors' list and contributors' list have been updated. 455 Major changes in version-06 456 1) Reference [3] is deleted. The reference indices are renmbered. 457 2) Changed the wording in the abstract to bring it in line with the 458 title 459 "INcident report" => "INcident information" 460 3) Added a sentence to the definition of Incident report 461 In this document the terms "incident report" and "incident 462 information" are used interchangeably. 463 4) Modified 4.1 (clause about preserving the contents of encoding 464 sensitive information when transferring is deleted). 465 5) Modified 4.11 (clause for supporting different time granularities 466 is deleted). 467 6) Revised the requirement 5.1 468 7) Editorial nits 470 Major changes in version-05 471 1) In 2.1 the definitions have been rearranged. Incident Report 472 (earlier 2.1.8 have been moved to 2.1.6) 473 2) Section 2.2, Operational model, revised 474 3) Editorial nits 475 4) IDnits 476 5) Added Roman Danyliw to the authors list. 478 Major changes in version -04 479 1) Operational model rewritten 480 2) Editorial nits 481 3) IPR notice updated 483 Major changes in version -03 (Second revision) 484 1) title changed to 485 Requirements for the Format for INcident information Exchange 486 (FINE) 487 2) editorial nits 488 3) RFC2119 key words used 489 4) added description to 4.6 490 5) reformatted 4.7 and 5.1 to have single statement requirements 491 followed by description of the requirements. 492 6) added an example to 4.2 493 7) moved 6.13 to Format requirements as 4.8 494 8) updated references #3, #5, #10 495 9) updated section 2.2 497 Major changes in version -03 (First revision) 498 1) editorial nits 499 2) in Security Considerations section an example is added to explain 500 the impact of the contents of the IR on the security and privacy 501 of individuals of organization. 502 3) Section 3 is deleted 504 Major changes in version -02 506 1) clarified definitions of some terms. Added a few definitions. 508 2) in 5.1, added requirement for handling non-standard/local 509 encoding and/or character codes. 511 3) in 5.7, added requirement that multiple versions of the report 512 should be consistent 514 4) in 7.5, added requirement that the source of each component of 515 the Incident report must be identified (if different from the 516 creator of the Incident report). 518 5) some editorial nits are fixed. 520 Major changes in version -01 522 1) clarified definition of some terms - still in the process, needs 523 more discussion with concerned parties. 525 2) re-written section 2. Operational model 527 3) added text about multilingual support for non-utf-8 character sets 529 to item "5.1 FINE shall support full internationalization and 530 localization" - results of discussion at IETF-56 532 4) included clear statement about unique identification of the 533 Incident report to item "5.1 FINE shall support full 534 internationalization and localization." 536 5) added item about the possibility of Incident description in 537 natural language: 539 7.7 The FINE may contain a description of the Incident or comprising 540 security events in a natural language. 542 6) requirement about describing impact of the Incident extended (item 543 7.9) with recommendation to provide guidelines to describe the impact 544 on the target to ensure a uniform interpretation of the description. 546 7) item 7.11 about time normalization extended with the possibility 547 to describe time offset when normalization is not possible.