idnits 2.17.1 draft-glenn-inch-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 91 has weird spacing: '...er hand the i...' == Line 109 has weird spacing: '...so that all u...' == Line 126 has weird spacing: '... should be in...' == Line 168 has weird spacing: '...vention that ...' -- 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 (October 28, 2002) is 7850 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) -- Looks like a reference, but probably isn't: 'RFC2277' on line 112 -- Looks like a reference, but probably isn't: 'RFC3067' on line 230 == Unused Reference: '1' is defined on line 238, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 241, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 244, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 251, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 260, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 263, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 268, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2828 (ref. '7') (Obsoleted by RFC 4949) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glenn M Keeni 3 Internet Draft Cyber Solutions Inc. 4 Expires: April 27, 2003 Hiroyuki Ohno 5 WIDE Project 6 October 28, 2002 8 INCH Requirements 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 1, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 The purpose of the Incident Report Format is to facilitate the 41 exchange of incident information and statistics among involved 42 parties and responsible Computer Security Incident Response Teams 43 (CSIRTs) for reactionary analysis of current intruder activity and 44 proactive identification of trends that can lead to incident 45 prevention. A common and well defined format will help in retrieving, 46 archiving and exchanging Incident Reports across organizations, 47 regions and countries. 49 This document describes the requirements for an Incident Report 50 format. 52 Table of Contents 54 1. Introduction .................................................. 3 55 2. Incident Report Information ................................... 3 56 3. General Requirements .......................................... 3 57 4. Format Requirements ........................................... 3 58 5. Communication Requirements .................................... 4 59 6. Content Requirements .......................................... 4 60 7. Intellectual Property ......................................... 6 61 8. Acknowledgements .............................................. 6 62 References ........................................................ 7 63 Security Considerations ........................................... 7 64 Authors' Addresses ................................................ 8 65 Full Copyright Statement .......................................... 9 67 1. Introduction 69 Computer security incidents occur across administrative domains often 70 spanning different organizations and national borders. Therefore, the 71 exchange of incident information and statistics among involved 72 parties and the responsible Computer Security Incident Response Teams 73 (CSIRTs) is crucial for both reactionary analysis of current intruder 74 activity and proactive identification of trends that can lead to 75 incident prevention. 77 In the following we refer to the information pertaining to an 78 incident as an Incident Report (IR). 80 This document defines the high-level functional requirements of the 81 format of an IR to facilitate collaboration between CSIRTs and 82 parties involved when handling computer security incidents. 84 2. The Information. 86 To make the information useful for search, retrieval, aggregation and 87 analysis related processing the semantics of the contents should be 88 well defined. It should be noted that there is a generic difference 89 between "alerts" [Cite idwg-requirements-doc] and incident reports. 90 The IDMEF alerts are generated by "sensors" and processed by managers 91 (applications). On the other hand the incident reports will be 92 generated by human beings and will also be consumed by human beings. 93 In the case of incident reports, the intent is 94 - to make its semantics as clear and unambiguous as possible 95 even across regional and national boundaries. 96 - to have a well defined syntax (atleast for parts of it), 97 - to enable categorization and statistical analysis 98 - to make it possible to ensure integrity of the message, 99 and the authenticity of the message source authenticated 100 3. General Requirements 102 3.1. The Incident Report Format (IRF) shall reference and use 103 previously published RFCs where possible. 105 4. Format Requirements 107 4.1 A major part of the IR will comprise of human-readable text. 108 The IRF must support full internationalization and localization, 109 so that all users of the Internet can use their own language 110 and its standard character set to express themselves. This 111 will require compliance with the IETF Character Set Policy 112 [RFC2277]. 114 4.2 IRF must be structured to support search and retrieval, 115 filtering and aggregation. The structure will contain several 116 components and some components may be structures themselves. Each 117 component of a structure will have a well defined semantics. 119 4.3 An IR may evolve with time. As investigation proceeds more 120 information about an incident may be revealed and parts of the 121 earlier information will be refined/obsoleted. The IRF must be able 122 to support an accurate record of the evolution of the IR with 123 appropriate timestamps identifying the epochs in the lifetime of an 124 IR.. 126 4.4 All time references in the IR should be interpreted 127 in an unambigious manner. It should be possible to transform 128 the time references to any of the standard time references e.g. 129 UTC. 131 4.5 An IR may contain sensitive information. The IRF must 132 support an access control mechanism. It must be possible to define 133 the access control for the individual components of the IR and for 134 individual accessing entities. 136 4.5 An IR must be globally uniquely identifiable. It should be 137 possible to map the origin of an IR from its globally unique 138 identifier. 140 4.6. The IRF itself must be extensible. The extension will be 141 in terms of addition of components and/or extending the 142 components. 144 5. Communications Requirements 146 5.1. IR generation and exchange will normally be initiated by 147 humans using standard communication protocols, for example, e-mail, 148 HTTP, FTP, etc. The communication mechanism must have no bearing on 149 the authenticity, integrity, confidentiality of the IR itself. 151 6. Content Requirements 152 The IRF must be flexible enough to support various degrees 153 of completeness. At the same time it must clearly state 154 the minimal information without which the information in the 155 IR will be seriously degraded. 157 6.1 An IR will generally refer to one or more entities. The entity 158 may be an attacker, a victim or an observer. There are several 159 facets of an entity involved in an IR. The entity may have 160 zero or more network addresses and names as well as zero or more 161 location names, organizational name, person names, machine names 162 etc. The IRF should support various facets describing the entities 163 involved. 165 6.2 There may be different rules and conventions for naming 166 entities in different regions and networks. The IRF must be able 167 to accomodate these rules and conventions. The format must be able 168 to identify the rule or convention that is used in the naming. 170 6.3 And IR must contain information based on which globally 171 uniquely identifier for the IR will be formed. 173 6.4 The IR should contain a classification of the attack. 174 The IRF must support well known classification/enumeration 175 schemes. 177 6.5 The IR must contain information about the originator of 178 the various components of the report. 180 6.6 The IR should contain information about the attacker and victim, 181 if known. 183 6.7 The IR should contain reference to advisories corresponding 184 to the IR e.g. CERT/CC, CVE, 186 6.8 The IR should contain a description of the incident. 188 6.9 The IR should contain additional references/pointers/information 189 This information should include IDMEF [4] messages which 190 may have been generated by security devices. 192 6.10 The IR should describe the Impact on the target, if known. 193 There should be guidelines to describe the impact on the target 194 to ensure a uniform interpretation of the description. 196 6.11 The IR should decribe the actions taken since the occurance 197 of the incidence. 199 6.12 The IR should carry information whereby its authenticity, integrity 200 can be verified and non-repudiation can be guaranteed. 202 6.13 The semantics of the IRF must be well defined. 203 The various components of the IRF should have a well defined 204 semantics. [Cant say the same about the contents of all components] 206 7. Intellectual Property 208 The IETF takes no position regarding the validity or scope of any 209 intellectual property or other rights that might be claimed to 210 pertain to the implementation or use of the technology described in 211 this document or the extent to which any license under such rights 212 might or might not be available; neither does it represent that it 213 has made any effort to identify any such rights. Information on the 214 IETF's procedures with respect to rights in standards-track and 215 standards-related documentation can be found in BCP-11. Copies of 216 claims of rights made available for publication and any assurances of 217 licenses to be made available, or the result of an attempt made to 218 obtain a general license or permission for the use of such 219 proprietary rights by implementors or users of this specification can 220 be obtained from the IETF Secretariat. 222 The IETF invites any interested party to bring to its attention any 223 copyrights, patents or patent applications, or other proprietary 224 rights which may cover technology that may be required to practice 225 this standard. Please address the information to the IETF Executive 226 Director. 228 8. Acknowledgments. 230 The precursor of this document is "IODEF Requirements" [RFC3067] 231 which is based on the work done at Incident Taxonomy and Description 232 Working Group at TERENA. Subsequent work and discussion has been 233 carried out in the INCH-BOF and in the WIDE-WG on Network Management 234 and Security. 236 9. References 238 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 239 Levels", BCP 14, RFC 2119, March 1997. 241 [2] Incident Taxonomy and Description Working Group Charter - 242 http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/ 244 [3] Intrusion Detection Exchange Format Requirements by Wood, M. - 245 December 2000, Work in Progress. 247 [4] Intrusion Detection Message Exchange Format Extensible Markup 248 Language (XML) Document Type Definition by D. Curry, H. Debar - 249 February 2001, Work in Progress. 251 [5] Guidelines for Evidence Collection and Archiving by Dominique 252 Brezinski, Tom Killalea - July 2000, Work in Progress. 254 [6] Brownlee, N. and E. Guttman, "Expectations for Computer Security 255 Incident Response", BCP 21, RFC 2350, June 1998. 257 [7] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 258 2000. 260 [8] Establishing a Computer Security Incident Response Capability 261 (CSIRC). NIST Special Publication 800-3, November, 1991 263 [9] Handbook for Computer Security Incident Response Teams (CSIRTs), 264 Moira J. West-Brown, Don Stikvoort, Klaus-Peter Kossakowski. - 265 CMU/SEI-98-HB-001. - Pittsburgh, PA: Carnegie Mellon University, 266 1998. 268 [10] A Common Language for Computer Security Incidents by John D. 269 Howard and Thomas A. Longstaff. - Sandia Report: SAND98-8667, 270 Sandia National Laboratories - 271 http://www.cert.org/research/taxonomy_988667.pdf 273 8. Security Considerations 275 This does not describe a protocol by itself memo it describes 276 the requirements for an Incident Report. It reports themselves 277 are about security incidents. The contents of the Incident Reports 278 will have significant direct and/or indirect impact on the security 279 and privacy of a network and/or individuals. Protocol designers 280 should take care to analyze and implement the requirements 281 stated in 4.5 and 6.12. 283 Authors' Addresses 285 Glenn Mansfield Keeni 286 Cyber Solutions Inc. 287 Sendai 288 Japan 290 EMail: glenn@cysols.com 292 Hiroyuki Ohno 293 WIDE Project, Japan 295 Email: hohno@wide.ad.jp 297 Full Copyright Statement 299 Copyright (C) The Internet Society (2002). All Rights Reserved. 301 This document and translations of it may be copied and furnished to 302 others, and derivative works that comment on or otherwise explain it 303 or assist in its implementation may be prepared, copied, published 304 and distributed, in whole or in part, without restriction of any 305 kind, provided that the above copyright notice and this paragraph are 306 included on all such copies and derivative works. However, this 307 document itself may not be modified in any way, such as by removing 308 the copyright notice or references to the Internet Society or other 309 Internet organizations, except as needed for the purpose of 310 developing Internet standards in which case the procedures for 311 copyrights defined in the Internet Standards process must be 312 followed, or as required to translate it into languages other than 313 English. 315 The limited permissions granted above are perpetual and will not be 316 revoked by the Internet Society or its successors or assigns. 318 This document and the information contained herein is provided on an 319 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 320 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 321 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 322 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 323 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 325 Acknowledgement 327 Funding for the RFC Editor function is currently provided by the 328 Internet Society.