idnits 2.17.1 draft-ietf-mile-sci-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([XCCDF], [OVAL], [CVSS], [CWE], [TM], [CWSS], [CEE], [RFC5070], [OCIL], [CPE], [CAPEC], [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 (Dec 28, 2011) is 4503 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 1442, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1445, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1452, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1455, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6045 (Obsoleted by RFC 6545) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLschemaPart1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLschemaPart2' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNames' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group T. Takahashi 3 Internet-Draft NICT 4 Intended status: Standards Track K. Landfield 5 Expires: June 30, 2012 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Dec 28, 2011 12 IODEF-extension to support structured cybersecurity information 13 draft-ietf-mile-sci-01.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], OCIL 23 [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 30, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. IDs for Structured Cybersecurity Information 64 Specifictions . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1.1. CAPEC_1.6 . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.2. CCE_5.0 . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1.3. CCSS_1.0 . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1.4. CEE_0.6 . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.5. CPE_Ref_2.3 . . . . . . . . . . . . . . . . . . . . . 7 70 4.1.6. CPE_Dic_2.3 . . . . . . . . . . . . . . . . . . . . . 8 71 4.1.7. CVE_1.0 . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.8. CVRF_1.0 . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.9. CVSS_2.0 . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.10. CWE_5.0 . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.11. CWSS_0.8 . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.12. OCIL_2.0 . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.13. OVAL_Def_5.10.1 . . . . . . . . . . . . . . . . . . . 10 78 4.1.14. OVAL_Res_5.10.1 . . . . . . . . . . . . . . . . . . . 10 79 4.1.15. OVAL_Com_5.10.1 . . . . . . . . . . . . . . . . . . . 10 80 4.1.16. XCCDF_1.2 . . . . . . . . . . . . . . . . . . . . . . 11 81 4.2. Extended Classes . . . . . . . . . . . . . . . . . . . . . 11 82 4.2.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 12 83 4.2.2. PlatformID . . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 85 4.2.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 16 86 4.2.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.2.6. EventReport . . . . . . . . . . . . . . . . . . . . . 19 88 4.2.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 20 89 4.2.8. Remediation . . . . . . . . . . . . . . . . . . . . . 21 90 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 22 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 25 94 6.2. Using the iodef:restriction Attribute . . . . . . . . . . 25 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 27 97 9. Appendix I: XML Schema Definition for Extension . . . . . . . 28 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 103 1. Introduction 105 Cyber attacks are getting more sophisticated, and their numbers are 106 increasing day by day. To cope with such situation, incident 107 information needs to be reported, exchanged, and shared among 108 organizations. IODEF is one of the tools enabling such exchange, and 109 is already in use. 111 To efficiently run cybersecurity operations, these exchanged 112 information needs to be machine-readable. IODEF provides a 113 structured means to describe the information, but it needs to embed 114 various non-structured such information in order to convey detailed 115 information. Further structure within IODEF increases IODEF 116 documents' machine-readability and thus facilitates streamlining 117 cybersecurity operations. 119 On the other hand, there exist various other activities facilitating 120 detailed and structured description of cybersecurity information, 121 major of which includes CAPEC [CAPEC], CEE [CEE], CPE [CPE], CVE 122 [CVE], CVRF [CVRF], CVSS [CVSS], CWE [CWE], CWSS [CWSS], OCIL [OCIL], 123 OVAL [OVAL], and XCCDF [XCCDF]. Since such structured description 124 facilitates cybersecurity operations, it would be beneficial to embed 125 and convey these information inside IODEF document. 127 To enable that, this document extends the IODEF to embed and convey 128 various structured cybersecurity information, with which 129 cybersecurity operations can be facilitated. Since IODEF defines a 130 flexible and extensible format and supports a granular level of 131 specificity, this document defines an extension to IODEF instead of 132 defining a new report format. For clarity, and to eliminate 133 duplication, only the additional structures necessary for describing 134 the exchange of such structured information are provided. 136 2. Terminology 138 The terminology used in this document follows the one defined in RFC 139 5070 [RFC5070]. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 3. Applicability 147 To maintain cybersecurity, organization needs to exchange 148 cybersecurity information, which includes the following information: 150 attack pattern, platform information, vulnerability and weakness, 151 countermeasure instruction, computer event log, and the severity. 153 IODEF provides a scheme to exchange such information among interested 154 parties. However, the detailed common format to describe such 155 information is not defined in the IODEF base document. 157 On the other hand, to describe those information and to facilitate 158 exchange, a structured format for that is already available. Major 159 of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OCIL, OVAL, 160 and XCCDF. By embedding them into the IODEF document, the document 161 can convey more detailed contents to the receivers, and the document 162 can be easily reused. Note that interactive communication is needed 163 in some cases, and some of these structured informatio nsuch as OCIL 164 solicits reply from recipients. These reply could be also embedded 165 inside the IODEF document. 167 These structured cybersecurity information facilitates cybersecurity 168 operation at the receiver side. Since the information is machine- 169 readable, the data can be processed by computers. That expedites the 170 automation of cybersecurity operations 172 For instance, an organization wishing to report a security incident 173 wants to describe what vulnerability was exploited. Then the sender 174 can simply use IODEF, where an CAPEC record is embedded instead of 175 describing everything in free format text. Receiver can also 176 identify the needed details of the attack pattern by looking up some 177 of the xml [XML1.0] tags defined by CAPEC. Receiver can accumulate 178 the attack pattern information (CAPEC record) in its database and 179 could distribute it to the interested parties if needed, without 180 needing human interventions. 182 4. Extension Definition 184 This draft extends IODEF to embed structured cybersecurity 185 information by introducing new classes, with which these information 186 can be embedded inside IODEF document as element contents of 187 AdditionalData and RecordItem classes. 189 4.1. IDs for Structured Cybersecurity Information Specifictions 191 This extension embeds structured cybersecurity information from 192 external specifications. The initial list of supported 193 specifications is in Figure 1 below, followed by a subsection for 194 each specification that lists the ID, specification name, version, 195 namespace [XMLNames], specification URI and applicable classes for 196 each specification. Future assignments are to be managed by IANA 197 using the Expert Review [RFC5226] and Specification Required 198 [RFC5226] allocation policies as further specified in Section 7. 200 ID Specification Name 201 --------------- ------------------------------------------------------ 202 CAPEC_1.6 Common Attack Pattern Enumeration and Classification 203 CCE_5.0 Common Configuration Enumeration 204 CCSS_1.0 Common Configuration Scoring System 205 CEE_0.6 Common Event Expression 206 CPE_Ref_2.3 Common Platform Enumeration Reference 207 CPE_Dic_2.3 Common Platform Enumeration Dictionary 208 CVE_1.0 Common Vulnerability and Exposures 209 CVRF_1.0 Common Vulnerability Reporting Format 210 CVSS_2.0 Common Vulnerability Scoring System 211 CWE_5.0 Common Weakness Enumeration 212 CWSS_0.8 Common Weakness Scoring System 213 OCIL_2.0 Open Checklist Interactive Language 214 OVAL_Def_5.10.1 Open Vulnerability and Assessment Language Definitions 215 OVAL_Res_5.10.1 Open Vulnerability and Assessment Language Results 216 OVAL_Com_5.10.1 Open Vulnerability and Assessment Language Common 217 XCCDF_1.2 Extensible Configuration Checklist Description Format 219 Figure 1: List of specification IDs 221 4.1.1. CAPEC_1.6 223 ID: CAPEC_1.6 225 Specification Name: Common Attack Pattern Enumeration and 226 Classification 228 Version: 1.6 230 Namespace: http://capec.mitre.org/observables 232 Specification URI: http://capec.mitre.org/ 234 Applicable Classes: AttackPattern 236 4.1.2. CCE_5.0 238 ID: CCE_5.0 240 Specification Name: Common Configuration Enumeration 241 Version: 5.0 243 Namespace: http://cce.mitre.org 245 Specification URI: TBD 247 pplicable Classes: Remediation 249 4.1.3. CCSS_1.0 251 ID: CCSS_1.0 253 Specification Name: Common Configuration Scoring System 255 Version: 1.0 257 Namespace: N/A 259 Specification URI: TBD 261 Applicable Classes: Scoring 263 4.1.4. CEE_0.6 265 ID: CEE_0.6 267 Specification Name: Common Event Expression 269 Version: 0.6 271 Namespace: http://cee.mitre.org 273 Specification URI: http://cee.mitre.org/ 275 Applicable Classes: EventReport 277 4.1.5. CPE_Ref_2.3 279 ID: CPE_Ref_2.3 281 Specification Name: Common Platform Enumeration Reference 283 Version: 2.3 285 Namespace: http://cpe.mitre.org/language/2.0 286 Specification URI: http://cpe.mitre.org/ 288 Applicable Classes: PlatformID 290 4.1.6. CPE_Dic_2.3 292 ID: CPE_Dic_2.3 294 Specification Name: Common Platform Enumeration Dictionary 296 Version: 2.3 298 Namespace: http://cpe.mitre.org/language/2.0 300 Specification URI: TBD 302 Applicable Classes: PlatformID 304 4.1.7. CVE_1.0 306 ID: CVE_1.0 308 Specification Name: Common Vulnerability and Exposures 310 Version: 1.0 312 Namespace: http://cve.mitre.org/cve/downloads/1.0 314 Specification URI: http://cve.mitre.org/ 316 Applicable Classes: Vulnerability 318 4.1.8. CVRF_1.0 320 ID: CVRF_1.0 322 Specification Name: Common Vulnerability Reporting Format 324 Version: 1.0 326 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 328 Specification URI: http://www.icasi.org/cvrf 330 Applicable Classes: Vulnerability 332 4.1.9. CVSS_2.0 334 ID: CVSS_2.0 336 Specification Name: Common Vulnerability Scoring System 338 Version: 2 340 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 342 Specification URI: http://www.first.org/cvss 344 Applicable Classes: Scoring 346 4.1.10. CWE_5.0 348 ID: CWE_5.0 350 Specification Name: Common Weakness Enumeration 352 Version; 5.1 354 Namespace: N/A 356 Specification URI: http://cwe.mitre.org/ 358 Applicable Classes: Weakness 360 4.1.11. CWSS_0.8 362 ID: CWSS_0.8 364 Specification Name: Common Weakness Scoring System 366 Version: 0.8 368 Namespace: N/A 370 Specification URI: http://cwe.mitre.org/cwss/ 372 Applicable Classes: Scoring 374 4.1.12. OCIL_2.0 375 ID: OCIL_2.0 377 Specification Name: Open Checklist Interactive Language 379 Version: 2.0 381 Namespace: http://scap.nist.gov/schema/ocil/2.0 383 Specification URI: http://scap.nist.gov/specifications/ocil/ 385 Applicable Classes: Verification 387 4.1.13. OVAL_Def_5.10.1 389 ID: OVAL_Def_5.10.1 391 Specification Name: Open Vulnerability and Assessment Language 393 Version: 5.10.1 395 Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 397 Specification URI: http://oval.mitre.org/ 399 Applicable Classes: Verification 401 4.1.14. OVAL_Res_5.10.1 403 ID: OVAL_Res_5.10.1 405 Specification Name: Open Vulnerability and Assessment Language 407 Version: 5.10.1 409 Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 411 Specification URI: TBD 413 Applicable Classes: Verification 415 4.1.15. OVAL_Com_5.10.1 417 ID: OVAL_Com_5.10.1 419 Specification Name: Open Vulnerability and Assessment Language 420 Version: 5.10.1 422 Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 424 Specification URI: TBD 426 Applicable Classes: Verification 428 4.1.16. XCCDF_1.2 430 ID: XCCDF_1.2 432 Specification Name: Extensible Configuration Checklist Description 433 Format 435 Version: 1.2 437 Namespace: http://checklists.nist.gov/xccdf/1.2 439 Specification URI: http://scap.nist.gov/specifications/xccdf/ 441 Applicable Classes: Verification 443 4.2. Extended Classes 445 The IODEF Incident element [RFC5070] is summarized below. It is 446 expressed in Unified Modeling Language (UML) syntax as used in the 447 IODEF specification. The UML representation is for illustrative 448 purposes only; elements are specified in XML as defined in Appendix 449 A. 451 +--------------------+ 452 | Incident | 453 +--------------------+ 454 | ENUM purpose |<>---------[IncidentID] 455 | STRING ext-purpose |<>--{0..1}-[AlternativeID] 456 | ENUM lang |<>--{0..1}-[RelatedActivity] 457 | ENUM restriction |<>--{0..1}-[DetectTime] 458 | |<>--{0..1}-[StartTime] 459 | |<>--{0..1}-[EndTime] 460 | |<>---------[ReportTime] 461 | |<>--{0..*}-[Description] 462 | |<>--{1..*}-[Assessment] 463 | |<>--{0..*}-[Method] 464 | | |<>--[AdditionalData] 465 | | |<>--[AttackPattern] 466 | | |<>--[Vulnerability] 467 | | |<>--[Weakness] 468 | |<>--{1..*}-[Contact] 469 | |<>--{0..*}-[EventData] 470 | | |<>--[Flow] 471 | | | |<>--[System] 472 | | | |<>--[AdditionalData] 473 | | | |<>--[PlatformID] 474 | | |<>--[Expectation] 475 | | |<>--[Record] 476 | | |<>--[RecordData] 477 | | |<>--[RecordItem] 478 | | |<>--[EventReport] 479 | |<>--{0..1}-[History] 480 | |<>--{0..*}-[AdditionalData] 481 | | |<>--[Verification] 482 | | |<>--[Remediation] 483 +--------------------+ 485 Figure 2: Incident class 487 This extension defines the following seven elements. 489 4.2.1. AttackPattern 491 An AttackPattern consists of an extension to the 492 Incident.Method.AdditionalData element with a dtype of "xml". The 493 extension describes attack patterns of incidents or events. 495 It is recommended that Method class SHOULD contain one or more of the 496 extension elements whenever available. 498 An AttackPattern class is structured as follows. 500 +------------------------+ 501 | AttackPattern | 502 +------------------------+ 503 | STRING Version |<>--(0..*)-[ RawData ] 504 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 505 | STRING AttackPatternID |<>--(0..*)-[ PlatformID ] 506 +------------------------+ 508 Figure 3: AttackPattern class 510 This class has the following attributes. 512 Version: OPTIONAL. STRING. The version number of the extension 513 specification to which this class conforms. This value should be 514 1.00, to be compliant with this document. Its default value is 515 1.00. 517 SpecificationID: REQUIRED. ENUM. The ID of the specification and 518 its version specifying the format of the RawData element. The 519 value should be chosen from the IDs listed in Figure 1, such as 520 CAPEC_1.6. Note that the lists in Figure 1 will be developed 521 further by IANA. 523 AttackPatternID: OPTIONAL. STRING. An ID of an attack pattern to 524 be reported. This attribute SHOULD be used whenever such ID is 525 available. In case a RawData or Reference element is provided 526 along with this attribute, writers/senders MUST ensure that this 527 ID is consistent with the one provided by the element; if a 528 reader/receiver detects an inconsistency, it SHOULD prefer the 529 value of this attribute, and SHOULD log the inconsistency so a 530 human can correct the problem. Note that this attribute could be 531 omitted if no such ID is available. In this case, either RawData 532 or Reference elements, or both of them, MUST be provided. 534 The AttackPattern class is composed of the following aggregate 535 classes. 537 RawData: Zero or more. xml. A complete document that is formatted 538 according to the specification and its version identified by the 539 value of the SpecificationID with the Figure 1. 541 Reference: Zero or more of iodef:Reference [RFC5070]. This element 542 allows an IODEF document to include a link to a structured 543 information instead of directly embedding it into a RawData 544 element. 546 PlatformID: Zero or more. An identifier of software platform 547 involved in the specific attack pattern, which is elaborated in 548 Section 4.2.2. Some of the structured information embedded in the 549 RawData element may include the identifier within it. In this 550 case, this PlatformID element SHOULD NOT be used. If a reader/ 551 receiver detects the identifiers in both RawData and PlatformID 552 elements and their inconsistency, it SHOULD prefer the identifiers 553 derived from the PlatformID element, and SHOULD log the 554 inconsistency so a human can correct the problem. 556 Writers/senders MUST ensure the specification name and version 557 identified by the SpecificationID are consistent with the contents of 558 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 559 prefer the specification name and version derived from the content, 560 and SHOULD log the inconsistency so a human can correct the problem. 562 4.2.2. PlatformID 564 A PlatformID identifies a software platform. It is recommended that 565 AttackPattern, Vulnerability, Weakness, and System classes contain 566 this elements whenever available. 568 A PlatformID element is structured as follows. 570 +----------------------+ 571 | PlatformID | 572 +----------------------+ 573 | STRING Version |<>--(1..*)-[ ID ] 574 | ENUM SpecificationID | 575 +----------------------+ 577 Figure 4: PlatformID class 579 This class has the following attributes. 581 Version: OPTIONAL. STRING. The version number of the extension 582 specification to which this class conforms. This value should be 583 1.00, to be compliant with this document. Its default value is 584 1.00. 586 SpecificationID: REQUIRED. ENUM. The ID of the specification and 587 its version specifying the format of the ID element. The value 588 should be chosen from the IDs listed in Figure 1, such as CPE_2.3 589 and ISO/IEC 19770-2. Note that the lists in Figure 1 will be 590 developed further by IANA. 592 This class is composed of the following aggregate classes. 594 ID: One or more. ML_STRING. An ID that is formatted according to 595 the rule defined by the specification and its version identified 596 by the value of the SpecificationID with the Figure 1. 598 Writers/senders MUST ensure the specification name and version 599 identified by the SpecificationID are consistent with the contents of 600 the ID; if a reader/receiver detects an inconsistency, it SHOULD 601 prefer the specification name and version derived from the content, 602 and SHOULD log the inconsistency so a human can correct the problem. 604 4.2.3. Vulnerability 606 A Vulnerability consists of an extension to the 607 Incident.Method.AdditionalData element with a dtype of "xml". The 608 extension describes the (candidate) vulnerabilities of incidents or 609 events. 611 It is recommended that Method class SHOULD contain one or more of the 612 extension elements whenever available. 614 A Vulnerability element is structured as follows. 616 +------------------------+ 617 | Vulnerability | 618 +------------------------+ 619 | STRING Version |<>--(0..*)-[ RawData ] 620 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 621 | STRING VulnerabilityID |<>--(0..*)-[ PlatformID ] 622 | |<>--(0..*)-[ Scoring ] 623 +------------------------+ 625 Figure 5: Vulnerability class 627 This class has the following attributes. 629 Version: OPTIONAL. STRING. The version number of the extension 630 specification to which this class conforms. This value should be 631 1.00, to be compliant with this document. Its default value is 632 1.00. 634 SpecificationID: REQUIRED. ENUM. The ID of the specification and 635 its version specifying the format of the RawData element. The 636 value should be chosen from the IDs listed in Figure 1, such as 637 CVE_1.0 and CVRF_1.0. Note that the lists in Figure 1 will be 638 developed further by IANA. 640 VulnerabilityID: OPTIONAL. STRING. An ID of a vulnerability to be 641 reported. This attribute SHOULD be used whenever such ID is 642 available. In case a RawData or Reference element is provided 643 along with this attribute, writers/senders MUST ensure that this 644 ID is consistent with the one provided by the element; if a 645 reader/receiver detects an inconsistency, it SHOULD prefer the 646 value of this attribute, and SHOULD log the inconsistency so a 647 human can correct the problem. Note that this attribute could be 648 omitted if no such ID is available. In this case, either RawData 649 or Reference elements, or both of them, MUST be provided. 651 This class is composed of the following aggregate classes. 653 RawData: Zero or one. xml. A complete document that is formatted 654 according to the specification and its version identified by the 655 value of the SpecificationID with the Figure 1. 657 Reference: Zero or one of iodef:Reference [RFC5070]. This element 658 allows an IODEF document to include a link to a structured 659 information instead of directly embedding it into a RawData 660 element. 662 PlatformID: Zero or more. An identifier of software platform 663 affected by the vulnerability, which is elaborated in 664 Section 4.2.2. Some of the structured information embedded in the 665 RawData element may include the identifier within it. In this 666 case, this PlatformID element SHOULD NOT be used. If a reader/ 667 receiver detects the identifiers in both RawData and PlatformID 668 elements and their inconsistency, it SHOULD prefer the identifiers 669 derived from the PlatformID element, and SHOULD log the 670 inconsistency so a human can correct the problem. 672 Scoring: Zero or more. An indicator of the severity of the 673 vulnerability, such as CVSS and CCSS scores, which is elaborated 674 in Section 4.2.4. Some of the structured information may include 675 scores within it. In this case, the Scoring element SHOULD NOT be 676 used since the RawData element contains the scores. If a reader/ 677 receiver detects scores in both RawData and Scoring elements and 678 their inconsistency, it SHOULD prefer the scores derived from the 679 RawData element, and SHOULD log the inconsistency so a human can 680 correct the problem. 682 4.2.4. Scoring 684 A Scoring class describes the scores of the severity in terms of 685 security. It is recommended that Vulnerability and Weakness classes 686 contain the elements whenever available. 688 A Scoring class is structured as follows. 690 +----------------------+ 691 | Scoring | 692 +----------------------+ 693 | STRING Version |<>---------[ Score ] 694 | ENUM SpecificationID | 695 +----------------------+ 697 Figure 6: Scoring class 699 This class has two attributes. 701 Version: OPTIONAL. STRING. The version number of the extension 702 specification to which this class conforms. This value should be 703 1.00, to be compliant with this document. Its default value is 704 1.00. 706 SpecificationID: REQUIRED. STRING. The ID of the specification and 707 its version specifying the format of the Score element. The value 708 should be chosen from the IDs listed in Figure 1, such as CCSS, 709 CVSS_2.0 and CWSS_0.8. Note that the lists in Figure 1 will be 710 developed further by IANA. 712 This class is composed of an aggregate class. 714 Score: One. xml. Arbitrary information structured by the 715 specification identified by the specification and its version 716 identified by the value of the SpecificationID with the Figure 1. 718 Writers/senders MUST ensure the specification name and version 719 identified by the SpecificationID are consistent with the contents of 720 the Score; if a reader/receiver detects an inconsistency, it SHOULD 721 prefer the specification name and version derived from the content, 722 and SHOULD log the inconsistency so a human can correct the problem. 724 4.2.5. Weakness 726 A Weakness consists of an extension to the 727 Incident.Method.AdditionalData element with a dtype of "xml". The 728 extension describes the weakness types of incidents or events. 730 It is recommended that Method class SHOULD contain one or more of the 731 extension elements whenever available. 733 A Weakness element is structured as follows. 735 +----------------------+ 736 | Weakness | 737 +----------------------+ 738 | STRING Version |<>--(0..*)-[ RawData ] 739 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 740 | STRING WeaknessID |<>--(0..*)-[ PlatformID ] 741 | |<>--(0..*)-[ Scoring ] 742 +----------------------+ 744 Figure 7: Weakness class 746 This class has the following attributes. 748 Version: OPTIONAL. STRING. The version number of the extension 749 specification to which this class conforms. This value should be 750 1.00, to be compliant with this document. Its default value is 751 1.00. 753 SpecificationID: REQUIRED. ENUM. The ID of the specification and 754 its version specifying the format of the RawData element. The 755 value should be chosen from the IDs listed in Figure 1, such as 756 CWE_5.0. Note that the lists in Figure 1 will be developed 757 further by IANA. 759 WeaknessID: OPTIONAL. STRING. An ID of a weakness to be reported. 760 This attribute SHOULD be used whenever such ID is available. In 761 case a RawData or Reference elements is provided along with this 762 attribute, writers/senders MUST ensure that this ID is consistent 763 with the one provided by the element; if a reader/receiver detects 764 an inconsistency, it SHOULD prefer the value of this attribute, 765 and SHOULD log the inconsistency so a human can correct the 766 problem. Note that this attribute could be omitted if no such ID 767 is available. In this case, either RawData or Reference elements, 768 or both of them, MUST be provided. 770 This class is composed of the following aggregate classes. 772 RawData: Zero or more. xml. A complete document that is formatted 773 according to the specification and its version identified by the 774 value of the SpecificationID with the Figure 1. 776 Reference: Zero or one of iodef:Reference [RFC5070]. This element 777 allows an IODEF document to include a link to a structured 778 information instead of directly embedding it into a RawData 779 element. 781 PlatformID: Zero or more. An identifier of software platform 782 affected by the weakness, which is elaborated in Section 4.2.2. 783 Some of the structured information embedded in the RawData element 784 may include the identifier within it. In this case, this 785 PlatformID element SHOULD NOT be used. If a reader/receiver 786 detects the identifiers in both RawData and PlatformID elements 787 and their inconsistency, it SHOULD prefer the identifiers derived 788 from the PlatformID element, and SHOULD log the inconsistency so a 789 human can correct the problem. 791 Scoring: Zero or more. An indicator of the severity of the 792 weakness, such as CWSS score, which is elaborated in 793 Section 4.2.4. Some of the structured information may include 794 scores within it. In this case, the Scoring element SHOULD NOT be 795 used since the RawData element contains the scores. If a reader/ 796 receiver detects scores in both RawData and Scoring elements and 797 their inconsistency, it SHOULD prefer the scores derived from the 798 RawData element, and SHOULD log the inconsistency so a human can 799 correct the problem. 801 4.2.6. EventReport 803 An EventReport consists of an extension to the 804 Incident.EventData.Record.RecordData.RecordItem element with a dtype 805 of "xml". The extension embeds structured event reports. 807 It is recommended that RecordItem class SHOULD contain one or more of 808 the extension elements whenever available. 810 An EventReport element is structured as follows. 812 +----------------------+ 813 | EventReport | 814 +----------------------+ 815 | STRING Version |<>--(0..*)-[ RawData ] 816 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 817 +----------------------+ 819 Figure 8: EventReport class 821 This class has the following attributes. 823 Version: OPTIONAL. STRING. The version number of the extension 824 specification to which this class conforms. This value should be 825 1.00, to be compliant with this document. Its default value is 826 1.00. 828 SpecificationID: REQUIRED. ENUM. The ID of the specification and 829 its version specifying the format of the RawData element. The 830 value should be chosen from the IDs listed in Figure 1, such as 831 CEE_0.6. Note that the lists in Figure 1 will be developed 832 further by IANA. 834 This class is composed of three aggregate classes. 836 RawData: Zero or one. xml. A complete document that is formatted 837 according to the specification and its version identified by the 838 value of the SpecificationID with the Figure 1. 840 Reference: Zero or one of iodef:Reference [RFC5070]. This element 841 allows an IODEF document to include a link to a structured 842 information instead of directly embedding it into a RawData 843 element. 845 This class MUST contain at least one of RawData or Reference 846 elements. Writers/senders MUST ensure the specification name and 847 version identified by the SpecificationID are consistent with the 848 contents of the RawData; if a reader/receiver detects an 849 inconsistency, it SHOULD prefer the specification name and version 850 derived from the content, and SHOULD log the inconsistency so a human 851 can correct the problem. 853 4.2.7. Verifcation 855 A Verification consists of an extension to the 856 Incident.AdditionalData element with a dtype of "xml". The extension 857 elements describes incident on vefifying incidents. 859 A Verification class is structured as follows. 861 +----------------------+ 862 | Verification | 863 +----------------------+ 864 | STRING Version |<>--(0..*)-[ RawData ] 865 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 866 +----------------------+ 868 Figure 9: Verification class 870 This class has the following attributes. 872 Version: OPTIONAL. STRING. The version number of the extension 873 specification to which this class conforms. This value should be 874 1.00, to be compliant with this document. Its default value is 875 1.00. 877 SpecificationID: REQUIRED. ENUM. The ID of the specification and 878 its version specifying the format of the RawData element. The 879 value should be chosen from the IDs listed in Figure 1, such as 880 OVAL_5.10, OCIL_2.0, and XCCDF_1.2. Note that the lists in 881 Figure 1 will be developed further by IANA. 883 This class is composed of two aggregate classes. 885 RawData: Zero or one. xml. A complete document that is formatted 886 according to the specification and its version identified by the 887 value of the SpecificationID with the Figure 1. 889 Reference: Zero or one of iodef:Reference [RFC5070]. This element 890 allows an IODEF document to include a link to a structured 891 information instead of directly embedding it into a RawData 892 element. 894 This class MUST contain at least either of RawData and Reference 895 elements. Writers/senders MUST ensure the specification name and 896 version identified by the SpecificationID are consistent with the 897 contents of the RawData; if a reader/receiver detects an 898 inconsistency, it SHOULD prefer the specification name and version 899 derived from the content, and SHOULD log the inconsistency so a human 900 can correct the problem. 902 4.2.8. Remediation 904 A Remediation consists of an extension to the Incident.AdditionalData 905 element with a dtype of "xml". The extension elements describes 906 incident remediation information including instructions. 908 It is recommended that Incident class SHOULD contain one or more of 909 this extension elements whenever available. 911 A Remediation class is structured as follows. 913 +----------------------+ 914 | Remediation | 915 +----------------------+ 916 | STRING Version |<>--(0..*)-[ RawData ] 917 | ENUM SpecificationID |<>--(0..*)-[ Reference ] 918 +----------------------+ 919 Figure 10: Remediation class 921 This class has the following attributes. 923 Version: OPTIONAL. STRING. The version number of the extension 924 specification to which this class conforms. This value should be 925 1.00, to be compliant with this document. Its default value is 926 1.00. 928 SpecificationID: REQUIRED. ENUM. The ID of the specification and 929 its version specifying the format of the RawData element. The 930 value should be chosen from the IDs listed in Figure 1. Note that 931 the lists in Figure 1 will be developed further by IANA. 933 This class is composed of two aggregate classes. 935 RawData: Zero or one. xml. A complete document that is formatted 936 according to the specification and its version identified by the 937 value of the SpecificationID with the Figure 1. 939 Reference: Zero or one of iodef:Reference [RFC5070]. This element 940 allows an IODEF document to include a link to a structured 941 information instead of directly embedding it into a RawData 942 element. 944 This class MUST contain at least either of RawData and Reference 945 elements. Writers/senders MUST ensure the specification name and 946 version identified by the SpecificationID are consistent with the 947 contents of the RawData; if a reader/receiver detects an 948 inconsistency, it SHOULD prefer the specification name and version 949 derived from the content, and SHOULD log the inconsistency so a human 950 can correct the problem. 952 5. Examples 954 This section provides examples of an incident encoded in the IODEF. 955 These examples do not necessarily represent the only way to encode a 956 particular incident. 958 5.1. Reporting an attack 960 An example of a CSIRT reporting an attack. 962 963 968 969 189493 970 2001-09-13T23:19:24+00:00 971 Incident report in company xx 972 973 974 975 976 977 Structured information on attack pattern, exploited 978 vulnerability, and weakness 979 980 982 [CAPEC-formatted data] 983 984 Link to Capec-14 985 http://capec.mitre.org/data/definitions/14.html 986 987 988 990 [CVE-formatted data] 991 992 [CPE ID] 993 994 995 [CVSS scores] 996 997 998 1000 [CWE-formatted data] 1001 1002 [CWSS scores] 1003 1004 1005 1006 1007 1008 Example.com CSIRT 1009 example-com 1010 contact@csirt.example.com 1011 1012 1013 1014 1015 1016
192.0.2.200
1017 57 1018 1019 1020 1021 1022
192.0.2.16/28
1023 1024 1025 80 1026 1027 1028 1029 [CPE ID] 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 2001-09-13T18:11:21+02:00 1040 a Web-server event record 1041 1042 1043 [CEE-formatted data] 1044 1045 1046 1047 1048 1049 1050 1051 1052 2001-09-14T08:19:01+00:00 1053 Notification sent to 1054 constituency-contact@192.0.2.200 1055 1056 1057 1058 1059 [OVAL-formatted data] 1060 1061 1062 [XCCDF-formatted data] 1063 1064 1065 1066 1068 Figure 11: Example UML Element Diagram 1070 6. Security Considerations 1072 This document specifies a format for encoding a particular class of 1073 security incidents appropriate for exchange across organizations. As 1074 merely a data representation, it does not directly introduce security 1075 issues. However, it is guaranteed that parties exchanging instances 1076 of this specification will have certain concerns. For this reason, 1077 the underlying message format and transport protocol used MUST ensure 1078 the appropriate degree of confidentiality, integrity, and 1079 authenticity for the specific environment. 1081 Organizations that exchange data using this document are URGED to 1082 develop operating procedures that document the following areas of 1083 concern. 1085 6.1. Transport-Specific Concerns 1087 The underlying messaging format and protocol used to exchange 1088 instances of the IODEF MUST provide appropriate guarantees of 1089 confidentiality, integrity, and authenticity. The use of a 1090 standardized security protocol is encouraged. The Real-time Inter- 1091 network Defense (RID) protocol [RFC6045] and its associated transport 1092 binding [RFC6046] provide such security. 1094 The critical security concerns are that these structured information 1095 may be falsified or they may become corrupt during transit. In areas 1096 where transmission security or secrecy is questionable, the 1097 application of a digital signature and/or message encryption on each 1098 report will counteract both of these concerns. We expect that each 1099 exchanging organization will determine the need, and mechanism, for 1100 transport protection. 1102 6.2. Using the iodef:restriction Attribute 1104 In some instances, data values in particular elements may contain 1105 data deemed sensitive by the reporter. Although there are no 1106 general-purpose rules on when to mark certain values as "private" or 1107 "need-to-know" via the iodef:restriction attribute, the reporter is 1108 cautioned not to apply element-level sensitivity markings unless they 1109 believe the receiving party (i.e., the party they are exchanging the 1110 event report data with) has a mechanism to adequately safeguard and 1111 process the data as marked. 1113 7. IANA Considerations 1115 This document uses URNs to describe XML namespaces and XML 1116 schemata[XMLschemaPart1][XMLschemaPart2] conforming to a registry 1117 mechanism described in [RFC3688]. 1119 Registration request for the IODEF structured cybersecurity 1120 information extension namespace: 1122 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 1124 Registrant Contact: Refer here to the authors' addresses section 1125 of the document. 1127 XML: None 1129 Registration request for the IODEF structured cybersecurity 1130 information extension XML schema: 1132 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 1134 Registrant Contact: Refer here to the authors' addresses section 1135 of the document. 1137 XML: Refer here to the XML Schema in the appendix of the document. 1139 This memo creates the following registry for IANA to manage: 1141 Name of the registry: "IODEF Structured Cyber Security Information 1142 Specifications" 1144 Namespace details: A registry entry for a Structured Cyber 1145 Security Information Specification (SCI specification) consists 1146 of: 1148 ID: A short XSD string that is used in the SpecificationID 1149 attribute of an IODEF extended class defined in this memo. The 1150 ID is usually based on the acronym and version number of the 1151 SCI specification. 1153 Specification Name: A string containing the spelled-out name of 1154 the SCI specification in human-readable form. 1156 Version: The version of the registered SCI specification. This 1157 is a string that SHOULD consist of numbers separated by '.' 1158 (period) characters, but additional characters and different 1159 formatting MAY be used when appropriate. 1161 Namespace: A URI [RFC3986] that is the XML namespace name used 1162 by the registered SCI specification. 1164 Specification URI: A URI [RFC3986] from which the registered 1165 specification can be obtained. The registered specification 1166 MUST be readily and publicly available from that URI. 1168 Applicable Classes: A list of one or more of the Extended 1169 Classes specified in Section 4.2 of this document. The 1170 registered SCI specification MUST only be used with the 1171 Extended Classes in the registry entry. 1173 Information that must be provided to assign a new value: The above 1174 list of information. 1176 Assignment policy: If the requested value is not already assigned, 1177 it may be assigned to the requester. 1179 Fields to record in the registry: ID/Specification Name/Version/ 1180 Namespace/Applicable Classes. 1182 Initial registry contents: See sections from Section 4.1.1 through 1183 Section 4.1.16 above. 1185 Allocation Policy: Expert Review [RFC5226] and Specification 1186 Required [RFC5226]. 1188 The Designated Expert is expected to consult with the mile (Managed 1189 Incident Lightweight Exchange) working group or its successor if any 1190 such WG exists (e.g., via email to the working group's mailing list). 1191 The Designated Expert is expected to retrieve the SCI specification 1192 from the provided URI in order to check the public availability of 1193 the specification and verify the correctness of the URI. An 1194 important responsibility of the Designated Expert is to ensure that 1195 the registered Applicable Classes are appropriate for the registered 1196 SCI specification. 1198 8. Acknowledgment 1200 We would like to acknowledge Mr. David Black from EMC, who kindly 1201 provided generous support, especially on the IANA registry issues. 1202 We also would like to thank Paul Cichonski from NIST, Robert Martin 1203 from MITRE, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, 1204 Shuhei Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, 1205 and Brian Trammel from CERT/NetSA for their sincere discussion and 1206 feedback on this document. 1208 9. Appendix I: XML Schema Definition for Extension 1210 The XML Schema describing the elements defined in the Extension 1211 Definition section is given here. Each of the examples in Section 5 1212 should be verified to validate against this schema by automated 1213 tools. 1215 1217 1224 1228 1232 1236 1237 1238 1239 1240 1241 1243 1245 1246 1248 1252 1253 1254 1255 1257 1259 1261 1262 1264 1265 1266 1267 1269 1273 1274 1275 1276 1278 1280 1282 1284 1285 1287 1289 1291 1292 1294 1297 1298 1299 1300 1302 1304 1306 1308 1309 1311 1313 1315 1316 1318 1322 1323 1324 1325 1327 1328 1330 1332 1333 1335 1339 1340 1341 1342 1343 1344 1346 1347 1348 1350 1352 1353 1355 1359 1360 1361 1362 1363 1364 1365 1366 1367 1369 1371 1372 1374 1378 1379 1380 1381 1382 1383 1384 1385 1386 1388 1390 1391 1393 1394 Example Schema Diagram 1396 10. References 1398 10.1. Normative References 1400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1401 Requirement Levels", BCP 14, RFC 2119, March 1997. 1403 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1404 Resource Identifier (URI): Generic Syntax", STD 66, 1405 RFC 3986, January 2005. 1407 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1408 Object Description Exchange Format", RFC 5070, 1409 December 2007. 1411 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1412 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1413 May 2008. 1415 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1416 RFC 6045, November 2010. 1418 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1419 Inter-network Defense (RID) Messages", RFC 6046, 1420 November 2010. 1422 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1423 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1424 Edition)", W3C Recommendation, November 2008. 1426 [XMLschemaPart1] 1427 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1428 "XML Schema Part 1: Structures Second Edition", 1429 W3C Recommendation, October 2004. 1431 [XMLschemaPart2] 1432 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1433 Second Edition", W3C Recommendation, October 2004. 1435 [XMLNames] 1436 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1437 Thomson, ""Namespaces in XML (Third Edition)", 1438 W3C Recommendation, December 2009. 1440 10.2. Informative References 1442 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1443 Internet: Timestamps", RFC 3339, July 2002. 1445 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1446 Text on Security Considerations", BCP 72, RFC 3552, 1447 July 2003. 1449 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1450 January 2004. 1452 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1453 October 2008. 1455 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1456 Uniform Resource Identifiers (URI) Dynamic Delegation 1457 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1458 March 2011. 1460 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1461 Common Vulnerability Scoring System (CVSS) and Its 1462 Applicability to Federal Agency Systems". 1464 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1465 and Classification (CAPEC)". 1467 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1469 [CPE] Brant A. Cheikes and David Waltermire and Karen Scarfone, 1470 "Common Platform Enumeration: Naming Specificatino Version 1471 2.3", August 2011. 1473 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1474 (CVE)". 1476 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1478 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1479 (CWE)". 1481 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1482 (CWSS)". 1484 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1485 Open Checklist Interactive Language (OCIL) Version 2.0", 1486 April 2011. 1488 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1489 Language (OVAL)". 1491 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1492 and Neal Ziring, "Specification for the Extensible 1493 Configuration Checklist Description Format (XCCDF) version 1494 1.2 (DRAFT)", July 2011. 1496 Authors' Addresses 1498 Takeshi Takahashi 1499 National Institute of Information and Communications Technology 1500 4-2-1 Nukui-Kitamachi Koganei 1501 184-8795 Tokyo 1502 Japan 1504 Phone: +80 423 27 5862 1505 Email: takeshi_takahashi@nict.go.jp 1507 Kent Landfield 1508 McAfee, Inc 1509 5000 Headquarters Drive 1510 Plano, TX 75024 1511 USA 1513 Email: Kent_Landfield@McAfee.com 1515 Thomas Millar 1516 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1517 245 Murray Lane SW, Building 410, MS #732 1518 Washington, DC 20598 1519 USA 1521 Phone: +1 888 282 0870 1522 Email: thomas.millar@us-cert.gov 1524 Youki Kadobayashi 1525 Nara Institute of Science and Technology 1526 8916-5 Takayama, Ikoma 1527 630-0192 Nara 1528 Japan 1530 Email: youki-k@is.aist-nara.ac.jp