idnits 2.17.1 draft-ietf-mile-sci-05.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 6 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC5070]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 15, 2012) is 4210 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3339' is defined on line 1403, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1406, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1413, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'CAPEC' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'CCE' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: 'CCSS' is defined on line 1427, but no explicit reference was found in the text == Unused Reference: 'CEE' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'CPE' is defined on line 1433, but no explicit reference was found in the text == Unused Reference: 'CVRF' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: 'CVSS' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'CWE' is defined on line 1445, but no explicit reference was found in the text == Unused Reference: 'CWSS' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: 'OCIL' is defined on line 1451, but no explicit reference was found in the text == Unused Reference: 'OVAL' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'SCAP' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'XCCDF' is defined on line 1464, 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 (~~), 18 warnings (==), 5 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: April 18, 2013 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Oct 15, 2012 12 IODEF-extension to support structured cybersecurity information 13 draft-ietf-mile-sci-05.txt 15 Abstract 17 This document extends the Incident Object Description Exchange Format 18 (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched 19 cybersecurity information among cybersecurity entities and facilitate 20 their operations. It provides the capability of embedding structured 21 information, such as identifier- and XML-based information. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. IANA Table for Structured Cybersecurity Information . . . 4 62 4.2. Extended Data Types . . . . . . . . . . . . . . . . . . . 5 63 4.2.1. XMLDATA . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 5 65 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 6 66 4.3.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 9 68 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13 71 4.3.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 15 72 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 16 73 5. Mandatory to Implement features . . . . . . . . . . . . . . . 17 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 18 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. Appendix I: XML Schema Definition for Extension . . . . . . . 20 79 10. Appendix II: Candidate Specifications for the IANA Table . . . 25 80 11. Appendix III: An XML Example . . . . . . . . . . . . . . . . . 28 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 30 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 86 1. Introduction 88 The number of cyber attacks is growing day by day, and incident 89 information needs to be reported, exchanged, and shared among 90 organizations in order to cope with the situation. IODEF is one of 91 the tools enabling such exchange, and is already in use. 93 To efficiently run cybersecurity operations, these exchanged 94 information needs to be machine-readable. IODEF provides a 95 structured means to describe the information, but it needs to embed 96 various non-structured such information in order to convey detailed 97 information. Further structure within IODEF increases IODEF 98 documents' machine-readability and thus facilitates streamlining 99 cybersecurity operations. 101 On the other hand, there exist various other activities facilitating 102 detailed and structured description of cybersecurity information, as 103 listed in Section 10. Since such structured description facilitates 104 cybersecurity operations, it would be beneficial to embed and convey 105 these information inside IODEF document. 107 To enable that, this document extends the IODEF to embed and convey 108 various structured cybersecurity information, with which 109 cybersecurity operations can be facilitated. Since IODEF defines a 110 flexible and extensible format and supports a granular level of 111 specificity, this document defines an extension to IODEF instead of 112 defining a new report format. For clarity, and to eliminate 113 duplication, only the additional structures necessary for describing 114 the exchange of such structured information are provided. 116 2. Terminology 118 The terminology used in this document follows the one defined in RFC 119 5070 [RFC5070]. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. Applicability 127 To maintain cybersecurity, organization needs to exchange 128 cybersecurity information, which includes the following information: 129 attack pattern, platform information, vulnerability and weakness, 130 countermeasure instruction, computer event log, and the severity. 132 IODEF provides a scheme to describe and exchange such information 133 among interested parties. However, it does not define the detailed 134 format to describe such information. 136 On the other hand, there already exist structured and detailed 137 formats for describing those information and facilitating such 138 exchange. Major of them are listed in Section 10. By embedding them 139 into the IODEF document, the document can convey more detailed 140 contents to the receivers, and the document can be easily reused. 142 These structured cybersecurity information facilitates cybersecurity 143 operation at the receiver side. Since the information is machine- 144 readable, the data can be processed by computers. That expedites the 145 automation of cybersecurity operations 147 For instance, an organization wishing to report a security incident 148 wants to describe what vulnerability was exploited. Then the sender 149 can simply use IODEF, where an XML [XML1.0]-based attack pattern 150 record that follows the syntax and vocabulary defined by an industry 151 specification is embedded instead of describing everything in free 152 format text. Receiver can identify the needed details of the attack 153 pattern by looking up some of the XML tags defined by the 154 specification. Receiver can accumulate the attack pattern record in 155 its database and could distribute it to the interested parties if 156 needed, without needing human interventions. 158 Another example is that, when an administrator wishes to check the 159 configuration of host computers in his organization, he may send a 160 query to host computers, which may automatically generate XML-based 161 software configuration information upon receiving thequery by running 162 a software and may embed that to an IODEF document, which is then 163 sent back to the administrator. 165 4. Extension Definition 167 This draft extends IODEF to embed structured cybersecurity 168 information by introducing new classes, with which these information 169 can be embedded inside IODEF document as element contents of 170 AdditionalData and RecordItem classes. 172 4.1. IANA Table for Structured Cybersecurity Information 174 This extension embeds structured cybersecurity information defined by 175 the other specifications. The list of supported specifications is 176 managed by IANA, and this draft defines the needed field for the 177 list's entry. 179 Each entry has namespace [XMLNames], specification name, version, 180 reference URI, and applicable classes for each specification. 181 Arbitrary URIs that may help readers to understand the specification 182 could be embedded inside the Reference URI field, but it is 183 recommended that standard/informational URI describing the 184 specification is prepared and is embedded here. 186 The table is to be managed by IANA using the Expert Review [RFC5226] 187 and Specification Required [RFC5226] allocation policies as further 188 specified in Section 7. 190 The SpecID attributes of extended classes (Section 4.3) must allow 191 the values of the specifications' namespace fields, but otherwise, 192 implementations are not required to support all the above 193 specifications. Implementations may choose which specifications to 194 support, though identifier and xml-data following CVE 1.0 [CVE] need 195 to be minimally supported, as described in Section 5. In case an 196 implementation received a data it does not support, it may expand its 197 functionality by looking up the IANA table or notify the sender of 198 its inability to parse the data by using any means defined outside 199 the scope of this specification. 201 4.2. Extended Data Types 203 This extension inherits all of the data types defined in the IODEF 204 model. One data type is added: XMLDATA. 206 4.2.1. XMLDATA 208 An embedded XML data is represented by the XMLDATA data type. This 209 type is defined as the extension to the iodef:ExtensionType 210 [RFC5070], whose dtype attribute is set to "xml." 212 4.3. Extended Classes 214 The IODEF Incident element [RFC5070] is summarized below. It is 215 expressed in Unified Modeling Language (UML) syntax as used in the 216 IODEF specification. The UML representation is for illustrative 217 purposes only; elements are specified in XML as defined in Appendix 218 A. 220 +--------------------+ 221 | Incident | 222 +--------------------+ 223 | ENUM purpose |<>---------[IncidentID] 224 | STRING ext-purpose |<>--{0..1}-[AlternativeID] 225 | ENUM lang |<>--{0..1}-[RelatedActivity] 226 | ENUM restriction |<>--{0..1}-[DetectTime] 227 | |<>--{0..1}-[StartTime] 228 | |<>--{0..1}-[EndTime] 229 | |<>---------[ReportTime] 230 | |<>--{0..*}-[Description] 231 | |<>--{1..*}-[Assessment] 232 | |<>--{0..*}-[Method] 233 | | |<>--[AdditionalData] 234 | | |<>--[AttackPattern] 235 | | |<>--[Vulnerability] 236 | | |<>--[Weakness] 237 | |<>--{1..*}-[Contact] 238 | |<>--{0..*}-[EventData] 239 | | |<>--[Flow] 240 | | | |<>--[System] 241 | | | |<>--[AdditionalData] 242 | | | |<>--[Platform] 243 | | |<>--[Expectation] 244 | | |<>--[Record] 245 | | |<>--[RecordData] 246 | | |<>--[RecordItem] 247 | | |<>--[EventReport] 248 | |<>--{0..1}-[History] 249 | |<>--{0..*}-[AdditionalData] 250 | | |<>--[Verification] 251 | | |<>--[Remediation] 252 +--------------------+ 254 Figure 1: Incident class 256 This extension defines the following seven elements. 258 4.3.1. AttackPattern 260 An AttackPattern consists of an extension to the 261 Incident.Method.AdditionalData element with a dtype of "xml". The 262 extension describes attack patterns of incidents or events. 264 It is recommended that Method class SHOULD contain one or more of the 265 extension elements whenever available. 267 An AttackPattern class is structured as follows. 269 +------------------------+ 270 | AttackPattern | 271 +------------------------+ 272 | ENUM SpecID |<>--(0..*)-[ RawData ] 273 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 274 | STRING AttackPatternID |<>--(0..*)-[ Platform ] 275 +------------------------+ 277 Figure 2: AttackPattern class 279 This class has the following attributes. 281 SpecID: REQUIRED. ENUM. A specification's identifier that 282 specifies the format of a structured cybersecurity information. 283 The value should be chosen from the namespaces [XMLNames] listed 284 in the IANA table (Section 4.1) or "private". The value "private" 285 is prepared for conveying RawData based on a format that is not 286 listed in the table. This is usually used for conveying data 287 formatted according to an organization's private schema. When the 288 value "private" is used, ext-SpecID element MUST be used. 290 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 291 specifies the format of a structured cybersecurity information. 292 When this element is used, the value of SpecID element must be 293 "private." 295 AttackPatternID: OPTIONAL. STRING. An identifier of an attack 296 pattern to be reported. This attribute SHOULD be used whenever 297 such identifier is available. Both RawData and Reference elements 298 MUST NOT be used when this attribute is used, while either of them 299 MUST be used if this attribute is omitted. 301 The AttackPattern class is composed of the following aggregate 302 classes. 304 RawData: Zero or more. XMLDATA. A complete document that is 305 formatted according to the specification and its version 306 identified by the SpecID/ext-SpecID. When this element is used, 307 writers/senders MUST ensure that the namespace specified by 308 SpecID/ext-SpecID and the one used in the RawData element are 309 consistent; if not, the namespace identified by SpecID SHOULD be 310 prefered, and the inconsistency SHOULD be logged so a human can 311 correct the problem. 313 Reference: Zero or more of iodef:Reference [RFC5070]. This element 314 allows an IODEF document to include a link to a structured 315 information instead of directly embedding it into a RawData 316 element. 318 Platform: Zero or more. An identifier of software platform involved 319 in the specific attack pattern, which is elaborated in 320 Section 4.3.2. 322 4.3.2. Platform 324 A Platform identifies a software platform. It is recommended that 325 AttackPattern, Vulnerability, Weakness, and System classes contain 326 this elements whenever available. 328 A Platform element is structured as follows. 330 +----------------------+ 331 | Platform | 332 +----------------------+ 333 | ENUM SpecID |<>--(0..*)-[ RawData ] 334 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 335 | STRING PlatformID | 336 +----------------------+ 338 Figure 3: Platform class 340 This class has the following attributes. 342 SpecID: REQUIRED. ENUM. A specification's identifier that 343 specifies the format of a structured cybersecurity information. 344 The value should be chosen from the namespaces [XMLNames] listed 345 in the IANA table (Section 4.1) or "private". The value "private" 346 is prepared for conveying RawData based on a format that is not 347 listed in the table. This is usually used for conveying data 348 formatted according to an organization's private schema. When the 349 value "private" is used, ext-SpecID element MUST be used. 351 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 352 specifies the format of a structured cybersecurity information. 353 When this element is used, the value of SpecID element must be 354 "private." 356 PlatformID: OPTIONAL. STRING. An identifier of a platform to be 357 reported. This attribute SHOULD be used whenever such identifier 358 is available. Both RawData and Reference elements MUST NOT be 359 used when this attribute is used, while either of them MUST be 360 used if this attribute is omitted. 362 This class is composed of the following aggregate classes. 364 RawData: Zero or more. XMLDATA. A complete document that is 365 formatted according to the specification and its version 366 identified by the SpecID/ext-SpecID. When this element is used, 367 writers/senders MUST ensure that the namespace specified by 368 SpecID/ext-SpecID and the one used in the RawData element are 369 consistent; if not, the namespace identified by SpecID SHOULD be 370 prefered, and the inconsistency SHOULD be logged so a human can 371 correct the problem. 373 Reference: Zero or more of iodef:Reference [RFC5070]. This element 374 allows an IODEF document to include a link to a structured 375 information instead of directly embedding it into a RawData 376 element. 378 4.3.3. Vulnerability 380 A Vulnerability consists of an extension to the 381 Incident.Method.AdditionalData element with a dtype of "xml". The 382 extension describes the (candidate) vulnerabilities of incidents or 383 events. 385 It is recommended that Method class SHOULD contain one or more of the 386 extension elements whenever available. 388 A Vulnerability element is structured as follows. 390 +------------------------+ 391 | Vulnerability | 392 +------------------------+ 393 | ENUM SpecID |<>--(0..*)-[ RawData ] 394 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 395 | STRING VulnerabilityID |<>--(0..*)-[ Platform ] 396 | |<>--(0..*)-[ Scoring ] 397 +------------------------+ 399 Figure 4: Vulnerability class 401 This class has the following attributes. 403 SpecID: REQUIRED. ENUM. A specification's identifier that 404 specifies the format of a structured cybersecurity information. 405 The value should be chosen from the namespaces [XMLNames] listed 406 in the IANA table (Section 4.1) or "private". The value "private" 407 is prepared for conveying RawData based on a format that is not 408 listed in the table. This is usually used for conveying data 409 formatted according to an organization's private schema. When the 410 value "private" is used, ext-SpecID element MUST be used. 412 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 413 specifies the format of a structured cybersecurity information. 414 When this element is used, the value of SpecID element must be 415 "private." 417 VulnerabilityID: OPTIONAL. STRING. An identifier of a 418 vulnerability to be reported. This attribute SHOULD be used 419 whenever such identifier is available. Both RawData and Reference 420 elements MUST NOT be used when this attribute is used, while 421 either of them MUST be used if this attribute is omitted. 423 This class is composed of the following aggregate classes. 425 RawData: Zero or one. XMLDATA. A complete document that is 426 formatted according to the specification and its version 427 identified by the SpecID/ext-SpecID. When this element is used, 428 writers/senders MUST ensure that the namespace specified by 429 SpecID/ext-SpecID and the one used in the RawData element are 430 consistent; if not, the namespace identified by SpecID SHOULD be 431 prefered, and the inconsistency SHOULD be logged so a human can 432 correct the problem. 434 Reference: Zero or one of iodef:Reference [RFC5070]. This element 435 allows an IODEF document to include a link to a structured 436 information instead of directly embedding it into a RawData 437 element. 439 Platform: Zero or more. An identifier of software platform affected 440 by the vulnerability, which is elaborated in Section 4.3.2. 442 Scoring: Zero or more. An indicator of the severity of the 443 vulnerability, such as CVSS and CCSS scores, which is elaborated 444 in Section 4.3.4. Some of the structured information may include 445 scores within it. In this case, the Scoring element SHOULD NOT be 446 used since the RawData element contains the scores. If a reader/ 447 receiver detects scores in both RawData and Scoring elements and 448 their inconsistency, it SHOULD prefer the scores derived from the 449 RawData element, and SHOULD log the inconsistency so a human can 450 correct the problem. 452 4.3.4. Scoring 454 A Scoring class describes the scores of the severity in terms of 455 security. It is recommended that Vulnerability and Weakness classes 456 contain the elements whenever available. 458 A Scoring class is structured as follows. 460 +----------------------+ 461 | Scoring | 462 +----------------------+ 463 | ENUM SpecID |<>---------[ ScoreSet ] 464 | STRING ext-SpecID | 465 +----------------------+ 467 Figure 5: Scoring class 469 This class has two attributes. 471 SpecID: REQUIRED. ENUM. A specification's identifier that 472 specifies the format of a structured cybersecurity information. 473 The value should be chosen from the namespaces [XMLNames] listed 474 in the IANA table (Section 4.1) or "private". The value "private" 475 is prepared for conveying RawData based on a format that is not 476 listed in the table. This is usually used for conveying data 477 formatted according to an organization's private schema. When the 478 value "private" is used, ext-SpecID element MUST be used. 480 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 481 specifies the format of a structured cybersecurity information. 482 When this element is used, the value of SpecID element must be 483 "private." 485 This class is composed of an aggregate class. 487 ScoreSet: One. XMLDATA. A complete document that is formatted 488 according to the specification and its version identified by the 489 SpecID/ext-SpecID. This element includes a set of score 490 information. When this element is used, writers/senders MUST 491 ensure that the namespace specified by SpecID/ext-SpecID and the 492 one used in the RawData element are consistent; if not, the 493 namespace identified by SpecID SHOULD be prefered, and the 494 inconsistency SHOULD be logged so a human can correct the problem. 496 Writers/senders MUST ensure the specification name and version 497 identified by the SpecID are consistent with the contents of the 498 Score; if a reader/receiver detects an inconsistency, it SHOULD 499 prefer the specification name and version derived from the content, 500 and SHOULD log the inconsistency so a human can correct the problem. 502 4.3.5. Weakness 504 A Weakness consists of an extension to the 505 Incident.Method.AdditionalData element with a dtype of "xml". The 506 extension describes the weakness types of incidents or events. 508 It is recommended that Method class SHOULD contain one or more of the 509 extension elements whenever available. 511 A Weakness element is structured as follows. 513 +----------------------+ 514 | Weakness | 515 +----------------------+ 516 | ENUM SpecID |<>--(0..*)-[ RawData ] 517 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 518 | STRING WeaknessID |<>--(0..*)-[ Platform ] 519 | |<>--(0..*)-[ Scoring ] 520 +----------------------+ 522 Figure 6: Weakness class 524 This class has the following attributes. 526 SpecID: REQUIRED. ENUM. A specification's identifier that 527 specifies the format of a structured cybersecurity information. 528 The value should be chosen from the namespaces [XMLNames] listed 529 in the IANA table (Section 4.1) or "private". The value "private" 530 is prepared for conveying RawData based on a format that is not 531 listed in the table. This is usually used for conveying data 532 formatted according to an organization's private schema. When the 533 value "private" is used, ext-SpecID element MUST be used. 535 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 536 specifies the format of a structured cybersecurity information. 537 When this element is used, the value of SpecID element must be 538 "private." 540 WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be 541 reported. This attribute SHOULD be used whenever such identifier 542 is available/ Both RawData and Reference elements MUST NOT be used 543 when this attribute is used, while either of them MUST be used if 544 this attribute is omitted. 546 This class is composed of the following aggregate classes. 548 RawData: Zero or more. XMLDATA. A complete document that is 549 formatted according to the specification and its version 550 identified by the SpecID/ext-SpecID. When this element is used, 551 writers/senders MUST ensure that the namespace specified by 552 SpecID/ext-SpecID and the one used in the RawData element are 553 consistent; if not, the namespace identified by SpecID SHOULD be 554 prefered, and the inconsistency SHOULD be logged so a human can 555 correct the problem. 557 Reference: Zero or one of iodef:Reference [RFC5070]. This element 558 allows an IODEF document to include a link to a structured 559 information instead of directly embedding it into a RawData 560 element. 562 Platform: Zero or more. An identifier of software platform affected 563 by the weakness, which is elaborated in Section 4.3.2. 565 Scoring: Zero or more. An indicator of the severity of the 566 weakness, such as CWSS score, which is elaborated in 567 Section 4.3.4. 569 4.3.6. EventReport 571 An EventReport consists of an extension to the 572 Incident.EventData.Record.RecordData.RecordItem element with a dtype 573 of "xml". The extension embeds structured event reports. 575 It is recommended that RecordItem class SHOULD contain one or more of 576 the extension elements whenever available. 578 An EventReport element is structured as follows. 580 +----------------------+ 581 | EventReport | 582 +----------------------+ 583 | ENUM SpecID |<>--(0..*)-[ RawData ] 584 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 585 | STRING EventID | 586 +----------------------+ 588 Figure 7: EventReport class 590 This class has the following attributes. 592 SpecID: REQUIRED. ENUM. A specification's identifier that 593 specifies the format of a structured cybersecurity information. 594 The value should be chosen from the namespaces [XMLNames] listed 595 in the IANA table (Section 4.1) or "private". The value "private" 596 is prepared for conveying RawData based on a format that is not 597 listed in the table. This is usually used for conveying data 598 formatted according to an organization's private schema. When the 599 value "private" is used, ext-SpecID element MUST be used. 601 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 602 specifies the format of a structured cybersecurity information. 603 When this element is used, the value of SpecID element must be 604 "private." 606 EventID: OPTIONAL. STRING. An identifier of an event to be 607 reported. This attribute SHOULD be used whenever such identifier 608 is available. Both RawData and Reference elements MUST NOT be 609 used when this attribute is used, while either of them MUST be 610 used if this attribute is omitted. 612 This class is composed of three aggregate classes. 614 RawData: Zero or one. XMLDATA. A complete document that is 615 formatted according to the specification and its version 616 identified by the SpecID/ext-SpecID. When this element is used, 617 writers/senders MUST ensure that the namespace specified by 618 SpecID/ext-SpecID and the one used in the RawData element are 619 consistent; if not, the namespace identified by SpecID SHOULD be 620 prefered, and the inconsistency SHOULD be logged so a human can 621 correct the problem. 623 Reference: Zero or one of iodef:Reference [RFC5070]. This element 624 allows an IODEF document to include a link to a structured 625 information instead of directly embedding it into a RawData 626 element. 628 This class MUST contain at least one of RawData or Reference 629 elements. Writers/senders MUST ensure the specification name and 630 version identified by the SpecID are consistent with the contents of 631 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 632 prefer the specification name and version derived from the content, 633 and SHOULD log the inconsistency so a human can correct the problem. 635 4.3.7. Verifcation 637 A Verification consists of an extension to the 638 Incident.AdditionalData element with a dtype of "xml". The extension 639 elements describes incident on vefifying incidents. 641 A Verification class is structured as follows. 643 +----------------------+ 644 | Verification | 645 +----------------------+ 646 | ENUM SpecID |<>--(0..*)-[ RawData ] 647 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 648 | STRING VerificationID| 649 +----------------------+ 651 Figure 8: Verification class 653 This class has the following attributes. 655 SpecID: REQUIRED. ENUM. A specification's identifier that 656 specifies the format of a structured cybersecurity information. 657 The value should be chosen from the namespaces [XMLNames] listed 658 in the IANA table (Section 4.1) or "private". The value "private" 659 is prepared for conveying RawData based on a format that is not 660 listed in the table. This is usually used for conveying data 661 formatted according to an organization's private schema. When the 662 value "private" is used, ext-SpecID element MUST be used. 664 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 665 specifies the format of a structured cybersecurity information. 666 When this element is used, the value of SpecID element must be 667 "private." 669 VerificationID: OPTIONAL. STRING. An identifier of an check item 670 to be reported. This attribute SHOULD be used whenever such 671 identifier is available. Both RawData and Reference elements MUST 672 NOT be used when this attribute is used, while either of them MUST 673 be used if this attribute is omitted. 675 This class is composed of two aggregate classes. 677 RawData: Zero or one. XMLDATA. A complete document that is 678 formatted according to the specification and its version 679 identified by the SpecID/ext-SpecID. When this element is used, 680 writers/senders MUST ensure that the namespace specified by 681 SpecID/ext-SpecID and the one used in the RawData element are 682 consistent; if not, the namespace identified by SpecID SHOULD be 683 prefered, and the inconsistency SHOULD be logged so a human can 684 correct the problem. 686 Reference: Zero or one of iodef:Reference [RFC5070]. This element 687 allows an IODEF document to include a link to a structured 688 information instead of directly embedding it into a RawData 689 element. 691 This class MUST contain at least either of RawData and Reference 692 elements. Writers/senders MUST ensure the specification name and 693 version identified by the SpecID are consistent with the contents of 694 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 695 prefer the specification name and version derived from the content, 696 and SHOULD log the inconsistency so a human can correct the problem. 698 4.3.8. Remediation 700 A Remediation consists of an extension to the Incident.AdditionalData 701 element with a dtype of "xml". The extension elements describes 702 incident remediation information including instructions. 704 It is recommended that Incident class SHOULD contain one or more of 705 this extension elements whenever available. 707 A Remediation class is structured as follows. 709 +----------------------+ 710 | Remediation | 711 +----------------------+ 712 | ENUM SpecID |<>--(0..*)-[ RawData ] 713 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 714 | String RemediationID | 715 +----------------------+ 717 Figure 9: Remediation class 719 This class has the following attributes. 721 SpecID: REQUIRED. ENUM. A specification's identifier that 722 specifies the format of a structured cybersecurity information. 723 The value should be chosen from the namespaces [XMLNames] listed 724 in the IANA table (Section 4.1) or "private". The value "private" 725 is prepared for conveying RawData based on a format that is not 726 listed in the table. This is usually used for conveying data 727 formatted according to an organization's private schema. When the 728 value "private" is used, ext-SpecID element MUST be used. 730 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 731 specifies the format of a structured cybersecurity information. 732 When this element is used, the value of SpecID element must be 733 "private." 735 RemediationID: OPTIONAL. STRING. An identifier of a remediation 736 information to be reported. This attribute SHOULD be used 737 whenever such identifier is available. Both RawData and Reference 738 elements MUST NOT be used when this attribute is used, while 739 either of them MUST be used if this attribute is omitted. 741 This class is composed of two aggregate classes. 743 RawData: Zero or one. XMLDATA. A complete document that is 744 formatted according to the specification and its version 745 identified by the SpecID/ext-SpecID. When this element is used, 746 writers/senders MUST ensure that the namespace specified by 747 SpecID/ext-SpecID and the one used in the RawData element are 748 consistent; if not, the namespace identified by SpecID SHOULD be 749 prefered, and the inconsistency SHOULD be logged so a human can 750 correct the problem. 752 Reference: Zero or one of iodef:Reference [RFC5070]. This element 753 allows an IODEF document to include a link to a structured 754 information instead of directly embedding it into a RawData 755 element. 757 This class MUST contain at least either of RawData and Reference 758 elements. Writers/senders MUST ensure the specification name and 759 version identified by the SpecID are consistent with the contents of 760 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 761 prefer the specification name and version derived from the content, 762 and SHOULD log the inconsistency so a human can correct the problem. 764 5. Mandatory to Implement features 766 The implementation of this draft MUST be capable of sending and 767 receiving the XML described in Section 11 without error. 769 The receiver MUST be capable of validating received XML documents 770 that are embedeed inside that against their schemata. Note that the 771 receiver can look up the namespace in the IANA table to understand 772 what specifications the embedded XML documents follows. 774 6. Security Considerations 776 This document specifies a format for encoding a particular class of 777 security incidents appropriate for exchange across organizations. As 778 merely a data representation, it does not directly introduce security 779 issues. However, it is guaranteed that parties exchanging instances 780 of this specification will have certain concerns. For this reason, 781 the underlying message format and transport protocol used MUST ensure 782 the appropriate degree of confidentiality, integrity, and 783 authenticity for the specific environment. 785 Organizations that exchange data using this document are URGED to 786 develop operating procedures that document the following areas of 787 concern. 789 6.1. Transport-Specific Concerns 791 The underlying messaging format and protocol used to exchange 792 instances of the IODEF MUST provide appropriate guarantees of 793 confidentiality, integrity, and authenticity. The use of a 794 standardized security protocol is encouraged. The Real-time Inter- 795 network Defense (RID) protocol [RFC6045] and its associated transport 796 binding [RFC6046] provide such security. 798 The critical security concerns are that these structured information 799 may be falsified or they may become corrupt during transit. In areas 800 where transmission security or secrecy is questionable, the 801 application of a digital signature and/or message encryption on each 802 report will counteract both of these concerns. We expect that each 803 exchanging organization will determine the need, and mechanism, for 804 transport protection. 806 7. IANA Considerations 808 This document uses URNs to describe XML namespaces and XML 809 schemata[XMLschemaPart1][XMLschemaPart2] conforming to a registry 810 mechanism described in [RFC3688]. 812 Registration request for the IODEF structured cybersecurity 813 information extension namespace: 815 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 817 Registrant Contact: Refer here to the authors' addresses section 818 of the document. 820 XML: None 822 Registration request for the IODEF structured cybersecurity 823 information extension XML schema: 825 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 827 Registrant Contact: Refer here to the authors' addresses section 828 of the document. 830 XML: Refer here to the XML Schema in the appendix of the document. 832 This memo creates the following registry for IANA to manage: 834 Name of the registry: "IODEF Structured Cyber Security Information 835 Specifications" 837 Namespace details: A registry entry for a Structured Cyber 838 Security Information Specification (SCI specification) consists 839 of: 841 Namespace: A URI [RFC3986] that is the XML namespace name used 842 by the registered SCI specification. 844 Specification Name: A string containing the spelled-out name of 845 the SCI specification in human-readable form. 847 Reference URI: A list of one or more of the URIs [RFC3986] from 848 which the registered specification can be obtained. The 849 registered specification MUST be readily and publicly available 850 from that URI. 852 Applicable Classes: A list of one or more of the Extended 853 Classes specified in Section 4.3 of this document. The 854 registered SCI specification MUST only be used with the 855 Extended Classes in the registry entry. 857 Information that must be provided to assign a new value: The above 858 list of information. 860 Fields to record in the registry: Namespace/Specification Name/ 861 Version/Applicable Classes. 863 Initial registry contents: none 865 Allocation Policy: Expert Review [RFC5226] and Specification 866 Required [RFC5226]. 868 The Designated Expert is expected to consult with the mile (Managed 869 Incident Lightweight Exchange) working group or its successor if any 870 such WG exists (e.g., via email to the working group's mailing list). 871 The Designated Expert is expected to retrieve the SCI specification 872 from the provided URI in order to check the public availability of 873 the specification and verify the correctness of the URI. An 874 important responsibility of the Designated Expert is to ensure that 875 the registered Applicable Classes are appropriate for the registered 876 SCI specification. 878 8. Acknowledgment 880 We would like to acknowledge Mr. David Black from EMC, who kindly 881 provided generous support, especially on the IANA registry issues. 882 We also would like to thank Jon Baker from MITRE, Paul Cichonski from 883 NIST, Robert Martin from MITRE, Kathleen Moriarty from EMC, Lagadec 884 Philippe from NATO, Shuhei Yamaguchi from NICT, Anthony Rutkowski 885 from Yaana Technology, Brian Trammel from CERT/NetSA, and David 886 Waltermire from NIST for their sincere discussion and feedback on 887 this document. 889 9. Appendix I: XML Schema Definition for Extension 891 The XML Schema describing the elements defined in the Extension 892 Definition section is given here. Each of the examples in Section 11 893 should be verified to validate against this schema by automated 894 tools. 896 898 904 907 911 915 916 917 918 919 921 922 923 924 925 926 927 928 929 931 935 936 937 938 940 941 942 944 945 947 951 952 953 954 955 957 959 960 962 963 964 966 968 969 971 975 976 977 978 979 981 983 984 986 988 989 990 992 994 995 997 1001 1002 1003 1004 1005 1007 1009 1010 1012 1014 1015 1016 1018 1020 1021 1023 1027 1028 1029 1030 1031 1033 1035 1036 1037 1038 1040 1042 1043 1045 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1060 1062 1063 1065 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1080 1082 1083 1085 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1100 1102 1103 1105 1107 10. Appendix II: Candidate Specifications for the IANA Table 1109 This draft defined the structure of the IANA table in Section 4.1. 1110 Though the management of the table is up to IANA, this appendix 1111 provides candidate entries. Note that OVAL and CVE are registered 1112 trademarks, and CAPEC, CCE, CEE, CPE, CWE, CWSS, MAEC, and OCIL are 1113 trademarks, of The MITRE Corporation. 1115 1. CAPEC 1.6 1117 Namespace: http://capec.mitre.org/observables 1118 Specification Name: Common Attack Pattern Enumeration and Classification 1119 Version: 1.6 1120 Reference URI: http://capec.mitre.org/ 1121 Applicable Classes: AttackPattern 1123 2. CCE 5.0 1125 Namespace: http://cce.mitre.org 1126 Specification Name: Common Configuration Enumeration 1127 Version: 5.0 1128 Reference URI: http://cce.mitre.org/ 1129 Applicable Classes: Verification 1131 3. CCSS 1.0 1133 Namespace: N/A 1134 Specification Name: Common Configuration Scoring System 1135 Version: 1.0 1136 Reference URI: http://csrc.nist.gov/publications/PubsNISTIRs.html 1137 #NIST-IR-7502 1138 Applicable Classes: Scoring 1140 4. CEE 1.0 alpha 1141 Namespace: http://cee.mitre.org 1142 Specification Name: Common Event Expression 1143 Version: 1.0 alpha 1144 Reference URI: http://cee.mitre.org/ 1145 Applicable Classes: EventReport 1147 5. CPE 2.3 Language 1149 Namespace: http://cpe.mitre.org/language/2.0 1150 Specification Name: Common Platform Enumeration Reference 1151 Version: 2.3 1152 Reference URI: http://scap.nist.gov/specifications/cpe/, 1153 http://csrc.nist.gov/publications/PubsNISTIRs.html 1154 #NIST-IR-7695 1155 Applicable Classes: Platform 1157 6. CPE 2.3 Dictionary 1159 Namespace: http://cpe.mitre.org/dictionary/2.0 1160 Specification Name: Common Platform Enumeration Dictionary 1161 Version: 2.3 1162 Reference URI: http://scap.nist.gov/specifications/cpe/, 1163 http://csrc.nist.gov/publications/PubsNISTIRs.html 1164 #NIST-IR-7697 1165 Applicable Classes: Platform 1167 7. CVE 1.0 1169 Namespace: http://cve.mitre.org/cve/downloads/1.0 1170 Specification Name: Common Vulnerability and Exposures 1171 Version: 1.0 1172 Reference URI: http://cve.mitre.org/ 1173 Applicable Classes: Vulnerability 1175 8. CVRF 1.0 1177 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 1178 Specification Name: Common Vulnerability Reporting Format 1179 Version: 1.0 1180 Reference URI: http://www.icasi.org/cvrf 1181 Applicable Classes: Vulnerability 1183 9. CVSS 2.0 1185 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 1186 Specification Name: Common Vulnerability Scoring System 1187 Version: 2 1188 Reference URI: http://www.first.org/cvss 1189 Applicable Classes: Scoring 1191 10. CWE 5.0 1193 Namespace: N/A 1194 Specification Name: Common Weakness Enumeration 1195 Version: 5.1 1196 Reference URI: http://cwe.mitre.org/ 1197 Applicable Classes: Weakness 1199 11. CWSS 0.8 1201 Namespace: N/A 1202 Specification Name: Common Weakness Scoring System 1203 Version: 0.8 1204 Reference URI: http://cwe.mitre.org/cwss/ 1205 Applicable Classes: Scoring 1207 12. MAEC 2.0 1209 Namespace: http://maec.mitre.org/XMLSchema/maec-core-2 1210 Specification Name: Malware Attribute Enumeration and Characterization 1211 Version: 2.0 1212 Reference URI: http://maec.mitre.org/ 1213 Applicable Classes: EventReport, AttackPattern 1215 13. OCIL 2.0 1217 Namespace: http://scap.nist.gov/schema/ocil/2.0 1218 Specification Name: Open Checklist Interactive Language 1219 Version: 2.0 1220 Reference URI: http://scap.nist.gov/specifications/ocil/, 1221 http://csrc.nist.gov/publications/PubsNISTIRs.html 1222 #NIST-IR-7692 1223 Applicable Classes: Verification 1225 14. OVAL 5.10.1 Definitions 1227 Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 1228 Specification Name: Open Vulnerability and Assessment Language 1229 Version: 5.10.1 1230 Reference URI: http://oval.mitre.org/ 1231 Applicable Classes: Verification 1233 15. OVAL 5.10.1 Results 1234 Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 1235 Specification Name: Open Vulnerability and Assessment Language 1236 Version: 5.10.1 1237 Reference URI: http://oval.mitre.org/ 1238 Applicable Classes: Verification 1240 16. OVAL 5.10.1 Common 1242 Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 1243 Specification Name: Open Vulnerability and Assessment Language 1244 Version: 5.10.1 1245 Reference URI: http://oval.mitre.org/ 1246 Applicable Classes: Verification 1248 17. XCCDF 1.2 1250 Namespace: http://checklists.nist.gov/xccdf/1.2 1251 Specification Name: Extensible Configuration Checklist Description Format 1252 Version: 1.2 1253 Reference URI: http://scap.nist.gov/specifications/xccdf/, 1254 http://csrc.nist.gov/publications/PubsNISTIRs.html 1255 #NIST-IR-7275-r4 1256 Applicable Classes: Verification 1258 11. Appendix III: An XML Example 1260 This section provides an example of an incident encoded in the IODEF. 1261 This do not necessarily represent the only way to encode a particular 1262 incident. This example reports an attack to a CSIRT and is extended 1263 from the example described in [RFC5070]. It uses identifiers whose 1264 dictionary follows CVE 1.0 schema, and it aembeds XML following CEE 1265 0.6. 1267 1268 1273 1274 189493 1275 2001-09-13T23:19:24+00:00 1276 Incident report in company xx 1277 1278 1279 1280 1281 An identifier of a vulnerability is embedded 1282 1283 1286 1287 1288 1289 Example.com CSIRT 1290 example-com 1291 contact@csirt.example.com 1292 1293 1294 1295 1296 1297
192.0.2.200
1298 57 1299 1300 1301 1302 1303
192.0.2.16/28
1304 1305 1306 80 1307 1308 1309 1311 1312 1313 1314 1315 1316 1317 1318 1319 2001-09-13T18:11:21+02:00 1320 a Web-server event record 1321 1322 1323 1324 1326 1327 system.example.com 1328 auth 1329 1330 application 1331 123 1332 10 1333 login 1334 app 1335 account 1336 web 1337 success 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 2001-09-14T08:19:01+00:00 1350 Notification sent to 1351 constituency-contact@192.0.2.200 1352 1353 1354 1355 1357 12. References 1359 12.1. Normative References 1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1362 Requirement Levels", BCP 14, RFC 2119, March 1997. 1364 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1365 Resource Identifier (URI): Generic Syntax", STD 66, 1366 RFC 3986, January 2005. 1368 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1369 Object Description Exchange Format", RFC 5070, 1370 December 2007. 1372 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1373 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1374 May 2008. 1376 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1377 RFC 6045, November 2010. 1379 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1380 Inter-network Defense (RID) Messages", RFC 6046, 1381 November 2010. 1383 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1384 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1385 Edition)", W3C Recommendation, November 2008. 1387 [XMLschemaPart1] 1388 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1389 "XML Schema Part 1: Structures Second Edition", 1390 W3C Recommendation, October 2004. 1392 [XMLschemaPart2] 1393 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1394 Second Edition", W3C Recommendation, October 2004. 1396 [XMLNames] 1397 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1398 Thomson, ""Namespaces in XML (Third Edition)", 1399 W3C Recommendation, December 2009. 1401 12.2. Informative References 1403 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1404 Internet: Timestamps", RFC 3339, July 2002. 1406 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1407 Text on Security Considerations", BCP 72, RFC 3552, 1408 July 2003. 1410 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1411 January 2004. 1413 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1414 October 2008. 1416 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1417 Uniform Resource Identifiers (URI) Dynamic Delegation 1418 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1419 March 2011. 1421 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1422 and Classification (CAPEC)". 1424 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1425 (CCE)". 1427 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1428 Scoring System (CCSS)", NIST Interagency Report 7502, 1429 December 2010. 1431 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1433 [CPE] National Institute of Standards and Technology, "Common 1434 Platform Enumeration", June 2011. 1436 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1437 (CVE)". 1439 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1441 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1442 Common Vulnerability Scoring System (CVSS) and Its 1443 Applicability to Federal Agency Systems". 1445 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1446 (CWE)". 1448 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1449 (CWSS)". 1451 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1452 Open Checklist Interactive Language (OCIL) Version 2.0", 1453 April 2011. 1455 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1456 Language (OVAL)". 1458 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 1459 Halbardier, "The Technical Specification for the Security 1460 Content Automation Protocol (SCAP): SCAP Version 1.2", 1461 NIST Special Publication 800-126 Revision 2, 1462 September 2011. 1464 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1465 and Neal Ziring, "Specification for the Extensible 1466 Configuration Checklist Description Format (XCCDF) version 1467 1.2 (DRAFT)", July 2011. 1469 Authors' Addresses 1471 Takeshi Takahashi 1472 National Institute of Information and Communications Technology 1473 4-2-1 Nukui-Kitamachi Koganei 1474 184-8795 Tokyo 1475 Japan 1477 Phone: +80 423 27 5862 1478 Email: takeshi_takahashi@nict.go.jp 1480 Kent Landfield 1481 McAfee, Inc 1482 5000 Headquarters Drive 1483 Plano, TX 75024 1484 USA 1486 Email: Kent_Landfield@McAfee.com 1488 Thomas Millar 1489 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1490 245 Murray Lane SW, Building 410, MS #732 1491 Washington, DC 20598 1492 USA 1494 Phone: +1 888 282 0870 1495 Email: thomas.millar@us-cert.gov 1497 Youki Kadobayashi 1498 Nara Institute of Science and Technology 1499 8916-5 Takayama, Ikoma 1500 630-0192 Nara 1501 Japan 1503 Email: youki-k@is.aist-nara.ac.jp