idnits 2.17.1 draft-ietf-inch-iodef-14.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4205. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 31, 2007) is 6086 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: '0-9' on line 3279 -- Looks like a reference, but probably isn't: '0-4' on line 3279 -- Looks like a reference, but probably isn't: '0-5' on line 3279 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- 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 4646 (ref. '7') (Obsoleted by RFC 5646) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2822 (ref. '11') (Obsoleted by RFC 5322) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extended Incident Handling Working Group R. Danyliw 3 Internet-Draft CERT 4 Intended status: Standards Track J. Meijer 5 Expires: February 1, 2008 SURFnet bv 6 Y. Demchenko 7 University of Amsterdam 8 July 31, 2007 10 The Incident Object Description Exchange Format 11 draft-ietf-inch-iodef-14.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 1, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Incident Object Description Exchange Format (IODEF) defines a 45 data representation that provides a framework for sharing information 46 commonly exchanged by Computer Security Incident Response Teams 47 (CSIRTs) about computer security incidents. This document describes 48 the information model for the IODEF and provides an associated data 49 model specified with XML Schema. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 55 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 56 1.3. About the IODEF Data Model . . . . . . . . . . . . . . . . 6 57 1.4. About the IODEF Implementation . . . . . . . . . . . . . . 7 58 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . . 8 59 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.3. Characters and Strings . . . . . . . . . . . . . . . . . . 8 62 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . . 8 63 2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 9 65 2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . . 9 66 2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 9 67 2.9. Timezone string . . . . . . . . . . . . . . . . . . . . . 9 68 2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . . 10 70 2.12. Person or Organization . . . . . . . . . . . . . . . . . . 10 71 2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 10 72 2.14. Email string . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.15. Uniform Resource Locator strings . . . . . . . . . . . . . 10 74 3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . . 11 75 3.1. IODEF-Document class . . . . . . . . . . . . . . . . . . . 11 76 3.2. Incident class . . . . . . . . . . . . . . . . . . . . . . 12 77 3.3. IncidentID class . . . . . . . . . . . . . . . . . . . . . 15 78 3.4. AlternativeID class . . . . . . . . . . . . . . . . . . . 16 79 3.5. RelatedActivity class . . . . . . . . . . . . . . . . . . 16 80 3.6. AdditionalData . . . . . . . . . . . . . . . . . . . . . . 17 81 3.7. Contact class . . . . . . . . . . . . . . . . . . . . . . 19 82 3.7.1. RegistryHandle class . . . . . . . . . . . . . . . . . 22 83 3.7.2. PostalAddress class . . . . . . . . . . . . . . . . . 23 84 3.7.3. Email class . . . . . . . . . . . . . . . . . . . . . 24 85 3.7.4. Telephone and Fax classes . . . . . . . . . . . . . . 24 86 3.8. Time classes . . . . . . . . . . . . . . . . . . . . . . . 25 87 3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 25 88 3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 25 89 3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . . 25 90 3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . . 25 91 3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . . 25 92 3.9. Method class . . . . . . . . . . . . . . . . . . . . . . . 25 93 3.9.1. Reference class . . . . . . . . . . . . . . . . . . . 26 94 3.10. Assessment class . . . . . . . . . . . . . . . . . . . . . 27 95 3.10.1. Impact class . . . . . . . . . . . . . . . . . . . . . 28 96 3.10.2. TimeImpact class . . . . . . . . . . . . . . . . . . . 30 97 3.10.3. MonetaryImpact class . . . . . . . . . . . . . . . . . 32 98 3.10.4. Confidence class . . . . . . . . . . . . . . . . . . . 33 99 3.11. History class . . . . . . . . . . . . . . . . . . . . . . 34 100 3.11.1. HistoryItem class . . . . . . . . . . . . . . . . . . 34 101 3.12. EventData class . . . . . . . . . . . . . . . . . . . . . 36 102 3.12.1. Relating the Incident and EventData classes . . . . . 38 103 3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 38 104 3.13. Expectation class . . . . . . . . . . . . . . . . . . . . 39 105 3.14. Flow class . . . . . . . . . . . . . . . . . . . . . . . . 41 106 3.15. System class . . . . . . . . . . . . . . . . . . . . . . . 42 107 3.16. Node class . . . . . . . . . . . . . . . . . . . . . . . . 44 108 3.16.1. Counter class . . . . . . . . . . . . . . . . . . . . 45 109 3.16.2. Address . . . . . . . . . . . . . . . . . . . . . . . 46 110 3.16.3. NodeRole class . . . . . . . . . . . . . . . . . . . . 48 111 3.17. Service class . . . . . . . . . . . . . . . . . . . . . . 49 112 3.17.1. Application class . . . . . . . . . . . . . . . . . . 51 113 3.18. OperatingSystem class . . . . . . . . . . . . . . . . . . 52 114 3.19. Record class . . . . . . . . . . . . . . . . . . . . . . . 52 115 3.19.1. RecordData class . . . . . . . . . . . . . . . . . . . 53 116 3.19.2. RecordPattern class . . . . . . . . . . . . . . . . . 54 117 3.19.3. RecordItem class . . . . . . . . . . . . . . . . . . . 55 118 4. Processing Considerations . . . . . . . . . . . . . . . . . . 56 119 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 56 120 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 56 121 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 56 122 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 58 123 5.1. Extending the enumerated values of attributes . . . . . . 58 124 5.2. Extending classes . . . . . . . . . . . . . . . . . . . . 58 125 6. Internationalization issues . . . . . . . . . . . . . . . . . 61 126 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 127 7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 128 7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 63 129 7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 65 130 7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . . 67 131 8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . . 69 132 9. Security considerations . . . . . . . . . . . . . . . . . . . 90 133 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 91 134 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 135 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 93 136 12.1. Normative References . . . . . . . . . . . . . . . . . . . 93 137 12.2. Informative References . . . . . . . . . . . . . . . . . . 94 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95 139 Intellectual Property and Copyright Statements . . . . . . . . . . 96 141 1. Introduction 143 Organizations require help from other parties to mitigate malicious 144 activity targeting their network and to gain insight into potential 145 threats. This coordination might entail working with an ISP to 146 filter attack traffic, contacting a remote site to take down a bot- 147 network, or sharing watch-lists of known malicious IP addresses in a 148 consortium. 150 The Incident Object Description Exchange Format (IODEF) is a format 151 for representing computer security information commonly exchanged 152 between Computer Security Incident Response Teams (CSIRTs). It 153 provides an XML representation for conveying incident information 154 across administrative domains between parties that have an 155 operational responsibility of remediation or a watch-and-warning over 156 a defined constituency. The data model encodes information about 157 hosts, networks, and the services running on these systems; attack 158 methodology and associated forensic evidence; impact of the activity; 159 and limited approaches for documenting workflow. 161 The overriding purpose of the IODEF is to enhance the operational 162 capabilities of CSIRTs. Community adoption of the IODEF provides an 163 improved ability to resolve incidents and convey situational 164 awareness by simplifying collaboration and data sharing. This 165 structured format provided by the IODEF allows for: 167 o increased automation in processing of incident data since the 168 resources of security analysts to parse free-form textual 169 documents will be reduced; 171 o decreased effort in normalizing similar data (even when highly 172 structured) from different sources; and 174 o a common format on which to build interoperable tools for incident 175 handling and subsequent analysis, specifically when data comes 176 from multiple constituencies. 178 Coordinating with other CSIRTs is not strictly a technical problem. 179 There are numerous procedural, trust, and legal considerations that 180 might prevent an organization from sharing information. The IODEF 181 does not attempt to address them. However operational 182 implementations of the IODEF will need to consider this broader 183 context. 185 Sections 3 and 8 specify the IODEF data model with text and an XML 186 schema. The types used by the data model are covered in Section 2. 187 Processing considerations, the handling of extensions, and 188 internationalization issues related to the data model are covered in 189 Sections 4, 5, and 6 respectively. Examples are listed in Section 7. 190 Section 1 provides the background for the IODEF, and Section 9 191 documents the security considerations. 193 1.1. Terminology 195 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 196 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 197 document are to be interpreted as described in RFC2119 [6]. 199 Definitions for some of the common computer security-related 200 terminology used in this document can be found in Section 2 of [16]. 202 1.2. Notations 204 The normative IODEF data model is specified with the text in Section 205 3 and the XML schema in Section 8. To help in the understanding of 206 the data elements, Section 3 also depicts the underlying information 207 model using Unified Modeling Language (UML). This abstract 208 presentation of the IODEF is not normative. 210 For clarity in this document, the term "XML document" will be used 211 when referring generically to any instance of an XML document. The 212 term "IODEF document" will be used to refer to specific elements and 213 attributes of the IODEF schema. The terms "class", and "element" 214 will be used interchangeably to reference either the corresponding 215 data element in the information or data models respectively. 217 1.3. About the IODEF Data Model 219 The IODEF data model is a data representation that provides a 220 framework for sharing information commonly exchanged by CSIRTs about 221 computer security incidents. A number of considerations were made in 222 the design of the data model. 224 o The data model serves as a transport format. Therefore, its 225 specific representation is not the optimal representation for on- 226 disk storage, long-term archiving, or in-memory processing. 228 o As there is no precise, widely agreed upon definition for an 229 incident, the data model does not attempt to dictate one through 230 its implementation. Rather, a broad understanding is assumed in 231 the IODEF that is flexible enough to encompass most operators. 233 o Describing an incident for all definitions would require an 234 extremely complex data model. Therefore, the IODEF only intends 235 to be a framework to convey commonly exchanged incident 236 information. It ensures that there are ample mechanisms for 237 extensibility to support organization-specific information, and 238 techniques to reference information kept outside of the explicit 239 data model. 241 o The domain of security analysis is not fully standardized and must 242 rely on free-form textual descriptions. The IODEF attempts to 243 strike a balance between supporting this free-form content, while 244 still allowing automated processing of incident information. 246 o The IODEF is only one of several security relevant data 247 representations being standardized. Attempts were made to ensure 248 they were complimentary. The data model of the Intrusion 249 Detection Message Exchange Format [17] influenced the design of 250 the IODEF. 252 Further discussion of the desirable properties for the IODEF can be 253 found in the Requirements for the Format for Incident Information 254 Exchange (FINE) [16]. 256 1.4. About the IODEF Implementation 258 The IODEF implementation is specified as an Extensible Markup 259 Language (XML) [1] Schema [2] in Section 8. 261 Implementing the IODEF in XML provides numerous advantages. Its 262 extensibility makes it ideal for specifying a data encoding framework 263 that supports various character encodings. Likewise, the abundance 264 of related technologies (e.g., XSL, XPath, XML-Signature) makes for 265 simplified manipulation. However, XML is fundamentally a text 266 representation which makes it inherently inefficient when binary data 267 must be embedded or large volumes of data must be exchanged. 269 2. IODEF Data Types 271 The various data elements of the IODEF data model are typed. This 272 section discusses these data types. When possible, native Schema 273 data types were adopted, but for more complicated formats, regular 274 expressions (see Appendix F of [3]) or external standards were used. 276 2.1. Integers 278 An integer is represented by the INTEGER data type. Integer data 279 MUST be encoded in Base 10. 281 The INTEGER data type is implemented as an "xs:integer" [3] in the 282 schema. 284 2.2. Real Numbers 286 Real (floating-point) attributes are represented by the REAL data 287 type. Real data MUST be encoded in Base 10. 289 The REAL data type is implemented as an "xs:float" [3] in the schema. 291 2.3. Characters and Strings 293 A single character is represented by the CHARACTER data type. A 294 character string is represented by the STRING data type. Special 295 characters must be encoded using entity references. See Section 4.1. 297 The CHARACTER and STRING data types are implement as an "xs:string" 298 [3] in the schema. 300 2.4. Multilingual Strings 302 STRING data that represents multi-character attributes in a language 303 different than the default encoding of the document is of the 304 ML_STRING data type. 306 The ML_STRING data type is implemented as an "iodef:MLStringType" in 307 the schema. 309 2.5. Bytes 311 A binary octet is represented by the BYTE data type. A sequence of 312 binary octets is represented by the BYTE[] data type. These octets 313 are encoded using base64. 315 The BYTE data type is implemented as an "xs:base64Binary" [3] in the 316 schema. 318 2.6. Hexadecimal Bytes 320 A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. 321 This octet is encoded as a character tuple consisting of two 322 hexadecimal digits. 324 The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the 325 schema. 327 2.7. Enumerated Types 329 Enumerated types are represented by the ENUM data type, and consist 330 of an ordered list of acceptable values. Each value has a 331 representative keyword. Within the IODEF schema, the enumerated type 332 keywords are used as attribute values. 334 The ENUM data type is implemented as a series of "xs:NMTOKEN" in the 335 schema. 337 2.8. Date-Time Strings 339 Date-time strings are represented by the DATETIME data type. Each 340 date-time string identifies a particular instant in time; ranges are 341 not supported. 343 Date-time strings are formatted according to a subset of ISO 8601: 344 2000 [13] documented in RFC 3339 [12]. 346 The DATETIME data type is implemented as an "xs:dateTime" [3] in the 347 schema. 349 2.9. Timezone string 351 A timezone offset from UTC is represented by the TIMEZONE data type. 352 It is formatted according to the following regular expression: 353 "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". 355 The TIMEZONE data type is implemented as an "xs:string" with a 356 regular expression constraint in the schema. This regular expression 357 is identical to the timezone representation implemented in an "xs: 358 dateTime". 360 2.10. Port Lists 362 A list of network ports are represented by the PORTLIST data type. A 363 PORTLIST consists of a comma-separated list of numbers and ranges 364 (N-M means ports N through M, inclusive). It is formatted according 365 to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". 367 For example, "2,5-15,30,32,40-50,55-60". 369 The PORTLIST data type is implemented as an "xs:string" with a 370 regular expression constraint in the schema. 372 2.11. Postal Address 374 A postal address is represented by the POSTAL data type. This data 375 type is a ML_STRING whose format is documented in Sections 2.23 of 376 RFC 4519 [10]. It defines a postal address as a free-form multi-line 377 string separated by the "$" character. 379 The POSTAL data type is implemented as an "xs:string" in the schema. 381 2.12. Person or Organization 383 The name of an individual or organization is represented by the NAME 384 data type. This data type is an ML_STRING whose format is documented 385 in Section 2.3 of RFC 4519 [10]. 387 The NAME data type is implemented as an "xs:string" in the schema. 389 2.13. Telephone and Fax Numbers 391 A telephone or fax number is represented by the PHONE data type. The 392 format of the PHONE data type is documented in Section 2.35 of RFC 393 4519 [10]. 395 The PHONE data type is implemented as an "xs:string" in the schema. 397 2.14. Email string 399 An email address is represented by the EMAIL data type. The format 400 of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11] 402 The EMAIL data type is implemented as an "xs:string" in the schema. 404 2.15. Uniform Resource Locator strings 406 A uniform resource locator (URL is represented by the URL data type. 407 The format of the URL data type is documented in RFC 2396 [8]. 409 The URL data type is implemented as an "xs:anyURI" in the schema. 411 3. The IODEF Data Model 413 In this section, the individual components of the IODEF data model 414 will be discussed in detail. For each class, the semantics will be 415 described and the relationship with other classes will be depicted 416 with UML. When necessary, specific comments will be made about 417 corresponding definition in the schema in Section 8 419 3.1. IODEF-Document class 421 The IODEF-Document class is the top level class in the IODEF data 422 model. All IODEF documents are an instance of this class. 424 +-----------------+ 425 | IODEF-Document | 426 +-----------------+ 427 | STRING version |<>--{1..*}--[ Incident ] 428 | ENUM lang | 429 | STRING formatid | 430 +-----------------+ 432 Figure 1: IODEF-Document class 434 The aggregate class that constitute IODEF-Document is: 436 Incident 437 One or more. The information related to a single incident. 439 The IODEF-Document class has three attributes: 441 version 442 Required. STRING. The IODEF specification version number to 443 which this IODEF document conforms. The value of this attribute 444 MUST be "1.00" 446 lang 447 Required. ENUM. A valid language code per RFC 4646 [7] 448 constrained by the definition of "xs:language". The 449 interpretation of this code is described in Section 6. 451 formatid 452 Optional. STRING. A free-form string to convey processing 453 instructions to the recipient of the document. Its semantics must 454 be negotiated out-of-band. 456 3.2. Incident class 458 Every incident is represented by an instance of the Incident class. 459 This class provides a standardized representation for commonly 460 exchanged incident data. 462 +--------------------+ 463 | Incident | 464 +--------------------+ 465 | ENUM purpose |<>----------[ IncidentID ] 466 | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] 467 | ENUM lang |<>--{0..1}--[ RelatedActivity ] 468 | ENUM restriction |<>--{0..1}--[ DetectTime ] 469 | |<>--{0..1}--[ StartTime ] 470 | |<>--{0..1}--[ EndTime ] 471 | |<>----------[ ReportTime ] 472 | |<>--{0..*}--[ Description ] 473 | |<>--{1..*}--[ Assessment ] 474 | |<>--{0..*}--[ Method ] 475 | |<>--{1..*}--[ Contact ] 476 | |<>--{0..*}--[ EventData ] 477 | |<>--{0..1}--[ History ] 478 | |<>--{0..*}--[ AdditionalData ] 479 +--------------------+ 481 Figure 2: the Incident class 483 The aggregate classes that constitute Incident are: 485 IncidentID 486 One. An incident tracking number assigned to this incident by the 487 CSIRT that generated the IODEF document. 489 AlternativeID 490 Zero or one. The incident tracking numbers used by other CSIRTs 491 to refer to the incident described in the document. 493 RelatedActivity 494 Zero or one. The incident tracking numbers of related incidents. 496 DetectTime 497 Zero or one. The time the incident was first detected. 499 StartTime 500 Zero or one. The time the incident started. 502 EndTime 503 Zero or one. The time the incident ended. 505 ReportTime 506 One. The time the incident was reported. 508 Description 509 Zero or more. ML_STRING. A free-form textual description of the 510 incident. 512 Assessment 513 One or more. A characterization of the impact of the incident. 515 Method 516 Zero or more. The techniques used by the intruder in the 517 incident. 519 Contact 520 One or more. Contact information for the parties involved in the 521 incident. 523 EventData 524 Zero or more. Description of the events comprising the incident, 526 History 527 Zero or one. A log of significant events or actions that occurred 528 during the course of handling the incident. 530 AdditionalData 531 Zero or more. Mechanism by which to extend the data model. 533 The Incident class has four attributes: 535 purpose 536 Required. ENUM. The purpose attribute represents the reason why 537 the IODEF document was created. It is closely related to the 538 Expectation class (Section 3.13). This attribute is defined as an 539 enumerated list: 541 1. traceback. The document was sent for trace-back purposes; 543 2. mitigation. The document was sent to request aid in 544 mitigating the described activity; 546 3. reporting. The document was sent to comply with reporting 547 requirements; 549 4. other. The document was sent for purposes specified in the 550 Expectation class. 552 5. ext-value. An escape value used to extend this attribute. 553 See Section 5.1. 555 ext-purpose 556 Optional. STRING. A means by which to extend the purpose 557 attribute. See Section 5.1. 559 lang 560 Optional. ENUM. A valid language code per RFC 4646 [7] 561 constrained by the definition of "xs:language". The 562 interpretation of this code is described in Section 6. 564 restriction 565 Optional. ENUM. This attribute indicates the disclosure 566 guidelines to which the sender expects the recipient to adhere for 567 the information represented in this class and its children. This 568 guideline provides no security since there are no specified 569 technical means to ensure that the recipient of the document 570 handles the information as the sender requested. 572 The value of this attribute is logically inherited by the children 573 of this class. That is to say, the disclosure rules applied to 574 this class, also apply to its children. 576 It is possible to set a granular disclosure policy, since all of 577 the high-level classes (i.e., children of the Incident class) have 578 a restriction attribute. Therefore, a child can override the 579 guidelines of a parent class, be it to restrict or relax the 580 disclosure rules (e.g., a child has a weaker policy than an 581 ancestor; or an ancestor has a weak policy, and the children 582 selectively apply more rigid controls). The implicit value of the 583 restriction attribute for a class that did not specify one can be 584 found in the closest ancestor that did specify a value. 586 This attribute is defined as an enumerated value with a default 587 value of "private". Note that the default value of the 588 restriction attribute is only defined in the context of the 589 Incident class. In other classes where this attribute is used, no 590 default is specified. 592 1. public. There are no restrictions placed in the information; 593 2. need-to-know. The information may be shared with other 594 parties that are involved in the incident as determined by the 595 recipient of this document (e.g., multiple victim sites can be 596 informed of each other); 598 3. private. The information may not be shared. 600 4. default. The information can be shared according to an 601 information disclosure policy pre-arranged by the 602 communicating parties. 604 3.3. IncidentID class 606 The IncidentID class represents an incident tracking number that is 607 unique in the context of the CSIRT and identifies the activity 608 characterized in an IODEF Document. This identifier would serve as 609 an index into the CSIRT incident handling system. The combination of 610 the name attribute and the string in the element content MUST be a 611 globally unique identifier describing the activity. Documents 612 generated by a given CSIRT MUST NOT reuse the same value unless they 613 are referencing the same incident. 615 +------------------+ 616 | IncidentID | 617 +------------------+ 618 | STRING | 619 | | 620 | STRING name | 621 | STRING instance | 622 | ENUM restriction | 623 +------------------+ 625 Figure 3: the IncidentID class 627 The IncidentID class has three attributes: 629 name 630 Required. STRING. An identifier describing the CSIRT that 631 created the document. In order to have a globally unique CSIRT 632 name, the fully qualified domain name associated with the CSIRT 633 MUST be used. 635 instance 636 Optional. STRING. An identifier referencing a subset of the 637 named incident. 639 restriction 640 Optional. ENUM. This attribute has been defined in Section 3.2. 642 3.4. AlternativeID class 644 The AlternativeID class lists the incident tracking numbers used by 645 CSIRTs, other than the one generating the document, to refer to the 646 identical activity described the IODEF document. A tracking number 647 listed as an AlternativeID references the same incident detected by 648 another CSIRT. The incident tracking numbers of the CSIRT that 649 generated the IODEF document should never be considered an 650 AlternativeID. 652 +------------------+ 653 | AlternativeID | 654 +------------------+ 655 | ENUM restriction |<>--{1..*}--[ IncidentID ] 656 | | 657 +------------------+ 659 Figure 4: the AlternativeID class 661 The aggregate class that constitutes AlternativeID is: 663 IncidentID 664 One or more. The incident tracking number of another CSIRT. 666 The AlternativeID class has one attribute: 668 restriction 669 Optional. ENUM. This attribute has been defined in Section 3.2. 671 3.5. RelatedActivity class 673 The RelatedActivity class lists either incident tracking numbers of 674 incidents or URLs (not both) that refer to activity related to the 675 one described in the IODEF document. These references may be to 676 local incident tracking numbers or to those of other CSIRTs. 678 The specifics of how a CSIRT comes to believe that two incidents are 679 related are considered out of scope. 681 +------------------+ 682 | RelatedActivity | 683 +------------------+ 684 | ENUM restriction |<>--{0..*}--[ IncidentID ] 685 | |<>--{0..*}--[ URL ] 686 +------------------+ 688 Figure 5: RelatedActivity class 690 The aggregate classes that constitutes RelatedActivity are: 692 IncidentID 693 One or more. The incident tracking number of a related incident. 695 URL 696 One or more. URL. A URL to activity related to this incident. 698 The RelatedActivity class has one attribute: 700 restriction 701 Optional. ENUM. This attribute has been defined in Section 3.2. 703 3.6. AdditionalData 705 The AdditionalData class serves as an extension mechanism for 706 information not otherwise represented in the data model. For 707 relatively simple information, atomic data types (e.g., integers, 708 strings) are provided with a mechanism to annotate their meaning. 709 The class can also be used to extend the data model (and the 710 associated Schema) to support proprietary extensions by encapsulating 711 entire XML documents conforming to another Schema (e.g., IDMEF). A 712 detailed discussion for extending the data model and the schema can 713 be found in Section 5. 715 Unlike XML, which is self-describing, atomic data must be documented 716 to convey its meaning. This information is described in the 717 'meaning' attribute. Since these description are outside the scope 718 of the specification, some additional coordination may be required to 719 ensure that a recipient of a document using the AdditionalData 720 classes can make sense of the custom extensions. 722 +------------------+ 723 | AdditionalData | 724 +------------------+ 725 | ANY | 726 | | 727 | ENUM dtype | 728 | STRING ext-dtype | 729 | STRING meaning | 730 | STRING formatid | 731 | ENUM restriction | 732 +------------------+ 734 Figure 6: the AdditionalData class 736 The AdditionalData class has five attributes: 738 dtype 739 Required. ENUM. The data type of the element content. The 740 permitted values for this attribute are shown below. The default 741 value is "string". 743 1. boolean. The element content is of type BOOLEAN. 745 2. byte. The element content is of type BYTE. 747 3. character. The element content is of type CHARACTER. 749 4. date-time. The element content is of type DATETIME. 751 5. integer. The element content is of type INTEGER. 753 6. portlist. The element content is of type PORTLIST. 755 7. real. The element content is of type REAL. 757 8. string. The element content is of type STRING. 759 9. file. The element content is a base64 encoded binary file 760 encoded as a BYTE[] type. 762 10. frame. The element content is a layer-2 frame encoded as a 763 HEXBIN type. 765 11. packet. The element content is a layer-3 packet encoded as a 766 HEXBIN type. 768 12. ipv4-packet. The element content is an IPv4 packet encoded 769 as a HEXBIN type. 771 13. ipv6-packet. The element content is an IPv6 packet encoded 772 as a HEXBIN type. 774 14. path. The element content is a file-system path encoded as a 775 STRING type. 777 15. url. The element content is of type URL. 779 16. csv. The element content is a common separated value (CSV) 780 list per Section 2 of [20] encoded as a STRING type. 782 17. winreg. The element content is a Windows registry key 783 encoded as a STRING type. 785 18. xml. The element content is XML (see Section 5). 787 19. ext-value. An escape value used to extend this attribute. 788 See Section 5.1. 790 ext-dtype 791 Optional. STRING. A means by which to extend the dtype 792 attribute. See Section 5.1. 794 meaning 795 Optional. STRING. A free-form description of the element 796 content. 798 formatid 799 Optional. STRING. An identifier referencing the format and 800 semantics of the element content. 802 restriction 803 Optional. ENUM. This attribute has been defined in Section 3.2. 805 3.7. Contact class 807 The Contact class describes contact information for organizations and 808 personnel involved in the incident. This class allows for the naming 809 of the involved party, specifying contact information for them, and 810 identifying their role in the incident. 812 People and organizations are treated interchangeably as contacts; one 813 can be associated with the other using the recursive definition of 814 the class (the Contact class is aggregated into the Contact class). 815 The 'type' attribute disambiguates the type of contact information 816 being provided. 818 The inheriting definition of Contact provides a way to relate 819 information without requiring the explicit use of identifiers in the 820 classes or duplication of data. A complete point of contact is 821 derived by a particular traversal from the root Contact class to the 822 leaf Contact class. As such, multiple points of contact might be 823 specified in a single instance of a Contact class. Each child 824 Contact class logically inherits contact information from it's 825 ancestors. 827 +------------------+ 828 | Contact | 829 +------------------+ 830 | ENUM role |<>--{0..1}--[ ContactName ] 831 | STRING ext-role |<>--{0..*}--[ Description ] 832 | ENUM type |<>--{0..*}--[ RegistryHandle ] 833 | STRING ext-type |<>--{0..1}--[ PostalAddress ] 834 | ENUM restriction |<>--{0..*}--[ Email ] 835 | |<>--{0..*}--[ Telephone ] 836 | |<>--{0..1}--[ Fax ] 837 | |<>--{0..1}--[ Timezone ] 838 | |<>--{0..*}--[ Contact ] 839 | |<>--{0..*}--[ AdditionalData ] 840 +------------------+ 842 Figure 7: the Contact class 844 The aggregate classes that constitute the Contact class are: 846 ContactName 847 Zero or one. ML_STRING. The name of the contact. The contact 848 may either be an organization or a person. The type attribute 849 disambiguates the semantics. 851 Description 852 Zero or many. ML_STRING. A free-form description of this 853 contact. In the case of a person, this is often the 854 organizational title of the individual. 856 RegistryHandle 857 Zero or many. A handle name into the registry of the contact. 859 PostalAddress 860 Zero or one. The postal address of the contact. 862 Email 863 Zero or many. The email address of the contact. 865 Telephone 866 Zero or many. The telephone number of the contact. 868 Fax 869 Zero or one. The facsimile telephone number of the contact. 871 Timezone 872 Zero or one. TIMEZONE. The timezone in which the contact resides 873 formatted according to Section 2.9. 875 Contact 876 Zero or many. A Contact instance contained within another Contact 877 instance inherits the values of the parent(s). This recursive 878 definition can be used to group common data pertaining to multiple 879 points of contact and is especially useful when listing multiple 880 contacts at the same organization. 882 AdditionalData 883 Zero or many. A mechanism by which to extend the data model. 885 At least one of the aggregate classes MUST be present in an instance 886 of the Contact class. This is not enforced in the IODEF schema as 887 there is no simple way to accomplish it. 889 The Contact class has five attributes: 891 role 892 Required. ENUM. Indicates the role the contact fulfills. This 893 attribute is defined as an enumerated list: 895 1. creator. The entity that generate the document. 897 2. admin. An administrative contact for a host or network. 899 3. tech. A technical contact for a host or network. 901 4. irt. The CSIRT involved in handling the incident. 903 5. cc. An entity that is to be kept informed about the handling 904 of the incident. 906 6. ext-value. An escape value used to extend this attribute. 907 See Section 5.1. 909 ext-role 910 Optional. STRING. A means by which to extend the role attribute. 911 See Section 5.1. 913 type 914 Required. ENUM. Indicates the type of contact being described. 915 This attribute is defined as an enumerated list: 917 1. person. The information for this contact references an 918 individual. 920 2. organization. The information for this contact references an 921 organization. 923 3. ext-value. An escape value used to extend this attribute. 924 See Section 5.1. 926 ext-type 927 Optional. STRING. A means by which to extend the type attribute. 928 See Section 5.1. 930 restriction 931 Optional. ENUM. This attribute is defined in Section 3.2. 933 3.7.1. RegistryHandle class 935 The RegistryHandle class represents a handle into an Internet 936 registry or community-specific database. The handle is specified in 937 the element content and the type attribute specifies the database. 939 +---------------------+ 940 | RegistryHandle | 941 +---------------------+ 942 | STRING | 943 | | 944 | ENUM registry | 945 | STRING ext-registry | 946 +---------------------+ 948 Figure 8: The RegistryHandle class 950 The RegistryHandle class has two attributes: 952 registry 953 Required. ENUM. The database to which the handle belongs. The 954 default value is 'local'. The possible values are: 956 1. internic. Internet Network Information Center 958 2. apnic. Asia Pacific Network Information Center 960 3. arin. American Registry for Internet Numbers 962 4. lacnic. Latin-American and Caribbean IP Address Registry 964 5. ripe. Reseaux IP Europeens 966 6. afrinic. African Internet Numbers Registry 968 7. local. A database local to the CSIRT. 970 8. ext-value. An escape value used to extend this attribute. 971 See Section 5.1. 973 ext-registry 974 Optional. STRING. A means by which to extend the registry 975 attribute. See Section 5.1. 977 3.7.2. PostalAddress class 979 The PostalAddress class specifies a postal address formatted 980 according to the POSTAL data type (Section 2.11). 982 +---------------------+ 983 | PostalAddress | 984 +---------------------+ 985 | POSTAL | 986 | | 987 | ENUM meaning | 988 | ENUM lang | 989 +---------------------+ 991 Figure 9: The PostalAddress class 993 The PostalAddress class has two attributes: 995 meaning 996 Optional. ENUM. A free-form description of the element content. 998 lang 999 Required. ENUM. A valid language code per RFC 4646 [7] 1000 constrained by the definition of "xs:language". The 1001 interpretation of this code is described in Section 6. 1003 3.7.3. Email class 1005 The Email class specifies an email address formatted according to 1006 EMAIL data type (Section 2.14). 1008 +--------------+ 1009 | Email | 1010 +--------------+ 1011 | EMAIL | 1012 | | 1013 | ENUM meaning | 1014 +--------------+ 1016 Figure 10: The Email class 1018 The Email class has one attribute: 1020 meaning 1021 Optional. ENUM. A free-form description of the element content. 1023 3.7.4. Telephone and Fax classes 1025 The Telephone and Fax classes specify a voice or fax telephone number 1026 respectively, and are formatted according to PHONE data type 1027 (Section 2.13). 1029 +--------------------+ 1030 | {Telephone | Fax } | 1031 +--------------------+ 1032 | PHONE | 1033 | | 1034 | ENUM meaning | 1035 +--------------------+ 1037 Figure 11: The Telephone and Fax classes 1039 The Telephone class has one attribute: 1041 meaning 1042 Optional. ENUM. A free-form description of the element content 1043 (e.g., hours of coverage for a given number). 1045 3.8. Time classes 1047 The data model uses five different classes to represent a timestamp. 1048 Their definition is identical, but each has a distinct name to convey 1049 a difference in semantics. 1051 The element content of each class is a timestamp formatted according 1052 to the DATETIME data type (see Section 2.8). 1054 +----------------------------------+ 1055 | {Start| End| Report| Detect}Time | 1056 +----------------------------------+ 1057 | DATETIME | 1058 +----------------------------------+ 1060 Figure 12: the Time classes 1062 3.8.1. StartTime 1064 The StartTime class represents the time the incident began. 1066 3.8.2. EndTime 1068 The EndTime class represents the time the incident ended. 1070 3.8.3. DetectTime 1072 The DetectTime class represents the time the first activity of the 1073 incident was detected. 1075 3.8.4. ReportTime 1077 The ReportTime class represents the time the incident was reported. 1078 This timestamp SHOULD coincide to the time at which the IODEF 1079 document is generated. 1081 3.8.5. DateTime 1083 The DateTime class is a generic representation of a timestamp. Its 1084 semantics should be inferred from the parent class in which it is 1085 aggregated. 1087 3.9. Method class 1089 The Method class describes the methodology used by the intruder to 1090 perpetrate the events of the incident. This class consists of a list 1091 of references describing the attack method and a free form 1092 description of the technique. 1094 +------------------+ 1095 | Method | 1096 +------------------+ 1097 | ENUM restriction |<>--{0..*}--[ Reference ] 1098 | |<>--{0..*}--[ Description ] 1099 | |<>--{0..*}--[ AdditionalData ] 1100 +------------------+ 1102 Figure 13: The Method class 1104 The Method class is composed of three aggregate classes. 1106 Reference 1107 Zero or many. A reference to a vulnerability, malware sample, 1108 advisory, or analysis of an attack technique. 1110 Description 1111 Zero or many. ML_STRING. A free-form text description of the 1112 methodology used by the intruder. 1114 AdditionalData 1115 Zero or many. A mechanism by which to extend the data model. 1117 Either an instance of the Reference or Description class MUST be 1118 present. 1120 The Method class has one attribute: 1122 restriction 1123 Optional. ENUM. This attribute is defined in Section 3.2. 1125 3.9.1. Reference class 1127 The Reference class is a reference to a vulnerability, IDS alert, 1128 malware sample, advisory, or attack technique. A reference consists 1129 of a name, a URL to this reference, and an optional description. 1131 +------------------+ 1132 | Reference | 1133 +------------------+ 1134 | |<>----------[ ReferenceName ] 1135 | |<>--{0..*}--[ URL ] 1136 | |<>--{0..*}--[ Description ] 1137 +------------------+ 1139 Figure 14: The Reference class 1141 The aggregate classes that constitute Reference: 1143 ReferenceName 1144 One. ML_STRING. Name of the reference. 1146 URL 1147 Zero or many. URL. A URL associated with the reference. 1149 Description 1150 Zero or many. ML_STRING. A free-form text description of this 1151 reference. 1153 3.10. Assessment class 1155 The Assessment class describes the technical and non-technical 1156 repercussions of the incident on the CSIRT's constituency. 1158 This class was derived from the IDMEF[17]. 1160 +------------------+ 1161 | Assessment | 1162 +------------------+ 1163 | ENUM occurrence |<>--{0..*}--[ Impact ] 1164 | ENUM restriction |<>--{0..*}--[ TimeImpact ] 1165 | |<>--{0..*}--[ MonetaryImpact ] 1166 | |<>--{0..*}--[ Counter ] 1167 | |<>--{0..1}--[ Confidence ] 1168 | |<>--{0..*}--[ AdditionalData ] 1169 +------------------+ 1171 Figure 15: Assessment class 1173 The aggregate classes that constitute Assessment are: 1175 Impact 1176 Zero or many. Technical impact of the incident on a network. 1178 TimeImpact 1179 Zero or many. Impact of the activity measured with respect to 1180 time. 1182 MonetaryImpact 1183 Zero or many. Impact of the activity measured with respect to 1184 financial loss. 1186 Counter 1187 Zero or more. A counter with which to summarize the magnitude of 1188 the activity. 1190 Confidence 1191 Zero or one. An estimate of confidence in the assessment. 1193 AdditionalData 1194 Zero or many. A mechanism by which to extend the data model. 1196 A least one instance of the possible three impact classes (i.e., 1197 Impact, TimeImpact, or MonetaryImpact) MUST be present. 1199 The Assessment class has two attributes: 1201 occurrence 1202 Optional. ENUM. Specifies whether the assessment is describing 1203 actual or potential outcomes. The default is "actual" and is 1204 assumed if not specified. 1206 1. actual. This assessment describes activity that has occurred. 1208 2. potential. This assessment describes potential activity that 1209 might occur. 1211 restriction 1212 Optional. ENUM. This attribute is defined in Section 3.2. 1214 3.10.1. Impact class 1216 The Impact class allows for categorizing and describing the technical 1217 impact of the incident on the network of an organization. 1219 This class is based on the IDMEF [17]. 1221 +------------------+ 1222 | Impact | 1223 +------------------+ 1224 | ML_STRING | 1225 | | 1226 | ENUM lang | 1227 | ENUM severity | 1228 | ENUM completion | 1229 | ENUM type | 1230 | STRING ext-type | 1231 +------------------+ 1232 Figure 16: Impact class 1234 The element content will be a free-form textual description of the 1235 impact. 1237 The Impact class has five attributes: 1239 lang 1240 Required. ENUM. A valid language code per RFC 4646 [7] 1241 constrained by the definition of "xs:language". The 1242 interpretation of this code is described in Section 6. 1244 severity 1245 Optional. ENUM. An estimate of the relative severity of the 1246 activity. The permitted values are shown below. There is no 1247 default value. 1249 1. low. Low severity 1251 2. medium. Medium severity 1253 3. high. High severity 1255 completion 1256 Optional. ENUM. An indication whether the described activity was 1257 successful. The permitted values are shown below. There is no 1258 default value. 1260 1. failed. The attempted activity was not successful. 1262 2. succeeded. The attempted activity succeeded. 1264 type 1265 Required. ENUM. Classifies the malicious activity into incident 1266 categories. The permitted values are shown below. The default 1267 value is "other". 1269 1. admin. Administrative privileges were attempted. 1271 2. dos. A denial of service was attempted. 1273 3. file. An action that impacts the integrity of a file or 1274 database was attempted. 1276 4. info-leak. An attempt was made to exfiltrate information. 1278 5. misconfiguration. An attempt was made to exploit a mis- 1279 configuration in a system. 1281 6. policy. Activity violating site's policy was attempted 1283 7. recon. Reconnaissance activity was attempted. 1285 8. social-engineering. A social engineering attack was 1286 attempted. 1288 9. user. User privileges were attempted. 1290 10. unknown. The classification of this activity is unknown. 1292 11. ext-value. An escape value used to extend this attribute. 1293 See Section 5.1. 1295 ext-type 1296 Optional. STRING. A means by which to extend the type attribute. 1297 See Section 5.1. 1299 3.10.2. TimeImpact class 1301 The TimeImpact class describes the impact of the incident on an 1302 organization as a function of time. It provides a way to convey down 1303 time and recovery time. 1305 +---------------------+ 1306 | TimeImpact | 1307 +---------------------+ 1308 | REAL | 1309 | | 1310 | ENUM severity | 1311 | ENUM metric | 1312 | STRING ext-metric | 1313 | ENUM duration | 1314 | STRING ext-duration | 1315 +---------------------+ 1317 Figure 17: TimeImpact class 1319 The element content is a positive, floating point (REAL) number 1320 specifying a unit of time. The duration and metric attributes will 1321 imply the semantics of the element content. 1323 The TimeImpact class has five attributes: 1325 severity 1326 Optional. ENUM. An estimate of the relative severity of the 1327 activity. The permitted values are shown below. There is no 1328 default value. 1330 1. low. Low severity 1332 2. medium. Medium severity 1334 3. high. High severity 1336 metric 1337 Required. ENUM. Defines the metric in which the time is 1338 expressed. The permitted values are shown below. There is no 1339 default value. 1341 1. labor. Total staff-time to recovery from the activity (e.g., 1342 2 employees working 4 hours each would be 8 hours). 1344 2. elapsed. Elapsed time from the beginning of the recovery to 1345 its completion (i.e., wall-clock time). 1347 3. downtime. Duration of time for which some provided service(s) 1348 was not available. 1350 4. ext-value. An escape value used to extend this attribute. 1351 See Section 5.1. 1353 ext-metric 1354 Optional. STRING. A means by which to extend the metric 1355 attribute. See Section 5.1. 1357 duration 1358 Required. ENUM. Defines a unit of time, that when combined with 1359 the metric attribute, fully describes a metric of impact that will 1360 be conveyed in the element content. The permitted values are 1361 shown below. The default value is "hour". 1363 1. second. The unit of the element content is seconds. 1365 2. minute. The unit of the element content is minutes. 1367 3. hour. The unit of the element content is hours. 1369 4. day. The unit of the element content is days. 1371 5. month. The unit of the element content is months. 1373 6. quarter. The unit of the element content is quarters. 1375 7. year. The unit of the element content is years. 1377 8. ext-value. An escape value used to extend this attribute. 1378 See Section 5.1. 1380 ext-duration 1381 Optional. STRING. A means by which to extend the duration 1382 attribute. See Section 5.1. 1384 3.10.3. MonetaryImpact class 1386 The MonetaryImpact class describes the financial impact of the 1387 activity on an organization. For example, this impact may consider 1388 losses due to the cost of the investigation or recovery, diminished 1389 productivity of the staff, or a tarnished reputation that will affect 1390 future opportunities. 1392 +------------------+ 1393 | MonetaryImpact | 1394 +------------------+ 1395 | REAL | 1396 | | 1397 | ENUM severity | 1398 | STRING currency | 1399 +------------------+ 1401 Figure 18: MonetaryImpact class 1403 The element content is a positive, floating point number (REAL) 1404 specifying a unit of currency described in the currency attribute. 1406 The MonetaryImpact class has two attributes: 1408 severity 1409 Optional. ENUM. An estimate of the relative severity of the 1410 activity. The permitted values are shown below. There is no 1411 default value. 1413 1. low. Low severity 1415 2. medium. Medium severity 1417 3. high. High severity 1419 currency 1420 Required. STRING. Defines the currency in which the monetary 1421 impact is expressed. The permitted values are defined in ISO 1422 4217:2001, Codes for the representation of currencies and funds 1423 [14]. There is no default value. 1425 3.10.4. Confidence class 1427 The Confidence class represents a best estimate of the validity and 1428 accuracy of the described impact (see Section 3.10) of the incident 1429 activity. This estimate can be expressed as a category or a numeric 1430 calculation. 1432 This class if based upon the IDMEF [17]). 1434 +------------------+ 1435 | Confidence | 1436 +------------------+ 1437 | REAL | 1438 | | 1439 | ENUM rating | 1440 +------------------+ 1442 Figure 19: Confidence class 1444 The element content expresses a numerical assessment in the 1445 confidence of the data when the value of the rating attribute is 1446 "numeric". Otherwise, this element should be empty. 1448 The Confidence class has one attribute. 1450 rating 1451 Required. ENUM. A rating of the analytical validity of the 1452 specified Assessment. The permitted values are shown below. 1453 There is no default value. 1455 1. low. Low confidence in the validity. 1457 2. medium. Medium confidence in the validity. 1459 3. high. High confidence in the validity. 1461 4. numeric. The element content contains a number that conveys 1462 the confidence of the data. The semantics of this number 1463 outside the scope of this specification. 1465 3.11. History class 1467 The History class is a log of the significant events or actions 1468 performed by the involved parties during the course of handling the 1469 incident. 1471 The level of detail maintained in this log is left up to the 1472 discretion of those handling the incident. 1474 +------------------+ 1475 | History | 1476 +------------------+ 1477 | ENUM restriction |<>--{1..*}--[ HistoryItem ] 1478 | | 1479 +------------------+ 1481 Figure 20: The History class 1483 The class that constitutes History is: 1485 HistoryItem 1486 One or many. Entry in the history log of significant events or 1487 actions performed by the involved parties. 1489 The History class has one attribute: 1491 restriction 1492 Optional. ENUM. This attribute is defined in Section 3.2. 1494 3.11.1. HistoryItem class 1496 The HistoryItem class is an entry in the History (Section 3.11) log 1497 that documents a particular action or event that occurred in the 1498 course of handling the incident. The details of the entry are a 1499 free-form description, but each can be categorized with the type 1500 attribute. 1502 +-------------------+ 1503 | HistoryItem | 1504 +-------------------+ 1505 | ENUM restriction |<>----------[ DateTime ] 1506 | ENUM action |<>--{0..1}--[ IncidentId ] 1507 | STRING ext-action |<>--{0..1}--[ Contact ] 1508 | |<>--{0..*}--[ Description ] 1509 | |<>--{0..*}--[ AdditionalData ] 1510 +-------------------+ 1512 Figure 21: HistoryItem class 1514 The aggregate classes that constitute HistoryItem are: 1516 DateTime 1517 One. Timestamp of this entry in the history log (e.g., when the 1518 action described in the Description was taken). 1520 IncidentID 1521 Zero or One. In a history log created by multiple parties, the 1522 IncidentID provides a mechanism to specify which CSIRT created a 1523 particular entry and references this organization's incident 1524 tracking number. When a single organization is maintaining the 1525 log, this class can be ignored. 1527 Contact 1528 Zero or One. Provides contact information for the person that 1529 performed the action documented in this class. 1531 Description 1532 Zero or many. ML_STRING. A free-form textual description of the 1533 action or event. 1535 AdditionalData 1536 Zero or many. A mechanism by which to extend the data model. 1538 The HistoryItem class has three attributes: 1540 restriction 1541 Optional. ENUM. This attribute has been defined in Section 3.2. 1543 action 1544 Required. ENUM. Classifies a performed action or occurrence 1545 documented in this history log entry. As activity will likely 1546 have been instigated either through a previously conveyed 1547 expectation or internal investigation, this attribute is identical 1548 to category attribute of the Expectation class. The difference is 1549 only one of tense. When an action is in this class, it has been 1550 completed. See Section 3.13. 1552 ext-action 1553 Optional. STRING. A means by which to extend the action 1554 attribute. See Section 5.1. 1556 3.12. EventData class 1558 The EventData class describes a particular event of the incident for 1559 a given set of hosts or networks. This description includes the 1560 systems from which the activity originated and those targeted, an 1561 assessment of the techniques used by the intruder, the impact of the 1562 activity on the organization, and any forensic evidence discovered. 1564 +------------------+ 1565 | EventData | 1566 +------------------+ 1567 | ENUM restriction |<>--{0..*}--[ Description ] 1568 | |<>--{0..1}--[ DetectTime ] 1569 | |<>--{0..1}--[ StartTime ] 1570 | |<>--{0..1}--[ EndTime ] 1571 | |<>--{0..*}--[ Contact ] 1572 | |<>--{0..1}--[ Assessment ] 1573 | |<>--{0..*}--[ Method ] 1574 | |<>--{0..*}--[ Flow ] 1575 | |<>--{0..*}--[ Expectation ] 1576 | |<>--{0..1}--[ Record ] 1577 | |<>--{0..*}--[ EventData ] 1578 | |<>--{0..*}--[ AdditionalData ] 1579 +------------------+ 1581 Figure 22: The EventData class 1583 The aggregate classes that constitute EventData are: 1585 Description 1586 Zero or more. ML_STRING. A free-form textual description of the 1587 event. 1589 DetectTime 1590 Zero or one. The time the event was detected. 1592 StartTime 1593 Zero or one. The time the event started. 1595 EndTime 1596 Zero or one. The time the event ended. 1598 Contact 1599 Zero or more. Contact information for the parties involved in the 1600 event. 1602 Assessment 1603 Zero or one. The impact of the event on the target and the 1604 actions taken. 1606 Method 1607 Zero or more. The technique used by the intruder in the event. 1609 Flow 1610 Zero or more. A description of the systems or networks involved. 1612 Expectation 1613 Zero or more. The expected action to be performed by the 1614 recipient for the described event. 1616 Record 1617 Zero or one. Supportive data (e.g., log files) that provides 1618 additional information about the event. 1620 EventData 1621 Zero or more. EventData instances contained within another 1622 EventData instance inherit the values of the parent(s); this 1623 recursive definition can be used to group common data pertaining 1624 to multiple events. When EventData elements are defined 1625 recursively, only the leaf instances (those EventData instances 1626 not containing other EventData instances) represent actual events. 1628 AdditionalData 1629 Zero or more. An extension mechanism for data not explicitly 1630 represented in the data model. 1632 At least one of the aggregate classes MUST be present in an instance 1633 of the EventData class. This is not enforced in the IODEF schema as 1634 there is no simple way to accomplish it. 1636 The EventData class has one attribute: 1638 restriction 1639 Optional. ENUM. This attribute is defined in Section 3.2. 1641 3.12.1. Relating the Incident and EventData classes 1643 There is substantial overlap in the Incident and EventData classes. 1644 Nevertheless, the semantics of these classes are quite different. 1645 The Incident class provides summary information about the entire 1646 incident, while the EventData class provides information about the 1647 individual events comprising the incident. In the most common case, 1648 the EventData class will provide more specific information for the 1649 general description provided in the Incident class. However, it may 1650 also be possible that the overall summarized information about the 1651 incident conflicts with some individual information in an EventData 1652 class when there is a substantial composition of various events in 1653 the incident. In such as case, the interpretation of the more 1654 specific EventData MUST supersede the more generic information 1655 provided in IncidentData. 1657 3.12.2. Cardinality of EventData 1659 The EventData class can be thought of as a container for the 1660 properties of an event in an incident. These properties include: the 1661 hosts involved, impact of the incident activity on the hosts, 1662 forensic logs, etc. With an instance of the EventData class, hosts 1663 (i.e., System class) are grouped around these common properties. 1665 The recursive definition (or instance property inheritance) of the 1666 EventData class (the EventData class is aggregated into the EventData 1667 class) provides a way to related information without requiring the 1668 explicit use of unique attribute identifiers in the classes or 1669 duplicating information. Instead, the relative depth (nesting) of a 1670 class is used to group (relate) information. 1672 For example, an EventData class might be used to describe two 1673 machines involved in an incident. This description can be achieved 1674 using multiple instances of the Flow class. It happens that there is 1675 a common technical contact (i.e., Contact class) for these two 1676 machines, but the impact (i.e., Assessment class) on them is 1677 different. A depiction of the representation for this situation can 1678 be found in Figure 23. 1680 +------------------+ 1681 | EventData | 1682 +------------------+ 1683 | |<>----[ Contact ] 1684 | | 1685 | |<>----[ EventData ]<>----[ Flow ] 1686 | | [ ]<>----[ Assessment ] 1687 | | 1688 | |<>----[ EventData ]<>----[ Flow ] 1689 | | [ ]<>----[ Assessment ] 1690 +------------------+ 1692 Figure 23: Recursion in the EventData class 1694 3.13. Expectation class 1696 The Expectation class conveys to the recipient of the IODEF document 1697 the actions the sender is requesting. The scope of the requested 1698 action is limited to purview of the EventData class in which this 1699 class is aggregated. 1701 +-------------------+ 1702 | Expectation | 1703 +-------------------+ 1704 | ENUM restriction |<>--{0..*}--[ Description ] 1705 | ENUM severity |<>--{0..1}--[ StartTime ] 1706 | ENUM action |<>--{0..1}--[ EndTime ] 1707 | STRING ext-action |<>--{0..1}--[ Contact ] 1708 +-------------------+ 1710 Figure 24: the Expectation class 1712 The aggregate classes that constitute Expectation are: 1714 Description 1715 Zero or many. ML_STRING. A free-form description of the desired 1716 action(s). 1718 StartTime 1719 Zero or one. The time at which the action should be performed. A 1720 timestamp that is earlier than the ReportTime specified in the 1721 Incident class denotes that the expectation should be fulfilled as 1722 soon as possible. The absence of this element leaves the 1723 execution of the expectation to the discretion of the recipient. 1725 EndTime 1726 Zero or one. The time by which the action should be completed. 1727 If the action is not carried out by this time, it should no longer 1728 be performed. 1730 Contact 1731 Zero or one. The expected actor for the action. 1733 The Expectations class has four attributes: 1735 restriction 1736 Optional. ENUM. This attribute is defined in Section 3.2. 1738 severity 1739 Optional. ENUM. Indicates the desired priority of the action. 1740 This attribute is an enumerated list with no default value, and 1741 the semantics of these relative measures are context dependant. 1743 1. low. Low priority 1745 2. medium. Medium priority 1747 3. high. High priority 1749 action 1750 Optional. ENUM. Classifies the type of action requested. This 1751 attribute is an enumerated list with no default value. 1753 1. nothing. No action is requested. Do nothing with the 1754 information. 1756 2. contact-source-site. Contact the site(s) identified as the 1757 source of the activity. 1759 3. contact-target-site. Contact the site(s) identified as the 1760 target of the activity. 1762 4. contact-sender. Contact the originator of the document. 1764 5. investigate. Investigate the systems(s) listed in the event. 1766 6. block-host. Block traffic from the machine(s) listed as 1767 sources the event. 1769 7. block-network. Block traffic from the network(s) lists as 1770 sources in the event. 1772 8. block-port. Block the port listed as sources in the event. 1774 9. rate-limit-host. Rate-limit the traffic from the machine(s) 1775 listed as sources in the event. 1777 10. rate-limit-network. Rate-limit the traffic from the 1778 network(s) lists as sources in the event. 1780 11. rate-limit-port. Rate-limit the port(s) listed as sources in 1781 the event. 1783 12. remediate-other. Remediate the activity in a way other than 1784 by rate limiting or blocking. 1786 13. status-triage. Conveys receipts and the triaging of an 1787 incident. 1789 14. status-new-info. Conveys that new information was received 1790 for this incident. 1792 15. other. Perform some custom action described in the 1793 Description class. 1795 16. ext-value. An escape value used to extend this attribute. 1796 See Section 5.1. 1798 ext-action 1799 Optional. STRING. A means by which to extend the action 1800 attribute. See Section 5.1. 1802 3.14. Flow class 1804 The Flow class groups related the source and target hosts. 1806 +------------------+ 1807 | Flow | 1808 +------------------+ 1809 | |<>--{1..*}--[ System ] 1810 +------------------+ 1812 Figure 25: the Flow class 1814 The aggregate class that constitutes Flow is: 1816 System 1817 One or More. A host or network involved in an event. 1819 The Flow System class has no attributes. 1821 3.15. System class 1823 The System class describes a system or network involved in an event. 1824 The systems or networks represented by this class are categorized 1825 according to the role they played in the incident through the 1826 category attribute. The value of this category attribute dictates 1827 the semantics of the aggregated classes in the System class. If the 1828 category attribute has a value of "source", then the aggregated 1829 classes denote the machine and service from which the activity is 1830 originating. With a category attribute value of "target" or 1831 "intermediary", then the machine or service is the one targeted in 1832 the activity. A value of "sensor" dictates that this System was part 1833 of an instrumentation to monitor the network. 1835 +---------------------+ 1836 | System | 1837 +---------------------+ 1838 | ENUM restriction |<>----------[ Node ] 1839 | ENUM category |<>--{0..*}--[ Service ] 1840 | STRING ext-category |<>--{0..*}--[ OperatingSystem ] 1841 | STRING interface |<>--{0..*}--[ Counter ] 1842 | ENUM spoofed |<>--{0..*}--[ Description ] 1843 | |<>--{0..*}--[ AdditionalData ] 1844 +---------------------+ 1846 Figure 26: the System class 1848 The aggregate classes that constitute System are: 1850 Node 1851 One. A host or network involved in the incident. 1853 Service 1854 Zero or more. A network service running on the system. 1856 OperatingSystem 1857 Zero or one. The operating system running on the system. 1859 Counter 1860 Zero or more. A counter with which to summarize properties of 1861 this host or network. 1863 Description 1864 Zero or more. ML_STRING. A free-form text description of the 1865 System. 1867 AdditionalData 1868 Zero or many. A mechanism by which to extend the data model. 1870 The System class has five attributes: 1872 restriction 1873 Optional. ENUM. This attribute is defined in Section 3.2. 1875 category 1876 Required. ENUM. Classifies the role the host or network played 1877 in the incident. The possible values are: 1879 1. source. The System was the source of the event. 1881 2. target. The System was the target of the event. 1883 3. intermediate. The System was an intermediary in the event. 1885 4. sensor. The System was a sensor monitoring the event. 1887 5. infrastructure. The System was an infrastructure node of 1888 IODEF document exchange. 1890 6. ext-value. An escape value used to extend this attribute. 1891 See Section 5.1. 1893 ext-category 1894 Optional. STRING. A means by which to extend the category 1895 attribute. See Section 5.1. 1897 interface 1898 Optional. STRING. Specifies the interface on which the event(s) 1899 on this System originated. If the Node class specifies a network 1900 rather than a host, this attribute has no meaning. 1902 spoofed 1903 Optional. ENUM. An indication of confidence in whether this 1904 System was the true target or attacking host. The permitted 1905 values for this attribute are shown below. The default value is 1906 "unknown". 1908 1. unknown. The accuracy of the category attribute value is 1909 unknown. 1911 2. yes. The category attribute value is probably incorrect. In 1912 the case of a source, the System is likely a decoy; with a 1913 target, the System was likely not the intended victim. 1915 3. no. The category attribute value is believed to be correct. 1917 3.16. Node class 1919 The Node class names a system (e.g., PC, router) or network. 1921 This class was derived from the IDMEF [17]. 1923 +---------------+ 1924 | Node | 1925 +---------------+ 1926 | |<>--{0..*}--[ NodeName ] 1927 | |<>--{0..*}--[ Address ] 1928 | |<>--{0..1}--[ Location ] 1929 | |<>--{0..1}--[ DateTime ] 1930 | |<>--{0..*}--[ NodeRole ] 1931 | |<>--{0..*}--[ Counter ] 1932 +---------------+ 1934 Figure 27: The Node class 1936 The aggregate classes that constitute Node are: 1938 NodeName 1939 Zero or more. ML_STRING. The name of the Node (e.g., fully 1940 qualified domain name). This information MUST be provided if no 1941 Address information is given. 1943 Address 1944 Zero or more. The hardware, network, or application address of 1945 the Node. If a NodeName is not provided, at least one Address 1946 MUST be specified. 1948 Location 1949 Zero or one. ML_STRING. A free-from description of the physical 1950 location of the equipment. 1952 DateTime 1953 Zero or one. A timestamp of when the resolution between the name 1954 and address was performed. This information SHOULD be provided if 1955 both an Address and NodeName are specified. 1957 NodeRole 1958 Zero or more. The intended purpose of the Node. 1960 Counter 1961 Zero or more. A counter with which to summarizes properties of 1962 this host or network. 1964 3.16.1. Counter class 1966 The Counter class summarize multiple occurrences of some event, or 1967 conveys counts or rates on various features (e.g., packets, sessions, 1968 events). 1970 The value of the counter is the element content with its units 1971 represented in the type attribute. A rate for a given feature can be 1972 expressed by setting the duration attribute. The complete semantics 1973 are entirely context dependant based on the class in which the 1974 Counter is aggregated. 1976 +---------------------+ 1977 | Counter | 1978 +---------------------+ 1979 | REAL | 1980 | | 1981 | ENUM type | 1982 | STRING ext-type | 1983 | STRING meaning | 1984 | ENUM duration | 1985 | STRING ext-duration | 1986 +---------------------+ 1988 Figure 28: the Counter class 1990 The Counter class has three attribute: 1992 type 1993 Required. ENUM. Specifies the units of the element content. 1995 1. byte. Count of bytes. 1997 2. packet. Count of packets. 1999 3. flow. Count of flow (e.g., NetFlow records). 2001 4. session. Count of sessions 2002 5. alert. Count of notifications generated by another system 2003 (e.g., IDS or SIM). 2005 6. message. Count of messages (e.g., mail messages). 2007 7. event. Count of events. 2009 8. host. Count of hosts. 2011 9. site. Count of site. 2013 10. organization. Count of organizations. 2015 11. ext-value. An escape value used to extend this attribute. 2016 See Section 5.1. 2018 ext-type 2019 Optional. STRING. A means by which to extend the type attribute. 2020 See Section 5.1. 2022 duration 2023 Optional. ENUM. If present, the Counter class represents a rate 2024 rather than a count over the entire event. In that case, this 2025 attribute specifies the denominator of the rate (where the type 2026 attribute specified the nominator). The possible values of this 2027 attribute are defined in Section 3.10.2 2029 ext-duration 2030 Optional. STRING. A means by which to extend the duration 2031 attribute. See Section 5.1. 2033 3.16.2. Address 2035 The Address class represents a hardware (layer-2), network (layer-3), 2036 or application (layer-7) address. 2038 This class was derived from the IDMEF [17]. 2040 +---------------------+ 2041 | Address | 2042 +---------------------+ 2043 | ENUM category | 2044 | STRING ext-category | 2045 | STRING vlan-name | 2046 | INTEGER vlan-num | 2047 +---------------------+ 2048 Figure 29: the Address class 2050 The Address class has four attributes: 2052 category 2053 Required. ENUM. The type of address represented. The permitted 2054 values for this attribute are shown below. The default value is 2055 "ipv4-addr". 2057 1. asn. Autonomous System Number 2059 2. atm. Asynchronous Transfer Mode (ATM) address 2061 3. e-mail. Electronic mail address (RFC 822) 2063 4. ipv4-addr. IPv4 host address in dotted-decimal notation 2064 (a.b.c.d) 2066 5. ipv4-net. IPv4 network address in dotted-decimal notation, 2067 slash, significant bits (a.b.c.d/nn) 2069 6. ipv4-net-mask. IPv4 network address in dotted-decimal 2070 notation, slash, network mask in dotted-decimal notation 2071 (a.b.c.d/w.x.y.z) 2073 7. ipv6-addr. IPv6 host address 2075 8. ipv6-net. IPv6 network address, slash, significant bits 2077 9. ipv6-net-mask. IPv6 network address, slash, network mask 2079 10. mac. Media Access Control (MAC) address 2081 11. ext-value. An escape value used to extend this attribute. 2082 See Section 5.1. 2084 ext-category 2085 Optional. STRING. A means by which to extend the category 2086 attribute. See Section 5.1. 2088 vlan-name 2089 Optional. STRING. The name of the Virtual LAN to which the 2090 address belongs. 2092 vlan-num 2093 Optional. STRING. The number of the Virtual LAN to which the 2094 address belongs. 2096 3.16.3. NodeRole class 2098 The NodeRole class describes the intended function performed by a 2099 particular host. 2101 +---------------------+ 2102 | NodeRole | 2103 +---------------------+ 2104 | ENUM category | 2105 | STRING ext-category | 2106 | ENUM lang | 2107 +---------------------+ 2109 Figure 30: The NodeRole class 2111 The NodeRole class has three attributes: 2113 category 2114 Required. ENUM. Functionality provided by a node. 2116 1. client. Client computer 2118 2. server-internal. Server with internal services 2120 3. server-public. Server with public services 2122 4. www. WWW server 2124 5. mail. Mail server 2126 6. messaging. Messaging server (e.g., NNTP, IRC, IM) 2128 7. streaming. Streaming-media server 2130 8. voice. Voice server (e.g., SIP, H.323) 2132 9. file. File server (e.g., SMB, CVS, AFS) 2134 10. ftp. FTP server 2136 11. p2p. Peer-to-peer node 2138 12. name. Name server (e.g., DNS, WINS) 2140 13. directory. Directory server (e.g., LDAP, finger, whois) 2141 14. credential. Credential server (e.g., domain controller, 2142 Kerberos) 2144 15. print. Print server 2146 16. application. Application server 2148 17. database. Database server 2150 18. infra. Infrastructure server (e.g., router, firewall, DHCP) 2152 19. log. Logserver (e.g., syslog) 2154 20. ext-value. An escape value used to extend this attribute. 2155 See Section 5.1. 2157 ext-category 2158 Optional. STRING. A means by which to extend the category 2159 attribute. See Section 5.1. 2161 lang 2162 Required. ENUM. A valid language code per RFC 4646 [7] 2163 constrained by the definition of "xs:language". The 2164 interpretation of this code is described in Section 6. 2166 3.17. Service class 2168 The Service class describes a network service of a host or network. 2169 The service is identified by specific port or list of ports, along 2170 with the application listening on that port. 2172 When Service occurs as an aggregate class of a System that is a 2173 source, then this service is the one from which activity of interest 2174 is originating. Conversely, when Service occurs as an aggregate 2175 class of a System that is a target, then that service is the one to 2176 which activity of interest is directed. 2178 This class was derived from the IDMEF [17]. 2180 +---------------------+ 2181 | Service | 2182 +---------------------+ 2183 | INTEGER ip_protocol |<>--{0..1}--[ Port ] 2184 | |<>--{0..1}--[ Portlist ] 2185 | |<>--{0..1}--[ ProtoCode ] 2186 | |<>--{0..1}--[ ProtoType ] 2187 | |<>--{0..1}--[ ProtoFlags ] 2188 | |<>--{0..1}--[ Application ] 2189 +---------------------+ 2191 Figure 31: The Service class 2193 The aggregate classes that constitute Service are: 2195 Port 2196 Zero or one. INTEGER. A port number. 2198 Portlist 2199 Zero or one. PORTLIST. A list of port numbers formatted 2200 according to Section 2.10. 2202 ProtoCode 2203 Zero or one. INTEGER. A layer-4 protocol-specific code field 2204 (e.g., ICMP code field). 2206 ProtoType 2207 Zero or one. INTEGER. A layer-4 protocol specific type field 2208 (e.g., ICMP type field). 2210 ProtoFlags 2211 Zero or one. INTEGER. A layer-4 protocol specific flag field 2212 (e.g., TCP flag field). 2214 Application 2215 Zero or more. The application bound to the specified Port or 2216 Portlist. 2218 Either a Port or Portlist class MUST be specified for a given 2219 instance of a Service class. 2221 For a given source, System@type="source", a corresponding target, 2222 System@type="target", maybe defined, or vice versa. When a Portlist 2223 class is defined in the Service class of both the source and target 2224 in a given instance of the Flow class, there MUST be symmetry in the 2225 enumeration of the ports. Thus, if n-ports are listed for a source, 2226 n-ports should be listed for the target. Likewise, the ports should 2227 be listed in an identical sequence such that the n-th port in the 2228 source corresponds to the n-th port of the target. This symmetry in 2229 listing and sequencing of ports applies whether there are 1-to-1, 2230 1-to-many, or many-to-many sources-to-targets. In the 1-to-many or 2231 many-to-many, the exact order in which the System classes are 2232 enumerated in the Flow class is significant. 2234 The Service class has one attribute: 2236 ip_protocol 2237 Required. INTEGER. The IANA protocol number. 2239 3.17.1. Application class 2241 The Application class describes an application running on a System 2242 providing a Service. 2244 +--------------------+ 2245 | Application | 2246 +--------------------+ 2247 | STRING swid |<>--{0..1}--[ URL ] 2248 | STRING configid | 2249 | STRING vendor | 2250 | STRING family | 2251 | STRING name | 2252 | STRING version | 2253 | STRING patch | 2254 +--------------------+ 2256 Figure 32: The Application class 2258 The aggregate classes that constitute Application are: 2260 URL 2261 Zero or one. URL. A URL describing the application. 2263 The Application class has seven attributes: 2265 swid 2266 Optional. STRING. An identifier that can be used to reference 2267 this software. 2269 configid 2270 Optional. STRING. An identifier that can be used to reference a 2271 particular configuration of this software. 2273 vendor 2274 Optional. STRING. Vendor name of the software. 2276 family 2277 Optional. STRING. Family of the software. 2279 name 2280 Optional. STRING. Name of the software. 2282 version 2283 Optional. STRING. Version of the software. 2285 patch 2286 Optional. STRING. Patch or service pack level of the software. 2288 3.18. OperatingSystem class 2290 The OperatingSystem class describes the operating system running on a 2291 System. The definition is identical to the Application class 2292 (Section 3.17.1). 2294 3.19. Record class 2296 The Record class is a container class for log and audit data that 2297 provides supportive information about the incident. The source of 2298 this data will often be the output of monitoring tools. These logs 2299 should substantiate the activity described in the document. 2301 +------------------+ 2302 | Record | 2303 +------------------+ 2304 | ENUM restriction |<>--{1..*}--[ RecordData ] 2305 +------------------+ 2307 Figure 33: Record class 2309 The aggregate class that constitutes Record is: 2311 RecordData 2312 One or more. Log or audit data generated by a particular type of 2313 sensor. Separate instances of the RecordData class SHOULD be used 2314 for each sensor type. 2316 The Record class has one attribute: 2318 restriction 2319 Optional. ENUM. This attribute has been defined in Section 3.2. 2321 3.19.1. RecordData class 2323 The RecordData class groups log or audit data from a given sensor 2324 (e.g., IDS, firewall log) and provides a way to annotate the output. 2326 +------------------+ 2327 | RecordData | 2328 +------------------+ 2329 | ENUM restriction |<>--{0..1}--[ DateTime ] 2330 | |<>--{0..*}--[ Description ] 2331 | |<>--{0..1}--[ Application ] 2332 | |<>--{0..*}--[ RecordPattern ] 2333 | |<>--{1..*}--[ RecordItem ] 2334 | |<>--{0..*}--[ AdditionalData ] 2335 +------------------+ 2337 Figure 34: The RecordData class 2339 The aggregate classes that constitutes RecordData is: 2341 DateTime 2342 Zero or one. Timestamp of the RecordItem data. 2344 Description 2345 Zero or more. ML_STRING. Free-form textual description of the 2346 provided RecordItem data. At minimum, this description should 2347 convey the significance of the provided RecordItem data. 2349 Application 2350 Zero or one. Information about the sensor used to generate the 2351 RecordItem data. 2353 RecordPattern 2354 Zero or more. A search string to precisely find the relevant data 2355 in a RecordItem. 2357 RecordItem 2358 One or more. Log, audit, or forensic data. 2360 AdditionalData 2361 Zero or one. An extension mechanism for data not explicitly 2362 represented in the data model. 2364 The RecordData class has one attribute: 2366 restriction 2367 Optional. ENUM. This attribute has been defined in Section 3.2. 2369 3.19.2. RecordPattern class 2371 The RecordPattern class describes where in the content of the 2372 RecordItem relevant information can be found. It provides a way to 2373 reference subsets of information, identified by a pattern, in a large 2374 log file, audit trail, or forensic data. 2376 +-----------------------+ 2377 | RecordPattern | 2378 +-----------------------+ 2379 | STRING | 2380 | | 2381 | ENUM type | 2382 | STRING ext-type | 2383 | INTEGER offset | 2384 | ENUM offsetunit | 2385 | STRING ext-offsetunit | 2386 | INTEGER instance | 2387 +-----------------------+ 2389 Figure 35: The RecordPattern class 2391 The specific pattern to search with in the RecordItem is defined in 2392 the body of the element. It is further annotated by four attributes: 2394 type 2395 Required. ENUM. Describes the type of pattern being specified in 2396 the element content. The default is "regex". 2398 1. regex. regular expression, per Appendix F of [3]. 2400 2. binary. Binhex encoded binary pattern, per the HEXBIN data 2401 type. 2403 3. xpath. XML Path (XPath) [5] 2405 4. ext-value. An escape value used to extend this attribute. 2406 See Section 5.1. 2408 ext-type 2409 Optional. STRING. A means by which to extend the type attribute. 2410 See Section 5.1. 2412 offset 2413 Optional. INTEGER. Amount of units (determined by the offsetunit 2414 attribute) to seek into the RecordItem data before matching the 2415 pattern. 2417 offsetunit 2418 Optional. ENUM. Describes the units of the offset attribute. 2419 The default is "line". 2421 1. line. Offset is a count of lines. 2423 2. binary. Offset is a count of bytes. 2425 3. ext-value. An escape value used to extend this attribute. 2426 See Section 5.1. 2428 ext-offsetunit 2429 Optional. STRING. A means by which to extend the offsetunit 2430 attribute. See Section 5.1. 2432 instance 2433 Optional. INTEGER. Number of types to apply the specified 2434 pattern. 2436 3.19.3. RecordItem class 2438 The RecordItem class provides a way to incorporate relevant logs, 2439 audit trails, or forensic data to support the conclusions made during 2440 the course of analyzing the incident. The class supports both the 2441 direct encapsulation of the data, as well as, provides primitives to 2442 reference data stored elsewhere. 2444 This class is identical to AdditionalData class (Section 3.6). 2446 4. Processing Considerations 2448 This section defines additional requirements on creating and parsing 2449 IODEF documents. 2451 4.1. Encoding 2453 Every IODEF document MUST begin with an XML declaration, and MUST 2454 specify the XML version used. If UTF-8 encoding is not used, the 2455 character encoding MUST also be explicitly specified. The IODEF 2456 conforms to all XML data encoding conventions and constraints. 2458 The XML declaration with no character encoding will read as follows: 2460 2462 When a character encoding is specified, the XML declaration will read 2463 like the following: 2465 2467 Where "charset" is the name of the character encoding as registered 2468 with the Internet Assigned Numbers Authority (IANA), see [9]. 2470 The following characters have special meaning in XML and MUST be 2471 escaped with their entity reference equivalent: "&", "<", ">", "\"" 2472 (double quotation mark), and "'" (apostrophe). These entity 2473 references are "&", "<", ">", """, and "'" 2474 respectively. 2476 4.2. IODEF Namespace 2478 The IODEF schema declares a namespace of 2479 "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each 2480 IODEF document SHOULD include a valid reference to the IODEF schema 2481 using the "xsi:schemaLocation" attribute. An example of such a 2482 declaration would look as follows: 2484 2573 A given extension attribute MUST NOT be set unless the corresponding 2574 extensible attribute has been set to "ext-value". 2576 5.2. Extending classes 2578 The classes of the data model can be extended only through the use of 2579 the AdditionalData and RecordItem classes. These container classes, 2580 collectively referred to as the extensible classes, are implemented 2581 with the iodef:ExtensionType data type in the schema. They provide 2582 the ability to have new atomic or XML-encoded data elements in all of 2583 the top-level classes of the Incident class and a few of the more 2584 complicated subordinate classes. As there are multiple instances of 2585 the extensible classes in the data model, there is discretion on 2586 where to add a new data element. It is RECOMMENDED that the 2587 extension be placed in the most closely related class to the new 2588 information. 2590 Extensions using the atomic data types (i.e., all values of the dtype 2591 attributes other than "xml") MUST: 2593 1. Set the element content of extensible class to the desired value, 2594 and 2596 2. Set the dtype attribute to correspond to the data type of the 2597 element content. 2599 The following guidelines exist for extensions using XML: 2601 1. The element content of the extensible class MUST be set to the 2602 desired value and the dtype attribute MUST be set to "xml". 2604 2. The extension schema MUST declare a separate namespace. It is 2605 RECOMMENDED that these extensions have the prefix "iodef-". 2607 3. It is RECOMMENDED that extension schemas follow the naming 2608 convention of the IODEF data model. The names of all elements 2609 are capitalized. For composed names, a capital letter is used 2610 for each word. Attribute names are lower case. 2612 4. When a parser encounters an IODEF document with an extension it 2613 does not understand, this extension MUST be ignored (and not 2614 processed), but the remainder of the document MUST be processed. 2615 Parsers will able to identify these extensions for which they 2616 have no processing logic through the namespace declaration. 2617 Parsers that encounter an unrecognized element in a namespace 2618 that they do support SHOULD reject the document as a syntax 2619 error. 2621 5. Implementations SHOULD NOT download schemas at runtime due to the 2622 security implications and extensions MUST NOT be required to 2623 provide a resolvable location of their schema. 2625 The following schema and XML document excerpt provide a template for 2626 an extension schema and its use in the IODEF document. 2628 This example schema defines a namespace of "iodef-extension1" and a 2629 single element named "newdata". 2631 2635 attributeFormDefault="unqualified" 2636 elementFormDefault="qualified"> 2637 2641 2642 2644 The following XML excerpt demonstrates the use of the above schema as 2645 an extension to the IODEF. 2647 2654 2655 ... 2656 2657 2658 Field that could not be represented elsewhere 2659 2660 2661 2713 2715 2719 2720 189493 2721 2001-09-13T23:19:24+00:00 2722 Host sending out Code Red probes 2723 2724 2725 2726 2727 2728 Example.com CSIRT 2729 example-com 2730 contact@csirt.example.com 2731 2732 2733 2734 2735 2736
192.0.2.200
2737 57 2738
2739
2740 2741 2742
192.0.2.16/28
2743
2744 2745 80 2746 2747
2749
2750 2751 2752 2753 2754 2001-09-13T18:11:21+02:00 2755 Web-server logs 2756 2757 192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida? 2758 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2759 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2760 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2761 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2762 2763 2764 2765 http://mylogs.example.com/logs/httpd_access 2766 2767 2768
2769 2770 2771 2772 2001-09-14T08:19:01+00:00 2773 Notification sent to 2774 constituency-contact@192.0.2.200 2775 2776 2777
2778
2780 7.2. Reconnaissance 2782 An example of a CSIRT reporting a scanning activity. 2784 2785 2787 2791 2792 59334 2793 2006-08-02T05:54:02-05:00 2794 2795 2796 2797 2798 2799 2800 nmap 2801 http://nmap.toolsite.example.com 2802 2803 2804 2806 2807 CSIRT for example.com 2808 contact@csirt.example.com 2809 +1 412 555 12345 2810 2812 2813 Joe Smith 2814 smith@csirt.example.com 2815 2816 2817 2818 2824 2825 2826 2827
192.0.2.200
2828
2829 2830 60524,60526,60527,60531 2831 2832
2833 2834 2835
192.0.2.201
2836
2837 2838 137-139,445 2839 2840
2841
2842 2844 2845 2846 2847
192.0.2.240
2848
2849
2850 2851 2852
192.0.2.64/28
2853
2854 2855 445 2856 2857
2858
2859
2860
2861
2863 7.3. Bot-Net Reporting 2865 An example of a CSIRT reporting a bot-network. 2867 2868 2870 2874 2875 908711 2876 2006-06-08T05:44:53-05:00 2877 Large bot-net 2878 2879 2880 2881 2882 2883 2884 GT Bot 2885 2886 2888 2889 CA-2003-22 2890 http://www.cert.org/advisories/CA-2003-22.html 2891 Root compromise via this IE vulnerability to 2892 install the GT Bot 2893 2894 2895 2897 2898 Joe Smith 2899 jsmith@csirt.example.com 2900 2901 2902 These hosts are compromised and acting as bots 2903 communicating with irc.example.com. 2904 2905 2907 2908 2909
192.0.2.1
2910
2911 10000 2912 bot 2913
2914 2915 2916 2917
192.0.2.3
2918
2919 250000 2920 bot 2921
2922 2923 2924 2925 irc.example.com 2926
192.0.2.20
2927 2006-06-08T01:01:03-05:00 2928
2929 IRC server on #give-me-cmd channel 2930
2931
2932 2933 2934 Confirm the source and take machines off-line and 2935 remediate 2936 2937
2938
2939
2941 7.4. Watch List 2943 An example of a CSIRT conveying a watch-list. 2945 2946 2947 2950 2954 2955 908711 2956 2006-08-01T00:00:00-05:00 2957 Watch-list of known bad IPs or networks 2958 2959 2960 2961 2962 2963 CSIRT for example.com 2964 contact@csirt.example.com 2965 2966 2967 2968 2969 2970 2971
192.0.2.53
2972
2973 Source of numerous attacks 2974
2975
2976 2978 2979
2980 2981 2982 2983 2984
192.0.2.16/28
2985
2986 2987 Source of heavy scanning over past 1-month 2988 2989
2990
2991 2992 2993 2994
192.0.2.241
2995
2996 C2 IRC server 2997
2998
2999 3001 3002
3003
3004
3005 8. The IODEF Schema 3007 3008 3015 3016 3017 Incident Object Description Exchange Format v1.00, see RFC XXX 3018 3019 3021 3026 3027 3028 3029 3031 3032 3034 3036 3038 3039 3040 3045 3046 3047 3048 3049 3051 3053 3055 3057 3059 3060 3062 3064 3066 3068 3070 3072 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3088 3090 3092 3093 3094 3099 3100 3101 3102 3103 3105 3107 3109 3110 3111 3112 3117 3118 3119 3120 3122 3123 3125 3126 3127 3132 3133 3134 3135 3137 3139 3140 3142 3143 3144 3150 3151 3156 3157 3158 3159 3161 3163 3165 3167 3169 3171 3173 3175 3177 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3205 3207 3208 3209 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3231 3232 3233 3234 3236 3237 3238 3239 3240 3242 3243 3244 3246 3247 3248 3249 3251 3252 3253 3254 3256 3257 3258 3260 3265 3267 3269 3271 3273 3275 3277 3278 3279 3280 3281 3282 3287 3288 3289 3290 3292 3293 3295 3296 3297 3298 3299 3300 3301 3303 3305 3307 3309 3310 3312 3314 3316 3317 3318 3323 3324 3325 3326 3328 3330 3332 3334 3335 3337 3339 3341 3343 3344 3345 3350 3351 3352 3353 3354 3355 3356 3357 3359 3360 3362 3363 3364 3365 3366 3367 3369 3371 3373 3374 3375 3376 3381 3382 3383 3384 3385 3386 3387 3388 3389 3391 3392 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3405 3406 3407 3408 3409 3410 3411 3413 3414 3415 3416 3417 3418 3419 3420 3421 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3439 3440 3441 3443 3444 3445 3446 3447 3448 3449 3450 3451 3453 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3466 3468 3470 3471 3472 3473 3474 3475 3476 3477 3478 3480 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3506 3507 3508 3509 3511 3513 3515 3517 3519 3521 3523 3525 3527 3529 3531 3533 3534 3536 3537 3538 3543 3544 3545 3546 3548 3549 3550 3551 3556 3557 3558 3559 3560 3562 3564 3566 3568 3570 3571 3573 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3589 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3606 3607 3608 3609 3610 3612 3614 3615 3617 3619 3621 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3649 3651 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3690 3691 3692 3693 3694 3699 3700 3701 3702 3703 3705 3707 3708 3710 3712 3714 3716 3717 3719 3720 3721 3722 3723 3724 3725 3726 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3754 3756 3758 3760 3761 3762 3763 3764 3769 3770 3771 3772 3774 3775 3777 3778 3779 3780 3781 3782 3784 3786 3788 3790 3792 3794 3795 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3815 3817 3819 3820 3821 3822 3823 3824 3825 3826 3827 3829 3831 3832 3833 3834 3835 3837 3842 3843 3844 3846 3847 3849 3851 3853 3855 3857 3859 3861 3862 3864 3866 3871 3873 3875 3880 3881 3882 3883 3884 3885 3886 3887 3888 3890 3891 3892 3893 3894 3895 3897 3898 3900 3902 3904 3906 3908 3909 3914 3915 3916 3917 3918 3919 3920 3921 3923 3924 3925 3926 3927 3928 3929 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3991 9. Security considerations 3993 The IODEF data model itself does not directly introduce security 3994 issues. Rather, it simply defines a representation for incident 3995 information. As the data encoded by the IODEF might be considered 3996 privacy sensitive by the parties exchanging the information or by 3997 those described by it, care needs to be taken in ensuring the 3998 appropriate disclosure during both document exchange and subsequent 3999 processing. The former must be handled by a messaging format but the 4000 latter risk must be addressed by the systems that process, store, and 4001 archive IODEF documents and information derived from them. 4003 The contents of an IODEF document may include a request for action or 4004 an IODEF parser may independently have logic to take certain actions 4005 based on information that it finds. For this reason, care must be 4006 taken by the parser to properly authenticate the recipient of the 4007 document and ascribe an appropriate confidence to the data prior to 4008 action. 4010 The underlying messaging format and protocol used to exchange 4011 instances of the IODEF MUST provide appropriate guarantees of 4012 confidentiality, integrity, and authenticity. The use of a 4013 standardized security protocol is encouraged. The Real-time Inter- 4014 network Defense (RID) protocol [18] and its associated transport 4015 binding IODEF/RID over SOAP [19] provide such security. 4017 In order to suggest data processing and handling guidelines of the 4018 encoded information, the IODEF allows a document sender to convey a 4019 privacy policy using the restriction attribute. The various 4020 instances of this attribute allow different data elements of the 4021 document to be covered by dissimilar policies. While flexible, it 4022 must be stressed that this approach only serves as a guideline from 4023 the sender, as the recipient is free to ignore it. The issue of 4024 enforcement is not a technical problem. 4026 10. IANA considerations 4028 This document uses URNs to describe an XML namespace and schema 4029 conforming to a registry mechanism described in [15] 4031 Registration request for the IODEF namespace: 4033 o URI: urn:ietf:params:xml:ns:iodef-1.0 4035 o Registrant Contact: See the first author of the "Author's Address" 4036 section of this document. 4038 o XML: None. Namespace URIs do not represent an XML specification. 4040 Registration request for the IODEF XML schema: 4042 o URI: urn:ietf:params:xml:schema:iodef-1.0 4044 o Registrant Contact: See the first author of the "Author's Address" 4045 section of this document. 4047 o XML: See the "IODEF Schema" in Section 8 of this document. 4049 11. Acknowledgments 4051 The following groups and individuals, listed alphabetically, 4052 contributed substantially to this document and should be recognized 4053 for their efforts. 4055 o Patrick Cain, Cooper-Cain Group, Inc. 4057 o The eCSIRT.net Project 4059 o The Incident Object Description and Exchange Format Working-Group 4060 of the TERENA task-force (TF-CSIRT) 4062 o Glenn Mansfield Keeni, Cyber Solutions, Inc. 4064 o Hiroyuki Kido, NARA Institute of Science and Technology 4066 o Kathleen Moriarty, MIT Lincoln Laboratory 4068 o Brian Trammell, CERT/NetSA 4070 12. References 4072 12.1. Normative References 4074 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 4075 1.0 (Second Edition)", W3C Recommendation , October 2000, 4076 . 4078 [2] World Wide Web Consortium, "XML XML Schema Part 1: Structures 4079 Second Edition", W3C Recommendation , October 2004, 4080 . 4082 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second 4083 Edition", W3C Recommendation , October 2004, 4084 . 4086 [4] World Wide Web Consortium, "Namespaces in XML", W3C 4087 Recommendation , January 1999, 4088 . 4090 [5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C 4091 Candidate Recommendation , June 2006, 4092 . 4094 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4095 Levels", RFC 2119, March 1997. 4097 [7] Philips, A. and M. Davis, "Tags for Identifying of Languages", 4098 RFC 4646, September 2006. 4100 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4101 Resource Identifiers (URI): Generic Syntax", RFC 3986, 4102 January 2005`. 4104 [9] Freed, N. and J. Postel, "IANA Charset Registration 4105 Procedures", BCP 2978, October 2000. 4107 [10] Sciberras, A., "Schema for User Applications", RFC 4519, 4108 June 2006. 4110 [11] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 4112 [12] Klyne, G. and C. Newman, "Date and Time on the Internet: 4113 Timestamps", RFC 3339, July 2002. 4115 [13] International Organization for Standardization, "International 4116 Standard: Data elements and interchange formats - Information 4117 interchange - Representation of dates and times", ISO 8601, 4118 Second Edition, December 2000. 4120 [14] International Organization for Standardization, "International 4121 Standard: Codes for the representation of currencies and funds, 4122 ISO 4217:2001", ISO 4217:2001, August 2001. 4124 [15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 4126 12.2. Informative References 4128 [16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the 4129 Format for Incident Information Exchange (FINE)", RFC XXX, 4130 December 2005. 4132 [17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion 4133 Detection Message Exchange Format", RFC 4765, March 2007. 4135 [18] Moriarty, K., "Incident Handling: Real-time Inter-network 4136 Defense", RFC XXX, June 2006. 4138 [19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", RFC XXX, 4139 June 2006. 4141 [20] Shafranovich, Y., "Common Format and MIME Type for Comma- 4142 Separated Values (CSV) File", RFC 4180, October 2005. 4144 Authors' Addresses 4146 Roman Danyliw 4147 CERT Program 4148 Pittsburgh 4149 USA 4151 Email: rdd@cert.org 4153 Jan Meijer 4154 SURFnet bv 4155 Utrecht 4156 Netherlands 4158 Email: jan.meijer@surfnet.nl 4160 Yuri Demchenko 4161 University of Amsterdam 4162 Amsterdam 4163 Netherlands 4165 Email: demch@chello.nl 4167 Full Copyright Statement 4169 Copyright (C) The IETF Trust (2007). 4171 This document is subject to the rights, licenses and restrictions 4172 contained in BCP 78, and except as set forth therein, the authors 4173 retain all their rights. 4175 This document and the information contained herein are provided on an 4176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4178 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4179 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4180 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4183 Intellectual Property 4185 The IETF takes no position regarding the validity or scope of any 4186 Intellectual Property Rights or other rights that might be claimed to 4187 pertain to the implementation or use of the technology described in 4188 this document or the extent to which any license under such rights 4189 might or might not be available; nor does it represent that it has 4190 made any independent effort to identify any such rights. Information 4191 on the procedures with respect to rights in RFC documents can be 4192 found in BCP 78 and BCP 79. 4194 Copies of IPR disclosures made to the IETF Secretariat and any 4195 assurances of licenses to be made available, or the result of an 4196 attempt made to obtain a general license or permission for the use of 4197 such proprietary rights by implementers or users of this 4198 specification can be obtained from the IETF on-line IPR repository at 4199 http://www.ietf.org/ipr. 4201 The IETF invites any interested party to bring to its attention any 4202 copyrights, patents or patent applications, or other proprietary 4203 rights that may cover technology that may be required to implement 4204 this standard. Please address the information to the IETF at 4205 ietf-ipr@ietf.org. 4207 Acknowledgment 4209 Funding for the RFC Editor function is provided by the IETF 4210 Administrative Support Activity (IASA).