idnits 2.17.1 draft-ietf-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 5 instances of too long lines in the document, the longest one being 3 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 (Feb 1, 2012) is 4461 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: 'CCE' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: 'CCSS' is defined on line 1451, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1499, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1502, but no explicit reference was found in the text == Unused Reference: 'SCAP' is defined on line 1507, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'CAPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CEE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CPE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CVE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CVRF' -- Possible downref: Non-RFC (?) normative reference: ref. 'CVSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CWE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CWSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OCIL' -- Possible downref: Non-RFC (?) normative reference: ref. 'OVAL' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCCDF' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 17 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: August 4, 2012 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Feb 1, 2012 12 IODEF-extension to support structured cybersecurity information 13 draft-ietf-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], 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 August 4, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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. List of Supported 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 . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1.4. CEE 0.6 . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1.5. CPE 2.3 Language . . . . . . . . . . . . . . . . . . . 6 70 4.1.6. CPE 2.3 Dictionary . . . . . . . . . . . . . . . . . . 7 71 4.1.7. CVE 1.0 . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1.8. CVRF 1.0 . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.9. CVSS 2.0 . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1.10. CWE 5.0 . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1.11. CWSS 0.8 . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1.12. MAEC 2.0 . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1.13. OCIL 2.0 . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1.14. OVAL 5.10.1 Definitions . . . . . . . . . . . . . . . 8 79 4.1.15. OVAL 5.10.1 Results . . . . . . . . . . . . . . . . . 8 80 4.1.16. OVAL 5.10.1 Common . . . . . . . . . . . . . . . . . . 8 81 4.1.17. XCCDF 1.2 . . . . . . . . . . . . . . . . . . . . . . 8 82 4.2. Extended Data Types . . . . . . . . . . . . . . . . . . . 9 83 4.2.1. XMLDATA . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 9 85 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 10 86 4.3.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 12 87 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 13 88 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 17 91 4.3.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 19 92 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 20 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 5.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 22 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24 97 8. Appendix I: XML Schema Definition for Extension . . . . . . . 24 98 9. Appendix II: XML Examples . . . . . . . . . . . . . . . . . . 28 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 104 1. Introduction 106 Cyber attacks are getting more sophisticated, and their numbers are 107 increasing day by day. To cope with such situation, incident 108 information needs to be reported, exchanged, and shared among 109 organizations. IODEF is one of the tools enabling such exchange, and 110 is already in use. 112 To efficiently run cybersecurity operations, these exchanged 113 information needs to be machine-readable. IODEF provides a 114 structured means to describe the information, but it needs to embed 115 various non-structured such information in order to convey detailed 116 information. Further structure within IODEF increases IODEF 117 documents' machine-readability and thus facilitates streamlining 118 cybersecurity operations. 120 On the other hand, there exist various other activities facilitating 121 detailed and structured description of cybersecurity information, 122 major of which includes CAPEC [CAPEC], CEE [CEE], CPE [CPE], CVE 123 [CVE], CVRF [CVRF], CVSS [CVSS], CWE [CWE], CWSS [CWSS], OCIL [OCIL], 124 OVAL [OVAL], and XCCDF [XCCDF]. Since such structured description 125 facilitates cybersecurity operations, it would be beneficial to embed 126 and convey these information inside IODEF document. 128 To enable that, this document extends the IODEF to embed and convey 129 various structured cybersecurity information, with which 130 cybersecurity operations can be facilitated. Since IODEF defines a 131 flexible and extensible format and supports a granular level of 132 specificity, this document defines an extension to IODEF instead of 133 defining a new report format. For clarity, and to eliminate 134 duplication, only the additional structures necessary for describing 135 the exchange of such structured information are provided. 137 2. Terminology 139 The terminology used in this document follows the one defined in RFC 140 5070 [RFC5070]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 3. Applicability 148 To maintain cybersecurity, organization needs to exchange 149 cybersecurity information, which includes the following information: 151 attack pattern, platform information, vulnerability and weakness, 152 countermeasure instruction, computer event log, and the severity. 154 IODEF provides a scheme to exchange such information among interested 155 parties. However, the detailed common format to describe such 156 information is not defined in the IODEF base document. 158 On the other hand, to describe those information and to facilitate 159 exchange, a structured format for that is already available. Major 160 of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OCIL, OVAL, 161 and XCCDF. By embedding them into the IODEF document, the document 162 can convey more detailed contents to the receivers, and the document 163 can be easily reused. Note that interactive communication is needed 164 in some cases, and some of these structured information, e.g., OCIL 165 information, solicits reply from recipients. These reply could be 166 also embedded inside the IODEF document. 168 These structured cybersecurity information facilitates cybersecurity 169 operation at the receiver side. Since the information is machine- 170 readable, the data can be processed by computers. That expedites the 171 automation of cybersecurity operations 173 For instance, an organization wishing to report a security incident 174 wants to describe what vulnerability was exploited. Then the sender 175 can simply use IODEF, where an CAPEC record is embedded instead of 176 describing everything in free format text. Receiver can also 177 identify the needed details of the attack pattern by looking up some 178 of the xml [XML1.0] tags defined by CAPEC. Receiver can accumulate 179 the attack pattern information (CAPEC record) in its database and 180 could distribute it to the interested parties if needed, without 181 needing human interventions. 183 4. Extension Definition 185 This draft extends IODEF to embed structured cybersecurity 186 information by introducing new classes, with which these information 187 can be embedded inside IODEF document as element contents of 188 AdditionalData and RecordItem classes. 190 4.1. List of Supported Structured Cybersecurity Information 191 Specifictions 193 This extension embeds structured cybersecurity information from 194 external specifications. The initial list of supported 195 specifications is listed below. Each entry has namespace [XMLNames], 196 specification name, version, specification URI and applicable classes 197 for each specification. Future assignments are to be managed by IANA 198 using the Expert Review [RFC5226] and Specification Required 199 [RFC5226] allocation policies as further specified in Section 6. 201 4.1.1. CAPEC 1.6 203 Namespace: http://capec.mitre.org/observables 204 Specification Name: Common Attack Pattern Enumeration and Classification 205 Version: 1.6 206 Specification URI: http://capec.mitre.org/ 207 Applicable Classes: AttackPattern 209 4.1.2. CCE 5.0 211 Namespace: http://cce.mitre.org 212 Specification Name: Common Configuration Enumeration 213 Version: 5.0 214 Specification URI: http://cce.mitre.org/ 215 Applicable Classes: Verification 217 4.1.3. CCSS 1.0 219 Namespace: N/A 220 Specification Name: Common Configuration Scoring System 221 Version: 1.0 222 Specification URI: TBD 223 Applicable Classes: Scoring 225 4.1.4. CEE 0.6 227 Namespace: http://cee.mitre.org 228 Specification Name: Common Event Expression 229 Version: 0.6 230 Specification URI: http://cee.mitre.org/ 231 Applicable Classes: EventReport 233 4.1.5. CPE 2.3 Language 235 Namespace: http://cpe.mitre.org/language/2.0 236 Specification Name: Common Platform Enumeration Reference 237 Version: 2.3 238 Specification URI: http://scap.nist.gov/specifications/cpe/ 239 Applicable Classes: Platform 241 4.1.6. CPE 2.3 Dictionary 243 Namespace: http://cpe.mitre.org/dictionary/2.0 244 Specification Name: Common Platform Enumeration Dictionary 245 Version: 2.3 246 Specification URI: http://scap.nist.gov/specifications/cpe/ 247 Applicable Classes: Platform 249 4.1.7. CVE 1.0 251 Namespace: http://cve.mitre.org/cve/downloads/1.0 252 Specification Name: Common Vulnerability and Exposures 253 Version: 1.0 254 Specification URI: http://cve.mitre.org/ 255 Applicable Classes: Vulnerability 257 4.1.8. CVRF 1.0 259 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 260 Specification Name: Common Vulnerability Reporting Format 261 Version: 1.0 262 Specification URI: http://www.icasi.org/cvrf 263 Applicable Classes: Vulnerability 265 4.1.9. CVSS 2.0 267 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 268 Specification Name: Common Vulnerability Scoring System 269 Version: 2 270 Specification URI: http://www.first.org/cvss 271 Applicable Classes: Scoring 273 4.1.10. CWE 5.0 275 Namespace: N/A 276 Specification Name: Common Weakness Enumeration 277 Version: 5.1 278 Specification URI: http://cwe.mitre.org/ 279 Applicable Classes: Weakness 281 4.1.11. CWSS 0.8 283 Namespace: N/A 284 Specification Name: Common Weakness Scoring System 285 Version: 0.8 286 Specification URI: http://cwe.mitre.org/cwss/ 287 Applicable Classes: Scoring 289 4.1.12. MAEC 2.0 291 Namespace: http://maec.mitre.org/XMLSchema/maec-core-2 292 Specification Name: Malware Attribute Enumeration and Characterization 293 Version: 2.0 294 Specification URI: http://maec.mitre.org/ 295 Applicable Classes: EventReport, AttackPattern 297 4.1.13. OCIL 2.0 299 Namespace: http://scap.nist.gov/schema/ocil/2.0 300 Specification Name: Open Checklist Interactive Language 301 Version: 2.0 302 Specification URI: http://scap.nist.gov/specifications/ocil/ 303 Applicable Classes: Verification 305 4.1.14. OVAL 5.10.1 Definitions 307 Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 308 Specification Name: Open Vulnerability and Assessment Language 309 Version: 5.10.1 310 Specification URI: http://oval.mitre.org/ 311 Applicable Classes: Verification 313 4.1.15. OVAL 5.10.1 Results 315 Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 316 Specification Name: Open Vulnerability and Assessment Language 317 Version: 5.10.1 318 Specification URI: TBD 319 Applicable Classes: Verification 321 4.1.16. OVAL 5.10.1 Common 323 Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 324 Specification Name: Open Vulnerability and Assessment Language 325 Version: 5.10.1 326 Specification URI: TBD 327 Applicable Classes: Verification 329 4.1.17. XCCDF 1.2 331 Namespace: http://checklists.nist.gov/xccdf/1.2 332 Specification Name: Extensible Configuration Checklist Description Format 333 Version: 1.2 334 Specification URI: http://scap.nist.gov/specifications/xccdf/ 335 Applicable Classes: Verification 337 4.2. Extended Data Types 339 This extension inherits all of the data types defined in the IODEF 340 model. One data type is added: XMLDATA. 342 4.2.1. XMLDATA 344 An embedded XML data is represented by the XMLDATA data type. This 345 type is defined as the extension to the iodef:ExtensionType 346 [RFC5070], whose dtype attribute is set to "xml." 348 4.3. Extended Classes 350 The IODEF Incident element [RFC5070] is summarized below. It is 351 expressed in Unified Modeling Language (UML) syntax as used in the 352 IODEF specification. The UML representation is for illustrative 353 purposes only; elements are specified in XML as defined in Appendix 354 A. 356 +--------------------+ 357 | Incident | 358 +--------------------+ 359 | ENUM purpose |<>---------[IncidentID] 360 | STRING ext-purpose |<>--{0..1}-[AlternativeID] 361 | ENUM lang |<>--{0..1}-[RelatedActivity] 362 | ENUM restriction |<>--{0..1}-[DetectTime] 363 | |<>--{0..1}-[StartTime] 364 | |<>--{0..1}-[EndTime] 365 | |<>---------[ReportTime] 366 | |<>--{0..*}-[Description] 367 | |<>--{1..*}-[Assessment] 368 | |<>--{0..*}-[Method] 369 | | |<>--[AdditionalData] 370 | | |<>--[AttackPattern] 371 | | |<>--[Vulnerability] 372 | | |<>--[Weakness] 373 | |<>--{1..*}-[Contact] 374 | |<>--{0..*}-[EventData] 375 | | |<>--[Flow] 376 | | | |<>--[System] 377 | | | |<>--[AdditionalData] 378 | | | |<>--[Platform] 379 | | |<>--[Expectation] 380 | | |<>--[Record] 381 | | |<>--[RecordData] 382 | | |<>--[RecordItem] 383 | | |<>--[EventReport] 384 | |<>--{0..1}-[History] 385 | |<>--{0..*}-[AdditionalData] 386 | | |<>--[Verification] 387 | | |<>--[Remediation] 388 +--------------------+ 390 Figure 1: Incident class 392 This extension defines the following seven elements. 394 4.3.1. AttackPattern 396 An AttackPattern consists of an extension to the 397 Incident.Method.AdditionalData element with a dtype of "xml". The 398 extension describes attack patterns of incidents or events. 400 It is recommended that Method class SHOULD contain one or more of the 401 extension elements whenever available. 403 An AttackPattern class is structured as follows. 405 +------------------------+ 406 | AttackPattern | 407 +------------------------+ 408 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 409 | STRING AttackPatternID |<>--(0..*)-[ Reference ] 410 | |<>--(0..*)-[ Platform ] 411 +------------------------+ 413 Figure 2: AttackPattern class 415 This class has the following attributes. 417 SpecificationID: REQUIRED. ENUM. The identifier of the 418 specification specifying the format of the RawData element. The 419 value should be chosen from the namespaces [XMLNames] listed in 420 Section 4.1. Note that the lists in Section 4.1 will be developed 421 further by IANA. In case a RawData or Reference element is 422 provided along with this attribute, writers/senders MUST ensure 423 that this value is consistent with the one provided by the 424 element; if a reader/receiver detects an inconsistency, it SHOULD 425 prefer this attribute's value, and SHOULD log the inconsistency so 426 a human can correct the problem. 428 AttackPatternID: OPTIONAL. STRING. An identifier of an attack 429 pattern to be reported. This attribute SHOULD be used whenever 430 such identifier is available, but could be omitted if no such one 431 is available. In this case, either RawData or Reference elements, 432 or both of them, MUST be provided. In case a RawData or Reference 433 element is provided along with this attribute, writers/senders 434 MUST ensure that this value is consistent with the one provided by 435 the element; if a reader/receiver detects an inconsistency, it 436 SHOULD prefer this attribute's value, and SHOULD log the 437 inconsistency so a human can correct the problem. 439 The AttackPattern class is composed of the following aggregate 440 classes. 442 RawData: Zero or more. XMLDATA. A complete document that is 443 formatted according to the specification and its version 444 identified by the value of the SpecificationID with the 445 Section 4.1. 447 Reference: Zero or more of iodef:Reference [RFC5070]. This element 448 allows an IODEF document to include a link to a structured 449 information instead of directly embedding it into a RawData 450 element. 452 Platform: Zero or more. An identifier of software platform involved 453 in the specific attack pattern, which is elaborated in 454 Section 4.3.2. Some of the structured information embedded in the 455 RawData element may include the identifier within it. In this 456 case, this Platform element SHOULD NOT be used. If a reader/ 457 receiver detects the identifiers in both RawData and Platform 458 elements and their inconsistency, it SHOULD prefer the identifiers 459 derived from the Platform element, and SHOULD log the 460 inconsistency so a human can correct the problem. 462 4.3.2. Platform 464 A Platform identifies a software platform. It is recommended that 465 AttackPattern, Vulnerability, Weakness, and System classes contain 466 this elements whenever available. 468 A Platform element is structured as follows. 470 +----------------------+ 471 | Platform | 472 +----------------------+ 473 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 474 | STRING PlatformID |<>--(0..*)-[ Reference ] 475 +----------------------+ 477 Figure 3: Platform class 479 This class has the following attributes. 481 SpecificationID: REQUIRED. ENUM. The identifier of the 482 specification specifying the format of the RawData element. The 483 value should be chosen from the namespaces [XMLNames] listed in 484 Section 4.1. Note that the lists in Section 4.1 will be developed 485 further by IANA. In case a RawData or Reference element is 486 provided along with this attribute, writers/senders MUST ensure 487 that this value is consistent with the one provided by the 488 element; if a reader/receiver detects an inconsistency, it SHOULD 489 prefer this attribute's value, and SHOULD log the inconsistency so 490 a human can correct the problem. 492 PlatformID: OPTIONAL. STRING. An identifier of a platform to be 493 reported. This attribute SHOULD be used whenever such identifier 494 is available, but could be omitted if no such one is available. 495 In this case, either RawData or Reference elements, or both of 496 them, MUST be provided. In case a RawData or Reference element is 497 provided along with this attribute, writers/senders MUST ensure 498 that this value is consistent with the one provided by the 499 element; if a reader/receiver detects an inconsistency, it SHOULD 500 prefer this attribute's value, and SHOULD log the inconsistency so 501 a human can correct the problem. 503 This class is composed of the following aggregate classes. 505 RawData: Zero or more. XMLDATA. A complete document that is 506 formatted according to the specification and its version 507 identified by the value of the SpecificationID with the 508 Section 4.1. 510 Reference: Zero or more of iodef:Reference [RFC5070]. This element 511 allows an IODEF document to include a link to a structured 512 information instead of directly embedding it into a RawData 513 element. 515 Writers/senders MUST ensure the specification name and version 516 identified by the SpecificationID are consistent with the contents of 517 the ID; if a reader/receiver detects an inconsistency, it SHOULD 518 prefer the specification name and version derived from the content, 519 and SHOULD log the inconsistency so a human can correct the problem. 521 4.3.3. Vulnerability 523 A Vulnerability consists of an extension to the 524 Incident.Method.AdditionalData element with a dtype of "xml". The 525 extension describes the (candidate) vulnerabilities of incidents or 526 events. 528 It is recommended that Method class SHOULD contain one or more of the 529 extension elements whenever available. 531 A Vulnerability element is structured as follows. 533 +------------------------+ 534 | Vulnerability | 535 +------------------------+ 536 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 537 | STRING VulnerabilityID |<>--(0..*)-[ Reference ] 538 | |<>--(0..*)-[ Platform ] 539 | |<>--(0..*)-[ Scoring ] 540 +------------------------+ 542 Figure 4: Vulnerability class 544 This class has the following attributes. 546 SpecificationID: REQUIRED. ENUM. The identifier of the 547 specification specifying the format of the RawData element. The 548 value should be chosen from the namespaces [XMLNames] listed in 549 Section 4.1. Note that the lists in Section 4.1 will be developed 550 further by IANA. In case a RawData or Reference element is 551 provided along with this attribute, writers/senders MUST ensure 552 that this value is consistent with the one provided by the 553 element; if a reader/receiver detects an inconsistency, it SHOULD 554 prefer this attribute's value, and SHOULD log the inconsistency so 555 a human can correct the problem. 557 VulnerabilityID: OPTIONAL. STRING. An identifier of a 558 vulnerability to be reported. This attribute SHOULD be used 559 whenever such identifier is available, but could be omitted if no 560 such one is available. In this case, either RawData or Reference 561 elements, or both of them, MUST be provided. In case a RawData or 562 Reference element is provided along with this attribute, writers/ 563 senders MUST ensure that this value is consistent with the one 564 provided by the element; if a reader/receiver detects an 565 inconsistency, it SHOULD prefer this attribute's value, and SHOULD 566 log the inconsistency so a human can correct the problem. 568 This class is composed of the following aggregate classes. 570 RawData: Zero or one. XMLDATA. A complete document that is 571 formatted according to the specification and its version 572 identified by the value of the SpecificationID with the 573 Section 4.1. 575 Reference: Zero or one of iodef:Reference [RFC5070]. This element 576 allows an IODEF document to include a link to a structured 577 information instead of directly embedding it into a RawData 578 element. 580 Platform: Zero or more. An identifier of software platform affected 581 by the vulnerability, which is elaborated in Section 4.3.2. Some 582 of the structured information embedded in the RawData element may 583 include the identifier within it. In this case, this element 584 SHOULD NOT be used. If a reader/receiver detects the identifiers 585 in both RawData and Platform elements and their inconsistency, it 586 SHOULD prefer the identifiers derived from the Platform element, 587 and SHOULD log the inconsistency so a human can correct the 588 problem. 590 Scoring: Zero or more. An indicator of the severity of the 591 vulnerability, such as CVSS and CCSS scores, which is elaborated 592 in Section 4.3.4. Some of the structured information may include 593 scores within it. In this case, the Scoring element SHOULD NOT be 594 used since the RawData element contains the scores. If a reader/ 595 receiver detects scores in both RawData and Scoring elements and 596 their inconsistency, it SHOULD prefer the scores derived from the 597 RawData element, and SHOULD log the inconsistency so a human can 598 correct the problem. 600 4.3.4. Scoring 602 A Scoring class describes the scores of the severity in terms of 603 security. It is recommended that Vulnerability and Weakness classes 604 contain the elements whenever available. 606 A Scoring class is structured as follows. 608 +----------------------+ 609 | Scoring | 610 +----------------------+ 611 | ENUM SpecificationID |<>---------[ ScoreSet ] 612 +----------------------+ 614 Figure 5: Scoring class 616 This class has two attributes. 618 SpecificationID: REQUIRED. ENUM. The identifier of the 619 specification specifying the format of the RawData element. The 620 value should be chosen from the namespaces [XMLNames] listed in 621 Section 4.1. Note that the lists in Section 4.1 will be developed 622 further by IANA. In case a RawData or Reference element is 623 provided along with this attribute, writers/senders MUST ensure 624 that this namespace is consistent with the one provided by the 625 element; if a reader/receiver detects an inconsistency, it SHOULD 626 prefer the value of this attribute, and SHOULD log the 627 inconsistency so a human can correct the problem. 629 This class is composed of an aggregate class. 631 ScoreSet: One. XMLDATA. A complete document that is formatted 632 according to the specification and its version identified by the 633 value of the SpecificationID with the Section 4.1. This element 634 includes a set of score information. 636 Writers/senders MUST ensure the specification name and version 637 identified by the SpecificationID are consistent with the contents of 638 the Score; if a reader/receiver detects an inconsistency, it SHOULD 639 prefer the specification name and version derived from the content, 640 and SHOULD log the inconsistency so a human can correct the problem. 642 4.3.5. Weakness 644 A Weakness consists of an extension to the 645 Incident.Method.AdditionalData element with a dtype of "xml". The 646 extension describes the weakness types of incidents or events. 648 It is recommended that Method class SHOULD contain one or more of the 649 extension elements whenever available. 651 A Weakness element is structured as follows. 653 +----------------------+ 654 | Weakness | 655 +----------------------+ 656 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 657 | STRING WeaknessID |<>--(0..*)-[ Reference ] 658 | |<>--(0..*)-[ Platform ] 659 | |<>--(0..*)-[ Scoring ] 660 +----------------------+ 662 Figure 6: Weakness class 664 This class has the following attributes. 666 SpecificationID: REQUIRED. ENUM. The identifier of the 667 specification specifying the format of the RawData element. The 668 value should be chosen from the namespaces [XMLNames] listed in 669 Section 4.1. Note that the lists in Section 4.1 will be developed 670 further by IANA. In case a RawData or Reference element is 671 provided along with this attribute, writers/senders MUST ensure 672 that this value is consistent with the one provided by the 673 element; if a reader/receiver detects an inconsistency, it SHOULD 674 prefer this attribute's value, and SHOULD log the inconsistency so 675 a human can correct the problem. 677 WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be 678 reported. This attribute SHOULD be used whenever such identifier 679 is available, but could be omitted if no such one is available. 680 In this case, either RawData or Reference elements, or both of 681 them, MUST be provided. In case a RawData or Reference element is 682 provided along with this attribute, writers/senders MUST ensure 683 that this value is consistent with the one provided by the 684 element; if a reader/receiver detects an inconsistency, it SHOULD 685 prefer this attribute's value, and SHOULD log the inconsistency so 686 a human can correct the problem. 688 This class is composed of the following aggregate classes. 690 RawData: Zero or more. XMLDATA. A complete document that is 691 formatted according to the specification and its version 692 identified by the value of the SpecificationID with the 693 Section 4.1. 695 Reference: Zero or one of iodef:Reference [RFC5070]. This element 696 allows an IODEF document to include a link to a structured 697 information instead of directly embedding it into a RawData 698 element. 700 Platform: Zero or more. An identifier of software platform affected 701 by the weakness, which is elaborated in Section 4.3.2. Some of 702 the structured information embedded in the RawData element may 703 include the identifier within it. In this case, this element 704 SHOULD NOT be used. If a reader/receiver detects the identifiers 705 in both RawData and Platform elements and their inconsistency, it 706 SHOULD prefer the identifiers derived from the Platform element, 707 and SHOULD log the inconsistency so a human can correct the 708 problem. 710 Scoring: Zero or more. An indicator of the severity of the 711 weakness, such as CWSS score, which is elaborated in 712 Section 4.3.4. Some of the structured information may include 713 scores within it. In this case, the Scoring element SHOULD NOT be 714 used since the RawData element contains the scores. If a reader/ 715 receiver detects scores in both RawData and Scoring elements and 716 their inconsistency, it SHOULD prefer the scores derived from the 717 RawData element, and SHOULD log the inconsistency so a human can 718 correct the problem. 720 4.3.6. EventReport 722 An EventReport consists of an extension to the 723 Incident.EventData.Record.RecordData.RecordItem element with a dtype 724 of "xml". The extension embeds structured event reports. 726 It is recommended that RecordItem class SHOULD contain one or more of 727 the extension elements whenever available. 729 An EventReport element is structured as follows. 731 +----------------------+ 732 | EventReport | 733 +----------------------+ 734 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 735 | STRING EventID |<>--(0..*)-[ Reference ] 736 +----------------------+ 737 Figure 7: EventReport class 739 This class has the following attributes. 741 SpecificationID: REQUIRED. ENUM. The identifier of the 742 specification specifying the format of the RawData element. The 743 value should be chosen from the namespaces [XMLNames] listed in 744 Section 4.1. Note that the lists in Section 4.1 will be developed 745 further by IANA. In case a RawData or Reference element is 746 provided along with this attribute, writers/senders MUST ensure 747 that this value is consistent with the one provided by the 748 element; if a reader/receiver detects an inconsistency, it SHOULD 749 prefer this attribute's value, and SHOULD log the inconsistency so 750 a human can correct the problem. 752 EventID: OPTIONAL. STRING. An identifier of an event to be 753 reported. This attribute SHOULD be used whenever such identifier 754 is available, but could be omitted if no such one is available. 755 In this case, either RawData or Reference elements, or both of 756 them, MUST be provided. In case a RawData or Reference element is 757 provided along with this attribute, writers/senders MUST ensure 758 that this value is consistent with the one provided by the 759 element; if a reader/receiver detects an inconsistency, it SHOULD 760 prefer this attribute's value, and SHOULD log the inconsistency so 761 a human can correct the problem. 763 This class is composed of three aggregate classes. 765 RawData: Zero or one. XMLDATA. A complete document that is 766 formatted according to the specification and its version 767 identified by the value of the SpecificationID with the 768 Section 4.1. 770 Reference: Zero or one of iodef:Reference [RFC5070]. This element 771 allows an IODEF document to include a link to a structured 772 information instead of directly embedding it into a RawData 773 element. 775 This class MUST contain at least one of RawData or Reference 776 elements. Writers/senders MUST ensure the specification name and 777 version identified by the SpecificationID are consistent with the 778 contents of the RawData; if a reader/receiver detects an 779 inconsistency, it SHOULD prefer the specification name and version 780 derived from the content, and SHOULD log the inconsistency so a human 781 can correct the problem. 783 4.3.7. Verifcation 785 A Verification consists of an extension to the 786 Incident.AdditionalData element with a dtype of "xml". The extension 787 elements describes incident on vefifying incidents. 789 A Verification class is structured as follows. 791 +----------------------+ 792 | Verification | 793 +----------------------+ 794 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 795 | STRING VerificationID|<>--(0..*)-[ Reference ] 796 +----------------------+ 798 Figure 8: Verification class 800 This class has the following attributes. 802 SpecificationID: REQUIRED. ENUM. The identifier of the 803 specification specifying the format of the RawData element. The 804 value should be chosen from the namespaces [XMLNames] listed in 805 Section 4.1. Note that the lists in Section 4.1 will be developed 806 further by IANA. In case a RawData or Reference element is 807 provided along with this attribute, writers/senders MUST ensure 808 that this value is consistent with the one provided by the 809 element; if a reader/receiver detects an inconsistency, it SHOULD 810 prefer this attribute's value, and SHOULD log the inconsistency so 811 a human can correct the problem. 813 VerificationID: OPTIONAL. STRING. An identifier of an check item 814 to be reported. This attribute SHOULD be used whenever such 815 identifier is available, but could be omitted if no such one is 816 available. In this case, either RawData or Reference elements, or 817 both of them, MUST be provided. In case a RawData or Reference 818 element is provided along with this attribute, writers/senders 819 MUST ensure that this value is consistent with the one provided by 820 the element; if a reader/receiver detects an inconsistency, it 821 SHOULD prefer this attribute's value, and SHOULD log the 822 inconsistency so a human can correct the problem. 824 This class is composed of two aggregate classes. 826 RawData: Zero or one. XMLDATA. A complete document that is 827 formatted according to the specification and its version 828 identified by the value of the SpecificationID with the 829 Section 4.1. 831 Reference: Zero or one of iodef:Reference [RFC5070]. This element 832 allows an IODEF document to include a link to a structured 833 information instead of directly embedding it into a RawData 834 element. 836 This class MUST contain at least either of RawData and Reference 837 elements. Writers/senders MUST ensure the specification name and 838 version identified by the SpecificationID are consistent with the 839 contents of the RawData; if a reader/receiver detects an 840 inconsistency, it SHOULD prefer the specification name and version 841 derived from the content, and SHOULD log the inconsistency so a human 842 can correct the problem. 844 4.3.8. Remediation 846 A Remediation consists of an extension to the Incident.AdditionalData 847 element with a dtype of "xml". The extension elements describes 848 incident remediation information including instructions. 850 It is recommended that Incident class SHOULD contain one or more of 851 this extension elements whenever available. 853 A Remediation class is structured as follows. 855 +----------------------+ 856 | Remediation | 857 +----------------------+ 858 | ENUM SpecificationID |<>--(0..*)-[ RawData ] 859 | String RemediationID |<>--(0..*)-[ Reference ] 860 +----------------------+ 862 Figure 9: Remediation class 864 This class has the following attributes. 866 SpecificationID: REQUIRED. ENUM. The identifier of the 867 specification specifying the format of the RawData element. The 868 value should be chosen from the namespaces [XMLNames] listed in 869 Section 4.1. Note that the lists in Section 4.1 will be developed 870 further by IANA. In case a RawData or Reference element is 871 provided along with this attribute, writers/senders MUST ensure 872 that this value is consistent with the one provided by the 873 element; if a reader/receiver detects an inconsistency, it SHOULD 874 prefer this attribute's value, and SHOULD log the inconsistency so 875 a human can correct the problem. 877 RemediationID: OPTIONAL. STRING. An identifier of a remediation 878 information to be reported. This attribute SHOULD be used 879 whenever such identifier is available, but could be omitted if no 880 such one is available. In this case, either RawData or Reference 881 elements, or both of them, MUST be provided. In case a RawData or 882 Reference element is provided along with this attribute, writers/ 883 senders MUST ensure that this value is consistent with the one 884 provided by the element; if a reader/receiver detects an 885 inconsistency, it SHOULD prefer this attribute's value, and SHOULD 886 log the inconsistency so a human can correct the problem. 888 This class is composed of two aggregate classes. 890 RawData: Zero or one. XMLDATA. A complete document that is 891 formatted according to the specification and its version 892 identified by the value of the SpecificationID with the 893 Section 4.1. 895 Reference: Zero or one of iodef:Reference [RFC5070]. This element 896 allows an IODEF document to include a link to a structured 897 information instead of directly embedding it into a RawData 898 element. 900 This class MUST contain at least either of RawData and Reference 901 elements. Writers/senders MUST ensure the specification name and 902 version identified by the SpecificationID are consistent with the 903 contents of the RawData; if a reader/receiver detects an 904 inconsistency, it SHOULD prefer the specification name and version 905 derived from the content, and SHOULD log the inconsistency so a human 906 can correct the problem. 908 5. Security Considerations 910 This document specifies a format for encoding a particular class of 911 security incidents appropriate for exchange across organizations. As 912 merely a data representation, it does not directly introduce security 913 issues. However, it is guaranteed that parties exchanging instances 914 of this specification will have certain concerns. For this reason, 915 the underlying message format and transport protocol used MUST ensure 916 the appropriate degree of confidentiality, integrity, and 917 authenticity for the specific environment. 919 Organizations that exchange data using this document are URGED to 920 develop operating procedures that document the following areas of 921 concern. 923 5.1. Transport-Specific Concerns 925 The underlying messaging format and protocol used to exchange 926 instances of the IODEF MUST provide appropriate guarantees of 927 confidentiality, integrity, and authenticity. The use of a 928 standardized security protocol is encouraged. The Real-time Inter- 929 network Defense (RID) protocol [RFC6045] and its associated transport 930 binding [RFC6046] provide such security. 932 The critical security concerns are that these structured information 933 may be falsified or they may become corrupt during transit. In areas 934 where transmission security or secrecy is questionable, the 935 application of a digital signature and/or message encryption on each 936 report will counteract both of these concerns. We expect that each 937 exchanging organization will determine the need, and mechanism, for 938 transport protection. 940 6. IANA Considerations 942 This document uses URNs to describe XML namespaces and XML 943 schemata[XMLschemaPart1][XMLschemaPart2] conforming to a registry 944 mechanism described in [RFC3688]. 946 Registration request for the IODEF structured cybersecurity 947 information extension namespace: 949 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 951 Registrant Contact: Refer here to the authors' addresses section 952 of the document. 954 XML: None 956 Registration request for the IODEF structured cybersecurity 957 information extension XML schema: 959 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 961 Registrant Contact: Refer here to the authors' addresses section 962 of the document. 964 XML: Refer here to the XML Schema in the appendix of the document. 966 This memo creates the following registry for IANA to manage: 968 Name of the registry: "IODEF Structured Cyber Security Information 969 Specifications" 971 Namespace details: A registry entry for a Structured Cyber 972 Security Information Specification (SCI specification) consists 973 of: 975 Namespace: A URI [RFC3986] that is the XML namespace name used 976 by the registered SCI specification. 978 Specification Name: A string containing the spelled-out name of 979 the SCI specification in human-readable form. 981 Specification URI: A list of one or more of the URIs [RFC3986] 982 from which the registered specification can be obtained. The 983 registered specification MUST be readily and publicly available 984 from that URI. 986 Applicable Classes: A list of one or more of the Extended 987 Classes specified in Section 4.3 of this document. The 988 registered SCI specification MUST only be used with the 989 Extended Classes in the registry entry. 991 Information that must be provided to assign a new value: The above 992 list of information. 994 Fields to record in the registry: Namespace/Specification Name/ 995 Version/Applicable Classes. 997 Initial registry contents: See sections from Section 4.1.1 through 998 Section 4.1.17 above. 1000 Allocation Policy: Expert Review [RFC5226] and Specification 1001 Required [RFC5226]. 1003 The Designated Expert is expected to consult with the mile (Managed 1004 Incident Lightweight Exchange) working group or its successor if any 1005 such WG exists (e.g., via email to the working group's mailing list). 1006 The Designated Expert is expected to retrieve the SCI specification 1007 from the provided URI in order to check the public availability of 1008 the specification and verify the correctness of the URI. An 1009 important responsibility of the Designated Expert is to ensure that 1010 the registered Applicable Classes are appropriate for the registered 1011 SCI specification. 1013 7. Acknowledgment 1015 We would like to acknowledge Mr. David Black from EMC, who kindly 1016 provided generous support, especially on the IANA registry issues. 1017 We also would like to thank Paul Cichonski from NIST, Robert Martin 1018 from MITRE, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, 1019 Shuhei Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, 1020 and Brian Trammel from CERT/NetSA for their sincere discussion and 1021 feedback on this document. 1023 8. Appendix I: XML Schema Definition for Extension 1025 The XML Schema describing the elements defined in the Extension 1026 Definition section is given here. Each of the examples in Section 9 1027 should be verified to validate against this schema by automated 1028 tools. 1030 1032 1038 1041 1045 1049 1050 1051 1052 1053 1055 1056 1058 1059 1060 1061 1062 1063 1064 1066 1070 1071 1072 1073 1075 1076 1078 1079 1081 1085 1086 1087 1088 1090 1092 1094 1095 1097 1099 1100 1102 1106 1107 1108 1109 1111 1113 1115 1117 1118 1120 1122 1123 1125 1129 1130 1131 1132 1134 1136 1138 1140 1141 1143 1145 1146 1148 1152 1153 1154 1155 1157 1159 1160 1162 1164 1165 1167 1171 1172 1173 1174 1175 1176 1177 1178 1179 1181 1183 1184 1186 1190 1191 1192 1193 1194 1195 1196 1197 1198 1200 1202 1204 1206 1210 1211 1212 1213 1214 1215 1216 1217 1218 1220 1222 1223 1225 1227 9. Appendix II: XML Examples 1229 This section provides an example of an incident encoded in the IODEF. 1230 This do not necessarily represent the only way to encode a particular 1231 incident. Below is an example of a CSIRT reporting an attack. 1233 1234 1239 1240 189493 1241 2001-09-13T23:19:24+00:00 1242 Incident report in company xx 1243 1244 1245 1246 1247 Structured information on attack pattern, exploited 1248 vulnerability, and weakness 1249 1250 1252 1253 1259 ..... 1260 1261 1262 1263 Link to Capec-14 1264 http://capec.mitre.org/data/definitions/14.html 1265 1266 1267 1269 1270 1274 1275 ... 1276 1277 1278 1279 1281 1282 1283 1284 9.3 1285 NETWORK 1286 MEDIUM 1287 NONE 1288 COMPLETE 1289 COMPLETE 1290 COMPLETE 1291 http://nvd.nist.gov 1292 2012-01-11T09:55:00.000-05:00 1293 1294 1295 1296 1297 1298 1300 1301 1307 ..... 1308 1309 1310 1311 1312 1313 1314 Example.com CSIRT 1315 example-com 1316 contact@csirt.example.com 1317 1318 1319 1320 1321 1322
192.0.2.200
1323 57 1324 1325 1326 1327 1328
192.0.2.16/28
1329 1330 1331 80 1332 1333 1334 1336 1337 1338 1339 1340 1341 1342 1343 1344 2001-09-13T18:11:21+02:00 1345 a Web-server event record 1346 1347 1348 1349 1350 ..... 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 2001-09-14T08:19:01+00:00 1362 Notification sent to 1363 constituency-contact@192.0.2.200 1364 1365 1366 1367 1368 1369 1381 ..... 1382 1383 1384 1385 1386 1387 1392 ..... 1393 1394 1396 1397 1398 1399 1401 10. References 1403 10.1. Normative References 1405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1406 Requirement Levels", BCP 14, RFC 2119, March 1997. 1408 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1409 Resource Identifier (URI): Generic Syntax", STD 66, 1410 RFC 3986, January 2005. 1412 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1413 Object Description Exchange Format", RFC 5070, 1414 December 2007. 1416 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1417 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1418 May 2008. 1420 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1421 RFC 6045, November 2010. 1423 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1424 Inter-network Defense (RID) Messages", RFC 6046, 1425 November 2010. 1427 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1428 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1429 Edition)", W3C Recommendation, November 2008. 1431 [XMLschemaPart1] 1432 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1433 "XML Schema Part 1: Structures Second Edition", 1434 W3C Recommendation, October 2004. 1436 [XMLschemaPart2] 1437 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1438 Second Edition", W3C Recommendation, October 2004. 1440 [XMLNames] 1441 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1442 Thomson, ""Namespaces in XML (Third Edition)", 1443 W3C Recommendation, December 2009. 1445 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1446 and Classification (CAPEC)". 1448 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1449 (CCE)". 1451 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1452 Scoring System (CCSS)", NIST Interagency Report 7502, 1453 December 2010. 1455 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1457 [CPE] National Institute of Standards and Technology, "Common 1458 Platform Enumeration", June 2011. 1460 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1461 (CVE)". 1463 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1465 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1466 Common Vulnerability Scoring System (CVSS) and Its 1467 Applicability to Federal Agency Systems". 1469 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1470 (CWE)". 1472 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1473 (CWSS)". 1475 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1476 Open Checklist Interactive Language (OCIL) Version 2.0", 1477 April 2011. 1479 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1480 Language (OVAL)". 1482 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1483 and Neal Ziring, "Specification for the Extensible 1484 Configuration Checklist Description Format (XCCDF) version 1485 1.2 (DRAFT)", July 2011. 1487 10.2. Informative References 1489 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1490 Internet: Timestamps", RFC 3339, July 2002. 1492 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1493 Text on Security Considerations", BCP 72, RFC 3552, 1494 July 2003. 1496 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1497 January 2004. 1499 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1500 October 2008. 1502 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1503 Uniform Resource Identifiers (URI) Dynamic Delegation 1504 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1505 March 2011. 1507 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 1508 Halbardier, "The Technical Specification for the Security 1509 Content Automation Protocol (SCAP): SCAP Version 1.2", 1510 NIST Special Publication 800-126 Revision 2, 1511 September 2011. 1513 Authors' Addresses 1515 Takeshi Takahashi 1516 National Institute of Information and Communications Technology 1517 4-2-1 Nukui-Kitamachi Koganei 1518 184-8795 Tokyo 1519 Japan 1521 Phone: +80 423 27 5862 1522 Email: takeshi_takahashi@nict.go.jp 1524 Kent Landfield 1525 McAfee, Inc 1526 5000 Headquarters Drive 1527 Plano, TX 75024 1528 USA 1530 Email: Kent_Landfield@McAfee.com 1531 Thomas Millar 1532 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1533 245 Murray Lane SW, Building 410, MS #732 1534 Washington, DC 20598 1535 USA 1537 Phone: +1 888 282 0870 1538 Email: thomas.millar@us-cert.gov 1540 Youki Kadobayashi 1541 Nara Institute of Science and Technology 1542 8916-5 Takayama, Ikoma 1543 630-0192 Nara 1544 Japan 1546 Email: youki-k@is.aist-nara.ac.jp