idnits 2.17.1 draft-takahashi-mile-sci-02.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 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([ISOIEC19770-2], [XCCDF], [OVAL], [CVSS], [CWE], [TM], [CWSS], [CEE], [RFC5070], [OCIL], [CPE], [CAPEC], [XDAS], [CVRF], [CVE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 29, 2011) is 4562 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TM' is mentioned on line 22, but not defined == Unused Reference: 'RFC3339' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1107, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 6045 (Obsoleted by RFC 6545) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission T. Takahashi 3 Internet-Draft NICT 4 Intended status: Standards Track K. Landfield 5 Expires: May 1, 2012 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NICT 10 Oct 29, 2011 12 IODEF-extension to support structured cybersecurity information 13 draft-takahashi-mile-sci-02.txt 15 Abstract 17 This document extends the Incident Object Description Exchange Format 18 (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched 19 cybersecurity information exchange among cybersecurity entities by 20 embedding structured information formatted by specifications, 21 including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) 22 [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], ISO/ 23 IEC 19770-2 [ISOIEC19770-2], OCIL [OCIL], OVAL(R) [OVAL], XCCDF 24 [XCCDF], and XDAS [XDAS]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 1, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Structured Cybersecurity Information Formats . . . . . . . 4 65 4.2. Extended Data Types . . . . . . . . . . . . . . . . . . . 5 66 4.2.1. EM_XML . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 6 68 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 7 69 4.3.2. PlatformID . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 9 71 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13 74 4.3.7. Remediation . . . . . . . . . . . . . . . . . . . . . 14 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 16 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 18 79 6.2. Using the iodef:restriction Attribute . . . . . . . . . . 19 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 20 82 9. Appendix: XML Schema Definition for Extension . . . . . . . . 20 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 Cyber attacks are getting more sophisticated, and their numbers are 91 increasing day by day. To cope with such situation, incident 92 information needs to be reported, exchanged, and shared among 93 organizations. IODEF is one of the tools enabling such exchange, and 94 is already in use. 96 To efficiently run cybersecurity operations, these exchanged 97 information needs to be machine-readable. IODEF provides a 98 structured means to describe the information, but it needs to embed 99 various non-structured such information in order to convey detailed 100 information. Further structure within IODEF increases IODEF 101 documents' machine-readability and thus facilitates streamlining 102 cybersecurity operations. 104 On the other hand, there exist various other activities facilitating 105 detailed and structured description of cybersecurity information, 106 major of which includes CAPEC [CAPEC], CEE [CEE], CPE [CPE], CVE 107 [CVE], CVRF [CVRF], CVSS [CVSS], CWE [CWE], CWSS [CWSS], ISO/IEC 108 19770-2 [ISOIEC19770-2], OCIL [OCIL], OVAL [OVAL], XCCDF [XCCDF], and 109 XDAS [XDAS]. Since such structured description facilitates 110 cybersecurity operations, it would be beneficial to embed and convey 111 these information inside IODEF document. 113 To enable that, this document extends the IODEF to embed and convey 114 various structured cybersecurity information, with which 115 cybersecurity operations can be facilitated. Since IODEF defines a 116 flexible and extensible format and supports a granular level of 117 specificity, this document defines an extension to IODEF instead of 118 defining a new report format. For clarity, and to eliminate 119 duplication, only the additional structures necessary for describing 120 the exchange of such structured information are provided. 122 2. Terminology 124 The terminology used in this document follows the one defined in RFC 125 5070 [RFC5070]. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 3. Applicability 133 To maintain cybersecurity, organization needs to exchange 134 cybersecurity information, which includes the following information: 135 attack pattern, platform information, vulnerability and weakness, 136 countermeasure instruction, computer event log, and the severity. 138 IODEF provides a scheme to exchange such information among interested 139 parties. However, the detailed common format to describe such 140 information is not defined in the IODEF base document. 142 On the other hand, to describe those information and to facilitate 143 exchange, a structured format for that is already available. Major 144 of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OVAL, and 145 XCCDF. By embedding them into the IODEF document, the document can 146 convey more detailed contents to the receivers, and the document can 147 be easily reused. 149 These structured cybersecurity information facilitates cybersecurity 150 operation at the receiver side. Since the information is machine- 151 readable, the data can be processed by computers. That expedites the 152 automation of cybersecurity operations 154 For instance, an organization wishing to report a security incident 155 wants to describe what vulnerability was exploited. Then the sender 156 can simply use IODEF, where an CAPEC record is embedded instead of 157 describing everything in free format text. Receiver can also 158 identify the needed details of the attack pattern by looking up some 159 of the xml tags defined by CAPEC. Receiver can accumulate the attack 160 pattern information (CAPEC record) in its database and could 161 distribute it to the interested parties if needed, without needing 162 human interventions. 164 4. Extension Definition 166 This draft extends IODEF to embed structured cybersecurity 167 information by introducing new classes, with which these information 168 can be embedded inside IODEF document as element contents of 169 AdditionalData and RecordItem classes. 171 4.1. Structured Cybersecurity Information Formats 173 This extension intends to embed various structured cybersecurity 174 information. The below table describes the initial list of supported 175 specifications and their IDs, versions, and namespaces; future 176 assignments are to be made through Expert Review, as requested in 177 Section 7. 179 ID Specification Name Version Namespace 180 --------- ---------------------- ------- ------------------------ 181 CAPEC_1.6 Common Attack Pattern 1.6 http://capec.mitre.org 182 Enumeration and /observables 183 Classification (CAPEC) 184 CEE_0.6 Common Event Expression 0.6 http://cee.mitre.org 185 (CEE) 186 CPE_2.3 Common Platform 2.3 http://cpe.mitre.org 187 Enumeration (CPE) /dictionary/2.0 188 CVE_1.0 Common Vulnerability 1.0 http://cve.mitre.org 189 and Exposures (CVE) /cve/downloads/1.0 190 CVRF_1.0 Common Vulnerability 1.0 http://www.icasi.org 191 Reporting Format /CVRF/schema/cvrf/1.0 192 (CVRF) 193 CVSS_2.0 Common Vulnerability 2 http://scap.nist.gov 194 Scoring System (CVSS) /schema/cvss-v2/1.0 195 CWE_5.0 Common Weakness 5.1 N/A 196 Enumeration (CWE) 197 CWSS_0.8 Common Weakness 0.8 N/A 198 Scoring System (CWSS) 199 OCIL_2.0 Open Checklist 2.0 http://scap.nist.gov 200 Interactive Language /schema/ocil/2.0 201 (OCIL) 202 OVAL_5.10 Open Vulnerability and 5.10 http://oval.mitre.org 203 Assessment Language /XMLSchema 204 (OVAL) /oval-definitions-5 205 XCCDF_1.2 Extensible 1.2 http://checklists.nist 206 Configuration .gov/xccdf/1.2 207 Checklist Description 208 Format (XCCDF) 209 XDAS_1998 Distributed Audit 1998 N/A 210 Service (XDAS) 211 19770-2 ISO/IEC 19770 Part 2 N/A 213 Figure 1: List of specifications 215 4.2. Extended Data Types 217 This extension inherits all of the data types defined in the IODEF 218 model. One data type is added: EM_XML. 220 4.2.1. EM_XML 222 An embedded complete XML document is represented by the EM_XML data 223 type. The elements of the document must match its root namespace 224 element. 226 4.3. Extended Classes 228 The IODEF Incident element [RFC5070] is summarized below. It is 229 expressed in Unified Modeling Language (UML) syntax as used in the 230 IODEF specification. The UML representation is for illustrative 231 purposes only; elements are specified in XML as defined in Appendix 232 A. 234 +--------------------+ 235 | Incident | 236 +--------------------+ 237 | ENUM purpose |<>---------[ IncidentID ] 238 | STRING ext-purpose |<>--{0..1}-[ AlternativeID ] 239 | ENUM lang |<>--{0..1}-[ RelatedActivity ] 240 | ENUM restriction |<>--{0..1}-[ DetectTime ] 241 | |<>--{0..1}-[ StartTime ] 242 | |<>--{0..1}-[ EndTime ] 243 | |<>---------[ ReportTime ] 244 | |<>--{0..*}-[ Description ] 245 | |<>--{1..*}-[ Assessment ] 246 | |<>--{0..*}-[ Method ] 247 | | |<>--[ AdditionalData ] 248 | | |<>--[ AttackPattern ] 249 | | |<>--[ Vulnerability ] 250 | | |<>--[ Weakness ] 251 | |<>--{1..*}-[ Contact ] 252 | |<>--{0..*}-[ EventData ] 253 | | |<>--[ Flow ] 254 | | | |<>--[ System ] 255 | | | |<>--[ AdditionalData ] 256 | | | |<>--[ PlatformID ] 257 | | |<>--[ Expectation ] 258 | | |<>--[ Record ] 259 | | |<>--[ RecordData ] 260 | | |<>--[ RecordItem ] 261 | | |<>--[ EventReport ] 262 | |<>--{0..1}-[ History ] 263 | |<>--{0..*}-[ AdditionalData ] 264 | | |<>--[ Remediation ] 265 +--------------------+ 267 Figure 2: Incident class 269 This extension defines the following seven elements. 271 4.3.1. AttackPattern 273 An AttackPattern consists of an extension to the 274 Incident.Method.AdditionalData element with a dtype of "xml". The 275 extension describes attack patterns of incidents or events. 277 It is recommended that Method class SHOULD contain one or more of the 278 extension elements whenever available. 280 An AttackPattern class is structured as follows. 282 +------------------------+ 283 | AttackPattern | 284 +------------------------+ 285 | STRING Version |<>--(0..*)-[ Record ] 286 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 287 | STRING AttackPatternID |<>--(0..*)-[ PlatformID ] 288 +------------------------+ 290 Figure 3: AttackPattern class 292 This class has the following attributes. 294 Version: OPTIONAL. STRING. The version number of the extension 295 specification to which this class conforms. This value should be 296 1.00, to be compliant with this document. Its default value is 297 1.00. 299 SpecificationID: REQUIRED. ENUM. The ID of the specification and 300 its version specifying the format of the Record element. The 301 value should be chosen from the IDs listed in Figure 1, such as 302 CAPEC_1.6. Note that the lists in Figure 1 will be developed 303 further by IANA. 305 AttackPatternID: OPTIONAL. STRING. An ID of an attack pattern to 306 be reported. This attribute SHOULD be used whenever such ID is 307 available. In case a Record or Reference element is provided 308 along with this attribute, writers/senders MUST ensure that this 309 ID is consistent with the one provided by the element; if a 310 reader/receiver detects an inconsistency, it SHOULD prefer the 311 value of this attribute, and SHOULD log the inconsistency so a 312 human can correct the problem. Note that this attribute could be 313 omitted if no such ID is available. In this case, either Record 314 or Reference elements, or both of them, MUST be provided. 316 The AttackPattern class is composed of the following aggregate 317 classes. 319 Record: Zero or more. EM_XML. A complete document that is 320 formatted according to the specification and its version 321 identified by the value of the SpecificationID with the Figure 1. 323 Reference: Zero or more of iodef:Reference [RFC5070]. This element 324 allows an IODEF document to include a link to a structured 325 information instead of directly embedding it into a Record 326 element. 328 PlatformID: Zero or more. An identifier of software platform 329 involved in the specific attack pattern, which is elaborated in 330 Section 4.3.2. Some of the structured information embedded in the 331 Record element may include the identifier within it. In this 332 case, this PlatformID element SHOULD NOT be used. If a reader/ 333 receiver detects the identifiers in both Record and PlatformID 334 elements and their inconsistency, it SHOULD prefer the identifiers 335 derived from the PlatformID element, and SHOULD log the 336 inconsistency so a human can correct the problem. 338 Writers/senders MUST ensure the specification name and version 339 identified by the SpecificationID are consistent with the contents of 340 the Record; if a reader/receiver detects an inconsistency, it SHOULD 341 prefer the specification name and version derived from the content, 342 and SHOULD log the inconsistency so a human can correct the problem. 344 4.3.2. PlatformID 346 A PlatformID identifies a software platform. It is recommended that 347 AttackPattern, Vulnerability, Weakness, and System classes contain 348 this elements whenever available. 350 A PlatformID element is structured as follows. 352 +----------------------+ 353 | PlatformID | 354 +----------------------+ 355 | STRING Version |<>--(1..*)-[ ID ] 356 | ENUM SpecificationID | 357 +----------------------+ 359 Figure 4: PlatformID class 361 This class has the following attributes. 363 Version: OPTIONAL. STRING. The version number of the extension 364 specification to which this class conforms. This value should be 365 1.00, to be compliant with this document. Its default value is 366 1.00. 368 SpecificationID: REQUIRED. ENUM. The ID of the specification and 369 its version specifying the format of the ID element. The value 370 should be chosen from the IDs listed in Figure 1, such as CPE_2.3 371 and ISO/IEC 19770-2. Note that the lists in Figure 1 will be 372 developed further by IANA. 374 This class is composed of the following aggregate classes. 376 ID: One or more. ML_STRING. An ID that is formatted according to 377 the rule defined by the specification and its version identified 378 by the value of the SpecificationID with the Figure 1. 380 Writers/senders MUST ensure the specification name and version 381 identified by the SpecificationID are consistent with the contents of 382 the ID; if a reader/receiver detects an inconsistency, it SHOULD 383 prefer the specification name and version derived from the content, 384 and SHOULD log the inconsistency so a human can correct the problem. 386 4.3.3. Vulnerability 388 A Vulnerability consists of an extension to the 389 Incident.Method.AdditionalData element with a dtype of "xml". The 390 extension describes the (candidate) vulnerabilities of incidents or 391 events. 393 It is recommended that Method class SHOULD contain one or more of the 394 extension elements whenever available. 396 A Vulnerability element is structured as follows. 398 +------------------------+ 399 | Vulnerability | 400 +------------------------+ 401 | STRING Version |<>--(0..*)-[ Record ] 402 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 403 | STRING VulnerabilityID |<>--(0..*)-[ PlatformID ] 404 | |<>--(0..*)-[ Scoring ] 405 +------------------------+ 407 Figure 5: Vulnerability class 409 This class has the following attributes. 411 Version: OPTIONAL. STRING. The version number of the extension 412 specification to which this class conforms. This value should be 413 1.00, to be compliant with this document. Its default value is 414 1.00. 416 SpecificationID: REQUIRED. ENUM. The ID of the specification and 417 its version specifying the format of the Record element. The 418 value should be chosen from the IDs listed in Figure 1, such as 419 CVE_1.0 and CVRF_1.0. Note that the lists in Figure 1 will be 420 developed further by IANA. 422 VulnerabilityID: OPTIONAL. STRING. An ID of a vulnerability to be 423 reported. This attribute SHOULD be used whenever such ID is 424 available. In case a Record or Reference element is provided 425 along with this attribute, writers/senders MUST ensure that this 426 ID is consistent with the one provided by the element; if a 427 reader/receiver detects an inconsistency, it SHOULD prefer the 428 value of this attribute, and SHOULD log the inconsistency so a 429 human can correct the problem. Note that this attribute could be 430 omitted if no such ID is available. In this case, either Record 431 or Reference elements, or both of them, MUST be provided. 433 This class is composed of the following aggregate classes. 435 Record: Zero or one. EM_XML. A complete document that is formatted 436 according to the specification and its version identified by the 437 value of the SpecificationID with the Figure 1. 439 Reference: Zero or one of iodef:Reference [RFC5070]. This element 440 allows an IODEF document to include a link to a structured 441 information instead of directly embedding it into a Record 442 element. 444 PlatformID: Zero or more. An identifier of software platform 445 affected by the vulnerability, which is elaborated in 446 Section 4.3.2. Some of the structured information embedded in the 447 Record element may include the identifier within it. In this 448 case, this PlatformID element SHOULD NOT be used. If a reader/ 449 receiver detects the identifiers in both Record and PlatformID 450 elements and their inconsistency, it SHOULD prefer the identifiers 451 derived from the PlatformID element, and SHOULD log the 452 inconsistency so a human can correct the problem. 454 Scoring: Zero or more. An indicator of the severity of the 455 vulnerability, such as CVSS score, which is elaborated in 456 Section 4.3.4. Some of the structured information may include 457 scores within it. In this case, the Scoring element SHOULD NOT be 458 used since the Record element contains the scores. If a reader/ 459 receiver detects scores in both Record and Scoring elements and 460 their inconsistency, it SHOULD prefer the scores derived from the 461 Record element, and SHOULD log the inconsistency so a human can 462 correct the problem. 464 4.3.4. Scoring 466 A Scoring class describes the scores of the severity in terms of 467 security. It is recommended that Vulnerability and Weakness classes 468 contain the elements whenever available. 470 A Scoring class is structured as follows. 472 +----------------------+ 473 | Scoring | 474 +----------------------+ 475 | STRING Version |<>---------[ Score ] 476 | ENUM SpecificationID | 477 +----------------------+ 479 Figure 6: Scoring class 481 This class has two attributes. 483 Version: OPTIONAL. STRING. The version number of the extension 484 specification to which this class conforms. This value should be 485 1.00, to be compliant with this document. Its default value is 486 1.00. 488 SpecificationID: REQUIRED. STRING. The ID of the specification and 489 its version specifying the format of the Score element. The value 490 should be chosen from the IDs listed in Figure 1, such as CVSS_2.0 491 and CWSS_0.8. Note that the lists in Figure 1 will be developed 492 further by IANA. 494 This class is composed of an aggregate class. 496 Score: One. EM_XML. Arbitrary information structured by the 497 specification identified by the specification and its version 498 identified by the value of the SpecificationID with the Figure 1. 500 Writers/senders MUST ensure the specification name and version 501 identified by the SpecificationID are consistent with the contents of 502 the Score; if a reader/receiver detects an inconsistency, it SHOULD 503 prefer the specification name and version derived from the content, 504 and SHOULD log the inconsistency so a human can correct the problem. 506 4.3.5. Weakness 508 A Weakness consists of an extension to the 509 Incident.Method.AdditionalData element with a dtype of "xml". The 510 extension describes the weakness types of incidents or events. 512 It is recommended that Method class SHOULD contain one or more of the 513 extension elements whenever available. 515 A Weakness element is structured as follows. 517 +----------------------+ 518 | Weakness | 519 +----------------------+ 520 | STRING Version |<>--(0..*)-[ Record ] 521 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 522 | STRING WeaknessID |<>--(0..*)-[ PlatformID ] 523 | |<>--(0..*)-[ Scoring ] 524 +----------------------+ 526 Figure 7: Weakness class 528 This class has the following attributes. 530 Version: OPTIONAL. STRING. The version number of the extension 531 specification to which this class conforms. This value should be 532 1.00, to be compliant with this document. Its default value is 533 1.00. 535 SpecificationID: REQUIRED. ENUM. The ID of the specification and 536 its version specifying the format of the Record element. The 537 value should be chosen from the IDs listed in Figure 1, such as 538 CWE_5.0. Note that the lists in Figure 1 will be developed 539 further by IANA. 541 WeaknessID: OPTIONAL. STRING. An ID of a weakness to be reported. 542 This attribute SHOULD be used whenever such ID is available. In 543 case a Record or Reference elements is provided along with this 544 attribute, writers/senders MUST ensure that this ID is consistent 545 with the one provided by the element; if a reader/receiver detects 546 an inconsistency, it SHOULD prefer the value of this attribute, 547 and SHOULD log the inconsistency so a human can correct the 548 problem. Note that this attribute could be omitted if no such ID 549 is available. In this case, either Record or Reference elements, 550 or both of them, MUST be provided. 552 This class is composed of the following aggregate classes. 554 Record: Zero or more. EM_XML. A complete document that is 555 formatted according to the specification and its version 556 identified by the value of the SpecificationID with the Figure 1. 558 Reference: Zero or one of iodef:Reference [RFC5070]. This element 559 allows an IODEF document to include a link to a structured 560 information instead of directly embedding it into a Record 561 element. 563 PlatformID: Zero or more. An identifier of software platform 564 affected by the weakness, which is elaborated in Section 4.3.2. 565 Some of the structured information embedded in the Record element 566 may include the identifier within it. In this case, this 567 PlatformID element SHOULD NOT be used. If a reader/receiver 568 detects the identifiers in both Record and PlatformID elements and 569 their inconsistency, it SHOULD prefer the identifiers derived from 570 the PlatformID element, and SHOULD log the inconsistency so a 571 human can correct the problem. 573 Scoring: Zero or more. An indicator of the severity of the 574 weakness, such as CWSS score, which is elaborated in 575 Section 4.3.4. Some of the structured information may include 576 scores within it. In this case, the Scoring element SHOULD NOT be 577 used since the Record element contains the scores. If a reader/ 578 receiver detects scores in both Record and Scoring elements and 579 their inconsistency, it SHOULD prefer the scores derived from the 580 Record element, and SHOULD log the inconsistency so a human can 581 correct the problem. 583 4.3.6. EventReport 585 An EventReport consists of an extension to the 586 Incident.EventData.Record.RecordData.RecordItem element with a dtype 587 of "xml". The extension embeds structured event reports. 589 It is recommended that RecordItem class SHOULD contain one or more of 590 the extension elements whenever available. 592 An EventReport element is structured as follows. 594 +----------------------+ 595 | EventReport | 596 +----------------------+ 597 | STRING Version |<>--(0..*)-[ Record ] 598 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 599 +----------------------+ 601 Figure 8: EventReport class 603 This class has the following attributes. 605 Version: OPTIONAL. STRING. The version number of the extension 606 specification to which this class conforms. This value should be 607 1.00, to be compliant with this document. Its default value is 608 1.00. 610 SpecificationID: REQUIRED. ENUM. The ID of the specification and 611 its version specifying the format of the Record element. The 612 value should be chosen from the IDs listed in Figure 1, such as 613 CEE_0.6 and XDAS_1998. Note that the lists in Figure 1 will be 614 developed further by IANA. 616 This class is composed of three aggregate classes. 618 Record: Zero or one. EM_XML. A complete document that is formatted 619 according to the specification and its version identified by the 620 value of the SpecificationID with the Figure 1. 622 Reference: Zero or one of iodef:Reference [RFC5070]. This element 623 allows an IODEF document to include a link to a structured 624 information instead of directly embedding it into a Record 625 element. 627 This class MUST contain at least one of Record or Reference elements. 628 Writers/senders MUST ensure the specification name and version 629 identified by the SpecificationID are consistent with the contents of 630 the Record; if a reader/receiver detects an inconsistency, it SHOULD 631 prefer the specification name and version derived from the content, 632 and SHOULD log the inconsistency so a human can correct the problem. 634 4.3.7. Remediation 636 A Remediation consists of an extension to the Incident.AdditionalData 637 element with a dtype of "xml". The extension elements describes 638 incident remediation information including instructions. Note that 639 the term remediation includes a range of concepts, e.g., valudation. 641 It is recommended that Incident class SHOULD contain one or more of 642 this extension elements whenever available. 644 A Remediation class is structured as follows. 646 +----------------------+ 647 | Remediation | 648 +----------------------+ 649 | STRING Version |<>--(0..*)-[ Record ] 650 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 651 +----------------------+ 653 Figure 9: Remediation class 655 This class has an attribute. 657 Version: OPTIONAL. STRING. The version number of the extension 658 specification to which this class conforms. This value should be 659 1.00, to be compliant with this document. Its default value is 660 1.00. 662 SpecificationID: REQUIRED. ENUM. The ID of the specification and 663 its version specifying the format of the Record element. The 664 value should be chosen from the IDs listed in Figure 1, such as 665 OVAL_5.10, OCIL_2.0, and XCCDF_1.2. Note that the lists in 666 Figure 1 will be developed further by IANA. 668 This class is composed of three aggregate classes. 670 Record: Zero or one. EM_XML. A complete document that is formatted 671 according to the specification and its version identified by the 672 value of the SpecificationID with the Figure 1. 674 Reference: Zero or one of iodef:Reference [RFC5070]. This element 675 allows an IODEF document to include a link to a structured 676 information instead of directly embedding it into a Record 677 element. 679 This class MUST contain at least either of Record and Reference 680 elements. Writers/senders MUST ensure the specification name and 681 version identified by the SpecificationID are consistent with the 682 contents of the Record; if a reader/receiver detects an 683 inconsistency, it SHOULD prefer the specification name and version 684 derived from the content, and SHOULD log the inconsistency so a human 685 can correct the problem. 687 5. Examples 689 This section provides examples of an incident encoded in the IODEF. 690 These examples do not necessarily represent the only way to encode a 691 particular incident. 693 5.1. Reporting an attack 695 An example of a CSIRT reporting an attack. 697 698 703 704 189493 705 2001-09-13T23:19:24+00:00 706 Incident report in company xx 707 708 709 710 711 712 Structured information on attack pattern, exploited 713 vulnerability, and weakness 714 715 717 [CAPEC-formatted data] 718 719 Link to Capec-14 720 http://capec.mitre.org/data/definitions/14.html 721 722 723 725 [CVE-formatted data] 726 727 [CPE ID] 728 729 730 [CVSS scores] 731 732 733 735 [CWE-formatted data] 736 737 [CWSS scores] 738 739 740 742 743 744 Example.com CSIRT 745 example-com 746 contact@csirt.example.com 747 748 749 750 751 752
192.0.2.200
753 57 754 755 756 757 758
192.0.2.16/28
759 760 761 80 762 763 764 765 [CPE ID] 766 767 768 769 770 771 772 773 774 775 2001-09-13T18:11:21+02:00 776 a Web-server event record 777 778 779 [CEE-formatted data] 780 781 782 783 784 785 786 787 788 2001-09-14T08:19:01+00:00 789 Notification sent to 790 constituency-contact@192.0.2.200 791 792 793 794 795 [OVAL-formatted data] 796 797 798 [XCCDF-formatted data] 799 800 801 802 804 Figure 10: Example UML Element Diagram 806 6. Security Considerations 808 This document specifies a format for encoding a particular class of 809 security incidents appropriate for exchange across organizations. As 810 merely a data representation, it does not directly introduce security 811 issues. However, it is guaranteed that parties exchanging instances 812 of this specification will have certain concerns. For this reason, 813 the underlying message format and transport protocol used MUST ensure 814 the appropriate degree of confidentiality, integrity, and 815 authenticity for the specific environment. 817 Organizations that exchange data using this document are URGED to 818 develop operating procedures that document the following areas of 819 concern. 821 6.1. Transport-Specific Concerns 823 The underlying messaging format and protocol used to exchange 824 instances of the IODEF MUST provide appropriate guarantees of 825 confidentiality, integrity, and authenticity. The use of a 826 standardized security protocol is encouraged. The Real-time Inter- 827 network Defense (RID) protocol [RFC6045] and its associated transport 828 binding [RFC6046] provide such security. 830 The critical security concerns are that these structured information 831 may be falsified or they may become corrupt during transit. In areas 832 where transmission security or secrecy is questionable, the 833 application of a digital signature and/or message encryption on each 834 report will counteract both of these concerns. We expect that each 835 exchanging organization will determine the need, and mechanism, for 836 transport protection. 838 6.2. Using the iodef:restriction Attribute 840 In some instances, data values in particular elements may contain 841 data deemed sensitive by the reporter. Although there are no 842 general-purpose rules on when to mark certain values as "private" or 843 "need-to-know" via the iodef:restriction attribute, the reporter is 844 cautioned not to apply element-level sensitivity markings unless they 845 believe the receiving party (i.e., the party they are exchanging the 846 event report data with) has a mechanism to adequately safeguard and 847 process the data as marked. 849 7. IANA Considerations 851 This document uses URNs to describe XML namespaces and XML schemata 852 conforming to a registry mechanism described in [RFC3688]. 854 Registration request for the IODEF structured cybersecurity 855 information extension namespace: 857 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 859 Registrant Contact: Refer here to the authors' addresses section 860 of the document. 862 XML: None 864 Registration request for the IODEF structured cybersecurity 865 information extension XML schema: 867 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 869 Registrant Contact: Refer here to the authors' addresses section 870 of the document. 872 XML: Refer here to the XML Schema in the appendix of the document. 874 Request for managing a namespace list: 876 the schemata of the embedded structured information are maintained 877 outside of the IETF currently, but the list of the embedded 878 specifications' namespaces need to be registered to IANA 879 repository. The initial list of the namespaces are shown in 880 Figure 1. 882 8. Acknowledgment 884 The following groups and individuals, listed alphabetically, 885 contributed substantially to this document and should be recognized 886 for their efforts. 888 Paul Cichonski, NIST 890 Black David, EMC 892 Robert Martin, MITRE 894 Kathleen Moriarty, EMC 896 Lagadec Philippe, NATO 898 Shuhei Yamaguchi, NICT 900 Anthony Rutkowski, Yaana Technology 902 Brian Trammell, CERT/NetSA 904 9. Appendix: XML Schema Definition for Extension 906 The XML Schema describing the elements defined in the Extension 907 Definition section is given here. Each of the examples in Section 5 908 should be verified to validate against this schema by automated 909 tools. [Note: this section will be thoroughly checked later.] 911 913 920 924 928 929 930 931 932 933 935 937 938 940 944 945 946 947 949 951 953 954 956 957 958 959 961 965 966 967 968 970 972 974 976 977 979 981 983 984 986 990 991 992 993 995 997 999 1001 1002 1004 1006 1008 1009 1011 1015 1016 1017 1018 1020 1021 1023 1026 1027 1029 1033 1034 1035 1036 1037 1038 1039 1040 1041 1043 1045 1046 1048 1052 1053 1054 1055 1056 1057 1058 1059 1060 1062 1064 1065 1067 1069 Example Schema Diagram 1071 10. References 1072 10.1. Normative References 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, March 1997. 1077 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1078 Object Description Exchange Format", RFC 5070, 1079 December 2007. 1081 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1082 RFC 6045, November 2010. 1084 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1085 Inter-network Defense (RID) Messages", RFC 6046, 1086 November 2010. 1088 10.2. Informative References 1090 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1091 Internet: Timestamps", RFC 3339, July 2002. 1093 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1094 Text on Security Considerations", BCP 72, RFC 3552, 1095 July 2003. 1097 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1098 January 2004. 1100 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1101 Resource Identifier (URI): Generic Syntax", STD 66, 1102 RFC 3986, January 2005. 1104 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1105 October 2008. 1107 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1108 Uniform Resource Identifiers (URI) Dynamic Delegation 1109 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1110 March 2011. 1112 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1113 Common Vulnerability Scoring System (CVSS) and Its 1114 Applicability to Federal Agency Systems". 1116 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1117 and Classification (CAPEC)". 1119 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1121 [CPE] Brant A. Cheikes and David Waltermire and Karen Scarfone, 1122 "Common Platform Enumeration: Naming Specificatino Version 1123 2.3", Aug 2011. 1125 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1126 (CVE)". 1128 [CVRF] ICASI, "http://www.icasi.org/cvrf". 1130 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1131 (CWE)". 1133 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1134 (CWSS)". 1136 [ISOIEC19770-2] 1137 ISO/IEC, "Information technology -- Software asset 1138 management -- Part 2: Software identification tag", 2009. 1140 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1141 Open Checklist Interactive Language (OCIL) Version 2.0", 1142 Apr 2011. 1144 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1145 Language (OVAL)". 1147 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1148 and Neal Ziring, "Specification for the Extensible 1149 Configuration Checklist Description Format (XCCDF) version 1150 1.2 (DRAFT)", Jul 2011. 1152 [XDAS] The Open Group, "Distributed Audit Service (XDAS), 1153 Preliminary Specification", Jan 1998. 1155 Authors' Addresses 1157 Takeshi Takahashi 1158 National Institute of Information and Communications Technology 1159 4-2-1 Nukui-Kitamachi Koganei 1160 184-8795 Tokyo 1161 Japan 1163 Phone: +80 423 27 5862 1164 Email: takeshi_takahashi@nict.go.jp 1165 Kent Landfield 1166 McAfee, Inc 1167 5000 Headquarters Drive 1168 Plano, TX 75024 1169 USA 1171 Email: Kent_Landfield@McAfee.com 1173 Thomas Millar 1174 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1175 245 Murray Lane SW, Building 410, MS #732 1176 Washington, DC 20598 1177 USA 1179 Phone: +1 888 282 0870 1180 Email: thomas.millar@us-cert.gov 1182 Youki Kadobayashi 1183 National Institute of Information and Communications Technology 1184 4-2-1 Nukui-Kitamachi Koganei 1185 184-8795 Tokyo 1186 Japan 1188 Email: youki-k@is.aist-nara.ac.jp