idnits 2.17.1 draft-ietf-mile-rfc5070-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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? -- The draft header indicates that this document obsoletes RFC5070, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2013) is 3886 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 3731 -- Looks like a reference, but probably isn't: '0-4' on line 3731 -- Looks like a reference, but probably isn't: '0-5' on line 3731 -- Looks like a reference, but probably isn't: 'RFC3275' on line 2755 -- 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: 2 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group R. Danyliw 3 Internet-Draft CERT 4 Obsoletes: 5070 (if approved) P. Stoecker 5 Intended status: Standards Track RSA 6 Expires: March 02, 2014 August 29, 2013 8 The Incident Object Description Exchange Format v2 9 draft-ietf-mile-rfc5070-bis-01 11 Abstract 13 The Incident Object Description Exchange Format (IODEF) defines a 14 data representation that provides a framework for sharing information 15 commonly exchanged by Computer Security Incident Response Teams 16 (CSIRTs) about computer security incidents. This document describes 17 the information model for the IODEF and provides an associated data 18 model specified with XML Schema. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 02, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Changes from 5070 . . . . . . . . . . . . . . . . . . . . 5 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.4. About the IODEF Data Model . . . . . . . . . . . . . . . 6 71 1.5. About the IODEF Implementation . . . . . . . . . . . . . 7 72 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 7 73 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . 8 75 2.3. Characters and Strings . . . . . . . . . . . . . . . . . 8 76 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . 8 77 2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 8 79 2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . 9 80 2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 9 81 2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 9 82 2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 9 83 2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . 10 84 2.12. Person or Organization . . . . . . . . . . . . . . . . . 10 85 2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 10 86 2.14. Email String . . . . . . . . . . . . . . . . . . . . . . 10 87 2.15. Uniform Resource Locator strings . . . . . . . . . . . . 10 88 3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . 10 89 3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 11 90 3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 11 91 3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . 15 92 3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 16 93 3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 16 94 3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . 17 95 3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 19 96 3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . 22 97 3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22 98 3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 23 99 3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23 100 3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . 24 101 3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24 102 3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24 103 3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . 24 104 3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . 25 105 3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 25 106 3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . 25 107 3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 26 108 3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . 27 109 3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . 28 110 3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . 30 111 3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . 32 112 3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . 32 113 3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 33 114 3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . 34 115 3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 35 116 3.12.1. Relating the Incident and EventData Classes . . . . 37 117 3.12.2. Cardinality of EventData . . . . . . . . . . . . . . 38 118 3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 39 119 3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 41 120 3.15. System Class . . . . . . . . . . . . . . . . . . . . . . 42 121 3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . 44 122 3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . 45 123 3.16.2. Address Class . . . . . . . . . . . . . . . . . . . 46 124 3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . 48 125 3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 50 126 3.17.1. Application Class . . . . . . . . . . . . . . . . . 51 127 3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 53 128 3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . 53 129 3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . 53 130 3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . 55 131 3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . 56 132 3.20. RegistryKeyModified Class . . . . . . . . . . . . . . . . 56 133 3.20.1. Key Class . . . . . . . . . . . . . . . . . . . . . 57 134 3.21. HashInformation Class . . . . . . . . . . . . . . . . . . 58 135 4. Processing Considerations . . . . . . . . . . . . . . . . . . 59 136 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 60 137 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 60 138 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 60 139 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 61 140 5.1. Extending the Enumerated Values of Attributes . . . . . . 62 141 5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 62 142 6. Internationalization Issues . . . . . . . . . . . . . . . . . 64 143 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 65 144 7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . 65 145 7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 67 146 7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 69 147 7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . 71 148 8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . 72 149 9. Security Considerations . . . . . . . . . . . . . . . . . . . 104 150 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105 151 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 105 152 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 153 12.1. Normative References . . . . . . . . . . . . . . . . . . 106 154 12.2. Informative References . . . . . . . . . . . . . . . . . 107 156 1. Introduction 158 Organizations require help from other parties to mitigate malicious 159 activity targeting their network and to gain insight into potential 160 threats. This coordination might entail working with an ISP to 161 filter attack traffic, contacting a remote site to take down a bot- 162 network, or sharing watch-lists of known malicious IP addresses in a 163 consortium. 165 The Incident Object Description Exchange Format (IODEF) is a format 166 for representing computer security information commonly exchanged 167 between Computer Security Incident Response Teams (CSIRTs). It 168 provides an XML representation for conveying: 170 o cyber intelligence to characterize threats; 172 o cyber incident reports to document particular cyber security 173 events or relationships between events; 175 o cyber event mitigation to request proactive and reactive 176 mitigation approaches to cyber intelligence or incidents; and 178 o cyber information sharing meta-data so that these various classes 179 of information can be exchanged among parties. 181 The data model encodes information about hosts, networks, and the 182 services running on these systems; attack methodology and associated 183 forensic evidence; impact of the activity; and limited approaches for 184 documenting workflow. 186 The overriding purpose of the IODEF is to enhance the operational 187 capabilities of CSIRTs. Community adoption of the IODEF provides an 188 improved ability to resolve incidents and convey situational 189 awareness by simplifying collaboration and data sharing. This 190 structured format provided by the IODEF allows for: 192 o increased automation in processing of incident data, since the 193 resources of security analysts to parse free-form textual 194 documents will be reduced; 196 o decreased effort in normalizing similar data (even when highly 197 structured) from different sources; and 199 o a common format on which to build interoperable tools for incident 200 handling and subsequent analysis, specifically when data comes 201 from multiple constituencies. 203 Coordinating with other CSIRTs is not strictly a technical problem. 204 There are numerous procedural, trust, and legal considerations that 205 might prevent an organization from sharing information. The IODEF 206 does not attempt to address them. However, operational 207 implementations of the IODEF will need to consider this broader 208 context. 210 Sections 3 and 8 specify the IODEF data model with text and an XML 211 schema. The types used by the data model are covered in Section 2. 212 Processing considerations, the handling of extensions, and 213 internationalization issues related to the data model are covered in 214 Sections 4, 5, and 6, respectively. Examples are listed in 215 Section 7. Section 1 provides the background for the IODEF, and 216 Section 9 documents the security considerations. 218 1.1. Changes from 5070 220 This document contains changes with respect to its predecessor 221 RFC5070. 223 o All of the RFC5070 Errata was implemented. 225 o Imported the xmlns:ds namespace to include digital signature hash 226 classes. 228 o The attributes @indicator-uid and @indicator-set-id were added to 229 various classes to reference commonly shared indicators. 231 o The following classes were added to the Service class: Email, 232 EmailSubject, X-Mailer, and DomainData. 234 o The following classes were added to the Record class: FileName, 235 ds:Reference, and WindowsRegistryKeysModified. 237 o (for consideration) The following class was added to the Node 238 class: URL. 240 o (for consideration) The following attributes was added to the 241 SoftwareType complexType: user-agent. 243 o Additional enumerated values were added to the following 244 attributes: @restriction, {Expectation, HistoryItem}@action, and 245 NodeRole@category. 247 1.2. Terminology 249 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 250 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 251 document are to be interpreted as described in RFC2119 [6]. 253 Definitions for some of the common computer security-related 254 terminology used in this document can be found in Section 2 of [16]. 256 1.3. Notations 258 The normative IODEF data model is specified with the text in 259 Section 3 and the XML schema in Section 8. To help in the 260 understanding of the data elements, Section 3 also depicts the 261 underlying information model using Unified Modeling Language (UML). 262 This abstract presentation of the IODEF is not normative. 264 For clarity in this document, the term "XML document" will be used 265 when referring generically to any instance of an XML document. The 266 term "IODEF document" will be used to refer to specific elements and 267 attributes of the IODEF schema. The terms "class" and "element" will 268 be used interchangeably to reference either the corresponding data 269 element in the information or data models, respectively. 271 1.4. About the IODEF Data Model 273 The IODEF data model is a data representation that provides a 274 framework for sharing information commonly exchanged by CSIRTs about 275 computer security incidents. A number of considerations were made in 276 the design of the data model. 278 o The data model serves as a transport format. Therefore, its 279 specific representation is not the optimal representation for on- 280 disk storage, long-term archiving, or in-memory processing. 282 o As there is no precise widely agreed upon definition for an 283 incident, the data model does not attempt to dictate one through 284 its implementation. Rather, a broad understanding is assumed in 285 the IODEF that is flexible enough to encompass most operators. 287 o Describing an incident for all definitions would require an 288 extremely complex data model. Therefore, the IODEF only intends 289 to be a framework to convey commonly exchanged incident 290 information. It ensures that there are ample mechanisms for 291 extensibility to support organization-specific information, and 292 techniques to reference information kept outside of the explicit 293 data model. 295 o The domain of security analysis is not fully standardized and must 296 rely on free-form textual descriptions. The IODEF attempts to 297 strike a balance between supporting this free-form content, while 298 still allowing automated processing of incident information. 300 o The IODEF is only one of several security relevant data 301 representations being standardized. Attempts were made to ensure 302 they were complimentary. The data model of the Intrusion 303 Detection Message Exchange Format [17] influenced the design of 304 the IODEF. 306 Further discussion of the desirable properties for the IODEF can be 307 found in the Requirements for the Format for Incident Information 308 Exchange (FINE) [16]. 310 1.5. About the IODEF Implementation 312 The IODEF implementation is specified as an Extensible Markup 313 Language (XML) [1] Schema [2] in Section 8. 315 Implementing the IODEF in XML provides numerous advantages. Its 316 extensibility makes it ideal for specifying a data encoding framework 317 that supports various character encodings. Likewise, the abundance 318 of related technologies (e.g., XSL, XPath, XML-Signature) makes for 319 simplified manipulation. However, XML is fundamentally a text 320 representation, which makes it inherently inefficient when binary 321 data must be embedded or large volumes of data must be exchanged. 323 2. IODEF Data Types 325 The various data elements of the IODEF data model are typed. This 326 section discusses these data types. When possible, native Schema 327 data types were adopted, but for more complicated formats, regular 328 expressions (see Appendix F of [3]) or external standards were used. 330 2.1. Integers 332 An integer is represented by the INTEGER data type. Integer data 333 MUST be encoded in Base 10. 335 The INTEGER data type is implemented as an "xs:integer" [3] in the 336 schema. 338 2.2. Real Numbers 340 Real (floating-point) attributes are represented by the REAL data 341 type. Real data MUST be encoded in Base 10. 343 The REAL data type is implemented as an "xs:float" [3] in the schema. 345 2.3. Characters and Strings 347 A single character is represented by the CHARACTER data type. A 348 character string is represented by the STRING data type. Special 349 characters must be encoded using entity references. See Section 4.1. 351 The CHARACTER and STRING data types are implement as an "xs:string" 352 [3] in the schema. 354 2.4. Multilingual Strings 356 STRING data that represents multi-character attributes in a language 357 different than the default encoding of the document is of the 358 ML_STRING data type. 360 The ML_STRING data type is implemented as an "iodef:MLStringType" in 361 the schema. 363 2.5. Bytes 365 A binary octet is represented by the BYTE data type. A sequence of 366 binary octets is represented by the BYTE[] data type. These octets 367 are encoded using base64. 369 The BYTE data type is implemented as an "xs:base64Binary" [3] in the 370 schema. 372 2.6. Hexadecimal Bytes 374 A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. 375 This octet is encoded as a character tuple consisting of two 376 hexadecimal digits. 378 The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the 379 schema. 381 2.7. Enumerated Types 383 Enumerated types are represented by the ENUM data type, and consist 384 of an ordered list of acceptable values. Each value has a 385 representative keyword. Within the IODEF schema, the enumerated type 386 keywords are used as attribute values. 388 The ENUM data type is implemented as a series of "xs:NMTOKEN" in the 389 schema. 391 2.8. Date-Time Strings 393 Date-time strings are represented by the DATETIME data type. Each 394 date-time string identifies a particular instant in time; ranges are 395 not supported. 397 Date-time strings are formatted according to a subset of ISO 398 8601:2000 [13] documented in RFC 3339 [12]. 400 The DATETIME data type is implemented as an "xs:dateTime" [3] in the 401 schema. 403 2.9. Timezone String 405 A timezone offset from UTC is represented by the TIMEZONE data type. 406 It is formatted according to the following regular expression: 407 "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". 409 The TIMEZONE data type is implemented as an "xs:string" with a 410 regular expression constraint in the schema. This regular expression 411 is identical to the timezone representation implemented in an 412 "xs:dateTime". 414 2.10. Port Lists 416 A list of network ports are represented by the PORTLIST data type. A 417 PORTLIST consists of a comma-separated list of numbers and ranges 418 (N-M means ports N through M, inclusive). It is formatted according 419 to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". 420 For example, "2,5-15,30,32,40-50,55-60". 422 The PORTLIST data type is implemented as an "xs:string" with a 423 regular expression constraint in the schema. 425 2.11. Postal Address 427 A postal address is represented by the POSTAL data type. This data 428 type is an ML_STRING whose format is documented in Section 2.23 of 429 RFC 4519 [10]. It defines a postal address as a free-form multi-line 430 string separated by the "$" character. 432 The POSTAL data type is implemented as an "xs:string" in the schema. 434 2.12. Person or Organization 436 The name of an individual or organization is represented by the NAME 437 data type. This data type is an ML_STRING whose format is documented 438 in Section 2.3 of RFC 4519 [10]. 440 The NAME data type is implemented as an "xs:string" in the schema. 442 2.13. Telephone and Fax Numbers 444 A telephone or fax number is represented by the PHONE data type. The 445 format of the PHONE data type is documented in Section 2.35 of RFC 446 4519 [10]. 448 The PHONE data type is implemented as an "xs:string" in the schema. 450 2.14. Email String 452 An email address is represented by the EMAIL data type. The format 453 of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11] 455 The EMAIL data type is implemented as an "xs:string" in the schema. 457 2.15. Uniform Resource Locator strings 459 A uniform resource locator (URL) is represented by the URL data type. 460 The format of the URL data type is documented in RFC 2396 [8]. 462 The URL data type is implemented as an "xs:anyURI" in the schema. 464 3. The IODEF Data Model 466 In this section, the individual components of the IODEF data model 467 will be discussed in detail. For each class, the semantics will be 468 described and the relationship with other classes will be depicted 469 with UML. When necessary, specific comments will be made about 470 corresponding definition in the schema in Section 8 472 3.1. IODEF-Document Class 474 The IODEF-Document class is the top level class in the IODEF data 475 model. All IODEF documents are an instance of this class. 477 +-----------------+ 478 | IODEF-Document | 479 +-----------------+ 480 | STRING version |<>--{1..*}--[ Incident ] 481 | ENUM lang | 482 | STRING formatid | 483 +-----------------+ 485 Figure 1: IODEF-Document Class 487 The aggregate class that constitute IODEF-Document is: 489 Incident 490 One or more. The information related to a single incident. 492 The IODEF-Document class has three attributes: 494 version 495 Required. STRING. The IODEF specification version number to 496 which this IODEF document conforms. The value of this attribute 497 MUST be "2.00" 499 lang 500 Required. ENUM. A valid language code per RFC 4646 [7] 501 constrained by the definition of "xs:language". The 502 interpretation of this code is described in Section 6. 504 formatid 505 Optional. STRING. A free-form string to convey processing 506 instructions to the recipient of the document. Its semantics must 507 be negotiated out-of-band. 509 3.2. Incident Class 511 Every incident is represented by an instance of the Incident class. 512 This class provides a standardized representation for commonly 513 exchanged incident data. 515 +--------------------+ 516 | Incident | 517 +--------------------+ 518 | ENUM purpose |<>----------[ IncidentID ] 519 | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] 520 | ENUM lang |<>--{0..1}--[ RelatedActivity ] 521 | ENUM restriction |<>--{0..1}--[ DetectTime ] 522 | |<>--{0..1}--[ StartTime ] 523 | |<>--{0..1}--[ EndTime ] 524 | |<>----------[ ReportTime ] 525 | |<>--{0..*}--[ Description ] 526 | |<>--{1..*}--[ Assessment ] 527 | |<>--{0..*}--[ Method ] 528 | |<>--{1..*}--[ Contact ] 529 | |<>--{0..*}--[ EventData ] 530 | |<>--{0..1}--[ History ] 531 | |<>--{0..*}--[ AdditionalData ] 532 +--------------------+ 534 Figure 2: The Incident Class 536 The aggregate classes that constitute Incident are: 538 IncidentID 539 One. An incident tracking number assigned to this incident by the 540 CSIRT that generated the IODEF document. 542 AlternativeID 543 Zero or one. The incident tracking numbers used by other CSIRTs 544 to refer to the incident described in the document. 546 RelatedActivity 547 Zero or one. The incident tracking numbers of related incidents. 549 DetectTime 550 Zero or one. The time the incident was first detected. 552 StartTime 553 Zero or one. The time the incident started. 555 EndTime 556 Zero or one. The time the incident ended. 558 ReportTime 559 One. The time the incident was reported. 561 Description 562 Zero or more. ML_STRING. A free-form textual description of the 563 incident. 565 Assessment 566 One or more. A characterization of the impact of the incident. 568 Method 569 Zero or more. The techniques used by the intruder in the 570 incident. 572 Contact 573 One or more. Contact information for the parties involved in the 574 incident. 576 EventData 577 Zero or more. Description of the events comprising the incident. 579 History 580 Zero or one. A log of significant events or actions that occurred 581 during the course of handling the incident. 583 AdditionalData 584 Zero or more. Mechanism by which to extend the data model. 586 The Incident class has five attributes: 588 purpose 589 Required. ENUM. The purpose attribute represents the reason why 590 the IODEF document was created. It is closely related to the 591 Expectation class (Section 3.13). This attribute is defined as an 592 enumerated list: 594 1. traceback. The document was sent for trace-back purposes. 596 2. mitigation. The document was sent to request aid in 597 mitigating the described activity. 599 3. reporting. The document was sent to comply with reporting 600 requirements. 602 4. other. The document was sent for purposes specified in the 603 Expectation class. 605 5. ext-value. An escape value used to extend this attribute. 606 See Section 5.1. 608 ext-purpose 609 Optional. STRING. A means by which to extend the purpose 610 attribute. See Section 5.1. 612 lang 613 Optional. ENUM. A valid language code per RFC 4646 [7] 614 constrained by the definition of "xs:language". The 615 interpretation of this code is described in Section 6. 617 restriction 618 Optional. ENUM. This attribute indicates the disclosure 619 guidelines to which the sender expects the recipient to adhere for 620 the information represented in this class and its children. This 621 guideline provides no security since there are no specified 622 technical means to ensure that the recipient of the document 623 handles the information as the sender requested. 625 The value of this attribute is logically inherited by the children 626 of this class. That is to say, the disclosure rules applied to 627 this class, also apply to its children. 629 It is possible to set a granular disclosure policy, since all of 630 the high-level classes (i.e., children of the Incident class) have 631 a restriction attribute. Therefore, a child can override the 632 guidelines of a parent class, be it to restrict or relax the 633 disclosure rules (e.g., a child has a weaker policy than an 634 ancestor; or an ancestor has a weak policy, and the children 635 selectively apply more rigid controls). The implicit value of the 636 restriction attribute for a class that did not specify one can be 637 found in the closest ancestor that did specify a value. 639 This attribute is defined as an enumerated value with a default 640 value of "private". Note that the default value of the 641 restriction attribute is only defined in the context of the 642 Incident class. In other classes where this attribute is used, no 643 default is specified. 645 1. public. The information can be freely distributed without 646 restriction. 648 2. partner. The information may be shared within a closed 649 community of peers, partners, or affected parties, but cannot 650 be openly published. 652 3. need-to-know. The information may be shared only within the 653 organization with individuals that have a need to know. 655 4. private. The information may not be shared. 657 5. default. The information can be shared according to an 658 information disclosure policy pre-arranged by the 659 communicating parties. 661 6. white. Same as 'public'. 663 7. green. Same as 'partner'. 665 8. amber. Same as 'need-to-know'. 667 9. red. Same as 'private'. 669 indicator-set-id 670 Optional. STRING. The indicator set ID is used to group related 671 indicators. 673 3.3. IncidentID Class 675 The IncidentID class represents an incident tracking number that is 676 unique in the context of the CSIRT and identifies the activity 677 characterized in an IODEF Document. This identifier would serve as 678 an index into the CSIRT incident handling system. The combination of 679 the name attribute and the string in the element content MUST be a 680 globally unique identifier describing the activity. Documents 681 generated by a given CSIRT MUST NOT reuse the same value unless they 682 are referencing the same incident. 684 +------------------+ 685 | IncidentID | 686 +------------------+ 687 | STRING | 688 | | 689 | STRING name | 690 | STRING instance | 691 | ENUM restriction | 692 +------------------+ 694 Figure 3: The IncidentID Class 696 The IncidentID class has three attributes: 698 name 699 Required. STRING. An identifier describing the CSIRT that 700 created the document. In order to have a globally unique CSIRT 701 name, the fully qualified domain name associated with the CSIRT 702 MUST be used. 704 instance 705 Optional. STRING. An identifier referencing a subset of the 706 named incident. 708 restriction 709 Optional. ENUM. This attribute has been defined in Section 3.2. 710 The default value is "public". 712 3.4. AlternativeID Class 714 The AlternativeID class lists the incident tracking numbers used by 715 CSIRTs, other than the one generating the document, to refer to the 716 identical activity described the IODEF document. A tracking number 717 listed as an AlternativeID references the same incident detected by 718 another CSIRT. The incident tracking numbers of the CSIRT that 719 generated the IODEF document must never be considered an 720 AlternativeID. 722 +------------------+ 723 | AlternativeID | 724 +------------------+ 725 | ENUM restriction |<>--{1..*}--[ IncidentID ] 726 | | 727 +------------------+ 729 Figure 4: The AlternativeID Class 731 The aggregate class that constitutes AlternativeID is: 733 IncidentID 734 One or more. The incident tracking number of another CSIRT. 736 The AlternativeID class has one attribute: 738 restriction 739 Optional. ENUM. This attribute has been defined in Section 3.2. 741 3.5. RelatedActivity Class 743 The RelatedActivity class lists either incident tracking numbers of 744 incidents or URLs (not both) that refer to activity related to the 745 one described in the IODEF document. These references may be to 746 local incident tracking numbers or to those of other CSIRTs. 748 The specifics of how a CSIRT comes to believe that two incidents are 749 related are considered out of scope. 751 +------------------+ 752 | RelatedActivity | 753 +------------------+ 754 | ENUM restriction |<>--{1..*}--[ IncidentID ] 755 | |<>--{1..*}--[ URL ] 756 +------------------+ 758 Figure 5: RelatedActivity Class 760 The aggregate classes that constitutes RelatedActivity are: 762 IncidentID 763 One or more. The incident tracking number of a related incident. 765 URL 766 One or more. URL. A URL to activity related to this incident. 768 The RelatedActivity class has one attribute: 770 restriction 771 Optional. ENUM. This attribute has been defined in Section 3.2. 773 3.6. AdditionalData Class 775 The AdditionalData class serves as an extension mechanism for 776 information not otherwise represented in the data model. For 777 relatively simple information, atomic data types (e.g., integers, 778 strings) are provided with a mechanism to annotate their meaning. 779 The class can also be used to extend the data model (and the 780 associated Schema) to support proprietary extensions by encapsulating 781 entire XML documents conforming to another Schema (e.g., IDMEF). A 782 detailed discussion for extending the data model and the schema can 783 be found in Section 5. 785 Unlike XML, which is self-describing, atomic data must be documented 786 to convey its meaning. This information is described in the 787 'meaning' attribute. Since these description are outside the scope 788 of the specification, some additional coordination may be required to 789 ensure that a recipient of a document using the AdditionalData 790 classes can make sense of the custom extensions. 792 +------------------+ 793 | AdditionalData | 794 +------------------+ 795 | ANY | 796 | | 797 | ENUM dtype | 798 | STRING ext-dtype | 799 | STRING meaning | 800 | STRING formatid | 801 | ENUM restriction | 802 +------------------+ 804 Figure 6: The AdditionalData Class 806 The AdditionalData class has five attributes: 808 dtype 809 Required. ENUM. The data type of the element content. The 810 permitted values for this attribute are shown below. The default 811 value is "string". 813 1. boolean. The element content is of type BOOLEAN. 815 2. byte. The element content is of type BYTE. 817 3. character. The element content is of type CHARACTER. 819 4. date-time. The element content is of type DATETIME. 821 5. integer. The element content is of type INTEGER. 823 6. portlist. The element content is of type PORTLIST. 825 7. real. The element content is of type REAL. 827 8. string. The element content is of type STRING. 829 9. file. The element content is a base64 encoded binary file 830 encoded as a BYTE[] type. 832 10. frame. The element content is a layer-2 frame encoded as a 833 HEXBIN type. 835 11. packet. The element content is a layer-3 packet encoded as a 836 HEXBIN type. 838 12. ipv4-packet. The element content is an IPv4 packet encoded 839 as a HEXBIN type. 841 13. ipv6-packet. The element content is an IPv6 packet encoded 842 as a HEXBIN type. 844 14. path. The element content is a file-system path encoded as a 845 STRING type. 847 15. url. The element content is of type URL. 849 16. csv. The element content is a common separated value (CSV) 850 list per Section 2 of [20] encoded as a STRING type. 852 17. winreg. The element content is a Windows registry key 853 encoded as a STRING type. 855 18. xml. The element content is XML (see Section 5). 857 19. ext-value. An escape value used to extend this attribute. 858 See Section 5.1. 860 ext-dtype 861 Optional. STRING. A means by which to extend the dtype 862 attribute. See Section 5.1. 864 meaning 865 Optional. STRING. A free-form description of the element 866 content. 868 formatid 869 Optional. STRING. An identifier referencing the format and 870 semantics of the element content. 872 restriction 873 Optional. ENUM. This attribute has been defined in Section 3.2. 875 3.7. Contact Class 877 The Contact class describes contact information for organizations and 878 personnel involved in the incident. This class allows for the naming 879 of the involved party, specifying contact information for them, and 880 identifying their role in the incident. 882 People and organizations are treated interchangeably as contacts; one 883 can be associated with the other using the recursive definition of 884 the class (the Contact class is aggregated into the Contact class). 885 The 'type' attribute disambiguates the type of contact information 886 being provided. 888 The inheriting definition of Contact provides a way to relate 889 information without requiring the explicit use of identifiers in the 890 classes or duplication of data. A complete point of contact is 891 derived by a particular traversal from the root Contact class to the 892 leaf Contact class. As such, multiple points of contact might be 893 specified in a single instance of a Contact class. Each child 894 Contact class logically inherits contact information from its 895 ancestors. 897 +------------------+ 898 | Contact | 899 +------------------+ 900 | ENUM role |<>--{0..1}--[ ContactName ] 901 | STRING ext-role |<>--{0..*}--[ Description ] 902 | ENUM type |<>--{0..*}--[ RegistryHandle ] 903 | STRING ext-type |<>--{0..1}--[ PostalAddress ] 904 | ENUM restriction |<>--{0..*}--[ Email ] 905 | |<>--{0..*}--[ Telephone ] 906 | |<>--{0..1}--[ Fax ] 907 | |<>--{0..1}--[ Timezone ] 908 | |<>--{0..*}--[ Contact ] 909 | |<>--{0..*}--[ AdditionalData ] 910 +------------------+ 912 Figure 7: The Contact Class 914 The aggregate classes that constitute the Contact class are: 916 ContactName 917 Zero or one. ML_STRING. The name of the contact. The contact 918 may either be an organization or a person. The type attribute 919 disambiguates the semantics. 921 Description 922 Zero or many. ML_STRING. A free-form description of this 923 contact. In the case of a person, this is often the 924 organizational title of the individual. 926 RegistryHandle 927 Zero or many. A handle name into the registry of the contact. 929 PostalAddress 930 Zero or one. The postal address of the contact. 932 Email 933 Zero or many. The email address of the contact. 935 Telephone 936 Zero or many. The telephone number of the contact. 938 Fax 939 Zero or one. The facsimile telephone number of the contact. 941 Timezone 942 Zero or one. TIMEZONE. The timezone in which the contact resides 943 formatted according to Section 2.9. 945 Contact 946 Zero or many. A Contact instance contained within another Contact 947 instance inherits the values of the parent(s). This recursive 948 definition can be used to group common data pertaining to multiple 949 points of contact and is especially useful when listing multiple 950 contacts at the same organization. 952 AdditionalData 953 Zero or many. A mechanism by which to extend the data model. 955 At least one of the aggregate classes MUST be present in an instance 956 of the Contact class. This is not enforced in the IODEF schema as 957 there is no simple way to accomplish it. 959 The Contact class has five attributes: 961 role 962 Required. ENUM. Indicates the role the contact fulfills. This 963 attribute is defined as an enumerated list: 965 1. creator. The entity that generate the document. 967 2. admin. An administrative contact for a host or network. 969 3. tech. A technical contact for a host or network. 971 4. irt. The CSIRT involved in handling the incident. 973 5. cc. An entity that is to be kept informed about the handling 974 of the incident. 976 6. ext-value. An escape value used to extend this attribute. 977 See Section 5.1. 979 ext-role 980 Optional. STRING. A means by which to extend the role attribute. 981 See Section 5.1. 983 type 984 Required. ENUM. Indicates the type of contact being described. 985 This attribute is defined as an enumerated list: 987 1. person. The information for this contact references an 988 individual. 990 2. organization. The information for this contact references an 991 organization. 993 3. ext-value. An escape value used to extend this attribute. 994 See Section 5.1. 996 ext-type 997 Optional. STRING. A means by which to extend the type attribute. 998 See Section 5.1. 1000 restriction 1001 Optional. ENUM. This attribute is defined in Section 3.2. 1003 3.7.1. RegistryHandle Class 1005 The RegistryHandle class represents a handle into an Internet 1006 registry or community-specific database. The handle is specified in 1007 the element content and the type attribute specifies the database. 1009 +---------------------+ 1010 | RegistryHandle | 1011 +---------------------+ 1012 | STRING | 1013 | | 1014 | ENUM registry | 1015 | STRING ext-registry | 1016 +---------------------+ 1018 Figure 8: The RegistryHandle Class 1020 The RegistryHandle class has two attributes: 1022 registry 1023 Required. ENUM. The database to which the handle belongs. The 1024 possible values are: 1026 1. internic. Internet Network Information Center 1028 2. apnic. Asia Pacific Network Information Center 1030 3. arin. American Registry for Internet Numbers 1032 4. lacnic. Latin-American and Caribbean IP Address Registry 1034 5. ripe. Reseaux IP Europeens 1036 6. afrinic. African Internet Numbers Registry 1038 7. local. A database local to the CSIRT 1040 8. ext-value. An escape value used to extend this attribute. 1041 See Section 5.1. 1043 ext-registry 1044 Optional. STRING. A means by which to extend the registry 1045 attribute. See Section 5.1. 1047 3.7.2. PostalAddress Class 1048 The PostalAddress class specifies a postal address formatted 1049 according to the POSTAL data type (Section 2.11). 1051 +---------------------+ 1052 | PostalAddress | 1053 +---------------------+ 1054 | POSTAL | 1055 | | 1056 | ENUM meaning | 1057 | ENUM lang | 1058 +---------------------+ 1060 Figure 9: The PostalAddress Class 1062 The PostalAddress class has two attributes: 1064 meaning 1065 Optional. ENUM. A free-form description of the element content. 1067 lang 1068 Optional. ENUM. A valid language code per RFC 4646 [7] 1069 constrained by the definition of "xs:language". The 1070 interpretation of this code is described in Section 6. 1072 3.7.3. Email Class 1074 The Email class specifies an email address formatted according to 1075 EMAIL data type (Section 2.14). 1077 +--------------+ 1078 | Email | 1079 +--------------+ 1080 | EMAIL | 1081 | | 1082 | ENUM meaning | 1083 +--------------+ 1085 Figure 10: The Email Class 1087 The Email class has one attribute: 1089 meaning 1090 Optional. ENUM. A free-form description of the element content. 1092 3.7.4. Telephone and Fax Classes 1093 The Telephone and Fax classes specify a voice or fax telephone number 1094 respectively, and are formatted according to PHONE data type 1095 (Section 2.13). 1097 +--------------------+ 1098 | {Telephone | Fax } | 1099 +--------------------+ 1100 | PHONE | 1101 | | 1102 | ENUM meaning | 1103 +--------------------+ 1105 Figure 11: The Telephone and Fax Classes 1107 The Telephone class has one attribute: 1109 meaning 1110 Optional. ENUM. A free-form description of the element content 1111 (e.g., hours of coverage for a given number). 1113 3.8. Time Classes 1115 The data model uses five different classes to represent a timestamp. 1116 Their definition is identical, but each has a distinct name to convey 1117 a difference in semantics. 1119 The element content of each class is a timestamp formatted according 1120 to the DATETIME data type (see Section 2.8). 1122 +----------------------------------+ 1123 | {Start| End| Report| Detect}Time | 1124 +----------------------------------+ 1125 | DATETIME | 1126 +----------------------------------+ 1128 Figure 12: The Time Classes 1130 3.8.1. StartTime 1132 The StartTime class represents the time the incident began. 1134 3.8.2. EndTime 1136 The EndTime class represents the time the incident ended. 1138 3.8.3. DetectTime 1139 The DetectTime class represents the time the first activity of the 1140 incident was detected. 1142 3.8.4. ReportTime 1144 The ReportTime class represents the time the incident was reported. 1145 This timestamp MUST be the time at which the IODEF document was 1146 generated. 1148 3.8.5. DateTime 1150 The DateTime class is a generic representation of a timestamp. Infer 1151 its semantics from the parent class in which it is aggregated. 1153 3.9. Method Class 1155 The Method class describes the methodology used by the intruder to 1156 perpetrate the events of the incident. This class consists of a list 1157 of references describing the attack method and a free form 1158 description of the technique. 1160 +------------------+ 1161 | Method | 1162 +------------------+ 1163 | ENUM restriction |<>--{0..*}--[ Reference ] 1164 | |<>--{0..*}--[ Description ] 1165 | |<>--{0..*}--[ AdditionalData ] 1166 +------------------+ 1168 Figure 13: The Method Class 1170 The Method class is composed of three aggregate classes. 1172 Reference 1173 Zero or many. A reference to a vulnerability, malware sample, 1174 advisory, or analysis of an attack technique. 1176 Description 1177 Zero or many. ML_STRING. A free-form text description of the 1178 methodology used by the intruder. 1180 AdditionalData 1181 Zero or many. A mechanism by which to extend the data model. 1183 Either an instance of the Reference or Description class MUST be 1184 present. 1186 The Method class has one attribute: 1188 restriction 1189 Optional. ENUM. This attribute is defined in Section 3.2. 1191 3.9.1. Reference Class 1193 The Reference class is a reference to a vulnerability, IDS alert, 1194 malware sample, advisory, or attack technique. A reference consists 1195 of a name, a URL to this reference, and an optional description. 1197 +------------------+ 1198 | Reference | 1199 +------------------+ 1200 | |<>----------[ ReferenceName ] 1201 | |<>--{0..*}--[ URL ] 1202 | |<>--{0..*}--[ Description ] 1203 +------------------+ 1205 Figure 14: The Reference Class 1207 The aggregate classes that constitute Reference: 1209 ReferenceName 1210 One. ML_STRING. Name of the reference. 1212 URL 1213 Zero or many. URL. A URL associated with the reference. 1215 Description 1216 Zero or many. ML_STRING. A free-form text description of this 1217 reference. 1219 The Reference class has 4 attributes. 1221 indicator-uid 1222 Optional. STRING. A unique identifier for an Indicator. 1224 indicator-set-id 1225 Optional. STRING. The indicator set ID is used to group 1226 releated indicators. 1228 attacktype 1229 Optional. ENUM. A unique identifier for an Indicator. 1231 ext-attacktype 1232 Optional. STRING. A mechanism by which to extend the 1233 Attack Type. 1235 3.10. Assessment Class 1237 The Assessment class describes the technical and non-technical 1238 repercussions of the incident on the CSIRT's constituency. 1240 This class was derived from the IDMEF[17]. 1242 +------------------+ 1243 | Assessment | 1244 +------------------+ 1245 | ENUM occurrence |<>--{0..*}--[ Impact ] 1246 | ENUM restriction |<>--{0..*}--[ TimeImpact ] 1247 | |<>--{0..*}--[ MonetaryImpact ] 1248 | |<>--{0..*}--[ Counter ] 1249 | |<>--{0..1}--[ Confidence ] 1250 | |<>--{0..*}--[ AdditionalData ] 1251 +------------------+ 1253 Figure 15: Assessment Class 1255 The aggregate classes that constitute Assessment are: 1257 Impact 1258 Zero or many. Technical impact of the incident on a network. 1260 TimeImpact 1261 Zero or many. Impact of the activity measured with respect to 1262 time. 1264 MonetaryImpact 1265 Zero or many. Impact of the activity measured with respect to 1266 financial loss. 1268 Counter 1269 Zero or more. A counter with which to summarize the magnitude of 1270 the activity. 1272 Confidence 1273 Zero or one. An estimate of confidence in the assessment. 1275 AdditionalData 1276 Zero or many. A mechanism by which to extend the data model. 1278 A least one instance of the possible three impact classes (i.e., 1279 Impact, TimeImpact, or MonetaryImpact) MUST be present. 1281 The Assessment class has four attributes: 1283 occurrence 1284 Optional. ENUM. Specifies whether the assessment is describing 1285 actual or potential outcomes. 1287 1. actual. This assessment describes activity that has occurred. 1289 2. potential. This assessment describes potential activity that 1290 might occur. 1292 restriction 1293 Optional. ENUM. This attribute is defined in Section 3.2. 1295 indicator-uid 1296 Optional. STRING. A unique identifier for an Indicator. 1298 indicator-set-id 1299 Optional. STRING. The indicator set ID is used to group related 1300 indicators. 1302 3.10.1. Impact Class 1304 The Impact class allows for categorizing and describing the technical 1305 impact of the incident on the network of an organization. 1307 This class is based on the IDMEF [17]. 1309 +------------------+ 1310 | Impact | 1311 +------------------+ 1312 | ML_STRING | 1313 | | 1314 | ENUM lang | 1315 | ENUM severity | 1316 | ENUM completion | 1317 | ENUM type | 1318 | STRING ext-type | 1319 +------------------+ 1321 Figure 16: Impact Class 1323 The element content will be a free-form textual description of the 1324 impact. 1326 The Impact class has five attributes: 1328 lang 1329 Optional. ENUM. A valid language code per RFC 4646 [7] 1330 constrained by the definition of "xs:language". The 1331 interpretation of this code is described in Section 6. 1333 severity 1334 Optional. ENUM. An estimate of the relative severity of the 1335 activity. The permitted values are shown below. There is no 1336 default value. 1338 1. low. Low severity 1340 2. medium. Medium severity 1342 3. high. High severity 1344 completion 1345 Optional. ENUM. An indication whether the described activity was 1346 successful. The permitted values are shown below. There is no 1347 default value. 1349 1. failed. The attempted activity was not successful. 1351 2. succeeded. The attempted activity succeeded. 1353 type 1354 Required. ENUM. Classifies the malicious activity into incident 1355 categories. The permitted values are shown below. The default 1356 value is "other". 1358 1. admin. Administrative privileges were attempted. 1360 2. dos. A denial of service was attempted. 1362 3. file. An action that impacts the integrity of a file or 1363 database was attempted. 1365 4. info-leak. An attempt was made to exfiltrate information. 1367 5. misconfiguration. An attempt was made to exploit a mis- 1368 configuration in a system. 1370 6. policy. Activity violating site's policy was attempted. 1372 7. recon. Reconnaissance activity was attempted. 1374 8. social-engineering. A social engineering attack was 1375 attempted. 1377 9. user. User privileges were attempted. 1379 10. unknown. The classification of this activity is unknown. 1381 11. ext-value. An escape value used to extend this attribute. 1382 See Section 5.1. 1384 ext-type 1385 Optional. STRING. A means by which to extend the type attribute. 1386 See Section 5.1. 1388 3.10.2. TimeImpact Class 1390 The TimeImpact class describes the impact of the incident on an 1391 organization as a function of time. It provides a way to convey down 1392 time and recovery time. 1394 +---------------------+ 1395 | TimeImpact | 1396 +---------------------+ 1397 | REAL | 1398 | | 1399 | ENUM severity | 1400 | ENUM metric | 1401 | STRING ext-metric | 1402 | ENUM duration | 1403 | STRING ext-duration | 1404 +---------------------+ 1406 Figure 17: TimeImpact Class 1408 The element content is a positive, floating point (REAL) number 1409 specifying a unit of time. The duration and metric attributes will 1410 imply the semantics of the element content. 1412 The TimeImpact class has five attributes: 1414 severity 1415 Optional. ENUM. An estimate of the relative severity of the 1416 activity. The permitted values are shown below. There is no 1417 default value. 1419 1. low. Low severity 1421 2. medium. Medium severity 1423 3. high. High severity 1425 metric 1426 Required. ENUM. Defines the metric in which the time is 1427 expressed. The permitted values are shown below. There is no 1428 default value. 1430 1. labor. Total staff-time to recovery from the activity (e.g., 1431 2 employees working 4 hours each would be 8 hours). 1433 2. elapsed. Elapsed time from the beginning of the recovery to 1434 its completion (i.e., wall-clock time). 1436 3. downtime. Duration of time for which some provided service(s) 1437 was not available. 1439 4. ext-value. An escape value used to extend this attribute. 1440 See Section 5.1. 1442 ext-metric 1443 Optional. STRING. A means by which to extend the metric 1444 attribute. See Section 5.1. 1446 duration 1447 Optional. ENUM. Defines a unit of time, that when combined with 1448 the metric attribute, fully describes a metric of impact that will 1449 be conveyed in the element content. The permitted values are 1450 shown below. The default value is "hour". 1452 1. second. The unit of the element content is seconds. 1454 2. minute. The unit of the element content is minutes. 1456 3. hour. The unit of the element content is hours. 1458 4. day. The unit of the element content is days. 1460 5. month. The unit of the element content is months. 1462 6. quarter. The unit of the element content is quarters. 1464 7. year. The unit of the element content is years. 1466 8. ext-value. An escape value used to extend this attribute. 1467 See Section 5.1. 1469 ext-duration 1470 Optional. STRING. A means by which to extend the duration 1471 attribute. See Section 5.1. 1473 3.10.3. MonetaryImpact Class 1475 The MonetaryImpact class describes the financial impact of the 1476 activity on an organization. For example, this impact may consider 1477 losses due to the cost of the investigation or recovery, diminished 1478 productivity of the staff, or a tarnished reputation that will affect 1479 future opportunities. 1481 +------------------+ 1482 | MonetaryImpact | 1483 +------------------+ 1484 | REAL | 1485 | | 1486 | ENUM severity | 1487 | STRING currency | 1488 +------------------+ 1490 Figure 18: MonetaryImpact Class 1492 The element content is a positive, floating point number (REAL) 1493 specifying a unit of currency described in the currency attribute. 1495 The MonetaryImpact class has two attributes: 1497 severity 1498 Optional. ENUM. An estimate of the relative severity of the 1499 activity. The permitted values are shown below. There is no 1500 default value. 1502 1. low. Low severity 1504 2. medium. Medium severity 1506 3. high. High severity 1508 currency 1509 Optional. STRING. Defines the currency in which the monetary 1510 impact is expressed. The permitted values are defined in ISO 1511 4217:2001, Codes for the representation of currencies and funds 1512 [14]. There is no default value. 1514 3.10.4. Confidence Class 1516 The Confidence class represents a best estimate of the validity and 1517 accuracy of the described impact (see Section 3.10) of the incident 1518 activity. This estimate can be expressed as a category or a numeric 1519 calculation. 1521 This class if based upon the IDMEF [17]). 1523 +------------------+ 1524 | Confidence | 1525 +------------------+ 1526 | REAL | 1527 | | 1528 | ENUM rating | 1529 +------------------+ 1531 Figure 19: Confidence Class 1533 The element content expresses a numerical assessment in the 1534 confidence of the data when the value of the rating attribute is 1535 "numeric". Otherwise, this element MUST be empty. 1537 The Confidence class has one attribute. 1539 rating 1540 Required. ENUM. A rating of the analytical validity of the 1541 specified Assessment. The permitted values are shown below. 1542 There is no default value. 1544 1. low. Low confidence in the validity. 1546 2. medium. Medium confidence in the validity. 1548 3. high. High confidence in the validity. 1550 4. numeric. The element content contains a number that conveys 1551 the confidence of the data. The semantics of this number 1552 outside the scope of this specification. 1554 5. unknown. The confidence rating value is not known. 1556 3.11. History Class 1558 The History class is a log of the significant events or actions 1559 performed by the involved parties during the course of handling the 1560 incident. 1562 The level of detail maintained in this log is left up to the 1563 discretion of those handling the incident. 1565 +------------------+ 1566 | History | 1567 +------------------+ 1568 | ENUM restriction |<>--{1..*}--[ HistoryItem ] 1569 | | 1570 +------------------+ 1572 Figure 20: The History Class 1574 The class that constitutes History is: 1576 HistoryItem 1577 One or many. Entry in the history log of significant events or 1578 actions performed by the involved parties. 1580 The History class has one attribute: 1582 restriction 1583 Optional. ENUM. This attribute is defined in Section 3.2. The 1584 default value is "default". 1586 3.11.1. HistoryItem Class 1588 The HistoryItem class is an entry in the History (Section 3.11) log 1589 that documents a particular action or event that occurred in the 1590 course of handling the incident. The details of the entry are a 1591 free-form description, but each can be categorized with the type 1592 attribute. 1594 +-------------------+ 1595 | HistoryItem | 1596 +-------------------+ 1597 | ENUM restriction |<>----------[ DateTime ] 1598 | ENUM action |<>--{0..1}--[ IncidentId ] 1599 | STRING ext-action |<>--{0..1}--[ Contact ] 1600 | |<>--{0..*}--[ Description ] 1601 | |<>--{0..*}--[ AdditionalData ] 1602 +-------------------+ 1604 Figure 21: HistoryItem Class 1606 The aggregate classes that constitute HistoryItem are: 1608 DateTime 1609 One. Timestamp of this entry in the history log (e.g., when the 1610 action described in the Description was taken). 1612 IncidentID 1613 Zero or One. In a history log created by multiple parties, the 1614 IncidentID provides a mechanism to specify which CSIRT created a 1615 particular entry and references this organization's incident 1616 tracking number. When a single organization is maintaining the 1617 log, this class can be ignored. 1619 Contact 1620 Zero or One. Provides contact information for the person that 1621 performed the action documented in this class. 1623 Description 1624 Zero or many. ML_STRING. A free-form textual description of the 1625 action or event. 1627 AdditionalData 1628 Zero or many. A mechanism by which to extend the data model. 1630 The HistoryItem class has five attributes: 1632 restriction 1633 Optional. ENUM. This attribute has been defined in Section 3.2. 1635 action 1636 Required. ENUM. Classifies a performed action or occurrence 1637 documented in this history log entry. As activity will likely 1638 have been instigated either through a previously conveyed 1639 expectation or internal investigation, this attribute is identical 1640 to the category attribute of the Expectation class. The 1641 difference is only one of tense. When an action is in this class, 1642 it has been completed. See Section 3.13. 1644 ext-action 1645 Optional. STRING. A means by which to extend the action 1646 attribute. See Section 5.1. 1648 indicator-uid 1649 Optional. STRING. A unique identifier for an Indicator. 1651 indicator-set-id 1652 Optional. STRING. The indicator set ID is used to group related 1653 indicators. 1655 3.12. EventData Class 1657 The EventData class describes a particular event of the incident for 1658 a given set of hosts or networks. This description includes the 1659 systems from which the activity originated and those targeted, an 1660 assessment of the techniques used by the intruder, the impact of the 1661 activity on the organization, and any forensic evidence discovered. 1663 +------------------+ 1664 | EventData | 1665 +------------------+ 1666 | ENUM restriction |<>--{0..*}--[ Description ] 1667 | |<>--{0..1}--[ DetectTime ] 1668 | |<>--{0..1}--[ StartTime ] 1669 | |<>--{0..1}--[ EndTime ] 1670 | |<>--{0..*}--[ Contact ] 1671 | |<>--{0..1}--[ Assessment ] 1672 | |<>--{0..*}--[ Method ] 1673 | |<>--{0..*}--[ Flow ] 1674 | |<>--{0..*}--[ Expectation ] 1675 | |<>--{0..1}--[ Record ] 1676 | |<>--{0..*}--[ EventData ] 1677 | |<>--{0..*}--[ AdditionalData ] 1678 +------------------+ 1680 Figure 22: The EventData Class 1682 The aggregate classes that constitute EventData are: 1684 Description 1685 Zero or more. ML_STRING. A free-form textual description of the 1686 event. 1688 DetectTime 1689 Zero or one. The time the event was detected. 1691 StartTime 1692 Zero or one. The time the event started. 1694 EndTime 1695 Zero or one. The time the event ended. 1697 Contact 1698 Zero or more. Contact information for the parties involved in the 1699 event. 1701 Assessment 1702 Zero or one. The impact of the event on the target and the 1703 actions taken. 1705 Method 1706 Zero or more. The technique used by the intruder in the event. 1708 Flow 1709 Zero or more. A description of the systems or networks involved. 1711 Expectation 1712 Zero or more. The expected action to be performed by the 1713 recipient for the described event. 1715 Record 1716 Zero or one. Supportive data (e.g., log files) that provides 1717 additional information about the event. 1719 EventData 1720 Zero or more. EventData instances contained within another 1721 EventData instance inherit the values of the parent(s); this 1722 recursive definition can be used to group common data pertaining 1723 to multiple events. When EventData elements are defined 1724 recursively, only the leaf instances (those EventData instances 1725 not containing other EventData instances) represent actual events. 1727 AdditionalData 1728 Zero or more. An extension mechanism for data not explicitly 1729 represented in the data model. 1731 At least one of the aggregate classes MUST be present in an instance 1732 of the EventData class. This is not enforced in the IODEF schema as 1733 there is no simple way to accomplish it. 1735 The EventData class has two attributes: 1737 restriction 1738 Optional. ENUM. This attribute is defined in Section 3.2. The 1739 default value is "default". 1741 indicator-set-id 1742 Optional. STRING. The indicator set ID is used to group related 1743 indicators. 1745 3.12.1. Relating the Incident and EventData Classes 1746 There is substantial overlap in the Incident and EventData classes. 1747 Nevertheless, the semantics of these classes are quite different. 1748 The Incident class provides summary information about the entire 1749 incident, while the EventData class provides information about the 1750 individual events comprising the incident. In the most common case, 1751 the EventData class will provide more specific information for the 1752 general description provided in the Incident class. However, it may 1753 also be possible that the overall summarized information about the 1754 incident conflicts with some individual information in an EventData 1755 class when there is a substantial composition of various events in 1756 the incident. In such a case, the interpretation of the more 1757 specific EventData MUST supersede the more generic information 1758 provided in IncidentData. 1760 3.12.2. Cardinality of EventData 1762 The EventData class can be thought of as a container for the 1763 properties of an event in an incident. These properties include: the 1764 hosts involved, impact of the incident activity on the hosts, 1765 forensic logs, etc. With an instance of the EventData class, hosts 1766 (i.e., System class) are grouped around these common properties. 1768 The recursive definition (or instance property inheritance) of the 1769 EventData class (the EventData class is aggregated into the EventData 1770 class) provides a way to related information without requiring the 1771 explicit use of unique attribute identifiers in the classes or 1772 duplicating information. Instead, the relative depth (nesting) of a 1773 class is used to group (relate) information. 1775 For example, an EventData class might be used to describe two 1776 machines involved in an incident. This description can be achieved 1777 using multiple instances of the Flow class. It happens that there is 1778 a common technical contact (i.e., Contact class) for these two 1779 machines, but the impact (i.e., Assessment class) on them is 1780 different. A depiction of the representation for this situation can 1781 be found in Figure 23. 1783 +------------------+ 1784 | EventData | 1785 +------------------+ 1786 | |<>----[ Contact ] 1787 | | 1788 | |<>----[ EventData ]<>----[ Flow ] 1789 | | [ ]<>----[ Assessment ] 1790 | | 1791 | |<>----[ EventData ]<>----[ Flow ] 1792 | | [ ]<>----[ Assessment ] 1793 +------------------+ 1794 Figure 23: Recursion in the EventData Class 1796 3.13. Expectation Class 1798 The Expectation class conveys to the recipient of the IODEF document 1799 the actions the sender is requesting. The scope of the requested 1800 action is limited to purview of the EventData class in which this 1801 class is aggregated. 1803 +-------------------+ 1804 | Expectation | 1805 +-------------------+ 1806 | ENUM restriction |<>--{0..*}--[ Description ] 1807 | ENUM severity |<>--{0..1}--[ StartTime ] 1808 | ENUM action |<>--{0..1}--[ EndTime ] 1809 | STRING ext-action |<>--{0..1}--[ Contact ] 1810 +-------------------+ 1812 Figure 24: The Expectation Class 1814 The aggregate classes that constitute Expectation are: 1816 Description 1817 Zero or many. ML_STRING. A free-form description of the desired 1818 action(s). 1820 StartTime 1821 Zero or one. The time at which the sender would like the action 1822 performed. A timestamp that is earlier than the ReportTime 1823 specified in the Incident class denotes that the sender would like 1824 the action performed as soon as possible. The absence of this 1825 element indicates no expections of when the recipient would like 1826 the action performed. 1828 EndTime 1829 Zero or one. The time by which the sensor expects the recipient 1830 to complete the action. If the recipient cannot complete the 1831 action before EndTime, the recipient MUST NOT carry out the 1832 action. Because of transit delays, clock drift, and so on, the 1833 sender MUST be prepared for the recipient to have carried out the 1834 action, even if it completes past EndTime. 1836 Contact 1837 Zero or one. The expected actor for the action. 1839 The Expectations class has six attributes: 1841 restriction 1842 Optional. ENUM. This attribute is defined in Section 3.2. The 1843 default value is "default". 1845 severity 1846 Optional. ENUM. Indicates the desired priority of the action. 1847 This attribute is an enumerated list with no default value, and 1848 the semantics of these relative measures are context dependant. 1850 1. low. Low priority 1852 2. medium. Medium priority 1854 3. high. High priority 1856 action 1857 Optional. ENUM. Classifies the type of action requested. This 1858 attribute is an enumerated list with a default value of "other". 1860 1. nothing. No action is requested. Do nothing with the 1861 information. 1863 2. contact-source-site. Contact the site(s) identified as the 1864 source of the activity. 1866 3. contact-target-site. Contact the site(s) identified as the 1867 target of the activity. 1869 4. contact-sender. Contact the originator of the document. 1871 5. investigate. Investigate the systems(s) listed in the event. 1873 6. block-host. Block traffic from the machine(s) listed as 1874 sources the event. 1876 7. block-network. Block traffic from the network(s) lists as 1877 sources in the event. 1879 8. block-port. Block the port listed as sources in the event. 1881 9. rate-limit-host. Rate-limit the traffic from the machine(s) 1882 listed as sources in the event. 1884 10. rate-limit-network. Rate-limit the traffic from the 1885 network(s) lists as sources in the event. 1887 11. rate-limit-port. Rate-limit the port(s) listed as sources in 1888 the event. 1890 12. remediate-other. Remediate the activity in a way other than 1891 by rate limiting or blocking. 1893 13. status-triage. Conveys receipts and the triaging of an 1894 incident. 1896 14. status-new-info. Conveys that new information was received 1897 for this incident. 1899 15. watch-and-report. Watch for the described activity and share 1900 if seen. 1902 16. other. Perform some custom action described in the 1903 Description class. 1905 17. ext-value. An escape value used to extend this attribute. 1906 See Section 5.1. 1908 ext-action 1909 Optional. STRING. A means by which to extend the action 1910 attribute. See Section 5.1. 1912 indicator-uid 1913 Optional. STRING. A unique identifier for an Indicator. 1915 indicator-set-id 1916 Optional. STRING. The indicator set ID is used to group related 1917 indicators. 1919 3.14. Flow Class 1921 The Flow class groups related the source and target hosts. 1923 +------------------+ 1924 | Flow | 1925 +------------------+ 1926 | |<>--{1..*}--[ System ] 1927 +------------------+ 1929 Figure 25: The Flow Class 1931 The aggregate class that constitutes Flow is: 1933 System 1934 One or More. A host or network involved in an event. 1936 The Flow System class has no attributes. 1938 3.15. System Class 1940 The System class describes a system or network involved in an event. 1941 The systems or networks represented by this class are categorized 1942 according to the role they played in the incident through the 1943 category attribute. The value of this category attribute dictates 1944 the semantics of the aggregated classes in the System class. If the 1945 category attribute has a value of "source", then the aggregated 1946 classes denote the machine and service from which the activity is 1947 originating. With a category attribute value of "target" or 1948 "intermediary", then the machine or service is the one targeted in 1949 the activity. A value of "sensor" dictates that this System was part 1950 of an instrumentation to monitor the network. 1952 +---------------------+ 1953 | System | 1954 +---------------------+ 1955 | ENUM restriction |<>----------[ Node ] 1956 | ENUM category |<>--{0..*}--[ Service ] 1957 | STRING ext-category |<>--{0..*}--[ OperatingSystem ] 1958 | STRING interface |<>--{0..*}--[ Counter ] 1959 | ENUM spoofed |<>--{0..*}--[ Description ] 1960 | |<>--{0..*}--[ AdditionalData ] 1961 +---------------------+ 1963 Figure 26: The System Class 1965 The aggregate classes that constitute System are: 1967 Node 1968 One. A host or network involved in the incident. 1970 Service 1971 Zero or more. A network service running on the system. 1973 OperatingSystem 1974 Zero or more. The operating system running on the system. 1976 Counter 1977 Zero or more. A counter with which to summarize properties of 1978 this host or network. 1980 Description 1981 Zero or more. ML_STRING. A free-form text description of the 1982 System. 1984 AdditionalData 1985 Zero or many. A mechanism by which to extend the data model. 1987 The System class has six attributes: 1989 restriction 1990 Optional. ENUM. This attribute is defined in Section 3.2. 1992 category 1993 Optional. ENUM. Classifies the role the host or network played 1994 in the incident. The possible values are: 1996 1. source. The System was the source of the event. 1998 2. target. The System was the target of the event. 2000 3. watchlist-source. The source of the event was on a watchlist. 2002 4. watchlist-target. The target of the event was on a watchlist. 2004 5. intermediate. The System was an intermediary in the event. 2006 6. sensor. The System was a sensor monitoring the event. 2008 7. infrastructure. The System was an infrastructure node of 2009 IODEF document exchange. 2011 8. ext-value. An escape value used to extend this attribute. 2012 See Section 5.1. 2014 ext-category 2015 Optional. STRING. A means by which to extend the category 2016 attribute. See Section 5.1. 2018 indicator-set-id 2019 Optional. STRING. The indicator set ID is used to group related 2020 indicators. 2022 interface 2023 Optional. STRING. Specifies the interface on which the event(s) 2024 on this System originated. If the Node class specifies a network 2025 rather than a host, this attribute has no meaning. 2027 spoofed 2028 Optional. ENUM. An indication of confidence in whether this 2029 System was the true target or attacking host. The permitted 2030 values for this attribute are shown below. The default value is 2031 "unknown". 2033 1. unknown. The accuracy of the category attribute value is 2034 unknown. 2036 2. yes. The category attribute value is probably incorrect. In 2037 the case of a source, the System is likely a decoy; with a 2038 target, the System was likely not the intended victim. 2040 3. no. The category attribute value is believed to be correct. 2042 3.16. Node Class 2044 The Node class names a system (e.g., PC, router) or network. 2046 This class was derived from the IDMEF [17]. 2048 +---------------+ 2049 | Node | 2050 +---------------+ 2051 | |<>--{0..*}--[ NodeName ] 2052 | |<>--{0..*}--[ DomainData ] 2053 | |<>--{0..*}--[ Address ] 2054 | |<>--{0..1}--[ Location ] 2055 | |<>--{0..1}--[ DateTime ] 2056 | |<>--{0..*}--[ NodeRole ] 2057 | |<>--{0..*}--[ Counter ] 2058 +---------------+ 2060 Figure 27: The Node Class 2062 The aggregate classes that constitute Node are: 2064 NodeName 2065 Zero or more. ML_STRING. The name of the Node (e.g., fully 2066 qualified domain name). This information MUST be provided if no 2067 Address information is given. 2069 DomainData 2070 Zero or more. The DomainData Class and Subclasses from RFC 5901. 2072 Address 2073 Zero or more. The hardware, network, or application address of 2074 the Node. If a NodeName is not provided, at least one Address 2075 MUST be specified. 2077 Location 2078 Zero or one. ML_STRING. A free-from description of the physical 2079 location of the equipment. 2081 DateTime 2082 Zero or one. A timestamp of when the resolution between the name 2083 and address was performed. This information MAY be provided if 2084 both an Address and NodeName are specified. 2086 NodeRole 2087 Zero or more. The intended purpose of the Node. 2089 Counter 2090 Zero or more. A counter with which to summarizes properties of 2091 this host or network. 2093 3.16.1. Counter Class 2095 The Counter class summarize multiple occurrences of some event, or 2096 conveys counts or rates on various features (e.g., packets, sessions, 2097 events). 2099 The value of the counter is the element content with its units 2100 represented in the type attribute. A rate for a given feature can be 2101 expressed by setting the duration attribute. The complete semantics 2102 are entirely context dependant based on the class in which the 2103 Counter is aggregated. 2105 +---------------------+ 2106 | Counter | 2107 +---------------------+ 2108 | REAL | 2109 | | 2110 | ENUM type | 2111 | STRING ext-type | 2112 | STRING meaning | 2113 | ENUM duration | 2114 | STRING ext-duration | 2115 +---------------------+ 2117 Figure 28: The Counter Class 2119 The Counter class has three attribute: 2121 type 2122 Required. ENUM. Specifies the units of the element content. 2124 1. byte. Count of bytes. 2126 2. packet. Count of packets. 2128 3. flow. Count of flow (e.g., NetFlow records). 2130 4. session. Count of sessions. 2132 5. alert. Count of notifications generated by another system 2133 (e.g., IDS or SIM). 2135 6. message. Count of messages (e.g., mail messages). 2137 7. event. Count of events. 2139 8. host. Count of hosts. 2141 9. site. Count of site. 2143 10. organization. Count of organizations. 2145 11. ext-value. An escape value used to extend this attribute. 2146 See Section 5.1. 2148 ext-type 2149 Optional. STRING. A means by which to extend the type attribute. 2150 See Section 5.1. 2152 duration 2153 Optional. ENUM. If present, the Counter class represents a rate 2154 rather than a count over the entire event. In that case, this 2155 attribute specifies the denominator of the rate (where the type 2156 attribute specified the nominator). The possible values of this 2157 attribute are defined in Section 3.10.2 2159 ext-duration 2160 Optional. STRING. A means by which to extend the duration 2161 attribute. See Section 5.1. 2163 3.16.2. Address Class 2165 The Address class represents a hardware (layer-2), network (layer-3), 2166 or application (layer-7) address. 2168 This class was derived from the IDMEF [17]. 2170 +---------------------+ 2171 | Address | 2172 +---------------------+ 2173 | ENUM category | 2174 | STRING ext-category | 2175 | STRING vlan-name | 2176 | INTEGER vlan-num | 2177 +---------------------+ 2178 Figure 29: The Address Class 2180 The Address class has five attributes: 2182 category 2183 Optional. ENUM. The type of address represented. The permitted 2184 values for this attribute are shown below. The default value is 2185 "ipv4-addr". 2187 1. asn. Autonomous System Number 2189 2. atm. Asynchronous Transfer Mode (ATM) address 2191 3. e-mail. Electronic mail address (RFC 822) 2193 4. ipv4-addr. IPv4 host address in dotted-decimal notation 2194 (a.b.c.d) 2196 5. ipv4-net. IPv4 network address in dotted-decimal notation, 2197 slash, significant bits (a.b.c.d/nn) 2199 6. ipv4-net-mask. IPv4 network address in dotted-decimal 2200 notation, slash, network mask in dotted-decimal notation 2201 (a.b.c.d/w.x.y.z) 2203 7. ipv6-addr. IPv6 host address 2205 8. ipv6-net. IPv6 network address, slash, significant bits 2207 9. ipv6-net-mask. IPv6 network address, slash, network mask 2209 10. mac. Media Access Control (MAC) address 2211 11. site-uri. A URL or URI for a site. 2213 12. ext-value. An escape value used to extend this attribute. 2214 See Section 5.1. 2216 ext-category 2217 Optional. STRING. A means by which to extend the category 2218 attribute. See Section 5.1. 2220 vlan-name 2221 Optional. STRING. The name of the Virtual LAN to which the 2222 address belongs. 2224 vlan-num 2225 Optional. STRING. The number of the Virtual LAN to which the 2226 address belongs. 2228 indicator-uid 2229 Optional. STRING. A unique identifier for an Indicator. 2231 3.16.3. NodeRole Class 2233 The NodeRole class describes the intended function performed by a 2234 particular host. 2236 +---------------------+ 2237 | NodeRole | 2238 +---------------------+ 2239 | ENUM category | 2240 | STRING ext-category | 2241 | ENUM lang | 2242 +---------------------+ 2244 Figure 30: The NodeRole Class 2246 The NodeRole class has three attributes: 2248 category 2249 Required. ENUM. Functionality provided by a node. 2251 1. client. Client computer 2253 2. client-enterprise. Client computer on the enterprise network 2255 3. client-partner. Client computer on network of a partner 2257 4. client-remote. Client computer remotely connected to the 2258 enterprise network 2260 5. client-kiosk. Client computer is serves as a kiosk 2262 6. client-mobile. Client is a mobile device 2264 7. server-internal. Server with internal services 2266 8. server-public. Server with public services 2268 9. www. WWW server 2270 10. mail. Mail server 2272 11. messaging. Messaging server (e.g., NNTP, IRC, IM) 2273 12. streaming. Streaming-media server 2275 13. voice. Voice server (e.g., SIP, H.323) 2277 14. file. File server (e.g., SMB, CVS, AFS) 2279 15. ftp. FTP server 2281 16. p2p. Peer-to-peer node 2283 17. name. Name server (e.g., DNS, WINS) 2285 18. directory. Directory server (e.g., LDAP, finger, whois) 2287 19. credential. Credential server (e.g., domain controller, 2288 Kerberos) 2290 20. print. Print server 2292 21. application. Application server 2294 22. database. Database server 2296 23. backup. Backup server 2298 24. dhcp. DHCP server 2300 25. infra. Infrastructure server (e.g., router, firewall, DHCP) 2302 26. infra-firewall. Firewall 2304 27. infra-router. Router 2306 28. infra-switch. Switch 2308 29. camera. Camera server 2310 30. proxy. Proxy server 2312 31. remote-access. Remote access server 2314 32. log. Logserver (e.g., syslog) 2316 33. virtualization. Server running virtual machines 2318 34. pos. Point-of-sale device 2320 35. scada. Supervisory control and data acquisition system 2321 36. scada-supervisory. Supervisory system for a SCADA 2323 37. ext-value. An escape value used to extend this attribute. 2324 See Section 5.1. 2326 ext-category 2327 Optional. STRING. A means by which to extend the category 2328 attribute. See Section 5.1. 2330 lang 2331 Optional. ENUM. A valid language code per RFC 4646 [7] 2332 constrained by the definition of "xs:language". The 2333 interpretation of this code is described in Section 6. 2335 3.17. Service Class 2337 The Service class describes a network service of a host or network. 2338 The service is identified by specific port or list of ports, along 2339 with the application listening on that port. 2341 When Service occurs as an aggregate class of a System that is a 2342 source, then this service is the one from which activity of interest 2343 is originating. Conversely, when Service occurs as an aggregate 2344 class of a System that is a target, then that service is the one to 2345 which activity of interest is directed. 2347 This class was derived from the IDMEF [17]. 2349 +---------------------+ 2350 | Service | 2351 +---------------------+ 2352 | INTEGER ip_protocol |<>--{0..1}--[ Port ] 2353 | |<>--{0..1}--[ Portlist ] 2354 | |<>--{0..1}--[ ProtoCode ] 2355 | |<>--{0..1}--[ ProtoType ] 2356 | |<>--{0..1}--[ ProtoField ] 2357 | |<>--{0..1}--[ Application ] 2358 +---------------------+ 2360 Figure 31: The Service Class 2362 The aggregate classes that constitute Service are: 2364 Port 2365 Zero or one. INTEGER. A port number. 2367 Portlist 2368 Zero or one. PORTLIST. A list of port numbers formatted 2369 according to Section 2.10. 2371 ProtoCode 2372 Zero or one. INTEGER. A layer-4 protocol-specific code field 2373 (e.g., ICMP code field). 2375 ProtoType 2376 Zero or one. INTEGER. A layer-4 protocol specific type field 2377 (e.g., ICMP type field). 2379 ProtoField 2380 Zero or one. INTEGER. A layer-4 protocol specific flag field 2381 (e.g., TCP flag field). 2383 Application 2384 Zero or one. The application bound to the specified Port or 2385 Portlist. 2387 Either a Port or Portlist class MUST be specified for a given 2388 instance of a Service class. 2390 When a given System classes with category="source" and another with 2391 category="target" are aggregated into a single Flow class, and each 2392 of these System classes has a Service and Portlist class, an implicit 2393 relationship between these Porlists exists. If N ports are listed 2394 for a System@category="source", and M ports are listed for 2395 System@category="target", the number of ports in N must be equal to 2396 M. Likewise, the ports MUST be listed in an identical sequence such 2397 that the n-th port in the source corresponds to the n-th port of the 2398 target. If N is greater than 1, a given instance of a a Flow class 2399 MUST only have a single instance of a System@category="source" and 2400 System@category="target". 2402 The Service class has three attributes: 2404 ip_protocol 2405 Required. INTEGER. The IANA protocol number. 2407 indicator-uid 2408 Optional. STRING. A unique identifier for an Indicator. 2410 indicator-set-id 2411 Optional. STRING. The indicator set ID is used to group related 2412 indicators. 2414 3.17.1. Application Class 2415 The Application class describes an application running on a System 2416 providing a Service. 2418 +--------------------+ 2419 | Application | 2420 +--------------------+ 2421 | STRING swid |<>--{0..1}--[ URL ] 2422 | STRING configid | 2423 | STRING vendor | 2424 | STRING family | 2425 | STRING name | 2426 | STRING version | 2427 | STRING patch | 2428 +--------------------+ 2430 Figure 32: The Application Class 2432 The aggregate class that constitute Application is: 2434 URL 2435 Zero or one. URL. A URL describing the application. 2437 The Application class has seven attributes: 2439 swid 2440 Optional. STRING. An identifier that can be used to reference 2441 this software, where the default value is "0". 2443 configid 2444 Optional. STRING. An identifier that can be used to reference a 2445 particular configuration of this software, where the default value 2446 is "0". 2448 vendor 2449 Optional. STRING. Vendor name of the software. 2451 family 2452 Optional. STRING. Family of the software. 2454 name 2455 Optional. STRING. Name of the software. 2457 version 2458 Optional. STRING. Version of the software. 2460 patch 2461 Optional. STRING. Patch or service pack level of the software. 2463 3.18. OperatingSystem Class 2465 The OperatingSystem class describes the operating system running on a 2466 System. The definition is identical to the Application class 2467 (Section 3.17.1). 2469 3.19. Record Class 2471 The Record class is a container class for log and audit data that 2472 provides supportive information about the incident. The source of 2473 this data will often be the output of monitoring tools. These logs 2474 substantiate the activity described in the document. 2476 +------------------+ 2477 | Record | 2478 +------------------+ 2479 | ENUM restriction |<>--{1..*}--[ RecordData ] 2480 +------------------+ 2482 Figure 33: Record Class 2484 The aggregate class that constitutes Record is: 2486 RecordData 2487 One or more. Log or audit data generated by a particular type of 2488 sensor. Separate instances of the RecordData class SHOULD be used 2489 for each sensor type. 2491 The Record class has one attribute: 2493 restriction 2494 Optional. ENUM. This attribute has been defined in Section 3.2. 2496 3.19.1. RecordData Class 2498 The RecordData class groups log or audit data from a given sensor 2499 (e.g., IDS, firewall log) and provides a way to annotate the output. 2501 +------------------+ 2502 | RecordData | 2503 +------------------+ 2504 | ENUM restriction |<>--{0..1}--[ DateTime ] 2505 | |<>--{0..*}--[ Description ] 2506 | |<>--{0..1}--[ Application ] 2507 | |<>--{0..*}--[ RecordPattern ] 2508 | |<>--{0..*}--[ RecordItem ] 2509 | |<>--{0..1}--[ HashInformation ] 2510 | |<>--{0..*}--[ WindowsRegistryKeysModified ] 2511 | |<>--{0..*}--[ AdditionalData ] 2512 +------------------+ 2514 Figure 34: The RecordData Class 2516 The aggregate classes that constitutes RecordData is: 2518 DateTime 2519 Zero or one. Timestamp of the RecordItem data. 2521 Description 2522 Zero or more. ML_STRING. Free-form textual description of the 2523 provided RecordItem data. At minimum, this description should 2524 convey the significance of the provided RecordItem data. 2526 Application 2527 Zero or one. Information about the sensor used to generate the 2528 RecordItem data. 2530 RecordPattern 2531 Zero or more. A search string to precisely find the relevant data 2532 in a RecordItem. 2534 RecordItem 2535 Zero or more. Log, audit, or forensic data. 2537 HashInformation 2538 Zero or one. The file name and hash of a file indicator. 2540 WindowsRegistryKeysModified 2541 Zero or more. The registry keys that were modified that are 2542 indicator(s). 2544 AdditionalData 2545 Zero or more. An extension mechanism for data not explicitly 2546 represented in the data model. 2548 The RecordData class has three attribute: 2550 restriction 2551 Optional. ENUM. This attribute has been defined in Section 3.2. 2553 indicator-uid 2554 Optional. STRING. A unique identifier for an Indicator. 2556 indicator-set-id 2557 Optional. STRING. The indicator set ID is used to group related 2558 indicators. 2560 3.19.2. RecordPattern Class 2562 The RecordPattern class describes where in the content of the 2563 RecordItem relevant information can be found. It provides a way to 2564 reference subsets of information, identified by a pattern, in a large 2565 log file, audit trail, or forensic data. 2567 +-----------------------+ 2568 | RecordPattern | 2569 +-----------------------+ 2570 | STRING | 2571 | | 2572 | ENUM type | 2573 | STRING ext-type | 2574 | INTEGER offset | 2575 | ENUM offsetunit | 2576 | STRING ext-offsetunit | 2577 | INTEGER instance | 2578 +-----------------------+ 2580 Figure 35: The RecordPattern Class 2582 The specific pattern to search with in the RecordItem is defined in 2583 the body of the element. It is further annotated by four attributes: 2585 type 2586 Required. ENUM. Describes the type of pattern being specified in 2587 the element content. The default is "regex". 2589 1. regex. regular expression, per Appendix F of [3]. 2591 2. binary. Binhex encoded binary pattern, per the HEXBIN data 2592 type. 2594 3. xpath. XML Path (XPath) [5] 2596 4. ext-value. An escape value used to extend this attribute. 2597 See Section 5.1. 2599 ext-type 2600 Optional. STRING. A means by which to extend the type attribute. 2601 See Section 5.1. 2603 offset 2604 Optional. INTEGER. Amount of units (determined by the offsetunit 2605 attribute) to seek into the RecordItem data before matching the 2606 pattern. 2608 offsetunit 2609 Optional. ENUM. Describes the units of the offset attribute. 2610 The default is "line". 2612 1. line. Offset is a count of lines. 2614 2. byte. Offset is a count of bytes. 2616 3. ext-value. An escape value used to extend this attribute. 2617 See Section 5.1. 2619 ext-offsetunit 2620 Optional. STRING. A means by which to extend the offsetunit 2621 attribute. See Section 5.1. 2623 instance 2624 Optional. INTEGER. Number of types to apply the specified 2625 pattern. 2627 3.19.3. RecordItem Class 2629 The RecordItem class provides a way to incorporate relevant logs, 2630 audit trails, or forensic data to support the conclusions made during 2631 the course of analyzing the incident. The class supports both the 2632 direct encapsulation of the data, as well as, provides primitives to 2633 reference data stored elsewhere. 2635 This class is identical to AdditionalData class (Section 3.6). 2637 3.20. RegistryKeyModified Class 2639 The Registry Key Modified class represents operating system registry 2640 keys that have been modified as part and may constitue an indicator 2641 of compromise. 2643 +-----------------------+ 2644 | RegistryKeyModified | 2645 +-----------------------+ 2646 | |<>----------[ Key ] 2647 +-----------------------+ 2649 Figure 36: The RegistryKeyModified Class 2651 The aggregate class that constitutes the Registry Key Modified class 2652 is: 2654 Key 2655 One. The Window Registry Key. 2657 3.20.1. Key Class 2659 The Key class shows name and value pairs representing an operating 2660 system registry key and its value. The key and value are encoded as 2661 in Microsoft .reg files. 2663 +--------------------------+ 2664 | Key | 2665 +--------------------------+ 2666 | ENUM regsitryaction |<>--{0..*}--[ KeyName ] 2667 | STRING ext-category |<>--{0..*}--[ Value ] 2668 | ENUM type | 2669 | STRING ext-type | 2670 | STRING indicator-uid | 2671 | STRING inidicator-set-id | 2672 +--------------------------+ 2674 Figure 37: The Registry Key Modified Class 2676 The aggregate classes that constitutes Key are: 2678 KeyName 2679 Zero or more. The name of the registry key. 2681 Value 2682 Zero or more. The value of the registry key. 2684 The Key class has six attributes: 2686 registryaction 2687 Optional. ENUM. The type of action. 2689 1. add-key. Registry key added. 2691 2. add-value. Value added to registry key. 2693 3. delete-key. Registry key deleted. 2695 4. delete-value. Value deleted from registry key. 2697 5. modify-key. Registry key modified. 2699 6. modify-value. Value modified for registry key. 2701 7. ext-value. External value. 2703 ext-category 2704 Optional. Extension category. 2706 type 2707 Optional. Type 2709 1. watchlist. Registry key information that is provided in a 2710 watchlist. 2712 2. ext-value. Registry key information from an external source. 2714 indicator-uid 2715 Optional. STRING. A unique identifier for an Indicator. 2717 indicator-set-id 2718 Optional. STRING. The indicator set ID is used to group relfated 2719 indicators. 2721 3.21. HashInformation Class 2723 This class are the hash and signature details that are needed for 2724 providing context for indicators. 2726 +--------------------------+ 2727 | HashInformation | 2728 +--------------------------+ 2729 | ENUM type |<>--{0..*}--[ FileName ] 2730 | STRING ext-category |<>--{0..*}--[ FileSize ] 2731 | BOOL valid |<>--{0..*}--[ ds:Signature ] 2732 | STRING indicator-uid |<>--{0..*}--[ ds:KeyInfo ] 2733 | STRING inidicator-set-id |<>--{0..*}--[ ds:Reference ] 2734 +--------------------------+ 2736 Figure 38: The Hash Sig Details Class 2738 The aggregate classes that constitutes HashInformation are: 2740 FileName 2741 Zero or more. ML_STRING. The name of the file. 2743 FileSize 2744 Zero or more. INTEGER. The size of the file in bytes. 2746 ds:Signature 2747 Zero or more. 2749 ds:KeyInfo 2750 Zero or more. 2752 ds:Reference 2753 Zero or more. The algorithm identification and value of a hash 2754 computed over the malware executable. This entire element is 2755 imported from [RFC3275]. Refer to RFC 5901. 2757 The HashInformation class has five attributes: 2759 type 2760 Optional. ENUM. The Hash Type. 2762 1. PKI-email-ds. PKI email digital signature. 2764 2. PKI-file-ds. PKI file digital signature. 2766 3. PKI-email-ds_watchlist. Watchlist of PKI email digital 2767 signatures. 2769 4. PKI-file-ds_watchlist. Watchlist of PKI file digital 2770 signatures. 2772 5. PGP-email-ds. PGP email digital signature. 2774 6. PGP-file-ds. PGP file digital signature. 2776 7. PGP-email-ds-watchlist. Watchlist of PGP email digital 2777 signatures. 2779 8. PGP-file-ds-watchlist. Watchlist of PGP file digital 2780 signatures 2782 9. file-hash. A file hash. 2784 10. email-hash. An email hash. 2786 11. file-hash-watchlist. Watchlist of file hashes 2788 12. email-hash-watchlist. Watchlist of email hashes 2790 13. ext-value. Extension value. 2792 indicator-uid 2793 Optional. STRING. A unique identifier for an Indicator. 2795 indicator-set-id 2796 Optional. STRING. The indicator set ID is used to group related 2797 indicators. 2799 4. Processing Considerations 2800 This section defines additional requirements on creating and parsing 2801 IODEF documents. 2803 4.1. Encoding 2805 Every IODEF document MUST begin with an XML declaration, and MUST 2806 specify the XML version used. If UTF-8 encoding is not used, the 2807 character encoding MUST also be explicitly specified. The IODEF 2808 conforms to all XML data encoding conventions and constraints. 2810 The XML declaration with no character encoding will read as follows: 2812 2814 When a character encoding is specified, the XML declaration will read 2815 like the following: 2817 2819 Where "charset" is the name of the character encoding as registered 2820 with the Internet Assigned Numbers Authority (IANA), see [9]. 2822 The following characters have special meaning in XML and MUST be 2823 escaped with their entity reference equivalent: "&", "<", ">", "\"" 2824 (double quotation mark), and "'" (apostrophe). These entity 2825 references are "&", "<", ">", """, and "'" 2826 respectively. 2828 4.2. IODEF Namespace 2830 The IODEF schema declares a namespace of 2831 "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each 2832 IODEF document MUST include a valid reference to the IODEF schema 2833 using the "xsi:schemaLocation" attribute. An example of such a 2834 declaration would look as follows: 2836 2926 A given extension attribute MUST NOT be set unless the corresponding 2927 extensible attribute has been set to "ext-value". 2929 5.2. Extending Classes 2931 The classes of the data model can be extended only through the use of 2932 the AdditionalData and RecordItem classes. These container classes, 2933 collectively referred to as the extensible classes, are implemented 2934 with the iodef:ExtensionType data type in the schema. They provide 2935 the ability to have new atomic or XML-encoded data elements in all of 2936 the top-level classes of the Incident class and a few of the more 2937 complicated subordinate classes. As there are multiple instances of 2938 the extensible classes in the data model, there is discretion on 2939 where to add a new data element. It is RECOMMENDED that the 2940 extension be placed in the most closely related class to the new 2941 information. 2943 Extensions using the atomic data types (i.e., all values of the dtype 2944 attributes other than "xml") MUST: 2946 1. Set the element content of extensible class to the desired value, 2947 and 2949 2. Set the dtype attribute to correspond to the data type of the 2950 element content. 2952 The following guidelines exist for extensions using XML: 2954 1. The element content of the extensible class MUST be set to the 2955 desired value and the dtype attribute MUST be set to "xml". 2957 2. The extension schema MUST declare a separate namespace. It is 2958 RECOMMENDED that these extensions have the prefix "iodef-". This 2959 recommendation makes readability of the document easier by 2960 allowing the reader to infer which namespaces relate to IODEF by 2961 inspection. 2963 3. It is RECOMMENDED that extension schemas follow the naming 2964 convention of the IODEF data model. This makes reading an 2965 extended IODEF document look like any other IODEF document. The 2966 names of all elements are capitalized. For elements with 2967 composed names, a capital letter is used for each word. 2968 Attribute names are lower case. Attributes with composed names 2969 are seperated by a hyphen. 2971 4. Parsers that encounter an unrecognized element in a namespace 2972 that they do support MUST reject the document as a syntax error. 2974 5. There are security and performance implications in requiring 2975 implementations to dynamically download schemas at run time. 2976 Thus, implementations SHOULD NOT download schemas at runtime, 2977 unless implementations take appropriate precautions and are 2978 prepared for potentially significant network, processing, and 2979 time-out demands. 2981 6. Some users of the IODEF may have private schema definitions that 2982 might not be available on the Internet. In this situation, if a 2983 IODEF document leaks out of the private use space, references to 2984 some of those document schemas may not be resolvable. This has 2985 two implications. First, references to private schemas may never 2986 resolve. As such, in addition to the suggestion that 2987 implementations do not download schemas at runtime mentioned 2988 above, recipients MUST be prepared for a schema definition in an 2989 IODEF document never to resolve. 2991 The following schema and XML document excerpt provide a template for 2992 an extension schema and its use in the IODEF document. 2994 This example schema defines a namespace of "iodef-extension1" and a 2995 single element named "newdata". 2997 3001 attributeFormDefault="unqualified" 3002 elementFormDefault="qualified"> 3003 3007 3008 3010 The following XML excerpt demonstrates the use of the above schema as 3011 an extension to the IODEF. 3013 3020 3021 ... 3022 3023 3024 Field that could not be represented elsewhere 3025 3026 3027 3079 3081 3085 3086 189493 3087 2001-09-13T23:19:24+00:00 3088 Host sending out Code Red probes 3089 3090 3091 3092 3093 3094 Example.com CSIRT 3095 example-com 3096 contact@csirt.example.com 3097 3098 3099 3100 3101 3102
192.0.2.200
3103 57 3104 3105 3106 3107 3108
192.0.2.16/28
3109 3110 3111 80 3112 3113 3114 3115 3116 3117 3118 3119 2001-09-13T18:11:21+02:00 3120 Web-server logs 3121 3122 192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida? 3123 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 3124 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 3125 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 3126 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 3127 3128 3129 3130 http://mylogs.example.com/logs/httpd_access 3131 3133 3134 3135 3136 3138 3139 2001-09-14T08:19:01+00:00 3140 Notification sent to 3141 constituency-contact@192.0.2.200 3142 3143 3144 3145 3147 7.2. Reconnaissance 3149 An example of a CSIRT reporting a scanning activity. 3151 3152 3154 3158 3159 59334 3160 2006-08-02T05:54:02-05:00 3161 3162 3163 3164 3165 3166 3167 nmap 3168 http://nmap.toolsite.example.com 3169 3170 3171 3173 3174 CSIRT for example.com 3175 contact@csirt.example.com 3176 +1 412 555 12345 3177 3179 3180 Joe Smith 3181 smith@csirt.example.com 3182 3183 3184 3185 3191 3192 3193 3194
192.0.2.200
3195 3196 3197 60524,60526,60527,60531 3198 3199 3200 3201 3202
192.0.2.201
3203 3204 3205 137-139,445 3206 3207 3208 3209 3211 3212 3213 3214
192.0.2.240
3215 3216 3217 3218 3219
192.0.2.64/28
3220 3221 3222 445 3223 3224 3225 3227 3228 3229 3231 7.3. Bot-Net Reporting 3233 An example of a CSIRT reporting a bot-network. 3235 3236 3238 3242 3243 908711 3244 2006-06-08T05:44:53-05:00 3245 Large bot-net 3246 3247 3248 3249 3250 3251 3252 GT Bot 3253 3254 3256 3257 CA-2003-22 3258 http://www.cert.org/advisories/CA-2003-22.html 3259 Root compromise via this IE vulnerability to 3260 install the GT Bot 3261 3262 3263 3265 3266 Joe Smith 3267 jsmith@csirt.example.com 3268 3269 3270 These hosts are compromised and acting as bots 3271 communicating with irc.example.com. 3273 3274 3276 3277 3278
192.0.2.1
3279 3280 10000 3281 bot 3282 3283 3284 3285 3286
192.0.2.3
3287 3288 250000 3289 bot 3290 3291 3292 3293 3294 irc.example.com 3295
192.0.2.20
3296 2006-06-08T01:01:03-05:00 3297 3298 3299 IRC server on #give-me-cmd channel 3300 3301 3302 3303 3304 3305 3306 Confirm the source and take machines off-line and 3307 remediate 3308 3309 3310 3311 3312 3314 7.4. Watch List 3316 An example of a CSIRT conveying a watch-list. 3318 3319 3320 3323 3327 3328 908711 3329 2006-08-01T00:00:00-05:00 3330 3331 Watch-list of known bad IPs or networks 3332 3333 3334 3335 3336 3337 3338 CSIRT for example.com 3339 contact@csirt.example.com 3340 3341 3343 3344 3345 3346 3347
192.0.2.53
3348 3349 Source of numerous attacks 3350 3351 3352 3354 3355 3356 3357 3358 3359 3360
192.0.2.16/28
3362 3363 3364 Source of heavy scanning over past 1-month 3365 3366 3367 3368 3369 3370 3371
192.0.2.241
3372 3373 C2 IRC server 3374 3375 3376 3378 3379 3380 3381 3383 8. The IODEF Schema 3385 3392 3395 3396 3397 Incident Object Description Exchange Format v2.0, RFC5070-bis 3398 3399 3401 3407 3438 3443 3444 3445 3446 3448 3449 3451 3453 3456 3457 3458 3463 3464 3465 3466 3467 3468 3475 3476 3477 3479 3481 3483 3485 3487 3488 3490 3492 3494 3496 3498 3500 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3516 3518 3520 3521 3523 3524 3525 3530 3531 3532 3533 3534 3536 3538 3541 3542 3543 3545 3550 3551 3552 3553 3555 3556 3558 3559 3561 3566 3567 3568 3569 3571 3572 3574 3575 3576 3581 3582 3583 3584 3586 3588 3589 3591 3592 3593 3598 3599 3604 3605 3606 3607 3609 3611 3613 3615 3617 3619 3621 3623 3625 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3642 3643 3644 3645 3646 3647 3649 3650 3651 3652 3654 3656 3657 3658 3661 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3683 3684 3685 3686 3688 3689 3690 3691 3692 3694 3695 3696 3698 3699 3700 3701 3703 3704 3705 3706 3708 3709 3710 3712 3717 3719 3721 3723 3725 3727 3729 3730 3731 3732 3733 3734 3739 3740 3741 3742 3744 3745 3748 3749 3750 3751 3752 3753 3754 3756 3758 3760 3762 3763 3765 3767 3769 3772 3774 3778 3780 3781 3782 3787 3788 3789 3790 3792 3795 3797 3799 3800 3803 3805 3807 3809 3811 3813 3816 3818 3819 3820 3825 3826 3827 3828 3829 3830 3831 3832 3834 3835 3837 3838 3839 3845 3846 3847 3848 3850 3852 3854 3855 3862 3864 3867 3869 3870 3872 3873 3875 3876 3878 3883 3884 3885 3886 3887 3888 3889 3890 3891 3893 3894 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3907 3911 3913 3918 3920 3921 3922 3923 3924 3925 3926 3928 3929 3930 3931 3932 3933 3934 3935 3936 3938 3939 3941 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3961 3962 3963 3964 3965 3966 3967 3968 3969 3971 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3984 3986 3988 3990 3991 3992 3993 3994 3995 3996 3997 3999 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4025 4026 4027 4028 4030 4032 4034 4036 4039 4041 4043 4045 4047 4049 4051 4053 4054 4056 4057 4059 4060 4061 4066 4071 4072 4073 4074 4076 4077 4078 4079 4084 4085 4086 4087 4088 4090 4092 4094 4096 4098 4099 4101 4103 4104 4105 4106 4107 4108 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4121 4123 4125 4127 4128 4129 4130 4131 4132 4133 4134 4136 4137 4138 4143 4144 4145 4146 4147 4149 4151 4154 4156 4165 4166 4168 4170 4172 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4202 4204 4206 4209 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4266 4269 4270 4271 4272 4273 4278 4279 4280 4281 4282 4284 4286 4287 4289 4291 4293 4295 4298 4299 4301 4303 4305 4307 4309 4310 4312 4315 4317 4321 4323 4324 4325 4326 4327 4329 4330 4331 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4359 4361 4363 4365 4366 4367 4368 4370 4375 4380 4381 4382 4383 4384 4386 4388 4389 4391 4393 4398 4399 4400 4401 4403 4405 4407 4409 4412 4414 4415 4416 4417 4418 4419 4420 4421 4422 4424 4425 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4461 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4512 4513 4514 4516 4521 4522 4523 4524 4526 4527 4529 4530 4531 4532 4533 4534 4536 4538 4540 4542 4545 4547 4549 4551 4552 4558 4561 4563 4564 4566 4568 4570 4574 4576 4577 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4595 4597 4599 4600 4601 4602 4603 4604 4605 4606 4607 4609 4611 4612 4613 4614 4615 4618 4623 4624 4625 4626 4627 4628 4630 4631 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4649 4652 4654 4655 4656 4660 4662 4663 4664 4670 4678 4679 4680 4682 4684 4690 4692 4694 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4716 4717 4718 4719 4720 4722 4724 4725 4727 4729 4731 4733 4735 4740 4741 4742 4744 4745 4747 4749 4751 4753 4755 4760 4763 4765 4767 4768 4770 4773 4778 4780 4782 4787 4788 4789 4790 4791 4792 4793 4794 4795 4797 4798 4799 4800 4801 4802 4804 4805 4807 4809 4812 4814 4816 4817 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4920 9. Security Considerations 4922 The IODEF data model itself does not directly introduce security 4923 issues. Rather, it simply defines a representation for incident 4924 information. As the data encoded by the IODEF might be considered 4925 privacy sensitive by the parties exchanging the information or by 4926 those described by it, care needs to be taken in ensuring the 4927 appropriate disclosure during both document exchange and subsequent 4928 processing. The former must be handled by a messaging format, but 4929 the latter risk must be addressed by the systems that process, store, 4930 and archive IODEF documents and information derived from them. 4932 The contents of an IODEF document may include a request for action or 4933 an IODEF parser may independently have logic to take certain actions 4934 based on information that it finds. For this reason, care must be 4935 taken by the parser to properly authenticate the recipient of the 4936 document and ascribe an appropriate confidence to the data prior to 4937 action. 4939 The underlying messaging format and protocol used to exchange 4940 instances of the IODEF MUST provide appropriate guarantees of 4941 confidentiality, integrity, and authenticity. The use of a 4942 standardized security protocol is encouraged. The Real-time Inter- 4943 network Defense (RID) protocol [18] and its associated transport 4944 binding IODEF/RID over SOAP [19] provide such security. 4946 In order to suggest data processing and handling guidelines of the 4947 encoded information, the IODEF allows a document sender to convey a 4948 privacy policy using the restriction attribute. The various 4949 instances of this attribute allow different data elements of the 4950 document to be covered by dissimilar policies. While flexible, it 4951 must be stressed that this approach only serves as a guideline from 4952 the sender, as the recipient is free to ignore it. The issue of 4953 enforcement is not a technical problem. 4955 10. IANA Considerations 4957 This document uses URNs to describe an XML namespace and schema 4958 conforming to a registry mechanism described in [15] 4960 Registration for the IODEF namespace: 4962 o URI: urn:ietf:params:xml:ns:iodef-2.0 4964 o Registrant Contact: See the first author of the "Author's Address" 4965 section of this document. 4967 o XML: None. Namespace URIs do not represent an XML specification. 4969 Registration for the IODEF XML schema: 4971 o URI: urn:ietf:params:xml:schema:iodef-2.0 4973 o Registrant Contact: See the first author of the "Author's Address" 4974 section of this document. 4976 o XML: See the "IODEF Schema" in Section 8 of this document. 4978 11. Acknowledgments 4980 The following groups and individuals, listed alphabetically, 4981 contributed substantially to this document and should be recognized 4982 for their efforts. 4984 o Patrick Cain, Cooper-Cain Group, Inc. 4986 o The eCSIRT.net Project 4988 o The Incident Object Description and Exchange Format Working-Group 4989 of the TERENA task-force (TF-CSIRT) 4991 o Glenn Mansfield Keeni, Cyber Solutions, Inc. 4993 o Hiroyuki Kido, NARA Institute of Science and Technology 4995 o Kathleen Moriarty, EMC Corporation 4997 o Brian Trammell, ETH Zurich 4999 o Jan Meijer, SURFnet bv 5001 o Yuri Demchenko, University of Amsterdam 5003 12. References 5005 12.1. Normative References 5007 [1] World Wide Web Consortium, "Extensible Markup Language 5008 (XML) 1.0 (Second Edition)", W3C Recommendation , October 5009 2000, . 5011 [2] World Wide Web Consortium, "XML XML Schema Part 1: 5012 Structures Second Edition", W3C Recommendation , October 5013 2004, . 5015 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes 5016 Second Edition", W3C Recommendation , October 2004, 5017 . 5019 [4] World Wide Web Consortium, "Namespaces in XML", W3C 5020 Recommendation , January 1999, 5021 . 5023 [5] World Wide Web Consortium, "XML Path Language (XPath) 5024 2.0", W3C Candidate Recommendation , June 2006, 5025 . 5027 [6] Bradner, S., "Key words for use in RFCs to Indicate 5028 Requirement Levels", RFC 2119, March 1997. 5030 [7] Philips, A. and M. Davis, "Tags for Identifying of 5031 Languages", RFC 4646, September 2006. 5033 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 5034 Resource Identifiers (URI): Generic Syntax", RFC 3986, 5035 January 2005`. 5037 [9] Freed, N. and J. Postel, "IANA Charset Registration 5038 Procedures", BCP 2978, October 2000. 5040 [10] Sciberras, A., "Schema for User Applications", RFC 4519, 5041 June 2006. 5043 [11] Resnick, P., "Internet Message Format", RFC 2822, April 5044 2001. 5046 [12] Klyne, G. and C. Newman, "Date and Time on the Internet: 5047 Timestamps", RFC 3339, July 2002. 5049 [13] International Organization for Standardization, 5050 "International Standard: Data elements and interchange 5051 formats - Information interchange - Representation of 5052 dates and times", ISO 8601, Second Edition, December 2000. 5054 [14] International Organization for Standardization, 5055 "International Standard: Codes for the representation of 5056 currencies and funds, ISO 4217:2001", ISO 4217:2001, 5057 August 2001. 5059 [15] Mealling, M., "The IETF XML Registry", RFC 3688, January 5060 2004. 5062 12.2. Informative References 5064 [16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements 5065 for the Format for Incident Information Exchange (FINE)", 5066 Work in Progress, June 2006. 5068 [17] Debar, H., Curry, D., Debar, H., and B. Feinstein, 5069 "Intrusion Detection Message Exchange Format", RFC 4765, 5070 March 2007. 5072 [18] Moriarty, K., "Real-time Inter-network Defense", Work in 5073 Progress, April 2007. 5075 [19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work 5076 in Progress, April 2007. 5078 [20] Shafranovich, Y., "Common Format and MIME Type for Comma- 5079 Separated Values (CSV) File ", RFC 4180, October 2005. 5081 Authors' Addresses 5083 Roman Danyliw 5084 CERT - Software Engineering Institute 5085 Pittsburgh, PA 5086 USA 5088 EMail: rdd@cert.org 5090 Paul Stoecker 5091 RSA 5092 Reston, VA 5093 USA 5095 EMail: paul.stoecker@rsa.com