idnits 2.17.1 draft-ietf-mile-sci-04.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 9 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 (May 10, 2012) is 4366 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 1491, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1494, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1501, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1504, but no explicit reference was found in the text == Unused Reference: 'CCE' is defined on line 1512, but no explicit reference was found in the text == Unused Reference: 'CCSS' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'SCAP' is defined on line 1543, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CVE' ** 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 (~~), 8 warnings (==), 6 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: November 11, 2012 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 May 10, 2012 12 IODEF-extension to support structured cybersecurity information 13 draft-ietf-mile-sci-04.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. It 20 provides the capability of embedding structured information, such as 21 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 November 11, 2012. 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. List of Supported Structured Cybersecurity Information 62 Specifictions . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Extended Data Types . . . . . . . . . . . . . . . . . . . 5 64 4.2.1. XMLDATA . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 5 66 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 6 67 4.3.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 9 69 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 15 73 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 16 74 5. Mandatory to Implement features . . . . . . . . . . . . . . . 17 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 18 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9. Appendix I: XML Schema Definition for Extension . . . . . . . 20 80 10. Appendix II: XML Examples . . . . . . . . . . . . . . . . . . 25 81 11. Appendix III: Candidate Specifications listed to the IANA 82 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 88 1. Introduction 90 Cyber attacks are getting more sophisticated, and their number is 91 increasing day by day. To cope with such situation, incident 92 information needs to be reported, exchanged, and shared among 93 organizations. IODEF is one of the tools enabling such exchange, and 94 is already in use. 96 To efficiently run cybersecurity operations, these exchanged 97 information needs to be machine-readable. IODEF provides a 98 structured means to describe the information, but it needs to embed 99 various non-structured such information in order to convey detailed 100 information. Further structure within IODEF increases IODEF 101 documents' machine-readability and thus facilitates streamlining 102 cybersecurity operations. 104 On the other hand, there exist various other activities facilitating 105 detailed and structured description of cybersecurity information, 106 major of which includes CAPEC [CAPEC], CEE [CEE], CPE [CPE], CVE 107 [CVE], CVRF [CVRF], CVSS [CVSS], CWE [CWE], CWSS [CWSS], OCIL [OCIL], 108 OVAL [OVAL], and XCCDF [XCCDF]. Since such structured description 109 facilitates cybersecurity operations, it would be beneficial to embed 110 and convey these information inside IODEF document. 112 To enable that, this document extends the IODEF to embed and convey 113 various structured cybersecurity information, with which 114 cybersecurity operations can be facilitated. Since IODEF defines a 115 flexible and extensible format and supports a granular level of 116 specificity, this document defines an extension to IODEF instead of 117 defining a new report format. For clarity, and to eliminate 118 duplication, only the additional structures necessary for describing 119 the exchange of such structured information are provided. 121 2. Terminology 123 The terminology used in this document follows the one defined in RFC 124 5070 [RFC5070]. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. Applicability 132 To maintain cybersecurity, organization needs to exchange 133 cybersecurity information, which includes the following information: 135 attack pattern, platform information, vulnerability and weakness, 136 countermeasure instruction, computer event log, and the severity. 138 IODEF provides a scheme to exchange such information among interested 139 parties. However, the detailed common format to describe such 140 information is not defined in the IODEF base document. 142 On the other hand, structured formats for that already exist to 143 describe those information and to facilitate such exchange. Major of 144 them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OCIL, OVAL, and 145 XCCDF. By embedding them into the IODEF document, the document can 146 convey more detailed contents to the receivers, and the document can 147 be easily reused. Note that interactive communication is needed in 148 some cases, and some of these structured information, e.g., OCIL 149 information, solicits reply from recipients. These reply could be 150 also embedded inside the IODEF document. 152 These structured cybersecurity information facilitates cybersecurity 153 operation at the receiver side. Since the information is machine- 154 readable, the data can be processed by computers. That expedites the 155 automation of cybersecurity operations 157 For instance, an organization wishing to report a security incident 158 wants to describe what vulnerability was exploited. Then the sender 159 can simply use IODEF, where an CAPEC record is embedded instead of 160 describing everything in free format text. Receiver can also 161 identify the needed details of the attack pattern by looking up some 162 of the xml [XML1.0] tags defined by CAPEC. Receiver can accumulate 163 the attack pattern information (CAPEC record) in its database and 164 could distribute it to the interested parties if needed, without 165 needing human interventions. 167 Antoer example is that, when an administrator wishes to check the 168 configuration of host computers in his organization, he may send a 169 query to host computers, which may automatically generate XML-based 170 software configuration information upon receiving thequery by running 171 a software and may embed that to an IODEF document, which is then 172 sent back to the administrator. 174 4. Extension Definition 176 This draft extends IODEF to embed structured cybersecurity 177 information by introducing new classes, with which these information 178 can be embedded inside IODEF document as element contents of 179 AdditionalData and RecordItem classes. 181 4.1. List of Supported Structured Cybersecurity Information 182 Specifictions 184 This extension embeds structured cybersecurity information defined by 185 the other specifications. The list of supported specifications is 186 managed by IANA, and this draft defines the needed field for the 187 list's entry. 189 Each entry has namespace [XMLNames], specification name, version, 190 reference URI and applicable classes for each specification. 191 Arbitrary URIs that may help readers to understand the specification 192 could be embedded inside the Reference URI field, but it is 193 recommended that standard/informational URI describing the 194 specification is prepared and is embedded here. 196 The table is to be managed by IANA using the Expert Review [RFC5226] 197 and Specification Required [RFC5226] allocation policies as further 198 specified in Section 7. 200 The SpecID attributes of extended classes (Section 4.3) must allow 201 the values of the specifications' namespace fields, but otherwise, 202 implementations are not required to support all the above 203 specifications. Implementations may choose which specifications to 204 support, though identifier and xml-data following CVE 1.0 [CVE] need 205 to be minimally supported, as described in Section 5. In case an 206 implementation received a data it does not support, it may expand its 207 functionality by looking up the IANA table or notify the sender of 208 its inability to parse the data by using any means defined outside 209 the scope of this specification. 211 4.2. Extended Data Types 213 This extension inherits all of the data types defined in the IODEF 214 model. One data type is added: XMLDATA. 216 4.2.1. XMLDATA 218 An embedded XML data is represented by the XMLDATA data type. This 219 type is defined as the extension to the iodef:ExtensionType 220 [RFC5070], whose dtype attribute is set to "xml." 222 4.3. Extended Classes 224 The IODEF Incident element [RFC5070] is summarized below. It is 225 expressed in Unified Modeling Language (UML) syntax as used in the 226 IODEF specification. The UML representation is for illustrative 227 purposes only; elements are specified in XML as defined in Appendix 228 A. 230 +--------------------+ 231 | Incident | 232 +--------------------+ 233 | ENUM purpose |<>---------[IncidentID] 234 | STRING ext-purpose |<>--{0..1}-[AlternativeID] 235 | ENUM lang |<>--{0..1}-[RelatedActivity] 236 | ENUM restriction |<>--{0..1}-[DetectTime] 237 | |<>--{0..1}-[StartTime] 238 | |<>--{0..1}-[EndTime] 239 | |<>---------[ReportTime] 240 | |<>--{0..*}-[Description] 241 | |<>--{1..*}-[Assessment] 242 | |<>--{0..*}-[Method] 243 | | |<>--[AdditionalData] 244 | | |<>--[AttackPattern] 245 | | |<>--[Vulnerability] 246 | | |<>--[Weakness] 247 | |<>--{1..*}-[Contact] 248 | |<>--{0..*}-[EventData] 249 | | |<>--[Flow] 250 | | | |<>--[System] 251 | | | |<>--[AdditionalData] 252 | | | |<>--[Platform] 253 | | |<>--[Expectation] 254 | | |<>--[Record] 255 | | |<>--[RecordData] 256 | | |<>--[RecordItem] 257 | | |<>--[EventReport] 258 | |<>--{0..1}-[History] 259 | |<>--{0..*}-[AdditionalData] 260 | | |<>--[Verification] 261 | | |<>--[Remediation] 262 +--------------------+ 264 Figure 1: Incident class 266 This extension defines the following seven elements. 268 4.3.1. AttackPattern 270 An AttackPattern consists of an extension to the 271 Incident.Method.AdditionalData element with a dtype of "xml". The 272 extension describes attack patterns of incidents or events. 274 It is recommended that Method class SHOULD contain one or more of the 275 extension elements whenever available. 277 An AttackPattern class is structured as follows. 279 +------------------------+ 280 | AttackPattern | 281 +------------------------+ 282 | ENUM SpecID |<>--(0..*)-[ RawData ] 283 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 284 | STRING AttackPatternID |<>--(0..*)-[ Platform ] 285 +------------------------+ 287 Figure 2: AttackPattern class 289 This class has the following attributes. 291 SpecID: REQUIRED. ENUM. A specification's identifier that 292 specifies the format of a structured cybersecurity information. 293 The value should be chosen from the namespaces [XMLNames] listed 294 in the IANA table (Section 4.1) or "private". The value "private" 295 is prepared for conveying RawData based on a format that is not 296 listed in the table. This is usually used for conveying data 297 formatted according to an organization's private schema. When the 298 value "private" is used, ext-SpecID element MUST be used. 300 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 301 specifies the format of a structured cybersecurity information. 302 When this element is used, the value of SpecID element must be 303 "private." 305 AttackPatternID: OPTIONAL. STRING. An identifier of an attack 306 pattern to be reported. This attribute SHOULD be used whenever 307 such identifier is available. Both RawData and Reference elements 308 MUST NOT be used when this attribute is used, while either of them 309 MUST be used if this attribute is omitted. 311 The AttackPattern class is composed of the following aggregate 312 classes. 314 RawData: Zero or more. XMLDATA. A complete document that is 315 formatted according to the specification and its version 316 identified by the SpecID/ext-SpecID. When this element is used, 317 writers/senders MUST ensure that the namespace specified by 318 SpecID/ext-SpecID and the one used in the RawData element are 319 consistent; if not, the namespace identified by SpecID SHOULD be 320 prefered, and the inconsistency SHOULD be logged so a human can 321 correct the problem. 323 Reference: Zero or more of iodef:Reference [RFC5070]. This element 324 allows an IODEF document to include a link to a structured 325 information instead of directly embedding it into a RawData 326 element. 328 Platform: Zero or more. An identifier of software platform involved 329 in the specific attack pattern, which is elaborated in 330 Section 4.3.2. 332 4.3.2. Platform 334 A Platform identifies a software platform. It is recommended that 335 AttackPattern, Vulnerability, Weakness, and System classes contain 336 this elements whenever available. 338 A Platform element is structured as follows. 340 +----------------------+ 341 | Platform | 342 +----------------------+ 343 | ENUM SpecID |<>--(0..*)-[ RawData ] 344 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 345 | STRING PlatformID | 346 +----------------------+ 348 Figure 3: Platform class 350 This class has the following attributes. 352 SpecID: REQUIRED. ENUM. A specification's identifier that 353 specifies the format of a structured cybersecurity information. 354 The value should be chosen from the namespaces [XMLNames] listed 355 in the IANA table (Section 4.1) or "private". The value "private" 356 is prepared for conveying RawData based on a format that is not 357 listed in the table. This is usually used for conveying data 358 formatted according to an organization's private schema. When the 359 value "private" is used, ext-SpecID element MUST be used. 361 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 362 specifies the format of a structured cybersecurity information. 363 When this element is used, the value of SpecID element must be 364 "private." 366 PlatformID: OPTIONAL. STRING. An identifier of a platform to be 367 reported. This attribute SHOULD be used whenever such identifier 368 is available. Both RawData and Reference elements MUST NOT be 369 used when this attribute is used, while either of them MUST be 370 used if this attribute is omitted. 372 This class is composed of the following aggregate classes. 374 RawData: Zero or more. XMLDATA. A complete document that is 375 formatted according to the specification and its version 376 identified by the SpecID/ext-SpecID. When this element is used, 377 writers/senders MUST ensure that the namespace specified by 378 SpecID/ext-SpecID and the one used in the RawData element are 379 consistent; if not, the namespace identified by SpecID SHOULD be 380 prefered, and the inconsistency SHOULD be logged so a human can 381 correct the problem. 383 Reference: Zero or more of iodef:Reference [RFC5070]. This element 384 allows an IODEF document to include a link to a structured 385 information instead of directly embedding it into a RawData 386 element. 388 4.3.3. Vulnerability 390 A Vulnerability consists of an extension to the 391 Incident.Method.AdditionalData element with a dtype of "xml". The 392 extension describes the (candidate) vulnerabilities of incidents or 393 events. 395 It is recommended that Method class SHOULD contain one or more of the 396 extension elements whenever available. 398 A Vulnerability element is structured as follows. 400 +------------------------+ 401 | Vulnerability | 402 +------------------------+ 403 | ENUM SpecID |<>--(0..*)-[ RawData ] 404 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 405 | STRING VulnerabilityID |<>--(0..*)-[ Platform ] 406 | |<>--(0..*)-[ Scoring ] 407 +------------------------+ 409 Figure 4: Vulnerability class 411 This class has the following attributes. 413 SpecID: REQUIRED. ENUM. A specification's identifier that 414 specifies the format of a structured cybersecurity information. 415 The value should be chosen from the namespaces [XMLNames] listed 416 in the IANA table (Section 4.1) or "private". The value "private" 417 is prepared for conveying RawData based on a format that is not 418 listed in the table. This is usually used for conveying data 419 formatted according to an organization's private schema. When the 420 value "private" is used, ext-SpecID element MUST be used. 422 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 423 specifies the format of a structured cybersecurity information. 424 When this element is used, the value of SpecID element must be 425 "private." 427 VulnerabilityID: OPTIONAL. STRING. An identifier of a 428 vulnerability to be reported. This attribute SHOULD be used 429 whenever such identifier is available. Both RawData and Reference 430 elements MUST NOT be used when this attribute is used, while 431 either of them MUST be used if this attribute is omitted. 433 This class is composed of the following aggregate classes. 435 RawData: Zero or one. XMLDATA. A complete document that is 436 formatted according to the specification and its version 437 identified by the SpecID/ext-SpecID. When this element is used, 438 writers/senders MUST ensure that the namespace specified by 439 SpecID/ext-SpecID and the one used in the RawData element are 440 consistent; if not, the namespace identified by SpecID SHOULD be 441 prefered, and the inconsistency SHOULD be logged so a human can 442 correct the problem. 444 Reference: Zero or one of iodef:Reference [RFC5070]. This element 445 allows an IODEF document to include a link to a structured 446 information instead of directly embedding it into a RawData 447 element. 449 Platform: Zero or more. An identifier of software platform affected 450 by the vulnerability, which is elaborated in Section 4.3.2. 452 Scoring: Zero or more. An indicator of the severity of the 453 vulnerability, such as CVSS and CCSS scores, which is elaborated 454 in Section 4.3.4. Some of the structured information may include 455 scores within it. In this case, the Scoring element SHOULD NOT be 456 used since the RawData element contains the scores. If a reader/ 457 receiver detects scores in both RawData and Scoring elements and 458 their inconsistency, it SHOULD prefer the scores derived from the 459 RawData element, and SHOULD log the inconsistency so a human can 460 correct the problem. 462 4.3.4. Scoring 464 A Scoring class describes the scores of the severity in terms of 465 security. It is recommended that Vulnerability and Weakness classes 466 contain the elements whenever available. 468 A Scoring class is structured as follows. 470 +----------------------+ 471 | Scoring | 472 +----------------------+ 473 | ENUM SpecID |<>---------[ ScoreSet ] 474 | STRING ext-SpecID | 475 +----------------------+ 477 Figure 5: Scoring class 479 This class has two attributes. 481 SpecID: REQUIRED. ENUM. A specification's identifier that 482 specifies the format of a structured cybersecurity information. 483 The value should be chosen from the namespaces [XMLNames] listed 484 in the IANA table (Section 4.1) or "private". The value "private" 485 is prepared for conveying RawData based on a format that is not 486 listed in the table. This is usually used for conveying data 487 formatted according to an organization's private schema. When the 488 value "private" is used, ext-SpecID element MUST be used. 490 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 491 specifies the format of a structured cybersecurity information. 492 When this element is used, the value of SpecID element must be 493 "private." 495 This class is composed of an aggregate class. 497 ScoreSet: One. XMLDATA. A complete document that is formatted 498 according to the specification and its version identified by the 499 SpecID/ext-SpecID. This element includes a set of score 500 information. When this element is used, writers/senders MUST 501 ensure that the namespace specified by SpecID/ext-SpecID and the 502 one used in the RawData element are consistent; if not, the 503 namespace identified by SpecID SHOULD be prefered, and the 504 inconsistency SHOULD be logged so a human can correct the problem. 506 Writers/senders MUST ensure the specification name and version 507 identified by the SpecID are consistent with the contents of the 508 Score; if a reader/receiver detects an inconsistency, it SHOULD 509 prefer the specification name and version derived from the content, 510 and SHOULD log the inconsistency so a human can correct the problem. 512 4.3.5. Weakness 514 A Weakness consists of an extension to the 515 Incident.Method.AdditionalData element with a dtype of "xml". The 516 extension describes the weakness types of incidents or events. 518 It is recommended that Method class SHOULD contain one or more of the 519 extension elements whenever available. 521 A Weakness element is structured as follows. 523 +----------------------+ 524 | Weakness | 525 +----------------------+ 526 | ENUM SpecID |<>--(0..*)-[ RawData ] 527 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 528 | STRING WeaknessID |<>--(0..*)-[ Platform ] 529 | |<>--(0..*)-[ Scoring ] 530 +----------------------+ 532 Figure 6: Weakness class 534 This class has the following attributes. 536 SpecID: REQUIRED. ENUM. A specification's identifier that 537 specifies the format of a structured cybersecurity information. 538 The value should be chosen from the namespaces [XMLNames] listed 539 in the IANA table (Section 4.1) or "private". The value "private" 540 is prepared for conveying RawData based on a format that is not 541 listed in the table. This is usually used for conveying data 542 formatted according to an organization's private schema. When the 543 value "private" is used, ext-SpecID element MUST be used. 545 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 546 specifies the format of a structured cybersecurity information. 547 When this element is used, the value of SpecID element must be 548 "private." 550 WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be 551 reported. This attribute SHOULD be used whenever such identifier 552 is available/ Both RawData and Reference elements MUST NOT be used 553 when this attribute is used, while either of them MUST be used if 554 this attribute is omitted. 556 This class is composed of the following aggregate classes. 558 RawData: Zero or more. XMLDATA. A complete document that is 559 formatted according to the specification and its version 560 identified by the SpecID/ext-SpecID. When this element is used, 561 writers/senders MUST ensure that the namespace specified by 562 SpecID/ext-SpecID and the one used in the RawData element are 563 consistent; if not, the namespace identified by SpecID SHOULD be 564 prefered, and the inconsistency SHOULD be logged so a human can 565 correct the problem. 567 Reference: Zero or one of iodef:Reference [RFC5070]. This element 568 allows an IODEF document to include a link to a structured 569 information instead of directly embedding it into a RawData 570 element. 572 Platform: Zero or more. An identifier of software platform affected 573 by the weakness, which is elaborated in Section 4.3.2. 575 Scoring: Zero or more. An indicator of the severity of the 576 weakness, such as CWSS score, which is elaborated in 577 Section 4.3.4. 579 4.3.6. EventReport 581 An EventReport consists of an extension to the 582 Incident.EventData.Record.RecordData.RecordItem element with a dtype 583 of "xml". The extension embeds structured event reports. 585 It is recommended that RecordItem class SHOULD contain one or more of 586 the extension elements whenever available. 588 An EventReport element is structured as follows. 590 +----------------------+ 591 | EventReport | 592 +----------------------+ 593 | ENUM SpecID |<>--(0..*)-[ RawData ] 594 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 595 | STRING EventID | 596 +----------------------+ 598 Figure 7: EventReport class 600 This class has the following attributes. 602 SpecID: REQUIRED. ENUM. A specification's identifier that 603 specifies the format of a structured cybersecurity information. 604 The value should be chosen from the namespaces [XMLNames] listed 605 in the IANA table (Section 4.1) or "private". The value "private" 606 is prepared for conveying RawData based on a format that is not 607 listed in the table. This is usually used for conveying data 608 formatted according to an organization's private schema. When the 609 value "private" is used, ext-SpecID element MUST be used. 611 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 612 specifies the format of a structured cybersecurity information. 613 When this element is used, the value of SpecID element must be 614 "private." 616 EventID: OPTIONAL. STRING. An identifier of an event to be 617 reported. This attribute SHOULD be used whenever such identifier 618 is available. Both RawData and Reference elements MUST NOT be 619 used when this attribute is used, while either of them MUST be 620 used if this attribute is omitted. 622 This class is composed of three aggregate classes. 624 RawData: Zero or one. XMLDATA. A complete document that is 625 formatted according to the specification and its version 626 identified by the SpecID/ext-SpecID. When this element is used, 627 writers/senders MUST ensure that the namespace specified by 628 SpecID/ext-SpecID and the one used in the RawData element are 629 consistent; if not, the namespace identified by SpecID SHOULD be 630 prefered, and the inconsistency SHOULD be logged so a human can 631 correct the problem. 633 Reference: Zero or one of iodef:Reference [RFC5070]. This element 634 allows an IODEF document to include a link to a structured 635 information instead of directly embedding it into a RawData 636 element. 638 This class MUST contain at least one of RawData or Reference 639 elements. Writers/senders MUST ensure the specification name and 640 version identified by the SpecID are consistent with the contents of 641 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 642 prefer the specification name and version derived from the content, 643 and SHOULD log the inconsistency so a human can correct the problem. 645 4.3.7. Verifcation 647 A Verification consists of an extension to the 648 Incident.AdditionalData element with a dtype of "xml". The extension 649 elements describes incident on vefifying incidents. 651 A Verification class is structured as follows. 653 +----------------------+ 654 | Verification | 655 +----------------------+ 656 | ENUM SpecID |<>--(0..*)-[ RawData ] 657 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 658 | STRING VerificationID| 659 +----------------------+ 661 Figure 8: Verification class 663 This class has the following attributes. 665 SpecID: REQUIRED. ENUM. A specification's identifier that 666 specifies the format of a structured cybersecurity information. 667 The value should be chosen from the namespaces [XMLNames] listed 668 in the IANA table (Section 4.1) or "private". The value "private" 669 is prepared for conveying RawData based on a format that is not 670 listed in the table. This is usually used for conveying data 671 formatted according to an organization's private schema. When the 672 value "private" is used, ext-SpecID element MUST be used. 674 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 675 specifies the format of a structured cybersecurity information. 676 When this element is used, the value of SpecID element must be 677 "private." 679 VerificationID: OPTIONAL. STRING. An identifier of an check item 680 to be reported. This attribute SHOULD be used whenever such 681 identifier is available. Both RawData and Reference elements MUST 682 NOT be used when this attribute is used, while either of them MUST 683 be used if this attribute is omitted. 685 This class is composed of two aggregate classes. 687 RawData: Zero or one. XMLDATA. A complete document that is 688 formatted according to the specification and its version 689 identified by the SpecID/ext-SpecID. When this element is used, 690 writers/senders MUST ensure that the namespace specified by 691 SpecID/ext-SpecID and the one used in the RawData element are 692 consistent; if not, the namespace identified by SpecID SHOULD be 693 prefered, and the inconsistency SHOULD be logged so a human can 694 correct the problem. 696 Reference: Zero or one of iodef:Reference [RFC5070]. This element 697 allows an IODEF document to include a link to a structured 698 information instead of directly embedding it into a RawData 699 element. 701 This class MUST contain at least either of RawData and Reference 702 elements. Writers/senders MUST ensure the specification name and 703 version identified by the SpecID are consistent with the contents of 704 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 705 prefer the specification name and version derived from the content, 706 and SHOULD log the inconsistency so a human can correct the problem. 708 4.3.8. Remediation 710 A Remediation consists of an extension to the Incident.AdditionalData 711 element with a dtype of "xml". The extension elements describes 712 incident remediation information including instructions. 714 It is recommended that Incident class SHOULD contain one or more of 715 this extension elements whenever available. 717 A Remediation class is structured as follows. 719 +----------------------+ 720 | Remediation | 721 +----------------------+ 722 | ENUM SpecID |<>--(0..*)-[ RawData ] 723 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 724 | String RemediationID | 725 +----------------------+ 727 Figure 9: Remediation class 729 This class has the following attributes. 731 SpecID: REQUIRED. ENUM. A specification's identifier that 732 specifies the format of a structured cybersecurity information. 733 The value should be chosen from the namespaces [XMLNames] listed 734 in the IANA table (Section 4.1) or "private". The value "private" 735 is prepared for conveying RawData based on a format that is not 736 listed in the table. This is usually used for conveying data 737 formatted according to an organization's private schema. When the 738 value "private" is used, ext-SpecID element MUST be used. 740 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 741 specifies the format of a structured cybersecurity information. 742 When this element is used, the value of SpecID element must be 743 "private." 745 RemediationID: OPTIONAL. STRING. An identifier of a remediation 746 information to be reported. This attribute SHOULD be used 747 whenever such identifier is available. Both RawData and Reference 748 elements MUST NOT be used when this attribute is used, while 749 either of them MUST be used if this attribute is omitted. 751 This class is composed of two aggregate classes. 753 RawData: Zero or one. XMLDATA. A complete document that is 754 formatted according to the specification and its version 755 identified by the SpecID/ext-SpecID. When this element is used, 756 writers/senders MUST ensure that the namespace specified by 757 SpecID/ext-SpecID and the one used in the RawData element are 758 consistent; if not, the namespace identified by SpecID SHOULD be 759 prefered, and the inconsistency SHOULD be logged so a human can 760 correct the problem. 762 Reference: Zero or one of iodef:Reference [RFC5070]. This element 763 allows an IODEF document to include a link to a structured 764 information instead of directly embedding it into a RawData 765 element. 767 This class MUST contain at least either of RawData and Reference 768 elements. Writers/senders MUST ensure the specification name and 769 version identified by the SpecID are consistent with the contents of 770 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 771 prefer the specification name and version derived from the content, 772 and SHOULD log the inconsistency so a human can correct the problem. 774 5. Mandatory to Implement features 776 The implementation of this draft needs to suffice the following. 778 The CVE SpecID value and related values (e.g., namespace) MUST be 779 implemented (implementation is capable of sending and receiving 780 well-formed CVE 1.0 XML documents without error). 782 The receiver MUST implement validation of received CVE 1.0 XML 783 documents against the CVE 1.0 XML schema in order to detect 784 invalid CVE documents. 786 The receiver SHOULD validate all received CVE 1.0 XML documents as 787 described in the above item. 789 6. Security Considerations 791 This document specifies a format for encoding a particular class of 792 security incidents appropriate for exchange across organizations. As 793 merely a data representation, it does not directly introduce security 794 issues. However, it is guaranteed that parties exchanging instances 795 of this specification will have certain concerns. For this reason, 796 the underlying message format and transport protocol used MUST ensure 797 the appropriate degree of confidentiality, integrity, and 798 authenticity for the specific environment. 800 Organizations that exchange data using this document are URGED to 801 develop operating procedures that document the following areas of 802 concern. 804 6.1. Transport-Specific Concerns 806 The underlying messaging format and protocol used to exchange 807 instances of the IODEF MUST provide appropriate guarantees of 808 confidentiality, integrity, and authenticity. The use of a 809 standardized security protocol is encouraged. The Real-time Inter- 810 network Defense (RID) protocol [RFC6045] and its associated transport 811 binding [RFC6046] provide such security. 813 The critical security concerns are that these structured information 814 may be falsified or they may become corrupt during transit. In areas 815 where transmission security or secrecy is questionable, the 816 application of a digital signature and/or message encryption on each 817 report will counteract both of these concerns. We expect that each 818 exchanging organization will determine the need, and mechanism, for 819 transport protection. 821 7. IANA Considerations 823 This document uses URNs to describe XML namespaces and XML 824 schemata[XMLschemaPart1][XMLschemaPart2] conforming to a registry 825 mechanism described in [RFC3688]. 827 Registration request for the IODEF structured cybersecurity 828 information extension namespace: 830 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 832 Registrant Contact: Refer here to the authors' addresses section 833 of the document. 835 XML: None 837 Registration request for the IODEF structured cybersecurity 838 information extension XML schema: 840 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 842 Registrant Contact: Refer here to the authors' addresses section 843 of the document. 845 XML: Refer here to the XML Schema in the appendix of the document. 847 This memo creates the following registry for IANA to manage: 849 Name of the registry: "IODEF Structured Cyber Security Information 850 Specifications" 852 Namespace details: A registry entry for a Structured Cyber 853 Security Information Specification (SCI specification) consists 854 of: 856 Namespace: A URI [RFC3986] that is the XML namespace name used 857 by the registered SCI specification. 859 Specification Name: A string containing the spelled-out name of 860 the SCI specification in human-readable form. 862 Reference URI: A list of one or more of the URIs [RFC3986] from 863 which the registered specification can be obtained. The 864 registered specification MUST be readily and publicly available 865 from that URI. 867 Applicable Classes: A list of one or more of the Extended 868 Classes specified in Section 4.3 of this document. The 869 registered SCI specification MUST only be used with the 870 Extended Classes in the registry entry. 872 Information that must be provided to assign a new value: The above 873 list of information. 875 Fields to record in the registry: Namespace/Specification Name/ 876 Version/Applicable Classes. 878 Initial registry contents: none 880 Allocation Policy: Expert Review [RFC5226] and Specification 881 Required [RFC5226]. 883 The Designated Expert is expected to consult with the mile (Managed 884 Incident Lightweight Exchange) working group or its successor if any 885 such WG exists (e.g., via email to the working group's mailing list). 886 The Designated Expert is expected to retrieve the SCI specification 887 from the provided URI in order to check the public availability of 888 the specification and verify the correctness of the URI. An 889 important responsibility of the Designated Expert is to ensure that 890 the registered Applicable Classes are appropriate for the registered 891 SCI specification. 893 8. Acknowledgment 895 We would like to acknowledge Mr. David Black from EMC, who kindly 896 provided generous support, especially on the IANA registry issues. 897 We also would like to thank Jon Baker from MITRE, Paul Cichonski from 898 NIST, Robert Martin from MITRE, Kathleen Moriarty from EMC, Lagadec 899 Philippe from NATO, Shuhei Yamaguchi from NICT, Anthony Rutkowski 900 from Yaana Technology, Brian Trammel from CERT/NetSA, and David 901 Waltermire from NIST for their sincere discussion and feedback on 902 this document. 904 9. Appendix I: XML Schema Definition for Extension 906 The XML Schema describing the elements defined in the Extension 907 Definition section is given here. Each of the examples in Section 10 908 should be verified to validate against this schema by automated 909 tools. 911 913 919 922 926 930 931 932 933 934 936 937 938 939 940 941 942 943 944 946 950 951 952 953 955 956 957 959 960 962 966 967 968 969 970 972 974 975 977 978 979 981 983 984 986 990 991 992 993 994 996 998 999 1001 1003 1004 1005 1007 1009 1010 1012 1016 1017 1018 1019 1020 1022 1024 1025 1027 1029 1030 1031 1033 1035 1036 1038 1042 1043 1044 1045 1046 1048 1050 1051 1052 1053 1055 1057 1058 1060 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1075 1077 1078 1080 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1095 1097 1098 1100 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1115 1117 1118 1120 1122 10. Appendix II: XML Examples 1124 This section provides an example of an incident encoded in the IODEF. 1125 This do not necessarily represent the only way to encode a particular 1126 incident. Below is an example of a CSIRT reporting an attack. 1128 1129 1134 1135 189493 1136 2001-09-13T23:19:24+00:00 1137 Incident report in company xx 1138 1139 1140 1141 1142 Structured information on attack pattern, exploited 1143 vulnerability, and weakness 1144 1145 1147 1148 Link to Capec-14 1149 http://capec.mitre.org/data/definitions/14.html 1150 1151 1152 1155 1157 1158 1162 1163 ... 1164 1165 1166 1167 1169 1171 1172 1173 9.3 1174 NETWORK 1175 MEDIUM 1176 NONE 1177 COMPLETE 1178 COMPLETE 1179 COMPLETE 1180 http://nvd.nist.gov 1181 2012-01-11T09:55:00.000-05:00 1182 1183 1184 1185 1186 1187 1189 1190 1196 ..... 1197 1198 1199 1200 1202 1203 1204 Example.com CSIRT 1205 example-com 1206 contact@csirt.example.com 1207 1208 1209 1210 1211 1212
192.0.2.200
1213 57 1214 1215 1216 1217 1218
192.0.2.16/28
1219 1220 1221 80 1222 1223 1224 1226 1227 1228 1229 1230 1231 1232 1233 1234 2001-09-13T18:11:21+02:00 1235 a Web-server event record 1236 1237 1238 1239 1240 ..... 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 2001-09-14T08:19:01+00:00 1252 Notification sent to 1253 constituency-contact@192.0.2.200 1254 1255 1256 1257 1259 1260 1272 ..... 1273 1274 1275 1276 1277 1278 1283 ..... 1284 1285 1286 1287 1288 1289 1291 11. Appendix III: Candidate Specifications listed to the IANA table 1293 This draft defined the structure of the IANA table in Section 4.1. 1294 Though the management of the table is up to IANA, this appendix 1295 provides candidate entries. 1297 1. CAPEC 1.6 1299 Namespace: http://capec.mitre.org/observables 1300 Specification Name: Common Attack Pattern Enumeration and Classification 1301 Version: 1.6 1302 Reference URI: http://capec.mitre.org/ 1303 Applicable Classes: AttackPattern 1305 2. CCE 5.0 1307 Namespace: http://cce.mitre.org 1308 Specification Name: Common Configuration Enumeration 1309 Version: 5.0 1310 Reference URI: http://cce.mitre.org/ 1311 Applicable Classes: Verification 1313 3. CCSS 1.0 1315 Namespace: N/A 1316 Specification Name: Common Configuration Scoring System 1317 Version: 1.0 1318 Reference URI: http://csrc.nist.gov/publications/PubsNISTIRs.html 1319 #NIST-IR-7502 1320 Applicable Classes: Scoring 1322 4. CEE 0.6 1324 Namespace: http://cee.mitre.org 1325 Specification Name: Common Event Expression 1326 Version: 0.6 1327 Reference URI: http://cee.mitre.org/ 1328 Applicable Classes: EventReport 1330 5. CPE 2.3 Language 1332 Namespace: http://cpe.mitre.org/language/2.0 1333 Specification Name: Common Platform Enumeration Reference 1334 Version: 2.3 1335 Reference URI: http://scap.nist.gov/specifications/cpe/, 1336 http://csrc.nist.gov/publications/PubsNISTIRs.html 1337 #NIST-IR-7695 1338 Applicable Classes: Platform 1340 6. CPE 2.3 Dictionary 1342 Namespace: http://cpe.mitre.org/dictionary/2.0 1343 Specification Name: Common Platform Enumeration Dictionary 1344 Version: 2.3 1345 Reference URI: http://scap.nist.gov/specifications/cpe/, 1346 http://csrc.nist.gov/publications/PubsNISTIRs.html 1347 #NIST-IR-7697 1348 Applicable Classes: Platform 1350 7. CVE 1.0 1352 Namespace: http://cve.mitre.org/cve/downloads/1.0 1353 Specification Name: Common Vulnerability and Exposures 1354 Version: 1.0 1355 Reference URI: http://cve.mitre.org/ 1356 Applicable Classes: Vulnerability 1358 8. CVRF 1.0 1360 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 1361 Specification Name: Common Vulnerability Reporting Format 1362 Version: 1.0 1363 Reference URI: http://www.icasi.org/cvrf 1364 Applicable Classes: Vulnerability 1366 9. CVSS 2.0 1368 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 1369 Specification Name: Common Vulnerability Scoring System 1370 Version: 2 1371 Reference URI: http://www.first.org/cvss 1372 Applicable Classes: Scoring 1374 10. CWE 5.0 1376 Namespace: N/A 1377 Specification Name: Common Weakness Enumeration 1378 Version: 5.1 1379 Reference URI: http://cwe.mitre.org/ 1380 Applicable Classes: Weakness 1382 11. CWSS 0.8 1384 Namespace: N/A 1385 Specification Name: Common Weakness Scoring System 1386 Version: 0.8 1387 Reference URI: http://cwe.mitre.org/cwss/ 1388 Applicable Classes: Scoring 1390 12. MAEC 2.0 1392 Namespace: http://maec.mitre.org/XMLSchema/maec-core-2 1393 Specification Name: Malware Attribute Enumeration and Characterization 1394 Version: 2.0 1395 Reference URI: http://maec.mitre.org/ 1396 Applicable Classes: EventReport, AttackPattern 1398 13. OCIL 2.0 1400 Namespace: http://scap.nist.gov/schema/ocil/2.0 1401 Specification Name: Open Checklist Interactive Language 1402 Version: 2.0 1403 Reference URI: http://scap.nist.gov/specifications/ocil/, 1404 http://csrc.nist.gov/publications/PubsNISTIRs.html 1405 #NIST-IR-7692 1406 Applicable Classes: Verification 1408 14. OVAL 5.10.1 Definitions 1410 Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 1411 Specification Name: Open Vulnerability and Assessment Language 1412 Version: 5.10.1 1413 Reference URI: http://oval.mitre.org/ 1414 Applicable Classes: Verification 1416 15. OVAL 5.10.1 Results 1418 Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 1419 Specification Name: Open Vulnerability and Assessment Language 1420 Version: 5.10.1 1421 Reference URI: http://oval.mitre.org/ 1422 Applicable Classes: Verification 1424 16. OVAL 5.10.1 Common 1426 Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 1427 Specification Name: Open Vulnerability and Assessment Language 1428 Version: 5.10.1 1429 Reference URI: http://oval.mitre.org/ 1430 Applicable Classes: Verification 1432 17. XCCDF 1.2 1434 Namespace: http://checklists.nist.gov/xccdf/1.2 1435 Specification Name: Extensible Configuration Checklist Description Format 1436 Version: 1.2 1437 Reference URI: http://scap.nist.gov/specifications/xccdf/, 1438 http://csrc.nist.gov/publications/PubsNISTIRs.html 1439 #NIST-IR-7275-r4 1440 Applicable Classes: Verification 1442 12. References 1444 12.1. Normative References 1446 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1447 (CVE)". 1449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1450 Requirement Levels", BCP 14, RFC 2119, March 1997. 1452 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1453 Resource Identifier (URI): Generic Syntax", STD 66, 1454 RFC 3986, January 2005. 1456 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1457 Object Description Exchange Format", RFC 5070, 1458 December 2007. 1460 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1461 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1462 May 2008. 1464 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1465 RFC 6045, November 2010. 1467 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1468 Inter-network Defense (RID) Messages", RFC 6046, 1469 November 2010. 1471 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1472 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1473 Edition)", W3C Recommendation, November 2008. 1475 [XMLschemaPart1] 1476 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1477 "XML Schema Part 1: Structures Second Edition", 1478 W3C Recommendation, October 2004. 1480 [XMLschemaPart2] 1481 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1482 Second Edition", W3C Recommendation, October 2004. 1484 [XMLNames] 1485 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1486 Thomson, ""Namespaces in XML (Third Edition)", 1487 W3C Recommendation, December 2009. 1489 12.2. Informative References 1491 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1492 Internet: Timestamps", RFC 3339, July 2002. 1494 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1495 Text on Security Considerations", BCP 72, RFC 3552, 1496 July 2003. 1498 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1499 January 2004. 1501 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1502 October 2008. 1504 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1505 Uniform Resource Identifiers (URI) Dynamic Delegation 1506 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1507 March 2011. 1509 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1510 and Classification (CAPEC)". 1512 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1513 (CCE)". 1515 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1516 Scoring System (CCSS)", NIST Interagency Report 7502, 1517 December 2010. 1519 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1521 [CPE] National Institute of Standards and Technology, "Common 1522 Platform Enumeration", June 2011. 1524 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1526 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1527 Common Vulnerability Scoring System (CVSS) and Its 1528 Applicability to Federal Agency Systems". 1530 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1531 (CWE)". 1533 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1534 (CWSS)". 1536 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1537 Open Checklist Interactive Language (OCIL) Version 2.0", 1538 April 2011. 1540 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1541 Language (OVAL)". 1543 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 1544 Halbardier, "The Technical Specification for the Security 1545 Content Automation Protocol (SCAP): SCAP Version 1.2", 1546 NIST Special Publication 800-126 Revision 2, 1547 September 2011. 1549 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1550 and Neal Ziring, "Specification for the Extensible 1551 Configuration Checklist Description Format (XCCDF) version 1552 1.2 (DRAFT)", July 2011. 1554 Authors' Addresses 1556 Takeshi Takahashi 1557 National Institute of Information and Communications Technology 1558 4-2-1 Nukui-Kitamachi Koganei 1559 184-8795 Tokyo 1560 Japan 1562 Phone: +80 423 27 5862 1563 Email: takeshi_takahashi@nict.go.jp 1565 Kent Landfield 1566 McAfee, Inc 1567 5000 Headquarters Drive 1568 Plano, TX 75024 1569 USA 1571 Email: Kent_Landfield@McAfee.com 1572 Thomas Millar 1573 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1574 245 Murray Lane SW, Building 410, MS #732 1575 Washington, DC 20598 1576 USA 1578 Phone: +1 888 282 0870 1579 Email: thomas.millar@us-cert.gov 1581 Youki Kadobayashi 1582 Nara Institute of Science and Technology 1583 8916-5 Takayama, Ikoma 1584 630-0192 Nara 1585 Japan 1587 Email: youki-k@is.aist-nara.ac.jp