idnits 2.17.1 draft-ietf-mile-sci-08.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 3 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 (Jul 4, 2013) is 3950 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 1945, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1948, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1955, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1958, but no explicit reference was found in the text == Unused Reference: 'CAPEC' is defined on line 1963, but no explicit reference was found in the text == Unused Reference: 'CCE' is defined on line 1966, but no explicit reference was found in the text == Unused Reference: 'CCSS' is defined on line 1969, but no explicit reference was found in the text == Unused Reference: 'CEE' is defined on line 1973, but no explicit reference was found in the text == Unused Reference: 'CPE' is defined on line 1975, but no explicit reference was found in the text == Unused Reference: 'CVE' is defined on line 1978, but no explicit reference was found in the text == Unused Reference: 'CVRF' is defined on line 1981, but no explicit reference was found in the text == Unused Reference: 'CVSS' is defined on line 1983, but no explicit reference was found in the text == Unused Reference: 'CWE' is defined on line 1987, but no explicit reference was found in the text == Unused Reference: 'CWSS' is defined on line 1990, but no explicit reference was found in the text == Unused Reference: 'MAEC' is defined on line 1993, but no explicit reference was found in the text == Unused Reference: 'OCIL' is defined on line 1996, but no explicit reference was found in the text == Unused Reference: 'OVAL' is defined on line 2000, but no explicit reference was found in the text == Unused Reference: 'SCAP' is defined on line 2003, but no explicit reference was found in the text == Unused Reference: 'XCCDF' is defined on line 2009, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MMDEF' ** 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. 'EICAR' -- 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 (~~), 20 warnings (==), 7 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: January 5, 2014 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Jul 4, 2013 12 IODEF-extension for structured cybersecurity information 13 draft-ietf-mile-sci-08.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 January 5, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 Type: XMLDATA . . . . . . . . . . . . . . . 5 63 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 6 64 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 7 65 4.3.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 9 67 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 13 71 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 14 72 5. Mandatory to Implement features . . . . . . . . . . . . . . . 16 73 5.1. An Example XML . . . . . . . . . . . . . . . . . . . . . . 16 74 5.2. An XML Schema for the Extension . . . . . . . . . . . . . 18 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 76 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 23 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24 79 9. Appendix I: Candidate Specifications for the IANA Table . . . 25 80 10. Appendix II: MMDEF version 1.2 scheema . . . . . . . . . . . . 29 81 11. Appendix III: An Example XML using Candidate Specifications . 40 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 87 1. Introduction 89 The number of cyber attacks is growing day by day, and incident 90 information needs to be reported, exchanged, and shared among 91 organizations in order to cope with the situation. IODEF is one of 92 the tools enabling such exchange, and is already in use. 94 To efficiently run cybersecurity operations, these exchanged 95 information needs to be machine-readable. IODEF provides a 96 structured means to describe the information, but it needs to embed 97 various non-structured such information in order to convey detailed 98 information. Further structure within IODEF increases IODEF 99 documents' machine-readability and thus facilitates streamlining 100 cybersecurity operations. 102 On the other hand, there exist various other activities facilitating 103 detailed and structured description of cybersecurity information, as 104 listed in Section 9 . Since such structured description facilitates 105 cybersecurity operations, it would be beneficial to embed and convey 106 these information inside IODEF document. 108 To enable that, this document extends the IODEF to embed and convey 109 various structured cybersecurity information, with which 110 cybersecurity operations can be facilitated. Since IODEF defines a 111 flexible and extensible format and supports a granular level of 112 specificity, this document defines an extension to IODEF instead of 113 defining a new report format. For clarity, and to eliminate 114 duplication, only the additional structures necessary for describing 115 the exchange of such structured information are provided. 117 2. Terminology 119 The terminology used in this document follows the one defined in RFC 120 5070 [RFC5070] . 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119] . 126 3. Applicability 128 To maintain cybersecurity, organization needs to exchange 129 cybersecurity information, which includes the following information: 130 attack pattern, platform information, vulnerability and weakness, 131 countermeasure instruction, computer event log, and the severity. 133 IODEF provides a scheme to describe and exchange such information 134 among interested parties. However, it does not define the detailed 135 format to describe such information. 137 On the other hand, there already exist structured and detailed 138 formats for describing those information and facilitating such 139 exchange. Major of them are listed in Section 9 . By embedding them 140 into the IODEF document, the document can convey more detailed 141 contents to the receivers, and the document can be easily reused. 143 These structured cybersecurity information facilitates cybersecurity 144 operation at the receiver side. Since the information is machine- 145 readable, the data can be processed by computers. That expedites the 146 automation of cybersecurity operations 148 For instance, an organization wishing to report a security incident 149 wants to describe what vulnerability was exploited. Then the sender 150 can simply use IODEF, where an XML [XML1.0] -based attack pattern 151 record that follows the syntax and vocabulary defined by an industry 152 specification is embedded instead of describing everything in free 153 format text. Receiver can identify the needed details of the attack 154 pattern by looking up some of the XML tags defined by the 155 specification. Receiver can accumulate the attack pattern record in 156 its database and could distribute it to the interested parties if 157 needed, without needing human interventions. 159 Another example is that, when an administrator wishes to check the 160 configuration of host computers in his organization, he may send a 161 query to host computers, which may automatically generate XML-based 162 software configuration information upon receiving thequery by running 163 a software and may embed that to an IODEF document, which is then 164 sent back to the administrator. 166 4. Extension Definition 168 This draft extends IODEF to embed structured cybersecurity 169 information by introducing new classes, with which these information 170 can be embedded inside IODEF document as element contents of 171 AdditionalData and RecordItem classes. 173 4.1. IANA Table for Structured Cybersecurity Information 175 This extension embeds structured cybersecurity information defined by 176 the other specifications. The list of supported specifications is 177 managed by IANA, and this draft defines the needed field for the 178 list's entry. 180 Each entry has namespace [XMLNames] , specification name, version, 181 reference URI, and applicable classes for each specification. 182 Arbitrary URIs that may help readers to understand the specification 183 could be embedded inside the Reference URI field, but it is 184 recommended that standard/informational URI describing the 185 specification is prepared and is embedded here. 187 The initial IANA table has only one entry, as below. 189 Namespace: http://xml/metadataSharing.xsd 190 Specification Name: Malware Metadata Exchange Format 191 Version: 1.2 192 Reference URI: http://standards.ieee.org/develop 193 indconn/icsg/mmdef.html 194 Applicable Classes: AttackPattern 196 Note that the specification was developed by The Institute of 197 Electrical and Electronics Engineers, Incorporated (IEEE), through 198 the Industry Connections Security Group (ICSG) of its Standards 199 Association. 201 The table is to be managed by IANA using the Expert Review [RFC5226] 202 and Specification Required [RFC5226] allocation policies as further 203 specified in Section 7 . 205 The SpecID attributes of extended classes (Section 4.3) must allow 206 the values of the specifications' namespace fields, but otherwise, 207 implementations are not required to support all specifications of the 208 IANA table and may choose which specifications to support, though the 209 specification listed in the initial table needs to be minimally 210 supported, as described in Section 5. In case an implementation 211 received a data it does not support, it may expand its functionality 212 by looking up the IANA table or notify the sender of its inability to 213 parse the data by using any means defined outside the scope of this 214 specification. 216 4.2. Extended Data Type: XMLDATA 218 This extension inherits all of the data types defined in the IODEF 219 model. One data type is added: XMLDATA. An embedded XML data is 220 represented by the XMLDATA data type. This type is defined as the 221 extension to the iodef:ExtensionType [RFC5070] , whose dtype 222 attribute is set to "xml." 224 4.3. Extended Classes 226 The IODEF Incident element [RFC5070] is summarized below. It is 227 expressed in Unified Modeling Language (UML) syntax as used in the 228 IODEF specification. The UML representation is for illustrative 229 purposes only; elements are specified in XML as defined in Appendix 230 A. 232 +---------------+ 233 | Incident | 234 +---------------+ 235 | ENUM purpose |<>---------[IncidentID] 236 | STRING |<>--{0..1}-[AlternativeID] 237 | ext-purpose |<>--{0..1}-[RelatedActivity] 238 | ENUM lang |<>--{0..1}-[DetectTime] 239 | ENUM |<>--{0..1}-[StartTime] 240 | restriction |<>--{0..1}-[EndTime] 241 | |<>---------[ReportTime] 242 | |<>--{0..*}-[Description] 243 | |<>--{1..*}-[Assessment] 244 | |<>--{0..*}-[Method] 245 | | |<>--{0..*}-[AdditionalData] 246 | | |<>--{0..*}-[AttackPattern] 247 | | |<>--{0..*}-[Vulnerability] 248 | | |<>--{0..*}-[Weakness] 249 | |<>--{1..*}-[Contact] 250 | |<>--{0..*}-[EventData] 251 | | |<>--{0..*}-[Flow] 252 | | | |<>--{1..*}-[System] 253 | | | |<>--{0..*}-[AdditionalData] 254 | | | |<>--{0..*}-[Platform] 255 | | |<>--{0..*}-[Expectation] 256 | | |<>--{0..1}-[Record] 257 | | |<>--{1..*}-[RecordData] 258 | | |<>--{1..*}-[RecordItem] 259 | | |<>--{0..*}-[EventReport] 260 | |<>--{0..1}-[History] 261 | |<>--{0..*}-[AdditionalData] 262 | | |<>--{0..*}-[Verification] 263 | | |<>--{0..*}-[Remediation] 264 +---------------+ 266 Figure 1: Incident class 268 This extension defines the following seven elements. 270 4.3.1. AttackPattern 272 An AttackPattern consists of an extension to the 273 Incident.Method.AdditionalData element with a dtype of "xml". The 274 extension describes attack patterns of incidents or events. 276 It is recommended that Method class SHOULD contain one or more of the 277 extension elements whenever available. 279 An AttackPattern class is structured as follows. 281 +------------------------+ 282 | AttackPattern | 283 +------------------------+ 284 | ENUM SpecID |<>--(0..*)-[ RawData ] 285 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 286 | STRING AttackPatternID |<>--(0..*)-[ Platform ] 287 +------------------------+ 289 Figure 2: AttackPattern class 291 This class has the following attributes. 293 SpecID: REQUIRED. ENUM. A specification's identifier that 294 specifies the format of a structured cybersecurity information. 295 The value should be chosen from the namespaces [XMLNames] listed 296 in the IANA table (Section 4.1) or "private". The value "private" 297 is prepared for conveying RawData based on a format that is not 298 listed in the table. This is usually used for conveying data 299 formatted according to an organization's private schema. When the 300 value "private" is used, ext-SpecID element MUST be used. 302 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 303 specifies the format of a structured cybersecurity information. 304 When this element is used, the value of SpecID element must be 305 "private." 307 AttackPatternID: OPTIONAL. STRING. An identifier of an attack 308 pattern to be reported. This attribute SHOULD be used whenever 309 such identifier is available. Both RawData and Reference elements 310 MUST NOT be used when this attribute is used, while either of them 311 MUST be used if this attribute is omitted. 313 The AttackPattern class is composed of the following aggregate 314 classes. 316 RawData: Zero or more. XMLDATA. A complete document that is 317 formatted according to the specification and its version 318 identified by the SpecID/ext-SpecID. When this element is used, 319 writers/senders MUST ensure that the namespace specified by 320 SpecID/ext-SpecID and the one used in the RawData element are 321 consistent; if not, the namespace identified by SpecID SHOULD be 322 prefered, and the inconsistency SHOULD be logged so a human can 323 correct the problem. 325 Reference: Zero or more of iodef:Reference [RFC5070] . This element 326 allows an IODEF document to include a link to a structured 327 information instead of directly embedding it into a RawData 328 element. 330 Platform: Zero or more. An identifier of software platform involved 331 in the specific attack pattern, which is elaborated in 332 Section 4.3.2 . 334 4.3.2. Platform 336 A Platform identifies a software platform. It is recommended that 337 AttackPattern, Vulnerability, Weakness, and System classes contain 338 this elements whenever available. 340 A Platform element is structured as follows. 342 +----------------------+ 343 | Platform | 344 +----------------------+ 345 | ENUM SpecID |<>--(0..*)-[ RawData ] 346 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 347 | STRING PlatformID | 348 +----------------------+ 350 Figure 3: Platform class 352 This class has the following attributes. 354 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 355 as that of the AttackPattern class (Section 4.3.1) . 357 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 358 same as that of the AttackPattern class (Section 4.3.1) . 360 PlatformID: OPTIONAL. STRING. An identifier of a platform to be 361 reported. This attribute SHOULD be used whenever such identifier 362 is available. Both RawData and Reference elements MUST NOT be 363 used when this attribute is used, while either of them MUST be 364 used if this attribute is omitted. 366 This class is composed of the following aggregate classes. 368 RawData: Zero or more. XMLDATA. The meaning of this element is the 369 same as that of the AttackPattern class (Section 4.3.1) . 371 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 372 of this element is the same as that of the AttackPattern class 373 (Section 4.3.1) . 375 4.3.3. Vulnerability 377 A Vulnerability consists of an extension to the 378 Incident.Method.AdditionalData element with a dtype of "xml". The 379 extension describes the (candidate) vulnerabilities of incidents or 380 events. 382 It is recommended that Method class SHOULD contain one or more of the 383 extension elements whenever available. 385 A Vulnerability element is structured as follows. 387 +------------------------+ 388 | Vulnerability | 389 +------------------------+ 390 | ENUM SpecID |<>--(0..*)-[ RawData ] 391 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 392 | STRING VulnerabilityID |<>--(0..*)-[ Platform ] 393 | |<>--(0..*)-[ Scoring ] 394 +------------------------+ 396 Figure 4: Vulnerability class 398 This class has the following attributes. 400 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 401 as that of the AttackPattern class (Section 4.3.1) . 403 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 404 same as that of the AttackPattern class (Section 4.3.1) . 406 VulnerabilityID: OPTIONAL. STRING. An identifier of a 407 vulnerability to be reported. This attribute SHOULD be used 408 whenever such identifier is available. Both RawData and Reference 409 elements MUST NOT be used when this attribute is used, while 410 either of them MUST be used if this attribute is omitted. 412 This class is composed of the following aggregate classes. 414 RawData: Zero or more. XMLDATA. The meaning of this element is the 415 same as that of the AttackPattern class (Section 4.3.1) . 417 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 418 of this element is the same as that of the AttackPattern class 419 (Section 4.3.1) . 421 Platform: Zero or more. An identifier of software platform affected 422 by the vulnerability, which is elaborated in Section 4.3.2 . 424 Scoring: Zero or more. An indicator of the severity of the 425 vulnerability, such as CVSS and CCSS scores, which is elaborated 426 in Section 4.3.4 . Some of the structured information may include 427 scores within it. In this case, the Scoring element SHOULD NOT be 428 used since the RawData element contains the scores. If a reader/ 429 receiver detects scores in both RawData and Scoring elements and 430 their inconsistency, it SHOULD prefer the scores derived from the 431 RawData element, and SHOULD log the inconsistency so a human can 432 correct the problem. 434 4.3.4. Scoring 436 A Scoring class describes the scores of the severity in terms of 437 security. It is recommended that Vulnerability and Weakness classes 438 contain the elements whenever available. 440 A Scoring class is structured as follows. 442 +----------------------+ 443 | Scoring | 444 +----------------------+ 445 | ENUM SpecID |<>---------[ ScoreSet ] 446 | STRING ext-SpecID | 447 +----------------------+ 448 Figure 5: Scoring class 450 This class has two attributes. 452 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 453 as that of the AttackPattern class (Section 4.3.1) . 455 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 456 same as that of the AttackPattern class (Section 4.3.1) . 458 This class is composed of an aggregate class. 460 ScoreSet: One. XMLDATA. A complete document that is formatted 461 according to the specification and its version identified by the 462 SpecID/ext-SpecID. This element includes a set of score 463 information. When this element is used, writers/senders MUST 464 ensure that the namespace specified by SpecID/ext-SpecID and the 465 one used in the RawData element are consistent; if not, the 466 namespace identified by SpecID SHOULD be prefered, and the 467 inconsistency SHOULD be logged so a human can correct the problem. 469 Writers/senders MUST ensure the specification name and version 470 identified by the SpecID are consistent with the contents of the 471 Score; if a reader/receiver detects an inconsistency, it SHOULD 472 prefer the specification name and version derived from the content, 473 and SHOULD log the inconsistency so a human can correct the problem. 475 4.3.5. Weakness 477 A Weakness consists of an extension to the 478 Incident.Method.AdditionalData element with a dtype of "xml". The 479 extension describes the weakness types of incidents or events. 481 It is recommended that Method class SHOULD contain one or more of the 482 extension elements whenever available. 484 A Weakness element is structured as follows. 486 +----------------------+ 487 | Weakness | 488 +----------------------+ 489 | ENUM SpecID |<>--(0..*)-[ RawData ] 490 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 491 | STRING WeaknessID |<>--(0..*)-[ Platform ] 492 | |<>--(0..*)-[ Scoring ] 493 +----------------------+ 494 Figure 6: Weakness class 496 This class has the following attributes. 498 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 499 as that of the AttackPattern class (Section 4.3.1) . 501 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 502 same as that of the AttackPattern class (Section 4.3.1) . 504 WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be 505 reported. This attribute SHOULD be used whenever such identifier 506 is available/ Both RawData and Reference elements MUST NOT be used 507 when this attribute is used, while either of them MUST be used if 508 this attribute is omitted. 510 This class is composed of the following aggregate classes. 512 RawData: Zero or more. XMLDATA. The meaning of this element is the 513 same as that of the AttackPattern class (Section 4.3.1) . 515 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 516 of this element is the same as that of the AttackPattern class 517 (Section 4.3.1) . 519 Platform: Zero or more. An identifier of software platform affected 520 by the weakness, which is elaborated in Section 4.3.2 . 522 Scoring: Zero or more. An indicator of the severity of the 523 weakness, such as CWSS score, which is elaborated in Section 4.3.4 524 . 526 4.3.6. EventReport 528 An EventReport consists of an extension to the 529 Incident.EventData.Record.RecordData.RecordItem element with a dtype 530 of "xml". The extension embeds structured event reports. 532 It is recommended that RecordItem class SHOULD contain one or more of 533 the extension elements whenever available. 535 An EventReport element is structured as follows. 537 +----------------------+ 538 | EventReport | 539 +----------------------+ 540 | ENUM SpecID |<>--(0..*)-[ RawData ] 541 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 542 | STRING EventID | 543 +----------------------+ 545 Figure 7: EventReport class 547 This class has the following attributes. 549 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 550 as that of the AttackPattern class (Section 4.3.1) . 552 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 553 same as that of the AttackPattern class (Section 4.3.1) . 555 EventID: OPTIONAL. STRING. An identifier of an event to be 556 reported. This attribute SHOULD be used whenever such identifier 557 is available. Both RawData and Reference elements MUST NOT be 558 used when this attribute is used, while either of them MUST be 559 used if this attribute is omitted. 561 This class is composed of three aggregate classes. 563 RawData: Zero or more. XMLDATA. The meaning of this element is the 564 same as that of the AttackPattern class (Section 4.3.1) . 566 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 567 of this element is the same as that of the AttackPattern class 568 (Section 4.3.1) . 570 This class MUST contain at least one of RawData or Reference 571 elements. Writers/senders MUST ensure the specification name and 572 version identified by the SpecID are consistent with the contents of 573 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 574 prefer the specification name and version derived from the content, 575 and SHOULD log the inconsistency so a human can correct the problem. 577 4.3.7. Verifcation 579 A Verification consists of an extension to the 580 Incident.AdditionalData element with a dtype of "xml". The extension 581 elements describes incident on vefifying incidents. 583 A Verification class is structured as follows. 585 +----------------------+ 586 | Verification | 587 +----------------------+ 588 | ENUM SpecID |<>--(0..*)-[ RawData ] 589 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 590 | STRING VerificationID| 591 +----------------------+ 593 Figure 8: Verification class 595 This class has the following attributes. 597 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 598 as that of the AttackPattern class (Section 4.3.1) . 600 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 601 same as that of the AttackPattern class (Section 4.3.1) . 603 VerificationID: OPTIONAL. STRING. An identifier of an check item 604 to be reported. This attribute SHOULD be used whenever such 605 identifier is available. Both RawData and Reference elements MUST 606 NOT be used when this attribute is used, while either of them MUST 607 be used if this attribute is omitted. 609 This class is composed of two aggregate classes. 611 RawData: Zero or more. XMLDATA. The meaning of this element is the 612 same as that of the AttackPattern class (Section 4.3.1) . 614 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 615 of this element is the same as that of the AttackPattern class 616 (Section 4.3.1) . 618 This class MUST contain at least either of RawData and Reference 619 elements. Writers/senders MUST ensure the specification name and 620 version identified by the SpecID are consistent with the contents of 621 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 622 prefer the specification name and version derived from the content, 623 and SHOULD log the inconsistency so a human can correct the problem. 625 4.3.8. Remediation 627 A Remediation consists of an extension to the Incident.AdditionalData 628 element with a dtype of "xml". The extension elements describes 629 incident remediation information including instructions. 631 It is recommended that Incident class SHOULD contain one or more of 632 this extension elements whenever available. 634 A Remediation class is structured as follows. 636 +----------------------+ 637 | Remediation | 638 +----------------------+ 639 | ENUM SpecID |<>--(0..*)-[ RawData ] 640 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 641 | String RemediationID | 642 +----------------------+ 644 Figure 9: Remediation class 646 This class has the following attributes. 648 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 649 as that of the AttackPattern class (Section 4.3.1) . 651 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 652 same as that of the AttackPattern class (Section 4.3.1) . 654 RemediationID: OPTIONAL. STRING. An identifier of a remediation 655 information to be reported. This attribute SHOULD be used 656 whenever such identifier is available. Both RawData and Reference 657 elements MUST NOT be used when this attribute is used, while 658 either of them MUST be used if this attribute is omitted. 660 This class is composed of two aggregate classes. 662 RawData: Zero or more. XMLDATA. The meaning of this element is the 663 same as that of the AttackPattern class (Section 4.3.1) . 665 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 666 of this element is the same as that of the AttackPattern class 667 (Section 4.3.1) . 669 This class MUST contain at least either of RawData and Reference 670 elements. Writers/senders MUST ensure the specification name and 671 version identified by the SpecID are consistent with the contents of 672 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 673 prefer the specification name and version derived from the content, 674 and SHOULD log the inconsistency so a human can correct the problem. 676 5. Mandatory to Implement features 678 The implementation of this draft MUST be capable of sending and 679 receiving the XML conforming to the specification listed in the 680 initial IANA table described in Section 4.1, i.e., MMDEF version 1.2, 681 without error. 683 The receiver MUST be capable of validating received XML documents 684 that are embedeed inside that against their schemata. Note that the 685 receiver can look up the namespace in the IANA table to understand 686 what specifications the embedded XML documents follows. 688 This section provides an XML comformant to this draft, and a scehma 689 for that. 691 Note that the schema of MMDEF version 1.2 is found in Section 10. 693 5.1. An Example XML 695 An example IODEF document for checking implementation's MTI 696 conformity is provided here. The document carries MMDEF metadata. 697 Note that the metadata is generated by genMMDEF [MMDEF] with EICAR 698 [EICAR] files. Implementations of this specification must be capable 699 of parsing the example XML since MMDEF is specified as the draft's 700 MTI specification. 702 703 708 709 189493 710 2013-06-18T23:19:24+00:00 711 a candidate security incident 712 713 714 715 716 A candidate attack event 717 718 720 721 726 N/A 727 MMDEF Generation Script 728 Test MMDEF v1.2 file generated using genMMDEF 729 730 2013-03-23T15:12:50.726000 731 732 733 6ce6f415d8475545be5ba114f208b0ff 734 da39a3ee5e6b4b0d3255bfef95601890afd80709 735 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b9 736 34ca495991b7852b855 737 cf83e1357eefb8bdf1542850d66d8007d620e4050b571 738 5dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d287 739 7eec2f63b931bd47417a81a538327af927da3e 740 741 184 742 eicar_com.zip 743 application/zip 744 745 746 44d88612fea8a8f36de82e1278abb02f 747 3395856ce81f2b7382dee72602f798b642f14140 748 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe 749 2a2c4538aabf651fd0f 750 cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4 751 e565e68847223b8e6b85cb48f3afad842726d99239c9e 752 36505c64b0dc9a061d9e507d833277ada336ab 753 754 68 755 1750191932 756 eicar.com 757 eicar.com 758 759 760 761 762 763 764 file[@id="6ce6f415d8475545be5ba114f208b0ff"] 765 766 767 768 file[@id="44d88612fea8a8f36de82e1278abb02f"] 769 770 771 2013-03-23T15:12:50.744000 772 773 774 775 776 777 778 779 iodef-sci.example.com 780 iodef-sci.example-com 781 782 contact@csirt.example.com 783 784 785 786 787 788
192.0.2.200
789 57 790 791 792 793 794
192.0.2.16/28
795 796 797 80 798 799 800 801 802 803 804 805 807 5.2. An XML Schema for the Extension 809 An XML Schema describing the elements defined in this draft is given 810 here. Any XMLs compliant to this draft including the ones in 811 Section 5.1 and Section 11 should be verified against this schema by 812 automated tools. 814 816 822 825 826 827 828 829 831 832 834 835 836 837 838 839 840 842 843 844 845 847 848 849 851 852 854 855 856 857 858 860 862 863 866 867 868 870 872 873 875 876 877 878 879 881 883 884 886 888 889 890 892 894 895 897 898 899 900 901 903 905 906 908 910 911 912 915 917 918 920 921 922 923 924 926 928 929 930 931 933 935 936 938 939 940 941 942 944 946 947 948 949 951 953 954 956 957 958 959 960 962 964 965 966 967 969 971 972 974 975 976 977 978 980 982 983 984 985 987 989 990 992 994 6. Security Considerations 996 This document specifies a format for encoding a particular class of 997 security incidents appropriate for exchange across organizations. As 998 merely a data representation, it does not directly introduce security 999 issues. However, it is guaranteed that parties exchanging instances 1000 of this specification will have certain concerns. For this reason, 1001 the underlying message format and transport protocol used MUST ensure 1002 the appropriate degree of confidentiality, integrity, and 1003 authenticity for the specific environment. 1005 Organizations that exchange data using this document are URGED to 1006 develop operating procedures that document the following areas of 1007 concern. 1009 6.1. Transport-Specific Concerns 1011 The underlying messaging format and protocol used to exchange 1012 instances of the IODEF MUST provide appropriate guarantees of 1013 confidentiality, integrity, and authenticity. The use of a 1014 standardized security protocol is encouraged. The Real-time Inter- 1015 network Defense (RID) protocol [RFC6045] and its associated transport 1016 binding [RFC6046] provide such security. 1018 The critical security concerns are that these structured information 1019 may be falsified or they may become corrupt during transit. In areas 1020 where transmission security or secrecy is questionable, the 1021 application of a digital signature and/or message encryption on each 1022 report will counteract both of these concerns. We expect that each 1023 exchanging organization will determine the need, and mechanism, for 1024 transport protection. 1026 7. IANA Considerations 1028 This document uses URNs to describe XML namespaces and XML schemata 1029 [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism 1030 described in [RFC3688] . 1032 Registration request for the IODEF structured cybersecurity 1033 information extension namespace: 1035 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 1037 Registrant Contact: Refer here to the authors' addresses section 1038 of the document. 1040 XML: None 1042 Registration request for the IODEF structured cybersecurity 1043 information extension XML schema: 1045 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 1047 Registrant Contact: Refer here to the authors' addresses section 1048 of the document. 1050 XML: Refer here to the XML Schema in the appendix of the document. 1052 This memo creates the following registry for IANA to manage: 1054 Name of the registry: "IODEF Structured Cyber Security Information 1055 Specifications" 1057 Namespace details: A registry entry for a Structured Cyber 1058 Security Information Specification (SCI specification) consists 1059 of: 1061 Namespace: A URI [RFC3986] that is the XML namespace name used 1062 by the registered SCI specification. 1064 Specification Name: A string containing the spelled-out name of 1065 the SCI specification in human-readable form. 1067 Reference URI: A list of one or more of the URIs [RFC3986] from 1068 which the registered specification can be obtained. The 1069 registered specification MUST be readily and publicly available 1070 from that URI. 1072 Applicable Classes: A list of one or more of the Extended 1073 Classes specified in Section 4.3 of this document. The 1074 registered SCI specification MUST only be used with the 1075 Extended Classes in the registry entry. 1077 Information that must be provided to assign a new value: The above 1078 list of information. 1080 Fields to record in the registry: Namespace/Specification Name/ 1081 Version/Applicable Classes. 1083 Initial registry contents: none 1085 Allocation Policy: Expert Review [RFC5226] and Specification 1086 Required [RFC5226] . 1088 The Designated Expert is expected to consult with the mile (Managed 1089 Incident Lightweight Exchange) working group or its successor if any 1090 such WG exists (e.g., via email to the working group's mailing list). 1091 The Designated Expert is expected to retrieve the SCI specification 1092 from the provided URI in order to check the public availability of 1093 the specification and verify the correctness of the URI. An 1094 important responsibility of the Designated Expert is to ensure that 1095 the registered Applicable Classes are appropriate for the registered 1096 SCI specification. 1098 8. Acknowledgment 1100 We would like to acknowledge Mr. David Black from EMC, who kindly 1101 provided generous support, especially on the IANA registry issues. 1102 We also would like to thank Jon Baker from MITRE, Paul Cichonski from 1103 NIST, Panos Kampanakis from CISCO, Ivan Kirillov from MITRE, Robert 1104 Martin from MITRE, Kathleen Moriarty from EMC, Lagadec Philippe from 1105 NATO, Shuhei Yamaguchi from NICT, Anthony Rutkowski from Yaana 1106 Technology, Brian Trammel from CERT/NetSA, David Waltermire from 1107 NIST, and James Wendorf from IEEE, for their sincere discussion and 1108 feedback on this document. 1110 9. Appendix I: Candidate Specifications for the IANA Table 1112 This draft defined the structure of the IANA table in Section 4.1 . 1113 Though the management of the table is up to IANA, this appendix 1114 provides candidate entries. Note that OVAL and CVE are registered 1115 trademarks, and CAPEC, CCE, CEE, CPE, CWE, CWSS, MAEC, and OCIL are 1116 trademarks, of The MITRE Corporation. 1118 1. CAPEC 1.6 1120 Namespace: http://capec.mitre.org/observables 1121 Specification Name: Common Attack Pattern Enumeration and 1122 Classification 1123 Version: 1.6 1124 Reference URI: http://capec.mitre.org/ 1125 Applicable Classes: AttackPattern 1127 2. CCE 5.0 1129 Namespace: http://cce.mitre.org 1130 Specification Name: Common Configuration Enumeration 1131 Version: 5.0 1132 Reference URI: http://cce.mitre.org/ 1133 Applicable Classes: Verification 1135 3. CCSS 1.0 1137 Namespace: N/A 1138 Specification Name: Common Configuration Scoring System 1139 Version: 1.0 1140 Reference URI: http://csrc.nist.gov/publications/PubsNISTIRs.html 1141 #NIST-IR-7502 1142 Applicable Classes: Scoring 1143 4. CEE 1.0 alpha 1145 Namespace: http://cee.mitre.org 1146 Specification Name: Common Event Expression 1147 Version: 1.0 alpha 1148 Reference URI: http://cee.mitre.org/ 1149 Applicable Classes: EventReport 1151 5. CPE 2.3 Language 1153 Namespace: http://cpe.mitre.org/language/2.0 1154 Specification Name: Common Platform Enumeration Reference 1155 Version: 2.3 1156 Reference URI: http://scap.nist.gov/specifications/cpe/, 1157 http://csrc.nist.gov/publications/PubsNISTIRs.html 1158 #NIST-IR-7695 1159 Applicable Classes: Platform 1161 6. CPE 2.3 Dictionary 1163 Namespace: http://cpe.mitre.org/dictionary/2.0 1164 Specification Name: Common Platform Enumeration Dictionary 1165 Version: 2.3 1166 Reference URI: http://scap.nist.gov/specifications/cpe/, 1167 http://csrc.nist.gov/publications/PubsNISTIRs.html 1168 #NIST-IR-7697 1169 Applicable Classes: Platform 1171 7. CVE 1.0 1173 Namespace: http://cve.mitre.org/cve/downloads/1.0 1174 Specification Name: Common Vulnerability and Exposures 1175 Version: 1.0 1176 Reference URI: http://cve.mitre.org/ 1177 Applicable Classes: Vulnerability 1179 8. CVRF 1.0 1180 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 1181 Specification Name: Common Vulnerability Reporting Format 1182 Version: 1.0 1183 Reference URI: http://www.icasi.org/cvrf 1184 Applicable Classes: Vulnerability 1186 9. CVSS 2.0 1188 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 1189 Specification Name: Common Vulnerability Scoring System 1190 Version: 2 1191 Reference URI: http://www.first.org/cvss 1192 Applicable Classes: Scoring 1194 10. CWE 5.0 1196 Namespace: N/A 1197 Specification Name: Common Weakness Enumeration 1198 Version: 5.1 1199 Reference URI: http://cwe.mitre.org/ 1200 Applicable Classes: Weakness 1202 11. CWSS 0.8 1204 Namespace: N/A 1205 Specification Name: Common Weakness Scoring System 1206 Version: 0.8 1207 Reference URI: http://cwe.mitre.org/cwss/ 1208 Applicable Classes: Scoring 1210 12. MAEC 2.0 1212 Namespace: http://maec.mitre.org/XMLSchema/maec-core-2 1213 Specification Name: Malware Attribute Enumeration and Characterization 1214 Version: 2.0 1215 Reference URI: http://maec.mitre.org/ 1216 Applicable Classes: EventReport, AttackPattern 1217 13. OCIL 2.0 1219 Namespace: http://scap.nist.gov/schema/ocil/2.0 1220 Specification Name: Open Checklist Interactive Language 1221 Version: 2.0 1222 Reference URI: http://scap.nist.gov/specifications/ocil/, 1223 http://csrc.nist.gov/publications/PubsNISTIRs.html 1224 #NIST-IR-7692 1225 Applicable Classes: Verification 1227 14. OVAL 5.10.1 Definitions 1229 Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 1230 Specification Name: Open Vulnerability and Assessment Language 1231 Version: 5.10.1 1232 Reference URI: http://oval.mitre.org/ 1233 Applicable Classes: Verification 1235 15. OVAL 5.10.1 Results 1237 Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 1238 Specification Name: Open Vulnerability and Assessment Language 1239 Version: 5.10.1 1240 Reference URI: http://oval.mitre.org/ 1241 Applicable Classes: Verification 1243 16. OVAL 5.10.1 Common 1245 Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 1246 Specification Name: Open Vulnerability and Assessment Language 1247 Version: 5.10.1 1248 Reference URI: http://oval.mitre.org/ 1249 Applicable Classes: Verification 1251 17. XCCDF 1.2 1253 Namespace: http://checklists.nist.gov/xccdf/1.2 1254 Specification Name: Extensible Configuration Checklist Description 1255 Format 1256 Version: 1.2 1257 Reference URI: http://scap.nist.gov/specifications/xccdf/, 1258 http://csrc.nist.gov/publications/PubsNISTIRs.html 1259 #NIST-IR-7275-r4 1260 Applicable Classes: Verification 1262 10. Appendix II: MMDEF version 1.2 scheema 1264 This draft identified MMDEF version 1.2 as its MTI, and its schema 1265 (without annotations) is provided here. 1267 1268 1273 1274 1275 1276 1277 1278 1280 1281 1282 1283 1284 1286 1287 1288 1289 1290 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1319 1320 1321 1322 1323 1324 1325 1326 1327 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1351 1352 1353 1354 1355 1356 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1434 1436 1438 1440 1443 1445 1447 1449 1451 1453 1455 1456 1457 1459 1460 1461 1462 1464 1465 1466 1468 1469 1470 1471 1473 1474 1475 1477 1478 1479 1480 1482 1483 1484 1485 1486 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1501 1502 1503 1504 1505 1506 1507 1508 1509 1511 1513 1515 1517 1519 1520 1522 1524 1526 1527 1528 1530 1531 1532 1533 1534 1535 1536 1538 1539 1540 1542 1544 1545 1546 1548 1549 1550 1551 1552 1553 1554 1556 1557 1558 1559 1560 1561 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1576 1577 1578 1579 1580 1581 1582 1584 1585 1586 1587 1588 1589 1590 1592 1593 1594 1595 1596 1597 1599 1600 1601 1602 1603 1604 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1617 1619 1620 1621 1622 1623 1625 1626 1627 1628 1630 1631 1632 1633 1634 1635 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1667 1668 1669 1670 1671 1673 1674 1675 1676 1677 1678 1679 1681 1682 1683 1684 1685 1686 1688 1689 1690 1691 1692 1693 1694 1695 1697 1698 1699 1700 1701 1702 1704 1705 1706 1708 1709 1710 1711 1713 1714 1715 1717 1718 1720 1721 1722 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1790 11. Appendix III: An Example XML using Candidate Specifications 1792 This section provides an example of an incident encoded in the IODEF. 1793 This do not necessarily represent the only way to encode a particular 1794 incident. This example reports an attack to a CSIRT and is extended 1795 from the example described in [RFC5070] . It uses identifiers whose 1796 dictionary follows CVE 1.0 schema, and it aembeds XML following CEE 1797 0.6. Though these specifications are not listed in the IANA table at 1798 this moment, this section shows the example to demonstrate the 1799 usability of the draft. 1801 1802 1807 1808 189493 1809 2001-09-13T23:19:24+00:00 1810 Incident report in company xx 1811 1812 1813 1814 1815 An identifier of a vulnerability is embedded 1816 1817 1818 1821 1822 1823 1824 Example.com CSIRT 1825 example-com 1826 contact@csirt.example.com 1827 1828 1829 1830 1831 1832
192.0.2.200
1833 57 1834 1835 1836 1837 1838
192.0.2.16/28
1839 1840 1841 80 1842 1843 1844 1847 1848 1849 1850 1851 1852 1853 1854 1855 2001-09-13T18:11:21+02:00 1856 a Web-server event record 1857 1858 1859 1860 1862 1863 system.example.com 1864 auth 1865 1866 application 1867 123 1868 10 1869 login 1870 app 1871 account 1872 web 1873 success 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 2001-09-14T08:19:01+00:00 1886 Notification sent to 1887 constituency-contact@192.0.2.200 1888 1889 1890 1891 1893 12. References 1895 12.1. Normative References 1897 [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, 1898 "Malware Metadata Exchange Format". 1900 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1901 Requirement Levels", BCP 14, RFC 2119, March 1997. 1903 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1904 Resource Identifier (URI): Generic Syntax", STD 66, 1905 RFC 3986, January 2005. 1907 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1908 Object Description Exchange Format", RFC 5070, 1909 December 2007. 1911 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1912 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1913 May 2008. 1915 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1916 RFC 6045, November 2010. 1918 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1919 Inter-network Defense (RID) Messages", RFC 6046, 1920 November 2010. 1922 [EICAR] European Expert Group for IT-Security, "Anti-Malware 1923 Testfile", 2003. 1925 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1926 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1927 Edition)", W3C Recommendation, November 2008. 1929 [XMLschemaPart1] 1930 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1931 "XML Schema Part 1: Structures Second Edition", 1932 W3C Recommendation, October 2004. 1934 [XMLschemaPart2] 1935 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1936 Second Edition", W3C Recommendation, October 2004. 1938 [XMLNames] 1939 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1940 Thomson, ""Namespaces in XML (Third Edition)", 1941 W3C Recommendation, December 2009. 1943 12.2. Informative References 1945 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1946 Internet: Timestamps", RFC 3339, July 2002. 1948 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1949 Text on Security Considerations", BCP 72, RFC 3552, 1950 July 2003. 1952 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1953 January 2004. 1955 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1956 October 2008. 1958 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1959 Uniform Resource Identifiers (URI) Dynamic Delegation 1960 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1961 March 2011. 1963 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1964 and Classification (CAPEC)". 1966 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1967 (CCE)". 1969 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1970 Scoring System (CCSS)", NIST Interagency Report 7502, 1971 December 2010. 1973 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1975 [CPE] National Institute of Standards and Technology, "Common 1976 Platform Enumeration", June 2011. 1978 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1979 (CVE)". 1981 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1983 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1984 Common Vulnerability Scoring System (CVSS) and Its 1985 Applicability to Federal Agency Systems". 1987 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1988 (CWE)". 1990 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1991 (CWSS)". 1993 [MAEC] The MITRE Corporation, "Malware Attribute Enumeration and 1994 Characterization". 1996 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1997 Open Checklist Interactive Language (OCIL) Version 2.0", 1998 April 2011. 2000 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 2001 Language (OVAL)". 2003 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 2004 Halbardier, "The Technical Specification for the Security 2005 Content Automation Protocol (SCAP): SCAP Version 1.2", 2006 NIST Special Publication 800-126 Revision 2, 2007 September 2011. 2009 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 2010 and Neal Ziring, "Specification for the Extensible 2011 Configuration Checklist Description Format (XCCDF) version 2012 1.2 (DRAFT)", July 2011. 2014 Authors' Addresses 2016 Takeshi Takahashi 2017 National Institute of Information and Communications Technology 2018 4-2-1 Nukui-Kitamachi Koganei 2019 184-8795 Tokyo 2020 Japan 2022 Phone: +80 423 27 5862 2023 Email: takeshi_takahashi@nict.go.jp 2025 Kent Landfield 2026 McAfee, Inc 2027 5000 Headquarters Drive 2028 Plano, TX 75024 2029 USA 2031 Email: Kent_Landfield@McAfee.com 2033 Thomas Millar 2034 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 2035 245 Murray Lane SW, Building 410, MS #732 2036 Washington, DC 20598 2037 USA 2039 Phone: +1 888 282 0870 2040 Email: thomas.millar@us-cert.gov 2042 Youki Kadobayashi 2043 Nara Institute of Science and Technology 2044 8916-5 Takayama, Ikoma 2045 630-0192 Nara 2046 Japan 2048 Email: youki-k@is.aist-nara.ac.jp