idnits 2.17.1 draft-stoecker-danyliw-rfc5070bis-00.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 17 instances of too long lines in the document, the longest one being 27 characters in excess of 72. == 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 date (February 17, 2013) is 4085 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0-9' on line 3472 -- Looks like a reference, but probably isn't: '0-4' on line 3472 -- Looks like a reference, but probably isn't: '0-5' on line 3472 ** Obsolete normative reference: RFC 4646 (ref. '7') (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 2822 (ref. '11') (Obsoleted by RFC 5322) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extended Incident Handling Working R. Danyliw 3 Group CERT 4 Internet-Draft P. Stoecker 5 Obsoletes: 5070 (if approved) RSA 6 Intended status: Informational February 17, 2013 7 Expires: August 21, 2013 9 The Incident Object Description Exchange Format 10 draft-stoecker-danyliw-rfc5070bis-00 12 Abstract 14 The Incident Object Description Exchange Format (IODEF) defines a 15 data representation that provides a framework for sharing information 16 commonly exchanged by Computer Security Incident Response Teams 17 (CSIRTs) about computer security incidents. This document describes 18 the information model for the IODEF and provides an associated data 19 model specified with XML Schema. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 21, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Changes from 5070 . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. About the IODEF Data Model . . . . . . . . . . . . . . . . 6 60 1.5. About the IODEF Implementation . . . . . . . . . . . . . . 7 61 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3. Characters and Strings . . . . . . . . . . . . . . . . . . 8 65 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . . 8 66 2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 8 68 2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . . 8 69 2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 9 70 2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 9 71 2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . . 9 73 2.12. Person or Organization . . . . . . . . . . . . . . . . . . 9 74 2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 10 75 2.14. Email String . . . . . . . . . . . . . . . . . . . . . . . 10 76 2.15. Uniform Resource Locator strings . . . . . . . . . . . . . 10 77 3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . . 10 78 3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . . 10 79 3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . . 11 80 3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . . 14 81 3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 15 82 3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 16 83 3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . . 16 84 3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 19 85 3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . . 21 86 3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22 87 3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 23 88 3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23 89 3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . . 24 90 3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24 91 3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24 92 3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . . 24 93 3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . . 25 94 3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . . 25 95 3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . . 25 96 3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 26 98 3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . . 27 99 3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . . 28 100 3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . . 30 101 3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . . 32 102 3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . . 33 103 3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 34 104 3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . . 34 105 3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 36 106 3.12.1. Relating the Incident and EventData Classes . . . . . 38 107 3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 38 108 3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 39 109 3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . . 41 110 3.15. System Class . . . . . . . . . . . . . . . . . . . . . . . 42 111 3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . . 44 112 3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . . 45 113 3.16.2. Address Class . . . . . . . . . . . . . . . . . . . . 47 114 3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . . 48 115 3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 50 116 3.17.1. Application Class . . . . . . . . . . . . . . . . . . 51 117 3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 53 118 3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . . 53 119 3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . . 53 120 3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . . 55 121 3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . . 56 122 4. Processing Considerations . . . . . . . . . . . . . . . . . . 56 123 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 57 124 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 57 125 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 57 126 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 58 127 5.1. Extending the Enumerated Values of Attributes . . . . . . 59 128 5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 59 129 6. Internationalization Issues . . . . . . . . . . . . . . . . . 61 130 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 131 7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 132 7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 63 133 7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 65 134 7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . . 67 135 8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . . 68 136 9. Security Considerations . . . . . . . . . . . . . . . . . . . 94 137 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 138 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 139 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 96 140 12.1. Normative References . . . . . . . . . . . . . . . . . . . 96 141 12.2. Informative References . . . . . . . . . . . . . . . . . . 97 143 1. Introduction 145 Organizations require help from other parties to mitigate malicious 146 activity targeting their network and to gain insight into potential 147 threats. This coordination might entail working with an ISP to 148 filter attack traffic, contacting a remote site to take down a bot- 149 network, or sharing watch-lists of known malicious IP addresses in a 150 consortium. 152 The Incident Object Description Exchange Format (IODEF) is a format 153 for representing computer security information commonly exchanged 154 between Computer Security Incident Response Teams (CSIRTs). It 155 provides an XML representation for conveying incident information 156 across administrative domains between parties that have an 157 operational responsibility of remediation or a watch-and-warning over 158 a defined constituency. The data model encodes information about 159 hosts, networks, and the services running on these systems; attack 160 methodology and associated forensic evidence; impact of the activity; 161 and limited approaches for documenting workflow. 163 The overriding purpose of the IODEF is to enhance the operational 164 capabilities of CSIRTs. Community adoption of the IODEF provides an 165 improved ability to resolve incidents and convey situational 166 awareness by simplifying collaboration and data sharing. This 167 structured format provided by the IODEF allows for: 169 o increased automation in processing of incident data, since the 170 resources of security analysts to parse free-form textual 171 documents will be reduced; 173 o decreased effort in normalizing similar data (even when highly 174 structured) from different sources; and 176 o a common format on which to build interoperable tools for incident 177 handling and subsequent analysis, specifically when data comes 178 from multiple constituencies. 180 Coordinating with other CSIRTs is not strictly a technical problem. 181 There are numerous procedural, trust, and legal considerations that 182 might prevent an organization from sharing information. The IODEF 183 does not attempt to address them. However, operational 184 implementations of the IODEF will need to consider this broader 185 context. 187 Sections 3 and 8 specify the IODEF data model with text and an XML 188 schema. The types used by the data model are covered in Section 2. 189 Processing considerations, the handling of extensions, and 190 internationalization issues related to the data model are covered in 191 Sections 4, 5, and 6, respectively. Examples are listed in Section 192 7. Section 1 provides the background for the IODEF, and Section 9 193 documents the security considerations. 195 1.1. Changes from 5070 197 o This document contains changes with respect to its predecessor 198 RFC5070 200 o All of the Errata that has been submitted at RFC5070 Errata has 201 been implemented with the exception of #17 which instead of 202 changing the UML, the schema waschanged. 204 o Addition of xmlns:ds and import of same namespace. This is to use 205 the digital signature hash inclusion of a file by referencing the 206 existing standard as was done in RFC5901, RFC3275 is the 207 reference, see RFC5901 section 5.9.5.2"> 209 o New indicator uid and set id values in the schema. The purpose of 210 the proposed changes is to include commonly shared indicators in 211 the base IODEF schema. This class will contain indicators from 212 the list below that are not represented elsewhere in the schema. 213 IODEF extensions or embedded schemas via the SCI classes will be 214 required to include additional data types. A table could be 215 maintained through IANA to extend or change this class in between 216 IODEF revisions. 218 o RFC5901 provides a method to include an entire email, the 219 following included indicators are ones commonly used when you do 220 not need the entire email 222 o The following are in the Service class: Email Address, Email 223 Subject, and X-Mailer 225 o The following are in the Record class: File Name, File Hash 226 (5.9.5.2 - using ds:reference), and WindowsRegistryKey (using 227 method from RFC5901 229 o The following are now in the Node class as a proposed location: 230 URL 232 o HTTPUserAgent is included as a SoftwareType - HTTP User Agent 233 String 235 o The following are already represented elsewhere in the schema 236 (Node): IP address, Network CIDR / ASN, Host Name, and Domain Name 237 (additional options for RFC5901 were not included in this revision 238 - can include point-in-time dig info) 240 1.2. Terminology 242 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 243 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 244 document are to be interpreted as described in RFC2119 [6]. 246 Definitions for some of the common computer security-related 247 terminology used in this document can be found in Section 2 of [16]. 249 1.3. Notations 251 The normative IODEF data model is specified with the text in Section 252 3 and the XML schema in Section 8. To help in the understanding of 253 the data elements, Section 3 also depicts the underlying information 254 model using Unified Modeling Language (UML). This abstract 255 presentation of the IODEF is not normative. 257 For clarity in this document, the term "XML document" will be used 258 when referring generically to any instance of an XML document. The 259 term "IODEF document" will be used to refer to specific elements and 260 attributes of the IODEF schema. The terms "class" and "element" will 261 be used interchangeably to reference either the corresponding data 262 element in the information or data models, respectively. 264 1.4. About the IODEF Data Model 266 The IODEF data model is a data representation that provides a 267 framework for sharing information commonly exchanged by CSIRTs about 268 computer security incidents. A number of considerations were made in 269 the design of the data model. 271 o The data model serves as a transport format. Therefore, its 272 specific representation is not the optimal representation for on- 273 disk storage, long-term archiving, or in-memory processing. 275 o As there is no precise widely agreed upon definition for an 276 incident, the data model does not attempt to dictate one through 277 its implementation. Rather, a broad understanding is assumed in 278 the IODEF that is flexible enough to encompass most operators. 280 o Describing an incident for all definitions would require an 281 extremely complex data model. Therefore, the IODEF only intends 282 to be a framework to convey commonly exchanged incident 283 information. It ensures that there are ample mechanisms for 284 extensibility to support organization-specific information, and 285 techniques to reference information kept outside of the explicit 286 data model. 288 o The domain of security analysis is not fully standardized and must 289 rely on free-form textual descriptions. The IODEF attempts to 290 strike a balance between supporting this free-form content, while 291 still allowing automated processing of incident information. 293 o The IODEF is only one of several security relevant data 294 representations being standardized. Attempts were made to ensure 295 they were complimentary. The data model of the Intrusion 296 Detection Message Exchange Format [17] influenced the design of 297 the IODEF. 299 Further discussion of the desirable properties for the IODEF can be 300 found in the Requirements for the Format for Incident Information 301 Exchange (FINE) [16]. 303 1.5. About the IODEF Implementation 305 The IODEF implementation is specified as an Extensible Markup 306 Language (XML) [1] Schema [2] in Section 8. 308 Implementing the IODEF in XML provides numerous advantages. Its 309 extensibility makes it ideal for specifying a data encoding framework 310 that supports various character encodings. Likewise, the abundance 311 of related technologies (e.g., XSL, XPath, XML-Signature) makes for 312 simplified manipulation. However, XML is fundamentally a text 313 representation, which makes it inherently inefficient when binary 314 data must be embedded or large volumes of data must be exchanged. 316 2. IODEF Data Types 318 The various data elements of the IODEF data model are typed. This 319 section discusses these data types. When possible, native Schema 320 data types were adopted, but for more complicated formats, regular 321 expressions (see Appendix F of [3]) or external standards were used. 323 2.1. Integers 325 An integer is represented by the INTEGER data type. Integer data 326 MUST be encoded in Base 10. 328 The INTEGER data type is implemented as an "xs:integer" [3] in the 329 schema. 331 2.2. Real Numbers 333 Real (floating-point) attributes are represented by the REAL data 334 type. Real data MUST be encoded in Base 10. 336 The REAL data type is implemented as an "xs:float" [3] in the schema. 338 2.3. Characters and Strings 340 A single character is represented by the CHARACTER data type. A 341 character string is represented by the STRING data type. Special 342 characters must be encoded using entity references. See Section 4.1. 344 The CHARACTER and STRING data types are implement as an "xs:string" 345 [3] in the schema. 347 2.4. Multilingual Strings 349 STRING data that represents multi-character attributes in a language 350 different than the default encoding of the document is of the 351 ML_STRING data type. 353 The ML_STRING data type is implemented as an "iodef:MLStringType" in 354 the schema. 356 2.5. Bytes 358 A binary octet is represented by the BYTE data type. A sequence of 359 binary octets is represented by the BYTE[] data type. These octets 360 are encoded using base64. 362 The BYTE data type is implemented as an "xs:base64Binary" [3] in the 363 schema. 365 2.6. Hexadecimal Bytes 367 A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. 368 This octet is encoded as a character tuple consisting of two 369 hexadecimal digits. 371 The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the 372 schema. 374 2.7. Enumerated Types 376 Enumerated types are represented by the ENUM data type, and consist 377 of an ordered list of acceptable values. Each value has a 378 representative keyword. Within the IODEF schema, the enumerated type 379 keywords are used as attribute values. 381 The ENUM data type is implemented as a series of "xs:NMTOKEN" in the 382 schema. 384 2.8. Date-Time Strings 386 Date-time strings are represented by the DATETIME data type. Each 387 date-time string identifies a particular instant in time; ranges are 388 not supported. 390 Date-time strings are formatted according to a subset of ISO 8601: 391 2000 [13] documented in RFC 3339 [12]. 393 The DATETIME data type is implemented as an "xs:dateTime" [3] in the 394 schema. 396 2.9. Timezone String 398 A timezone offset from UTC is represented by the TIMEZONE data type. 399 It is formatted according to the following regular expression: 400 "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". 402 The TIMEZONE data type is implemented as an "xs:string" with a 403 regular expression constraint in the schema. This regular expression 404 is identical to the timezone representation implemented in an "xs: 405 dateTime". 407 2.10. Port Lists 409 A list of network ports are represented by the PORTLIST data type. A 410 PORTLIST consists of a comma-separated list of numbers and ranges 411 (N-M means ports N through M, inclusive). It is formatted according 412 to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". 413 For example, "2,5-15,30,32,40-50,55-60". 415 The PORTLIST data type is implemented as an "xs:string" with a 416 regular expression constraint in the schema. 418 2.11. Postal Address 420 A postal address is represented by the POSTAL data type. This data 421 type is an ML_STRING whose format is documented in Section 2.23 of 422 RFC 4519 [10]. It defines a postal address as a free-form multi-line 423 string separated by the "$" character. 425 The POSTAL data type is implemented as an "xs:string" in the schema. 427 2.12. Person or Organization 429 The name of an individual or organization is represented by the NAME 430 data type. This data type is an ML_STRING whose format is documented 431 in Section 2.3 of RFC 4519 [10]. 433 The NAME data type is implemented as an "xs:string" in the schema. 435 2.13. Telephone and Fax Numbers 437 A telephone or fax number is represented by the PHONE data type. The 438 format of the PHONE data type is documented in Section 2.35 of RFC 439 4519 [10]. 441 The PHONE data type is implemented as an "xs:string" in the schema. 443 2.14. Email String 445 An email address is represented by the EMAIL data type. The format 446 of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11] 448 The EMAIL data type is implemented as an "xs:string" in the schema. 450 2.15. Uniform Resource Locator strings 452 A uniform resource locator (URL) is represented by the URL data type. 453 The format of the URL data type is documented in RFC 2396 [8]. 455 The URL data type is implemented as an "xs:anyURI" in the schema. 457 3. The IODEF Data Model 459 In this section, the individual components of the IODEF data model 460 will be discussed in detail. For each class, the semantics will be 461 described and the relationship with other classes will be depicted 462 with UML. When necessary, specific comments will be made about 463 corresponding definition in the schema in Section 8 465 3.1. IODEF-Document Class 467 The IODEF-Document class is the top level class in the IODEF data 468 model. All IODEF documents are an instance of this class. 470 +-----------------+ 471 | IODEF-Document | 472 +-----------------+ 473 | STRING version |<>--{1..*}--[ Incident ] 474 | ENUM lang | 475 | STRING formatid | 476 +-----------------+ 478 Figure 1: IODEF-Document Class 480 The aggregate class that constitute IODEF-Document is: 482 Incident 483 One or more. The information related to a single incident. 485 The IODEF-Document class has three attributes: 487 version 488 Required. STRING. The IODEF specification version number to 489 which this IODEF document conforms. The value of this attribute 490 MUST be "1.00" 492 lang 493 Required. ENUM. A valid language code per RFC 4646 [7] 494 constrained by the definition of "xs:language". The 495 interpretation of this code is described in Section 6. 497 formatid 498 Optional. STRING. A free-form string to convey processing 499 instructions to the recipient of the document. Its semantics must 500 be negotiated out-of-band. 502 3.2. Incident Class 504 Every incident is represented by an instance of the Incident class. 505 This class provides a standardized representation for commonly 506 exchanged incident data. 508 +--------------------+ 509 | Incident | 510 +--------------------+ 511 | ENUM purpose |<>----------[ IncidentID ] 512 | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] 513 | ENUM lang |<>--{0..1}--[ RelatedActivity ] 514 | ENUM restriction |<>--{0..1}--[ DetectTime ] 515 | |<>--{0..1}--[ StartTime ] 516 | |<>--{0..1}--[ EndTime ] 517 | |<>----------[ ReportTime ] 518 | |<>--{0..*}--[ Description ] 519 | |<>--{1..*}--[ Assessment ] 520 | |<>--{0..*}--[ Method ] 521 | |<>--{1..*}--[ Contact ] 522 | |<>--{0..*}--[ EventData ] 523 | |<>--{0..1}--[ History ] 524 | |<>--{0..*}--[ AdditionalData ] 525 +--------------------+ 526 Figure 2: The Incident Class 528 The aggregate classes that constitute Incident are: 530 IncidentID 531 One. An incident tracking number assigned to this incident by the 532 CSIRT that generated the IODEF document. 534 AlternativeID 535 Zero or one. The incident tracking numbers used by other CSIRTs 536 to refer to the incident described in the document. 538 RelatedActivity 539 Zero or one. The incident tracking numbers of related incidents. 541 DetectTime 542 Zero or one. The time the incident was first detected. 544 StartTime 545 Zero or one. The time the incident started. 547 EndTime 548 Zero or one. The time the incident ended. 550 ReportTime 551 One. The time the incident was reported. 553 Description 554 Zero or more. ML_STRING. A free-form textual description of the 555 incident. 557 Assessment 558 One or more. A characterization of the impact of the incident. 560 Method 561 Zero or more. The techniques used by the intruder in the 562 incident. 564 Contact 565 One or more. Contact information for the parties involved in the 566 incident. 568 EventData 569 Zero or more. Description of the events comprising the incident. 571 History 572 Zero or one. A log of significant events or actions that occurred 573 during the course of handling the incident. 575 AdditionalData 576 Zero or more. Mechanism by which to extend the data model. 578 The Incident class has five attributes: 580 purpose 581 Required. ENUM. The purpose attribute represents the reason why 582 the IODEF document was created. It is closely related to the 583 Expectation class (Section 3.13). This attribute is defined as an 584 enumerated list: 586 1. traceback. The document was sent for trace-back purposes. 588 2. mitigation. The document was sent to request aid in 589 mitigating the described activity. 591 3. reporting. The document was sent to comply with reporting 592 requirements. 594 4. other. The document was sent for purposes specified in the 595 Expectation class. 597 5. ext-value. An escape value used to extend this attribute. 598 See Section 5.1. 600 ext-purpose 601 Optional. STRING. A means by which to extend the purpose 602 attribute. See Section 5.1. 604 lang 605 Optional. ENUM. A valid language code per RFC 4646 [7] 606 constrained by the definition of "xs:language". The 607 interpretation of this code is described in Section 6. 609 restriction 610 Optional. ENUM. This attribute indicates the disclosure 611 guidelines to which the sender expects the recipient to adhere for 612 the information represented in this class and its children. This 613 guideline provides no security since there are no specified 614 technical means to ensure that the recipient of the document 615 handles the information as the sender requested. 617 The value of this attribute is logically inherited by the children 618 of this class. That is to say, the disclosure rules applied to 619 this class, also apply to its children. 621 It is possible to set a granular disclosure policy, since all of 622 the high-level classes (i.e., children of the Incident class) have 623 a restriction attribute. Therefore, a child can override the 624 guidelines of a parent class, be it to restrict or relax the 625 disclosure rules (e.g., a child has a weaker policy than an 626 ancestor; or an ancestor has a weak policy, and the children 627 selectively apply more rigid controls). The implicit value of the 628 restriction attribute for a class that did not specify one can be 629 found in the closest ancestor that did specify a value. 631 This attribute is defined as an enumerated value with a default 632 value of "private". Note that the default value of the 633 restriction attribute is only defined in the context of the 634 Incident class. In other classes where this attribute is used, no 635 default is specified. 637 1. public. There are no restrictions placed in the information. 639 2. need-to-know. The information may be shared with other 640 parties that are involved in the incident as determined by the 641 recipient of this document (e.g., multiple victim sites can be 642 informed of each other). 644 3. private. The information may not be shared. 646 4. default. The information can be shared according to an 647 information disclosure policy pre-arranged by the 648 communicating parties. 650 5. 651 Optional. STRING. The indicator set ID is used to group 652 releated indicators. 654 3.3. IncidentID Class 656 The IncidentID class represents an incident tracking number that is 657 unique in the context of the CSIRT and identifies the activity 658 characterized in an IODEF Document. This identifier would serve as 659 an index into the CSIRT incident handling system. The combination of 660 the name attribute and the string in the element content MUST be a 661 globally unique identifier describing the activity. Documents 662 generated by a given CSIRT MUST NOT reuse the same value unless they 663 are referencing the same incident. 665 +------------------+ 666 | IncidentID | 667 +------------------+ 668 | STRING | 669 | | 670 | STRING name | 671 | STRING instance | 672 | ENUM restriction | 673 +------------------+ 675 Figure 3: The IncidentID Class 677 The IncidentID class has three attributes: 679 name 680 Required. STRING. An identifier describing the CSIRT that 681 created the document. In order to have a globally unique CSIRT 682 name, the fully qualified domain name associated with the CSIRT 683 MUST be used. 685 instance 686 Optional. STRING. An identifier referencing a subset of the 687 named incident. 689 restriction 690 Optional. ENUM. This attribute has been defined in Section 3.2. 691 The default value is "public". 693 3.4. AlternativeID Class 695 The AlternativeID class lists the incident tracking numbers used by 696 CSIRTs, other than the one generating the document, to refer to the 697 identical activity described the IODEF document. A tracking number 698 listed as an AlternativeID references the same incident detected by 699 another CSIRT. The incident tracking numbers of the CSIRT that 700 generated the IODEF document should never be considered an 701 AlternativeID. 703 +------------------+ 704 | AlternativeID | 705 +------------------+ 706 | ENUM restriction |<>--{1..*}--[ IncidentID ] 707 | | 708 +------------------+ 710 Figure 4: The AlternativeID Class 712 The aggregate class that constitutes AlternativeID is: 714 IncidentID 715 One or more. The incident tracking number of another CSIRT. 717 The AlternativeID class has one attribute: 719 restriction 720 Optional. ENUM. This attribute has been defined in Section 3.2. 722 3.5. RelatedActivity Class 724 The RelatedActivity class lists either incident tracking numbers of 725 incidents or URLs (not both) that refer to activity related to the 726 one described in the IODEF document. These references may be to 727 local incident tracking numbers or to those of other CSIRTs. 729 The specifics of how a CSIRT comes to believe that two incidents are 730 related are considered out of scope. 732 +------------------+ 733 | RelatedActivity | 734 +------------------+ 735 | ENUM restriction |<>--{1..*}--[ IncidentID ] 736 | |<>--{1..*}--[ URL ] 737 +------------------+ 739 Figure 5: RelatedActivity Class 741 The aggregate classes that constitutes RelatedActivity are: 743 IncidentID 744 One or more. The incident tracking number of a related incident. 746 URL 747 One or more. URL. A URL to activity related to this incident. 749 The RelatedActivity class has one attribute: 751 restriction 752 Optional. ENUM. This attribute has been defined in Section 3.2. 754 3.6. AdditionalData Class 756 The AdditionalData class serves as an extension mechanism for 757 information not otherwise represented in the data model. For 758 relatively simple information, atomic data types (e.g., integers, 759 strings) are provided with a mechanism to annotate their meaning. 760 The class can also be used to extend the data model (and the 761 associated Schema) to support proprietary extensions by encapsulating 762 entire XML documents conforming to another Schema (e.g., IDMEF). A 763 detailed discussion for extending the data model and the schema can 764 be found in Section 5. 766 Unlike XML, which is self-describing, atomic data must be documented 767 to convey its meaning. This information is described in the 768 'meaning' attribute. Since these description are outside the scope 769 of the specification, some additional coordination may be required to 770 ensure that a recipient of a document using the AdditionalData 771 classes can make sense of the custom extensions. 773 +------------------+ 774 | AdditionalData | 775 +------------------+ 776 | ANY | 777 | | 778 | ENUM dtype | 779 | STRING ext-dtype | 780 | STRING meaning | 781 | STRING formatid | 782 | ENUM restriction | 783 +------------------+ 785 Figure 6: The AdditionalData Class 787 The AdditionalData class has five attributes: 789 dtype 790 Required. ENUM. The data type of the element content. The 791 permitted values for this attribute are shown below. The default 792 value is "string". 794 1. boolean. The element content is of type BOOLEAN. 796 2. byte. The element content is of type BYTE. 798 3. character. The element content is of type CHARACTER. 800 4. date-time. The element content is of type DATETIME. 802 5. integer. The element content is of type INTEGER. 804 6. portlist. The element content is of type PORTLIST. 806 7. real. The element content is of type REAL. 808 8. string. The element content is of type STRING. 810 9. file. The element content is a base64 encoded binary file 811 encoded as a BYTE[] type. 813 10. frame. The element content is a layer-2 frame encoded as a 814 HEXBIN type. 816 11. packet. The element content is a layer-3 packet encoded as a 817 HEXBIN type. 819 12. ipv4-packet. The element content is an IPv4 packet encoded 820 as a HEXBIN type. 822 13. ipv6-packet. The element content is an IPv6 packet encoded 823 as a HEXBIN type. 825 14. path. The element content is a file-system path encoded as a 826 STRING type. 828 15. url. The element content is of type URL. 830 16. csv. The element content is a common separated value (CSV) 831 list per Section 2 of [20] encoded as a STRING type. 833 17. winreg. The element content is a Windows registry key 834 encoded as a STRING type. 836 18. xml. The element content is XML (see Section 5). 838 19. ext-value. An escape value used to extend this attribute. 839 See Section 5.1. 841 ext-dtype 842 Optional. STRING. A means by which to extend the dtype 843 attribute. See Section 5.1. 845 meaning 846 Optional. STRING. A free-form description of the element 847 content. 849 formatid 850 Optional. STRING. An identifier referencing the format and 851 semantics of the element content. 853 restriction 854 Optional. ENUM. This attribute has been defined in Section 3.2. 856 3.7. Contact Class 858 The Contact class describes contact information for organizations and 859 personnel involved in the incident. This class allows for the naming 860 of the involved party, specifying contact information for them, and 861 identifying their role in the incident. 863 People and organizations are treated interchangeably as contacts; one 864 can be associated with the other using the recursive definition of 865 the class (the Contact class is aggregated into the Contact class). 866 The 'type' attribute disambiguates the type of contact information 867 being provided. 869 The inheriting definition of Contact provides a way to relate 870 information without requiring the explicit use of identifiers in the 871 classes or duplication of data. A complete point of contact is 872 derived by a particular traversal from the root Contact class to the 873 leaf Contact class. As such, multiple points of contact might be 874 specified in a single instance of a Contact class. Each child 875 Contact class logically inherits contact information from its 876 ancestors. 878 +------------------+ 879 | Contact | 880 +------------------+ 881 | ENUM role |<>--{0..1}--[ ContactName ] 882 | STRING ext-role |<>--{0..*}--[ Description ] 883 | ENUM type |<>--{0..*}--[ RegistryHandle ] 884 | STRING ext-type |<>--{0..1}--[ PostalAddress ] 885 | ENUM restriction |<>--{0..*}--[ Email ] 886 | |<>--{0..*}--[ Telephone ] 887 | |<>--{0..1}--[ Fax ] 888 | |<>--{0..1}--[ Timezone ] 889 | |<>--{0..*}--[ Contact ] 890 | |<>--{0..*}--[ AdditionalData ] 891 +------------------+ 893 Figure 7: The Contact Class 895 The aggregate classes that constitute the Contact class are: 897 ContactName 898 Zero or one. ML_STRING. The name of the contact. The contact 899 may either be an organization or a person. The type attribute 900 disambiguates the semantics. 902 Description 903 Zero or many. ML_STRING. A free-form description of this 904 contact. In the case of a person, this is often the 905 organizational title of the individual. 907 RegistryHandle 908 Zero or many. A handle name into the registry of the contact. 910 PostalAddress 911 Zero or one. The postal address of the contact. 913 Email 914 Zero or many. The email address of the contact. 916 Telephone 917 Zero or many. The telephone number of the contact. 919 Fax 920 Zero or one. The facsimile telephone number of the contact. 922 Timezone 923 Zero or one. TIMEZONE. The timezone in which the contact resides 924 formatted according to Section 2.9. 926 Contact 927 Zero or many. A Contact instance contained within another Contact 928 instance inherits the values of the parent(s). This recursive 929 definition can be used to group common data pertaining to multiple 930 points of contact and is especially useful when listing multiple 931 contacts at the same organization. 933 AdditionalData 934 Zero or many. A mechanism by which to extend the data model. 936 At least one of the aggregate classes MUST be present in an instance 937 of the Contact class. This is not enforced in the IODEF schema as 938 there is no simple way to accomplish it. 940 The Contact class has five attributes: 942 role 943 Required. ENUM. Indicates the role the contact fulfills. This 944 attribute is defined as an enumerated list: 946 1. creator. The entity that generate the document. 948 2. admin. An administrative contact for a host or network. 950 3. tech. A technical contact for a host or network. 952 4. irt. The CSIRT involved in handling the incident. 954 5. cc. An entity that is to be kept informed about the handling 955 of the incident. 957 6. ext-value. An escape value used to extend this attribute. 958 See Section 5.1. 960 ext-role 961 Optional. STRING. A means by which to extend the role attribute. 962 See Section 5.1. 964 type 965 Required. ENUM. Indicates the type of contact being described. 966 This attribute is defined as an enumerated list: 968 1. person. The information for this contact references an 969 individual. 971 2. organization. The information for this contact references an 972 organization. 974 3. ext-value. An escape value used to extend this attribute. 975 See Section 5.1. 977 ext-type 978 Optional. STRING. A means by which to extend the type attribute. 979 See Section 5.1. 981 restriction 982 Optional. ENUM. This attribute is defined in Section 3.2. 984 3.7.1. RegistryHandle Class 986 The RegistryHandle class represents a handle into an Internet 987 registry or community-specific database. The handle is specified in 988 the element content and the type attribute specifies the database. 990 +---------------------+ 991 | RegistryHandle | 992 +---------------------+ 993 | STRING | 994 | | 995 | ENUM registry | 996 | STRING ext-registry | 997 +---------------------+ 999 Figure 8: The RegistryHandle Class 1001 The RegistryHandle class has two attributes: 1003 registry 1004 Required. ENUM. The database to which the handle belongs. The 1005 possible values are: 1007 1. internic. Internet Network Information Center 1009 2. apnic. Asia Pacific Network Information Center 1011 3. arin. American Registry for Internet Numbers 1013 4. lacnic. Latin-American and Caribbean IP Address Registry 1015 5. ripe. Reseaux IP Europeens 1017 6. afrinic. African Internet Numbers Registry 1019 7. local. A database local to the CSIRT 1021 8. ext-value. An escape value used to extend this attribute. 1022 See Section 5.1. 1024 ext-registry 1025 Optional. STRING. A means by which to extend the registry 1026 attribute. See Section 5.1. 1028 3.7.2. PostalAddress Class 1030 The PostalAddress class specifies a postal address formatted 1031 according to the POSTAL data type (Section 2.11). 1033 +---------------------+ 1034 | PostalAddress | 1035 +---------------------+ 1036 | POSTAL | 1037 | | 1038 | ENUM meaning | 1039 | ENUM lang | 1040 +---------------------+ 1042 Figure 9: The PostalAddress Class 1044 The PostalAddress class has two attributes: 1046 meaning 1047 Optional. ENUM. A free-form description of the element content. 1049 lang 1050 Optional. ENUM. A valid language code per RFC 4646 [7] 1051 constrained by the definition of "xs:language". The 1052 interpretation of this code is described in Section 6. 1054 3.7.3. Email Class 1056 The Email class specifies an email address formatted according to 1057 EMAIL data type (Section 2.14). 1059 +--------------+ 1060 | Email | 1061 +--------------+ 1062 | EMAIL | 1063 | | 1064 | ENUM meaning | 1065 +--------------+ 1067 Figure 10: The Email Class 1069 The Email class has one attribute: 1071 meaning 1072 Optional. ENUM. A free-form description of the element content. 1074 3.7.4. Telephone and Fax Classes 1076 The Telephone and Fax classes specify a voice or fax telephone number 1077 respectively, and are formatted according to PHONE data type 1078 (Section 2.13). 1080 +--------------------+ 1081 | {Telephone | Fax } | 1082 +--------------------+ 1083 | PHONE | 1084 | | 1085 | ENUM meaning | 1086 +--------------------+ 1088 Figure 11: The Telephone and Fax Classes 1090 The Telephone class has one attribute: 1092 meaning 1093 Optional. ENUM. A free-form description of the element content 1094 (e.g., hours of coverage for a given number). 1096 3.8. Time Classes 1098 The data model uses five different classes to represent a timestamp. 1099 Their definition is identical, but each has a distinct name to convey 1100 a difference in semantics. 1102 The element content of each class is a timestamp formatted according 1103 to the DATETIME data type (see Section 2.8). 1105 +----------------------------------+ 1106 | {Start| End| Report| Detect}Time | 1107 +----------------------------------+ 1108 | DATETIME | 1109 +----------------------------------+ 1111 Figure 12: The Time Classes 1113 3.8.1. StartTime 1115 The StartTime class represents the time the incident began. 1117 3.8.2. EndTime 1119 The EndTime class represents the time the incident ended. 1121 3.8.3. DetectTime 1123 The DetectTime class represents the time the first activity of the 1124 incident was detected. 1126 3.8.4. ReportTime 1128 The ReportTime class represents the time the incident was reported. 1129 This timestamp SHOULD coincide to the time at which the IODEF 1130 document is generated. 1132 3.8.5. DateTime 1134 The DateTime class is a generic representation of a timestamp. Its 1135 semantics should be inferred from the parent class in which it is 1136 aggregated. 1138 3.9. Method Class 1140 The Method class describes the methodology used by the intruder to 1141 perpetrate the events of the incident. This class consists of a list 1142 of references describing the attack method and a free form 1143 description of the technique. 1145 +------------------+ 1146 | Method | 1147 +------------------+ 1148 | ENUM restriction |<>--{0..*}--[ Reference ] 1149 | |<>--{0..*}--[ Description ] 1150 | |<>--{0..*}--[ AdditionalData ] 1151 +------------------+ 1153 Figure 13: The Method Class 1155 The Method class is composed of three aggregate classes. 1157 Reference 1158 Zero or many. A reference to a vulnerability, malware sample, 1159 advisory, or analysis of an attack technique. 1161 Description 1162 Zero or many. ML_STRING. A free-form text description of the 1163 methodology used by the intruder. 1165 AdditionalData 1166 Zero or many. A mechanism by which to extend the data model. 1168 Either an instance of the Reference or Description class MUST be 1169 present. 1171 The Method class has one attribute: 1173 restriction 1174 Optional. ENUM. This attribute is defined in Section 3.2. 1176 3.9.1. Reference Class 1178 The Reference class is a reference to a vulnerability, IDS alert, 1179 malware sample, advisory, or attack technique. A reference consists 1180 of a name, a URL to this reference, and an optional description. 1182 +------------------+ 1183 | Reference | 1184 +------------------+ 1185 | |<>----------[ ReferenceName ] 1186 | |<>--{0..*}--[ URL ] 1187 | |<>--{0..*}--[ Description ] 1188 +------------------+ 1190 Figure 14: The Reference Class 1192 The aggregate classes that constitute Reference: 1194 ReferenceName 1195 One. ML_STRING. Name of the reference. 1197 URL 1198 Zero or many. URL. A URL associated with the reference. 1200 Description 1201 Zero or many. ML_STRING. A free-form text description of this 1202 reference. 1204 The Reference class has 4 attributes. 1206 indicator-uid 1207 Optional. STRING. A unique identifier for an Indicator. 1209 indicator-set-id 1210 Optional. STRING. The indicator set ID is used to group 1211 releated indicators. 1213 attacktype 1214 Optional. ENUM. A unique identifier for an Indicator. 1216 ext-attacktype 1217 Optional. STRING. A mechanism by which to extend the Attack 1218 Type. 1220 3.10. Assessment Class 1222 The Assessment class describes the technical and non-technical 1223 repercussions of the incident on the CSIRT's constituency. 1225 This class was derived from the IDMEF[17]. 1227 +------------------+ 1228 | Assessment | 1229 +------------------+ 1230 | ENUM occurrence |<>--{0..*}--[ Impact ] 1231 | ENUM restriction |<>--{0..*}--[ TimeImpact ] 1232 | |<>--{0..*}--[ MonetaryImpact ] 1233 | |<>--{0..*}--[ Counter ] 1234 | |<>--{0..1}--[ Confidence ] 1235 | |<>--{0..*}--[ AdditionalData ] 1236 +------------------+ 1238 Figure 15: Assessment Class 1240 The aggregate classes that constitute Assessment are: 1242 Impact 1243 Zero or many. Technical impact of the incident on a network. 1245 TimeImpact 1246 Zero or many. Impact of the activity measured with respect to 1247 time. 1249 MonetaryImpact 1250 Zero or many. Impact of the activity measured with respect to 1251 financial loss. 1253 Counter 1254 Zero or more. A counter with which to summarize the magnitude of 1255 the activity. 1257 Confidence 1258 Zero or one. An estimate of confidence in the assessment. 1260 AdditionalData 1261 Zero or many. A mechanism by which to extend the data model. 1263 A least one instance of the possible three impact classes (i.e., 1264 Impact, TimeImpact, or MonetaryImpact) MUST be present. 1266 The Assessment class has four attributes: 1268 occurrence 1269 Optional. ENUM. Specifies whether the assessment is describing 1270 actual or potential outcomes. 1272 1. actual. This assessment describes activity that has occurred. 1274 2. potential. This assessment describes potential activity that 1275 might occur. 1277 restriction 1278 Optional. ENUM. This attribute is defined in Section 3.2. 1280 indicator-uid 1281 Optional. STRING. A unique identifier for an Indicator. 1283 indicator-set-id 1284 Optional. STRING. The indicator set ID is used to group releated 1285 indicators. 1287 3.10.1. Impact Class 1289 The Impact class allows for categorizing and describing the technical 1290 impact of the incident on the network of an organization. 1292 This class is based on the IDMEF [17]. 1294 +------------------+ 1295 | Impact | 1296 +------------------+ 1297 | ML_STRING | 1298 | | 1299 | ENUM lang | 1300 | ENUM severity | 1301 | ENUM completion | 1302 | ENUM type | 1303 | STRING ext-type | 1304 +------------------+ 1306 Figure 16: Impact Class 1308 The element content will be a free-form textual description of the 1309 impact. 1311 The Impact class has five attributes: 1313 lang 1314 Optional. ENUM. A valid language code per RFC 4646 [7] 1315 constrained by the definition of "xs:language". The 1316 interpretation of this code is described in Section 6. 1318 severity 1319 Optional. ENUM. An estimate of the relative severity of the 1320 activity. The permitted values are shown below. There is no 1321 default value. 1323 1. low. Low severity 1325 2. medium. Medium severity 1327 3. high. High severity 1329 completion 1330 Optional. ENUM. An indication whether the described activity was 1331 successful. The permitted values are shown below. There is no 1332 default value. 1334 1. failed. The attempted activity was not successful. 1336 2. succeeded. The attempted activity succeeded. 1338 type 1339 Required. ENUM. Classifies the malicious activity into incident 1340 categories. The permitted values are shown below. The default 1341 value is "other". 1343 1. admin. Administrative privileges were attempted. 1345 2. dos. A denial of service was attempted. 1347 3. file. An action that impacts the integrity of a file or 1348 database was attempted. 1350 4. info-leak. An attempt was made to exfiltrate information. 1352 5. misconfiguration. An attempt was made to exploit a mis- 1353 configuration in a system. 1355 6. policy. Activity violating site's policy was attempted. 1357 7. recon. Reconnaissance activity was attempted. 1359 8. social-engineering. A social engineering attack was 1360 attempted. 1362 9. user. User privileges were attempted. 1364 10. unknown. The classification of this activity is unknown. 1366 11. ext-value. An escape value used to extend this attribute. 1367 See Section 5.1. 1369 ext-type 1370 Optional. STRING. A means by which to extend the type attribute. 1371 See Section 5.1. 1373 3.10.2. TimeImpact Class 1375 The TimeImpact class describes the impact of the incident on an 1376 organization as a function of time. It provides a way to convey down 1377 time and recovery time. 1379 +---------------------+ 1380 | TimeImpact | 1381 +---------------------+ 1382 | REAL | 1383 | | 1384 | ENUM severity | 1385 | ENUM metric | 1386 | STRING ext-metric | 1387 | ENUM duration | 1388 | STRING ext-duration | 1389 +---------------------+ 1391 Figure 17: TimeImpact Class 1393 The element content is a positive, floating point (REAL) number 1394 specifying a unit of time. The duration and metric attributes will 1395 imply the semantics of the element content. 1397 The TimeImpact class has five attributes: 1399 severity 1400 Optional. ENUM. An estimate of the relative severity of the 1401 activity. The permitted values are shown below. There is no 1402 default value. 1404 1. low. Low severity 1406 2. medium. Medium severity 1407 3. high. High severity 1409 metric 1410 Required. ENUM. Defines the metric in which the time is 1411 expressed. The permitted values are shown below. There is no 1412 default value. 1414 1. labor. Total staff-time to recovery from the activity (e.g., 1415 2 employees working 4 hours each would be 8 hours). 1417 2. elapsed. Elapsed time from the beginning of the recovery to 1418 its completion (i.e., wall-clock time). 1420 3. downtime. Duration of time for which some provided service(s) 1421 was not available. 1423 4. ext-value. An escape value used to extend this attribute. 1424 See Section 5.1. 1426 ext-metric 1427 Optional. STRING. A means by which to extend the metric 1428 attribute. See Section 5.1. 1430 duration 1431 Optional. ENUM. Defines a unit of time, that when combined with 1432 the metric attribute, fully describes a metric of impact that will 1433 be conveyed in the element content. The permitted values are 1434 shown below. The default value is "hour". 1436 1. second. The unit of the element content is seconds. 1438 2. minute. The unit of the element content is minutes. 1440 3. hour. The unit of the element content is hours. 1442 4. day. The unit of the element content is days. 1444 5. month. The unit of the element content is months. 1446 6. quarter. The unit of the element content is quarters. 1448 7. year. The unit of the element content is years. 1450 8. ext-value. An escape value used to extend this attribute. 1451 See Section 5.1. 1453 ext-duration 1454 Optional. STRING. A means by which to extend the duration 1455 attribute. See Section 5.1. 1457 3.10.3. MonetaryImpact Class 1459 The MonetaryImpact class describes the financial impact of the 1460 activity on an organization. For example, this impact may consider 1461 losses due to the cost of the investigation or recovery, diminished 1462 productivity of the staff, or a tarnished reputation that will affect 1463 future opportunities. 1465 +------------------+ 1466 | MonetaryImpact | 1467 +------------------+ 1468 | REAL | 1469 | | 1470 | ENUM severity | 1471 | STRING currency | 1472 +------------------+ 1474 Figure 18: MonetaryImpact Class 1476 The element content is a positive, floating point number (REAL) 1477 specifying a unit of currency described in the currency attribute. 1479 The MonetaryImpact class has two attributes: 1481 severity 1482 Optional. ENUM. An estimate of the relative severity of the 1483 activity. The permitted values are shown below. There is no 1484 default value. 1486 1. low. Low severity 1488 2. medium. Medium severity 1490 3. high. High severity 1492 currency 1493 Optional. STRING. Defines the currency in which the monetary 1494 impact is expressed. The permitted values are defined in ISO 1495 4217:2001, Codes for the representation of currencies and funds 1496 [14]. There is no default value. 1498 3.10.4. Confidence Class 1500 The Confidence class represents a best estimate of the validity and 1501 accuracy of the described impact (see Section 3.10) of the incident 1502 activity. This estimate can be expressed as a category or a numeric 1503 calculation. 1505 This class if based upon the IDMEF [17]). 1507 +------------------+ 1508 | Confidence | 1509 +------------------+ 1510 | REAL | 1511 | | 1512 | ENUM rating | 1513 +------------------+ 1515 Figure 19: Confidence Class 1517 The element content expresses a numerical assessment in the 1518 confidence of the data when the value of the rating attribute is 1519 "numeric". Otherwise, this element should be empty. 1521 The Confidence class has one attribute. 1523 rating 1524 Required. ENUM. A rating of the analytical validity of the 1525 specified Assessment. The permitted values are shown below. 1526 There is no default value. 1528 1. low. Low confidence in the validity. 1530 2. medium. Medium confidence in the validity. 1532 3. high. High confidence in the validity. 1534 4. numeric. The element content contains a number that conveys 1535 the confidence of the data. The semantics of this number 1536 outside the scope of this specification. 1538 5. unknown. The confidence rating value is not known. 1540 3.11. History Class 1542 The History class is a log of the significant events or actions 1543 performed by the involved parties during the course of handling the 1544 incident. 1546 The level of detail maintained in this log is left up to the 1547 discretion of those handling the incident. 1549 +------------------+ 1550 | History | 1551 +------------------+ 1552 | ENUM restriction |<>--{1..*}--[ HistoryItem ] 1553 | | 1554 +------------------+ 1556 Figure 20: The History Class 1558 The class that constitutes History is: 1560 HistoryItem 1561 One or many. Entry in the history log of significant events or 1562 actions performed by the involved parties. 1564 The History class has one attribute: 1566 restriction 1567 Optional. ENUM. This attribute is defined in Section 3.2. The 1568 default value is "default". 1570 3.11.1. HistoryItem Class 1572 The HistoryItem class is an entry in the History (Section 3.11) log 1573 that documents a particular action or event that occurred in the 1574 course of handling the incident. The details of the entry are a 1575 free-form description, but each can be categorized with the type 1576 attribute. 1578 +-------------------+ 1579 | HistoryItem | 1580 +-------------------+ 1581 | ENUM restriction |<>----------[ DateTime ] 1582 | ENUM action |<>--{0..1}--[ IncidentId ] 1583 | STRING ext-action |<>--{0..1}--[ Contact ] 1584 | |<>--{0..*}--[ Description ] 1585 | |<>--{0..*}--[ AdditionalData ] 1586 +-------------------+ 1588 Figure 21: HistoryItem Class 1590 The aggregate classes that constitute HistoryItem are: 1592 DateTime 1593 One. Timestamp of this entry in the history log (e.g., when the 1594 action described in the Description was taken). 1596 IncidentID 1597 Zero or One. In a history log created by multiple parties, the 1598 IncidentID provides a mechanism to specify which CSIRT created a 1599 particular entry and references this organization's incident 1600 tracking number. When a single organization is maintaining the 1601 log, this class can be ignored. 1603 Contact 1604 Zero or One. Provides contact information for the person that 1605 performed the action documented in this class. 1607 Description 1608 Zero or many. ML_STRING. A free-form textual description of the 1609 action or event. 1611 AdditionalData 1612 Zero or many. A mechanism by which to extend the data model. 1614 The HistoryItem class has five attributes: 1616 restriction 1617 Optional. ENUM. This attribute has been defined in Section 3.2. 1619 action 1620 Required. ENUM. Classifies a performed action or occurrence 1621 documented in this history log entry. As activity will likely 1622 have been instigated either through a previously conveyed 1623 expectation or internal investigation, this attribute is identical 1624 to the category attribute of the Expectation class. The 1625 difference is only one of tense. When an action is in this class, 1626 it has been completed. See Section 3.13. 1628 ext-action 1629 Optional. STRING. A means by which to extend the action 1630 attribute. See Section 5.1. 1632 indicator-uid 1633 Optional. STRING. A unique identifier for an Indicator. 1635 indicator-set-id 1636 Optional. STRING. The indicator set ID is used to group releated 1637 indicators. 1639 3.12. EventData Class 1641 The EventData class describes a particular event of the incident for 1642 a given set of hosts or networks. This description includes the 1643 systems from which the activity originated and those targeted, an 1644 assessment of the techniques used by the intruder, the impact of the 1645 activity on the organization, and any forensic evidence discovered. 1647 +------------------+ 1648 | EventData | 1649 +------------------+ 1650 | ENUM restriction |<>--{0..*}--[ Description ] 1651 | |<>--{0..1}--[ DetectTime ] 1652 | |<>--{0..1}--[ StartTime ] 1653 | |<>--{0..1}--[ EndTime ] 1654 | |<>--{0..*}--[ Contact ] 1655 | |<>--{0..1}--[ Assessment ] 1656 | |<>--{0..*}--[ Method ] 1657 | |<>--{0..*}--[ Flow ] 1658 | |<>--{0..*}--[ Expectation ] 1659 | |<>--{0..1}--[ Record ] 1660 | |<>--{0..*}--[ EventData ] 1661 | |<>--{0..*}--[ AdditionalData ] 1662 +------------------+ 1664 Figure 22: The EventData Class 1666 The aggregate classes that constitute EventData are: 1668 Description 1669 Zero or more. ML_STRING. A free-form textual description of the 1670 event. 1672 DetectTime 1673 Zero or one. The time the event was detected. 1675 StartTime 1676 Zero or one. The time the event started. 1678 EndTime 1679 Zero or one. The time the event ended. 1681 Contact 1682 Zero or more. Contact information for the parties involved in the 1683 event. 1685 Assessment 1686 Zero or one. The impact of the event on the target and the 1687 actions taken. 1689 Method 1690 Zero or more. The technique used by the intruder in the event. 1692 Flow 1693 Zero or more. A description of the systems or networks involved. 1695 Expectation 1696 Zero or more. The expected action to be performed by the 1697 recipient for the described event. 1699 Record 1700 Zero or one. Supportive data (e.g., log files) that provides 1701 additional information about the event. 1703 EventData 1704 Zero or more. EventData instances contained within another 1705 EventData instance inherit the values of the parent(s); this 1706 recursive definition can be used to group common data pertaining 1707 to multiple events. When EventData elements are defined 1708 recursively, only the leaf instances (those EventData instances 1709 not containing other EventData instances) represent actual events. 1711 AdditionalData 1712 Zero or more. An extension mechanism for data not explicitly 1713 represented in the data model. 1715 At least one of the aggregate classes MUST be present in an instance 1716 of the EventData class. This is not enforced in the IODEF schema as 1717 there is no simple way to accomplish it. 1719 The EventData class has two attributes: 1721 restriction 1722 Optional. ENUM. This attribute is defined in Section 3.2. The 1723 default value is "default". 1725 indicator-set-id 1726 Optional. STRING. The indicator set ID is used to group releated 1727 indicators. 1729 3.12.1. Relating the Incident and EventData Classes 1731 There is substantial overlap in the Incident and EventData classes. 1732 Nevertheless, the semantics of these classes are quite different. 1733 The Incident class provides summary information about the entire 1734 incident, while the EventData class provides information about the 1735 individual events comprising the incident. In the most common case, 1736 the EventData class will provide more specific information for the 1737 general description provided in the Incident class. However, it may 1738 also be possible that the overall summarized information about the 1739 incident conflicts with some individual information in an EventData 1740 class when there is a substantial composition of various events in 1741 the incident. In such a case, the interpretation of the more 1742 specific EventData MUST supersede the more generic information 1743 provided in IncidentData. 1745 3.12.2. Cardinality of EventData 1747 The EventData class can be thought of as a container for the 1748 properties of an event in an incident. These properties include: the 1749 hosts involved, impact of the incident activity on the hosts, 1750 forensic logs, etc. With an instance of the EventData class, hosts 1751 (i.e., System class) are grouped around these common properties. 1753 The recursive definition (or instance property inheritance) of the 1754 EventData class (the EventData class is aggregated into the EventData 1755 class) provides a way to related information without requiring the 1756 explicit use of unique attribute identifiers in the classes or 1757 duplicating information. Instead, the relative depth (nesting) of a 1758 class is used to group (relate) information. 1760 For example, an EventData class might be used to describe two 1761 machines involved in an incident. This description can be achieved 1762 using multiple instances of the Flow class. It happens that there is 1763 a common technical contact (i.e., Contact class) for these two 1764 machines, but the impact (i.e., Assessment class) on them is 1765 different. A depiction of the representation for this situation can 1766 be found in Figure 23. 1768 +------------------+ 1769 | EventData | 1770 +------------------+ 1771 | |<>----[ Contact ] 1772 | | 1773 | |<>----[ EventData ]<>----[ Flow ] 1774 | | [ ]<>----[ Assessment ] 1775 | | 1776 | |<>----[ EventData ]<>----[ Flow ] 1777 | | [ ]<>----[ Assessment ] 1778 +------------------+ 1780 Figure 23: Recursion in the EventData Class 1782 3.13. Expectation Class 1784 The Expectation class conveys to the recipient of the IODEF document 1785 the actions the sender is requesting. The scope of the requested 1786 action is limited to purview of the EventData class in which this 1787 class is aggregated. 1789 +-------------------+ 1790 | Expectation | 1791 +-------------------+ 1792 | ENUM restriction |<>--{0..*}--[ Description ] 1793 | ENUM severity |<>--{0..1}--[ StartTime ] 1794 | ENUM action |<>--{0..1}--[ EndTime ] 1795 | STRING ext-action |<>--{0..1}--[ Contact ] 1796 +-------------------+ 1798 Figure 24: The Expectation Class 1800 The aggregate classes that constitute Expectation are: 1802 Description 1803 Zero or many. ML_STRING. A free-form description of the desired 1804 action(s). 1806 StartTime 1807 Zero or one. The time at which the action should be performed. A 1808 timestamp that is earlier than the ReportTime specified in the 1809 Incident class denotes that the expectation should be fulfilled as 1810 soon as possible. The absence of this element leaves the 1811 execution of the expectation to the discretion of the recipient. 1813 EndTime 1814 Zero or one. The time by which the action should be completed. 1815 If the action is not carried out by this time, it should no longer 1816 be performed. 1818 Contact 1819 Zero or one. The expected actor for the action. 1821 The Expectations class has six attributes: 1823 restriction 1824 Optional. ENUM. This attribute is defined in Section 3.2. The 1825 default value is "default". 1827 severity 1828 Optional. ENUM. Indicates the desired priority of the action. 1829 This attribute is an enumerated list with no default value, and 1830 the semantics of these relative measures are context dependant. 1832 1. low. Low priority 1834 2. medium. Medium priority 1836 3. high. High priority 1838 action 1839 Optional. ENUM. Classifies the type of action requested. This 1840 attribute is an enumerated list with a default value of "other". 1842 1. nothing. No action is requested. Do nothing with the 1843 information. 1845 2. contact-source-site. Contact the site(s) identified as the 1846 source of the activity. 1848 3. contact-target-site. Contact the site(s) identified as the 1849 target of the activity. 1851 4. contact-sender. Contact the originator of the document. 1853 5. investigate. Investigate the systems(s) listed in the event. 1855 6. block-host. Block traffic from the machine(s) listed as 1856 sources the event. 1858 7. block-network. Block traffic from the network(s) lists as 1859 sources in the event. 1861 8. block-port. Block the port listed as sources in the event. 1863 9. rate-limit-host. Rate-limit the traffic from the machine(s) 1864 listed as sources in the event. 1866 10. rate-limit-network. Rate-limit the traffic from the 1867 network(s) lists as sources in the event. 1869 11. rate-limit-port. Rate-limit the port(s) listed as sources in 1870 the event. 1872 12. remediate-other. Remediate the activity in a way other than 1873 by rate limiting or blocking. 1875 13. status-triage. Conveys receipts and the triaging of an 1876 incident. 1878 14. status-new-info. Conveys that new information was received 1879 for this incident. 1881 15. other. Perform some custom action described in the 1882 Description class. 1884 16. ext-value. An escape value used to extend this attribute. 1885 See Section 5.1. 1887 ext-action 1888 Optional. STRING. A means by which to extend the action 1889 attribute. See Section 5.1. 1891 indicator-uid 1892 Optional. STRING. A unique identifier for an Indicator. 1894 indicator-set-id 1895 Optional. STRING. The indicator set ID is used to group releated 1896 indicators. 1898 3.14. Flow Class 1900 The Flow class groups related the source and target hosts. 1902 +------------------+ 1903 | Flow | 1904 +------------------+ 1905 | |<>--{1..*}--[ System ] 1906 +------------------+ 1907 Figure 25: The Flow Class 1909 The aggregate class that constitutes Flow is: 1911 System 1912 One or More. A host or network involved in an event. 1914 The Flow System class has no attributes. 1916 3.15. System Class 1918 The System class describes a system or network involved in an event. 1919 The systems or networks represented by this class are categorized 1920 according to the role they played in the incident through the 1921 category attribute. The value of this category attribute dictates 1922 the semantics of the aggregated classes in the System class. If the 1923 category attribute has a value of "source", then the aggregated 1924 classes denote the machine and service from which the activity is 1925 originating. With a category attribute value of "target" or 1926 "intermediary", then the machine or service is the one targeted in 1927 the activity. A value of "sensor" dictates that this System was part 1928 of an instrumentation to monitor the network. 1930 +---------------------+ 1931 | System | 1932 +---------------------+ 1933 | ENUM restriction |<>----------[ Node ] 1934 | ENUM category |<>--{0..*}--[ Service ] 1935 | STRING ext-category |<>--{0..*}--[ OperatingSystem ] 1936 | STRING interface |<>--{0..*}--[ Counter ] 1937 | ENUM spoofed |<>--{0..*}--[ Description ] 1938 | |<>--{0..*}--[ AdditionalData ] 1939 +---------------------+ 1941 Figure 26: The System Class 1943 The aggregate classes that constitute System are: 1945 Node 1946 One. A host or network involved in the incident. 1948 Service 1949 Zero or more. A network service running on the system. 1951 OperatingSystem 1952 Zero or more. The operating system running on the system. 1954 Counter 1955 Zero or more. A counter with which to summarize properties of 1956 this host or network. 1958 Description 1959 Zero or more. ML_STRING. A free-form text description of the 1960 System. 1962 AdditionalData 1963 Zero or many. A mechanism by which to extend the data model. 1965 The System class has six attributes: 1967 restriction 1968 Optional. ENUM. This attribute is defined in Section 3.2. 1970 category 1971 Optional. ENUM. Classifies the role the host or network played 1972 in the incident. The possible values are: 1974 1. source. The System was the source of the event. 1976 2. target. The System was the target of the event. 1978 3. watchlist-source. The source of the event was on a watchlist. 1980 4. watchlist-target. The target of the event was on a watchlist. 1982 5. intermediate. The System was an intermediary in the event. 1984 6. sensor. The System was a sensor monitoring the event. 1986 7. infrastructure. The System was an infrastructure node of 1987 IODEF document exchange. 1989 8. ext-value. An escape value used to extend this attribute. 1990 See Section 5.1. 1992 ext-category 1993 Optional. STRING. A means by which to extend the category 1994 attribute. See Section 5.1. 1996 indicator-set-id 1997 Optional. STRING. The indicator set ID is used to group releated 1998 indicators. 2000 interface 2001 Optional. STRING. Specifies the interface on which the event(s) 2002 on this System originated. If the Node class specifies a network 2003 rather than a host, this attribute has no meaning. 2005 spoofed 2006 Optional. ENUM. An indication of confidence in whether this 2007 System was the true target or attacking host. The permitted 2008 values for this attribute are shown below. The default value is 2009 "unknown". 2011 1. unknown. The accuracy of the category attribute value is 2012 unknown. 2014 2. yes. The category attribute value is probably incorrect. In 2015 the case of a source, the System is likely a decoy; with a 2016 target, the System was likely not the intended victim. 2018 3. no. The category attribute value is believed to be correct. 2020 3.16. Node Class 2022 The Node class names a system (e.g., PC, router) or network. 2024 This class was derived from the IDMEF [17]. 2026 +---------------+ 2027 | Node | 2028 +---------------+ 2029 | |<>--{0..*}--[ NodeName ] 2030 | |<>--{0..*}--[ Address ] 2031 | |<>--{0..1}--[ Location ] 2032 | |<>--{0..1}--[ DateTime ] 2033 | |<>--{0..*}--[ NodeRole ] 2034 | |<>--{0..*}--[ Counter ] 2035 +---------------+ 2037 Figure 27: The Node Class 2039 The aggregate classes that constitute Node are: 2041 NodeName 2042 Zero or more. ML_STRING. The name of the Node (e.g., fully 2043 qualified domain name). This information MUST be provided if no 2044 Address information is given. 2046 Address 2047 Zero or more. The hardware, network, or application address of 2048 the Node. If a NodeName is not provided, at least one Address 2049 MUST be specified. 2051 Location 2052 Zero or one. ML_STRING. A free-from description of the physical 2053 location of the equipment. 2055 DateTime 2056 Zero or one. A timestamp of when the resolution between the name 2057 and address was performed. This information SHOULD be provided if 2058 both an Address and NodeName are specified. 2060 NodeRole 2061 Zero or more. The intended purpose of the Node. 2063 Counter 2064 Zero or more. A counter with which to summarizes properties of 2065 this host or network. 2067 3.16.1. Counter Class 2069 The Counter class summarize multiple occurrences of some event, or 2070 conveys counts or rates on various features (e.g., packets, sessions, 2071 events). 2073 The value of the counter is the element content with its units 2074 represented in the type attribute. A rate for a given feature can be 2075 expressed by setting the duration attribute. The complete semantics 2076 are entirely context dependant based on the class in which the 2077 Counter is aggregated. 2079 +---------------------+ 2080 | Counter | 2081 +---------------------+ 2082 | REAL | 2083 | | 2084 | ENUM type | 2085 | STRING ext-type | 2086 | STRING meaning | 2087 | ENUM duration | 2088 | STRING ext-duration | 2089 +---------------------+ 2091 Figure 28: The Counter Class 2093 The Counter class has three attribute: 2095 type 2096 Required. ENUM. Specifies the units of the element content. 2098 1. byte. Count of bytes. 2100 2. packet. Count of packets. 2102 3. flow. Count of flow (e.g., NetFlow records). 2104 4. session. Count of sessions. 2106 5. alert. Count of notifications generated by another system 2107 (e.g., IDS or SIM). 2109 6. message. Count of messages (e.g., mail messages). 2111 7. event. Count of events. 2113 8. host. Count of hosts. 2115 9. site. Count of site. 2117 10. organization. Count of organizations. 2119 11. ext-value. An escape value used to extend this attribute. 2120 See Section 5.1. 2122 ext-type 2123 Optional. STRING. A means by which to extend the type attribute. 2124 See Section 5.1. 2126 duration 2127 Optional. ENUM. If present, the Counter class represents a rate 2128 rather than a count over the entire event. In that case, this 2129 attribute specifies the denominator of the rate (where the type 2130 attribute specified the nominator). The possible values of this 2131 attribute are defined in Section 3.10.2 2133 ext-duration 2134 Optional. STRING. A means by which to extend the duration 2135 attribute. See Section 5.1. 2137 3.16.2. Address Class 2139 The Address class represents a hardware (layer-2), network (layer-3), 2140 or application (layer-7) address. 2142 This class was derived from the IDMEF [17]. 2144 +---------------------+ 2145 | Address | 2146 +---------------------+ 2147 | ENUM category | 2148 | STRING ext-category | 2149 | STRING vlan-name | 2150 | INTEGER vlan-num | 2151 +---------------------+ 2153 Figure 29: The Address Class 2155 The Address class has five attributes: 2157 category 2158 Optional. ENUM. The type of address represented. The permitted 2159 values for this attribute are shown below. The default value is 2160 "ipv4-addr". 2162 1. asn. Autonomous System Number 2164 2. atm. Asynchronous Transfer Mode (ATM) address 2166 3. e-mail. Electronic mail address (RFC 822) 2168 4. ipv4-addr. IPv4 host address in dotted-decimal notation 2169 (a.b.c.d) 2171 5. ipv4-net. IPv4 network address in dotted-decimal notation, 2172 slash, significant bits (a.b.c.d/nn) 2174 6. ipv4-net-mask. IPv4 network address in dotted-decimal 2175 notation, slash, network mask in dotted-decimal notation 2176 (a.b.c.d/w.x.y.z) 2178 7. ipv6-addr. IPv6 host address 2180 8. ipv6-net. IPv6 network address, slash, significant bits 2182 9. ipv6-net-mask. IPv6 network address, slash, network mask 2183 10. mac. Media Access Control (MAC) address 2185 11. site-uri. A URL or URI for a site. 2187 12. ext-value. An escape value used to extend this attribute. 2188 See Section 5.1. 2190 ext-category 2191 Optional. STRING. A means by which to extend the category 2192 attribute. See Section 5.1. 2194 vlan-name 2195 Optional. STRING. The name of the Virtual LAN to which the 2196 address belongs. 2198 vlan-num 2199 Optional. STRING. The number of the Virtual LAN to which the 2200 address belongs. 2202 indicator-uid 2203 Optional. STRING. A unique identifier for an Indicator. 2205 3.16.3. NodeRole Class 2207 The NodeRole class describes the intended function performed by a 2208 particular host. 2210 +---------------------+ 2211 | NodeRole | 2212 +---------------------+ 2213 | ENUM category | 2214 | STRING ext-category | 2215 | ENUM lang | 2216 +---------------------+ 2218 Figure 30: The NodeRole Class 2220 The NodeRole class has three attributes: 2222 category 2223 Required. ENUM. Functionality provided by a node. 2225 1. client. Client computer 2227 2. server-internal. Server with internal services 2228 3. server-public. Server with public services 2230 4. www. WWW server 2232 5. mail. Mail server 2234 6. messaging. Messaging server (e.g., NNTP, IRC, IM) 2236 7. streaming. Streaming-media server 2238 8. voice. Voice server (e.g., SIP, H.323) 2240 9. file. File server (e.g., SMB, CVS, AFS) 2242 10. ftp. FTP server 2244 11. p2p. Peer-to-peer node 2246 12. name. Name server (e.g., DNS, WINS) 2248 13. directory. Directory server (e.g., LDAP, finger, whois) 2250 14. credential. Credential server (e.g., domain controller, 2251 Kerberos) 2253 15. print. Print server 2255 16. application. Application server 2257 17. database. Database server 2259 18. infra. Infrastructure server (e.g., router, firewall, DHCP) 2261 19. log. Logserver (e.g., syslog) 2263 20. ext-value. An escape value used to extend this attribute. 2264 See Section 5.1. 2266 ext-category 2267 Optional. STRING. A means by which to extend the category 2268 attribute. See Section 5.1. 2270 lang 2271 Optional. ENUM. A valid language code per RFC 4646 [7] 2272 constrained by the definition of "xs:language". The 2273 interpretation of this code is described in Section 6. 2275 3.17. Service Class 2277 The Service class describes a network service of a host or network. 2278 The service is identified by specific port or list of ports, along 2279 with the application listening on that port. 2281 When Service occurs as an aggregate class of a System that is a 2282 source, then this service is the one from which activity of interest 2283 is originating. Conversely, when Service occurs as an aggregate 2284 class of a System that is a target, then that service is the one to 2285 which activity of interest is directed. 2287 This class was derived from the IDMEF [17]. 2289 +---------------------+ 2290 | Service | 2291 +---------------------+ 2292 | INTEGER ip_protocol |<>--{0..1}--[ Port ] 2293 | |<>--{0..1}--[ Portlist ] 2294 | |<>--{0..1}--[ ProtoCode ] 2295 | |<>--{0..1}--[ ProtoType ] 2296 | |<>--{0..1}--[ ProtoFlags ] 2297 | |<>--{0..1}--[ Application ] 2298 +---------------------+ 2300 Figure 31: The Service Class 2302 The aggregate classes that constitute Service are: 2304 Port 2305 Zero or one. INTEGER. A port number. 2307 Portlist 2308 Zero or one. PORTLIST. A list of port numbers formatted 2309 according to Section 2.10. 2311 ProtoCode 2312 Zero or one. INTEGER. A layer-4 protocol-specific code field 2313 (e.g., ICMP code field). 2315 ProtoType 2316 Zero or one. INTEGER. A layer-4 protocol specific type field 2317 (e.g., ICMP type field). 2319 ProtoFlags 2320 Zero or one. INTEGER. A layer-4 protocol specific flag field 2321 (e.g., TCP flag field). 2323 Application 2324 Zero or one. The application bound to the specified Port or 2325 Portlist. 2327 Either a Port or Portlist class MUST be specified for a given 2328 instance of a Service class. 2330 For a given source, System@type="source", a corresponding target, 2331 System@type="target", maybe defined, or vice versa. When a Portlist 2332 class is defined in the Service class of both the source and target 2333 in a given instance of the Flow class, there MUST be symmetry in the 2334 enumeration of the ports. Thus, if n-ports are listed for a source, 2335 n-ports should be listed for the target. Likewise, the ports should 2336 be listed in an identical sequence such that the n-th port in the 2337 source corresponds to the n-th port of the target. This symmetry in 2338 listing and sequencing of ports applies whether there are 1-to-1, 2339 1-to-many, or many-to-many sources-to-targets. In the 1-to-many or 2340 many-to-many, the exact order in which the System classes are 2341 enumerated in the Flow class is significant. 2343 The Service class has three attributes: 2345 ip_protocol 2346 Required. INTEGER. The IANA protocol number. 2348 indicator-uid 2349 Optional. STRING. A unique identifier for an Indicator. 2351 indicator-set-id 2352 Optional. STRING. The indicator set ID is used to group releated 2353 indicators. 2355 3.17.1. Application Class 2357 The Application class describes an application running on a System 2358 providing a Service. 2360 +--------------------+ 2361 | Application | 2362 +--------------------+ 2363 | STRING swid |<>--{0..1}--[ URL ] 2364 | STRING configid | 2365 | STRING vendor | 2366 | STRING family | 2367 | STRING name | 2368 | STRING version | 2369 | STRING patch | 2370 +--------------------+ 2372 Figure 32: The Application Class 2374 The aggregate class that constitute Application is: 2376 URL 2377 Zero or one. URL. A URL describing the application. 2379 The Application class has seven attributes: 2381 swid 2382 Optional. STRING. An identifier that can be used to reference 2383 this software, where the default value is "0". 2385 configid 2386 Optional. STRING. An identifier that can be used to reference a 2387 particular configuration of this software, where the default value 2388 is "0". 2390 vendor 2391 Optional. STRING. Vendor name of the software. 2393 family 2394 Optional. STRING. Family of the software. 2396 name 2397 Optional. STRING. Name of the software. 2399 version 2400 Optional. STRING. Version of the software. 2402 patch 2403 Optional. STRING. Patch or service pack level of the software. 2405 3.18. OperatingSystem Class 2407 The OperatingSystem class describes the operating system running on a 2408 System. The definition is identical to the Application class 2409 (Section 3.17.1). 2411 3.19. Record Class 2413 The Record class is a container class for log and audit data that 2414 provides supportive information about the incident. The source of 2415 this data will often be the output of monitoring tools. These logs 2416 should substantiate the activity described in the document. 2418 +------------------+ 2419 | Record | 2420 +------------------+ 2421 | ENUM restriction |<>--{1..*}--[ RecordData ] 2422 +------------------+ 2424 Figure 33: Record Class 2426 The aggregate class that constitutes Record is: 2428 RecordData 2429 One or more. Log or audit data generated by a particular type of 2430 sensor. Separate instances of the RecordData class SHOULD be used 2431 for each sensor type. 2433 The Record class has one attribute: 2435 restriction 2436 Optional. ENUM. This attribute has been defined in Section 3.2. 2438 3.19.1. RecordData Class 2440 The RecordData class groups log or audit data from a given sensor 2441 (e.g., IDS, firewall log) and provides a way to annotate the output. 2443 +------------------+ 2444 | RecordData | 2445 +------------------+ 2446 | ENUM restriction |<>--{0..1}--[ DateTime ] 2447 | |<>--{0..*}--[ Description ] 2448 | |<>--{0..1}--[ Application ] 2449 | |<>--{0..*}--[ RecordPattern ] 2450 | |<>--{1..*}--[ RecordItem ] 2451 | |<>--{0..1}--[ FileName ] 2452 | |<>--{0..*}--[ WindowsRegistryKeysModified ] 2453 | |<>--{0..*}--[ AdditionalData ] 2454 +------------------+ 2456 Figure 34: The RecordData Class 2458 The aggregate classes that constitutes RecordData is: 2460 DateTime 2461 Zero or one. Timestamp of the RecordItem data. 2463 Description 2464 Zero or more. ML_STRING. Free-form textual description of the 2465 provided RecordItem data. At minimum, this description should 2466 convey the significance of the provided RecordItem data. 2468 Application 2469 Zero or one. Information about the sensor used to generate the 2470 RecordItem data. 2472 RecordPattern 2473 Zero or more. A search string to precisely find the relevant data 2474 in a RecordItem. 2476 RecordItem 2477 One or more. Log, audit, or forensic data. 2479 FileName 2480 Zero or one. ML_STRING. The file name and hash of a file 2481 indicator. 2483 WindowsRegistryKeysModified 2484 Zero or more. The registry keys that were modified that are 2485 indicator(s). 2487 AdditionalData 2488 Zero or more. An extension mechanism for data not explicitly 2489 represented in the data model. 2491 The RecordData class has three attribute: 2493 restriction 2494 Optional. ENUM. This attribute has been defined in Section 3.2. 2496 indicator-uid 2497 Optional. STRING. A unique identifier for an Indicator. 2499 indicator-set-id 2500 Optional. STRING. The indicator set ID is used to group releated 2501 indicators. 2503 3.19.2. RecordPattern Class 2505 The RecordPattern class describes where in the content of the 2506 RecordItem relevant information can be found. It provides a way to 2507 reference subsets of information, identified by a pattern, in a large 2508 log file, audit trail, or forensic data. 2510 +-----------------------+ 2511 | RecordPattern | 2512 +-----------------------+ 2513 | STRING | 2514 | | 2515 | ENUM type | 2516 | STRING ext-type | 2517 | INTEGER offset | 2518 | ENUM offsetunit | 2519 | STRING ext-offsetunit | 2520 | INTEGER instance | 2521 +-----------------------+ 2523 Figure 35: The RecordPattern Class 2525 The specific pattern to search with in the RecordItem is defined in 2526 the body of the element. It is further annotated by four attributes: 2528 type 2529 Required. ENUM. Describes the type of pattern being specified in 2530 the element content. The default is "regex". 2532 1. regex. regular expression, per Appendix F of [3]. 2534 2. binary. Binhex encoded binary pattern, per the HEXBIN data 2535 type. 2537 3. xpath. XML Path (XPath) [5] 2539 4. ext-value. An escape value used to extend this attribute. 2540 See Section 5.1. 2542 ext-type 2543 Optional. STRING. A means by which to extend the type attribute. 2544 See Section 5.1. 2546 offset 2547 Optional. INTEGER. Amount of units (determined by the offsetunit 2548 attribute) to seek into the RecordItem data before matching the 2549 pattern. 2551 offsetunit 2552 Optional. ENUM. Describes the units of the offset attribute. 2553 The default is "line". 2555 1. line. Offset is a count of lines. 2557 2. byte. Offset is a count of bytes. 2559 3. ext-value. An escape value used to extend this attribute. 2560 See Section 5.1. 2562 ext-offsetunit 2563 Optional. STRING. A means by which to extend the offsetunit 2564 attribute. See Section 5.1. 2566 instance 2567 Optional. INTEGER. Number of types to apply the specified 2568 pattern. 2570 3.19.3. RecordItem Class 2572 The RecordItem class provides a way to incorporate relevant logs, 2573 audit trails, or forensic data to support the conclusions made during 2574 the course of analyzing the incident. The class supports both the 2575 direct encapsulation of the data, as well as, provides primitives to 2576 reference data stored elsewhere. 2578 This class is identical to AdditionalData class (Section 3.6). 2580 4. Processing Considerations 2582 This section defines additional requirements on creating and parsing 2583 IODEF documents. 2585 4.1. Encoding 2587 Every IODEF document MUST begin with an XML declaration, and MUST 2588 specify the XML version used. If UTF-8 encoding is not used, the 2589 character encoding MUST also be explicitly specified. The IODEF 2590 conforms to all XML data encoding conventions and constraints. 2592 The XML declaration with no character encoding will read as follows: 2594 2596 When a character encoding is specified, the XML declaration will read 2597 like the following: 2599 2601 Where "charset" is the name of the character encoding as registered 2602 with the Internet Assigned Numbers Authority (IANA), see [9]. 2604 The following characters have special meaning in XML and MUST be 2605 escaped with their entity reference equivalent: "&", "<", ">", "\"" 2606 (double quotation mark), and "'" (apostrophe). These entity 2607 references are "&", "<", ">", """, and "'" 2608 respectively. 2610 4.2. IODEF Namespace 2612 The IODEF schema declares a namespace of 2613 "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each 2614 IODEF document SHOULD include a valid reference to the IODEF schema 2615 using the "xsi:schemaLocation" attribute. An example of such a 2616 declaration would look as follows: 2618 2707 A given extension attribute MUST NOT be set unless the corresponding 2708 extensible attribute has been set to "ext-value". 2710 5.2. Extending Classes 2712 The classes of the data model can be extended only through the use of 2713 the AdditionalData and RecordItem classes. These container classes, 2714 collectively referred to as the extensible classes, are implemented 2715 with the iodef:ExtensionType data type in the schema. They provide 2716 the ability to have new atomic or XML-encoded data elements in all of 2717 the top-level classes of the Incident class and a few of the more 2718 complicated subordinate classes. As there are multiple instances of 2719 the extensible classes in the data model, there is discretion on 2720 where to add a new data element. It is RECOMMENDED that the 2721 extension be placed in the most closely related class to the new 2722 information. 2724 Extensions using the atomic data types (i.e., all values of the dtype 2725 attributes other than "xml") MUST: 2727 1. Set the element content of extensible class to the desired value, 2728 and 2730 2. Set the dtype attribute to correspond to the data type of the 2731 element content. 2733 The following guidelines exist for extensions using XML: 2735 1. The element content of the extensible class MUST be set to the 2736 desired value and the dtype attribute MUST be set to "xml". 2738 2. The extension schema MUST declare a separate namespace. It is 2739 RECOMMENDED that these extensions have the prefix "iodef-". 2741 3. It is RECOMMENDED that extension schemas follow the naming 2742 convention of the IODEF data model. The names of all elements 2743 are capitalized. For composed names, a capital letter is used 2744 for each word. Attribute names are lower case. 2746 4. When a parser encounters an IODEF document with an extension it 2747 does not understand, this extension MUST be ignored (and not 2748 processed), but the remainder of the document MUST be processed. 2749 Parsers will able to identify these extensions for which they 2750 have no processing logic through the namespace declaration. 2751 Parsers that encounter an unrecognized element in a namespace 2752 that they do support SHOULD reject the document as a syntax 2753 error. 2755 5. Implementations SHOULD NOT download schemas at runtime due to the 2756 security implications, and extensions MUST NOT be required to 2757 provide a resolvable location of their schema. 2759 The following schema and XML document excerpt provide a template for 2760 an extension schema and its use in the IODEF document. 2762 This example schema defines a namespace of "iodef-extension1" and a 2763 single element named "newdata". 2765 2769 attributeFormDefault="unqualified" 2770 elementFormDefault="qualified"> 2771 2775 2776 2778 The following XML excerpt demonstrates the use of the above schema as 2779 an extension to the IODEF. 2781 2788 2789 ... 2790 2791 2792 Field that could not be represented elsewhere 2793 2794 2795 2847 2849 2853 2854 189493 2855 2001-09-13T23:19:24+00:00 2856 Host sending out Code Red probes 2857 2858 2859 2860 2861 2862 Example.com CSIRT 2863 example-com 2864 contact@csirt.example.com 2865 2866 2867 2868 2869 2870
192.0.2.200
2871 57 2872 2874 2875 2876 2877
192.0.2.16/28
2878 2879 2880 80 2881 2882 2883 2884 2885 2886 2887 2888 2001-09-13T18:11:21+02:00 2889 Web-server logs 2890 2891 192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida? 2892 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2893 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2894 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2895 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2896 2897 2898 2899 http://mylogs.example.com/logs/httpd_access 2900 2901 2902 2903 2904 2905 2906 2001-09-14T08:19:01+00:00 2907 Notification sent to 2908 constituency-contact@192.0.2.200 2909 2910 2911 2912 2914 7.2. Reconnaissance 2916 An example of a CSIRT reporting a scanning activity. 2918 2919 2921 2925 2926 59334 2927 2006-08-02T05:54:02-05:00 2928 2929 2930 2931 2932 2933 2934 nmap 2935 http://nmap.toolsite.example.com 2936 2937 2938 2940 2941 CSIRT for example.com 2942 contact@csirt.example.com 2943 +1 412 555 12345 2944 2946 2947 Joe Smith 2948 smith@csirt.example.com 2949 2950 2951 2952 2958 2959 2960 2961
192.0.2.200
2962 2963 2964 60524,60526,60527,60531 2965 2966 2967 2968 2969
192.0.2.201
2970 2971 2972 137-139,445 2973 2974 2975 2976 2978 2979 2980 2981
192.0.2.240
2982 2983 2984 2985 2986
192.0.2.64/28
2987 2988 2989 445 2990 2991 2992 2993 2994 2995 2997 7.3. Bot-Net Reporting 2999 An example of a CSIRT reporting a bot-network. 3001 3002 3004 3008 3009 908711 3010 2006-06-08T05:44:53-05:00 3011 Large bot-net 3012 3013 3014 3015 3016 3017 3018 GT Bot 3019 3020 3022 3023 CA-2003-22 3024 http://www.cert.org/advisories/CA-2003-22.html 3025 Root compromise via this IE vulnerability to 3026 install the GT Bot 3027 3028 3029 3031 3032 Joe Smith 3033 jsmith@csirt.example.com 3034 3035 3036 These hosts are compromised and acting as bots 3037 communicating with irc.example.com. 3038 3039 3041 3042 3043
192.0.2.1
3044 3045 10000 3046 bot 3047 3048 3049 3050 3051
192.0.2.3
3052 3053 250000 3054 bot 3055 3056 3057 3058 3059 irc.example.com 3060
192.0.2.20
3061 2006-06-08T01:01:03-05:00 3062 3063 IRC server on #give-me-cmd channel 3064 3065 3066 3067 3068 Confirm the source and take machines off-line and 3069 remediate 3070 3071 3072 3073 3075 7.4. Watch List 3077 An example of a CSIRT conveying a watch-list. 3079 3080 3081 3084 3088 3089 908711 3090 2006-08-01T00:00:00-05:00 3091 Watch-list of known bad IPs or networks 3092 3093 3094 3095 3096 3097 CSIRT for example.com 3098 contact@csirt.example.com 3099 3100 3101 3102 3103 3104 3105
192.0.2.53
3106 3107 Source of numerous attacks 3108 3109 3110 3112 3113 3114 3115 3116 3117 3118
192.0.2.16/28
3119 3120 3121 Source of heavy scanning over past 1-month 3122 3123 3124 3125 3126 3127 3128
192.0.2.241
3129 3130 C2 IRC server 3131 3132 3133 3135 3136 3137 3138 3140 8. The IODEF Schema 3142 3149 3151 3152 3153 Incident Object Description Exchange Format v1.10, RFC5070-bis 3154 3155 3157 3162 3198 3203 3204 3205 3206 3208 3209 3211 3213 3215 3216 3217 3222 3223 3224 3225 3226 3227 3234 3235 3236 3238 3240 3242 3244 3247 3248 3250 3252 3254 3256 3258 3260 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3276 3278 3280 3281 3283 3284 3285 3290 3291 3292 3293 3294 3296 3298 3300 3301 3302 3304 3309 3310 3311 3312 3314 3315 3317 3318 3319 3324 3325 3326 3327 3329 3331 3332 3334 3335 3336 3341 3342 3347 3348 3349 3350 3352 3354 3356 3358 3360 3362 3364 3366 3368 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3385 3386 3387 3388 3389 3390 3392 3393 3394 3395 3397 3399 3400 3401 3403 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3425 3426 3427 3428 3430 3431 3432 3433 3434 3436 3437 3438 3439 3440 3441 3442 3444 3445 3446 3447 3449 3450 3451 3453 3458 3460 3462 3464 3466 3468 3470 3471 3472 3473 3474 3475 3480 3481 3482 3483 3485 3486 3489 3490 3491 3492 3493 3494 3495 3497 3499 3501 3503 3504 3506 3508 3510 3513 3515 3519 3521 3522 3523 3528 3529 3530 3531 3533 3535 3538 3540 3541 3543 3545 3547 3549 3551 3553 3556 3558 3559 3560 3565 3566 3567 3568 3569 3570 3571 3572 3574 3575 3577 3578 3579 3584 3585 3586 3587 3589 3591 3593 3594 3601 3603 3606 3608 3609 3610 3611 3613 3614 3615 3620 3621 3622 3623 3624 3625 3626 3627 3628 3630 3631 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3644 3647 3649 3653 3655 3656 3657 3658 3659 3660 3661 3663 3664 3665 3666 3667 3668 3669 3670 3671 3673 3674 3675 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3694 3695 3696 3697 3698 3699 3700 3701 3702 3704 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3717 3719 3721 3722 3723 3724 3725 3726 3727 3728 3729 3731 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3757 3758 3759 3760 3762 3764 3766 3768 3770 3772 3774 3776 3779 3781 3783 3785 3786 3788 3789 3791 3792 3793 3798 3799 3800 3801 3803 3804 3805 3806 3811 3812 3813 3814 3815 3817 3819 3821 3823 3825 3826 3828 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3847 3848 3850 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3867 3868 3869 3870 3871 3873 3876 3885 3886 3888 3890 3892 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3922 3925 3927 3930 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3970 3971 3972 3974 3975 3980 3981 3982 3983 3984 3986 3988 3989 3991 3993 3995 3997 4000 4001 4003 4005 4006 4008 4011 4013 4017 4019 4020 4021 4022 4023 4024 4025 4026 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4054 4056 4058 4060 4061 4062 4063 4064 4069 4070 4071 4072 4074 4075 4077 4078 4079 4080 4081 4082 4084 4086 4088 4090 4093 4094 4096 4098 4099 4105 4107 4109 4110 4112 4114 4116 4120 4122 4123 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4141 4143 4145 4146 4147 4148 4149 4150 4151 4152 4153 4155 4157 4158 4159 4160 4161 4163 4169 4170 4171 4172 4173 4174 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4194 4197 4200 4201 4202 4206 4208 4209 4210 4215 4220 4221 4222 4224 4225 4227 4229 4231 4233 4235 4240 4242 4244 4246 4247 4249 4252 4257 4259 4261 4266 4267 4268 4269 4270 4271 4272 4273 4274 4276 4277 4278 4279 4280 4281 4283 4284 4286 4288 4290 4292 4294 4295 4300 4301 4302 4303 4304 4305 4306 4307 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4375 4376 4377 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4396 9. Security Considerations 4398 The IODEF data model itself does not directly introduce security 4399 issues. Rather, it simply defines a representation for incident 4400 information. As the data encoded by the IODEF might be considered 4401 privacy sensitive by the parties exchanging the information or by 4402 those described by it, care needs to be taken in ensuring the 4403 appropriate disclosure during both document exchange and subsequent 4404 processing. The former must be handled by a messaging format, but 4405 the latter risk must be addressed by the systems that process, store, 4406 and archive IODEF documents and information derived from them. 4408 The contents of an IODEF document may include a request for action or 4409 an IODEF parser may independently have logic to take certain actions 4410 based on information that it finds. For this reason, care must be 4411 taken by the parser to properly authenticate the recipient of the 4412 document and ascribe an appropriate confidence to the data prior to 4413 action. 4415 The underlying messaging format and protocol used to exchange 4416 instances of the IODEF MUST provide appropriate guarantees of 4417 confidentiality, integrity, and authenticity. The use of a 4418 standardized security protocol is encouraged. The Real-time Inter- 4419 network Defense (RID) protocol [18] and its associated transport 4420 binding IODEF/RID over SOAP [19] provide such security. 4422 In order to suggest data processing and handling guidelines of the 4423 encoded information, the IODEF allows a document sender to convey a 4424 privacy policy using the restriction attribute. The various 4425 instances of this attribute allow different data elements of the 4426 document to be covered by dissimilar policies. While flexible, it 4427 must be stressed that this approach only serves as a guideline from 4428 the sender, as the recipient is free to ignore it. The issue of 4429 enforcement is not a technical problem. 4431 10. IANA Considerations 4433 This document uses URNs to describe an XML namespace and schema 4434 conforming to a registry mechanism described in [15] 4436 Registration for the IODEF namespace: 4438 o URI: urn:ietf:params:xml:ns:iodef-1.0 4440 o Registrant Contact: See the first author of the "Author's Address" 4441 section of this document. 4443 o XML: None. Namespace URIs do not represent an XML specification. 4445 Registration for the IODEF XML schema: 4447 o URI: urn:ietf:params:xml:schema:iodef-1.0 4449 o Registrant Contact: See the first author of the "Author's Address" 4450 section of this document. 4452 o XML: See the "IODEF Schema" in Section 8 of this document. 4454 11. Acknowledgments 4456 The following groups and individuals, listed alphabetically, 4457 contributed substantially to this document and should be recognized 4458 for their efforts. 4460 o Patrick Cain, Cooper-Cain Group, Inc. 4462 o The eCSIRT.net Project 4464 o The Incident Object Description and Exchange Format Working-Group 4465 of the TERENA task-force (TF-CSIRT) 4467 o Glenn Mansfield Keeni, Cyber Solutions, Inc. 4469 o Hiroyuki Kido, NARA Institute of Science and Technology 4471 o Kathleen Moriarty, EMC Corporation 4473 o Brian Trammell, ETH Zurich 4475 o Jan Meijer, SURFnet bv 4477 o Yuri Demchenko, University of Amsterdam 4479 12. References 4481 12.1. Normative References 4483 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 4484 1.0 (Second Edition)", W3C Recommendation , October 2000, 4485 . 4487 [2] World Wide Web Consortium, "XML XML Schema Part 1: Structures 4488 Second Edition", W3C Recommendation , October 2004, 4489 . 4491 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second 4492 Edition", W3C Recommendation , October 2004, 4493 . 4495 [4] World Wide Web Consortium, "Namespaces in XML", W3C 4496 Recommendation , January 1999, 4497 . 4499 [5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C 4500 Candidate Recommendation , June 2006, 4501 . 4503 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4504 Levels", RFC 2119, March 1997. 4506 [7] Philips, A. and M. Davis, "Tags for Identifying of Languages", 4507 RFC 4646, September 2006. 4509 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4510 Resource Identifiers (URI): Generic Syntax", RFC 3986, 4511 January 2005`. 4513 [9] Freed, N. and J. Postel, "IANA Charset Registration 4514 Procedures", BCP 2978, October 2000. 4516 [10] Sciberras, A., "Schema for User Applications", RFC 4519, 4517 June 2006. 4519 [11] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 4521 [12] Klyne, G. and C. Newman, "Date and Time on the Internet: 4522 Timestamps", RFC 3339, July 2002. 4524 [13] International Organization for Standardization, "International 4525 Standard: Data elements and interchange formats - Information 4526 interchange - Representation of dates and times", ISO 8601, 4527 Second Edition, December 2000. 4529 [14] International Organization for Standardization, "International 4530 Standard: Codes for the representation of currencies and funds, 4531 ISO 4217:2001", ISO 4217:2001, August 2001. 4533 [15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 4535 12.2. Informative References 4537 [16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the 4538 Format for Incident Information Exchange (FINE)", Work 4539 in Progress, June 2006. 4541 [17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion 4542 Detection Message Exchange Format", RFC 4765, March 2007. 4544 [18] Moriarty, K., "Real-time Inter-network Defense", Work 4545 in Progress, April 2007. 4547 [19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work 4548 in Progress, April 2007. 4550 [20] Shafranovich, Y., "Common Format and MIME Type for Comma- 4551 Separated Values (CSV) File", RFC 4180, October 2005. 4553 Authors' Addresses 4555 Roman Danyliw 4556 CERT - Software Engineering Institute 4557 Pittsburgh, PA 4558 USA 4560 EMail: rdd@cert.org 4562 Paul Stoecker 4563 RSA 4564 Reston, VA 4565 USA 4567 EMail: paul.stoecker@rsa.com