idnits 2.17.1 draft-ietf-mile-sci-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC5070]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 12, 2013) is 4062 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: 'MMDEF' is defined on line 1291, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 1314, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1324, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1327, but no explicit reference was found in the text == Unused Reference: 'CAPEC' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: 'CCE' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: 'CCSS' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: 'CEE' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'CPE' is defined on line 1344, but no explicit reference was found in the text == Unused Reference: 'CVE' is defined on line 1347, but no explicit reference was found in the text == Unused Reference: 'CVRF' is defined on line 1350, but no explicit reference was found in the text == Unused Reference: 'CVSS' is defined on line 1352, but no explicit reference was found in the text == Unused Reference: 'CWE' is defined on line 1356, but no explicit reference was found in the text == Unused Reference: 'CWSS' is defined on line 1359, but no explicit reference was found in the text == Unused Reference: 'OCIL' is defined on line 1362, but no explicit reference was found in the text == Unused Reference: 'OVAL' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'SCAP' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'XCCDF' is defined on line 1375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6045 (Obsoleted by RFC 6545) ** Obsolete normative reference: RFC 6046 (Obsoleted by RFC 6546) -- Possible downref: Non-RFC (?) normative reference: ref. 'MMDEF' -- 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 (==), 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: August 16, 2013 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Feb 12, 2013 12 IODEF-extension to support structured cybersecurity information 13 draft-ietf-mile-sci-06.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 August 16, 2013. 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 . . . . . . . . . . . . . . . . . . . . . 5 64 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 15 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9. Appendix I: XML Schema Definition for Extension . . . . . . . 18 78 10. Appendix II: Candidate Specifications for the IANA Table . . . 23 79 11. Appendix III: An XML Example . . . . . . . . . . . . . . . . . 27 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 85 1. Introduction 87 The number of cyber attacks is growing day by day, and incident 88 information needs to be reported, exchanged, and shared among 89 organizations in order to cope with the situation. IODEF is one of 90 the tools enabling such exchange, and is already in use. 92 To efficiently run cybersecurity operations, these exchanged 93 information needs to be machine-readable. IODEF provides a 94 structured means to describe the information, but it needs to embed 95 various non-structured such information in order to convey detailed 96 information. Further structure within IODEF increases IODEF 97 documents' machine-readability and thus facilitates streamlining 98 cybersecurity operations. 100 On the other hand, there exist various other activities facilitating 101 detailed and structured description of cybersecurity information, as 102 listed in Section 10. Since such structured description facilitates 103 cybersecurity operations, it would be beneficial to embed and convey 104 these information inside IODEF document. 106 To enable that, this document extends the IODEF to embed and convey 107 various structured cybersecurity information, with which 108 cybersecurity operations can be facilitated. Since IODEF defines a 109 flexible and extensible format and supports a granular level of 110 specificity, this document defines an extension to IODEF instead of 111 defining a new report format. For clarity, and to eliminate 112 duplication, only the additional structures necessary for describing 113 the exchange of such structured information are provided. 115 2. Terminology 117 The terminology used in this document follows the one defined in RFC 118 5070 [RFC5070]. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Applicability 126 To maintain cybersecurity, organization needs to exchange 127 cybersecurity information, which includes the following information: 128 attack pattern, platform information, vulnerability and weakness, 129 countermeasure instruction, computer event log, and the severity. 131 IODEF provides a scheme to describe and exchange such information 132 among interested parties. However, it does not define the detailed 133 format to describe such information. 135 On the other hand, there already exist structured and detailed 136 formats for describing those information and facilitating such 137 exchange. Major of them are listed in Section 10. By embedding them 138 into the IODEF document, the document can convey more detailed 139 contents to the receivers, and the document can be easily reused. 141 These structured cybersecurity information facilitates cybersecurity 142 operation at the receiver side. Since the information is machine- 143 readable, the data can be processed by computers. That expedites the 144 automation of cybersecurity operations 146 For instance, an organization wishing to report a security incident 147 wants to describe what vulnerability was exploited. Then the sender 148 can simply use IODEF, where an XML [XML1.0]-based attack pattern 149 record that follows the syntax and vocabulary defined by an industry 150 specification is embedded instead of describing everything in free 151 format text. Receiver can identify the needed details of the attack 152 pattern by looking up some of the XML tags defined by the 153 specification. Receiver can accumulate the attack pattern record in 154 its database and could distribute it to the interested parties if 155 needed, without needing human interventions. 157 Another example is that, when an administrator wishes to check the 158 configuration of host computers in his organization, he may send a 159 query to host computers, which may automatically generate XML-based 160 software configuration information upon receiving thequery by running 161 a software and may embed that to an IODEF document, which is then 162 sent back to the administrator. 164 4. Extension Definition 166 This draft extends IODEF to embed structured cybersecurity 167 information by introducing new classes, with which these information 168 can be embedded inside IODEF document as element contents of 169 AdditionalData and RecordItem classes. 171 4.1. IANA Table for Structured Cybersecurity Information 173 This extension embeds structured cybersecurity information defined by 174 the other specifications. The list of supported specifications is 175 managed by IANA, and this draft defines the needed field for the 176 list's entry. 178 Each entry has namespace [XMLNames], specification name, version, 179 reference URI, and applicable classes for each specification. 180 Arbitrary URIs that may help readers to understand the specification 181 could be embedded inside the Reference URI field, but it is 182 recommended that standard/informational URI describing the 183 specification is prepared and is embedded here. 185 The initial IANA table has only one entry, as below. 187 Namespace: http://xml/metadataSharing.xsd 188 Specification Name: Malware Metadata Exchange Format 189 Version: 1.2 190 Reference URI: http://standards.ieee.org/develop/ 191 indconn/icsg/mmdef.html 192 Applicable Classes: AttackPattern 194 The table is to be managed by IANA using the Expert Review [RFC5226] 195 and Specification Required [RFC5226] allocation policies as further 196 specified in Section 7. 198 The SpecID attributes of extended classes (Section 4.3) must allow 199 the values of the specifications' namespace fields, but otherwise, 200 implementations are not required to support all specifications of the 201 IANA table and may choose which specifications to support, though the 202 specification listed in the initial table needs to be minimally 203 supported, as described in Section 5. In case an implementation 204 received a data it does not support, it may expand its functionality 205 by looking up the IANA table or notify the sender of its inability to 206 parse the data by using any means defined outside the scope of this 207 specification. 209 4.2. Extended Data Type: XMLDATA 211 This extension inherits all of the data types defined in the IODEF 212 model. One data type is added: XMLDATA. An embedded XML data is 213 represented by the XMLDATA data type. This type is defined as the 214 extension to the iodef:ExtensionType [RFC5070], whose dtype attribute 215 is set to "xml." 217 4.3. Extended Classes 219 The IODEF Incident element [RFC5070] is summarized below. It is 220 expressed in Unified Modeling Language (UML) syntax as used in the 221 IODEF specification. The UML representation is for illustrative 222 purposes only; elements are specified in XML as defined in Appendix 223 A. 225 +--------------------+ 226 | Incident | 227 +--------------------+ 228 | ENUM purpose |<>---------[IncidentID] 229 | STRING ext-purpose |<>--{0..1}-[AlternativeID] 230 | ENUM lang |<>--{0..1}-[RelatedActivity] 231 | ENUM restriction |<>--{0..1}-[DetectTime] 232 | |<>--{0..1}-[StartTime] 233 | |<>--{0..1}-[EndTime] 234 | |<>---------[ReportTime] 235 | |<>--{0..*}-[Description] 236 | |<>--{1..*}-[Assessment] 237 | |<>--{0..*}-[Method] 238 | | |<>--[AdditionalData] 239 | | |<>--[AttackPattern] 240 | | |<>--[Vulnerability] 241 | | |<>--[Weakness] 242 | |<>--{1..*}-[Contact] 243 | |<>--{0..*}-[EventData] 244 | | |<>--[Flow] 245 | | | |<>--[System] 246 | | | |<>--[AdditionalData] 247 | | | |<>--[Platform] 248 | | |<>--[Expectation] 249 | | |<>--[Record] 250 | | |<>--[RecordData] 251 | | |<>--[RecordItem] 252 | | |<>--[EventReport] 253 | |<>--{0..1}-[History] 254 | |<>--{0..*}-[AdditionalData] 255 | | |<>--[Verification] 256 | | |<>--[Remediation] 257 +--------------------+ 259 Figure 1: Incident class 261 This extension defines the following seven elements. 263 4.3.1. AttackPattern 265 An AttackPattern consists of an extension to the 266 Incident.Method.AdditionalData element with a dtype of "xml". The 267 extension describes attack patterns of incidents or events. 269 It is recommended that Method class SHOULD contain one or more of the 270 extension elements whenever available. 272 An AttackPattern class is structured as follows. 274 +------------------------+ 275 | AttackPattern | 276 +------------------------+ 277 | ENUM SpecID |<>--(0..*)-[ RawData ] 278 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 279 | STRING AttackPatternID |<>--(0..*)-[ Platform ] 280 +------------------------+ 282 Figure 2: AttackPattern class 284 This class has the following attributes. 286 SpecID: REQUIRED. ENUM. A specification's identifier that 287 specifies the format of a structured cybersecurity information. 288 The value should be chosen from the namespaces [XMLNames] listed 289 in the IANA table (Section 4.1) or "private". The value "private" 290 is prepared for conveying RawData based on a format that is not 291 listed in the table. This is usually used for conveying data 292 formatted according to an organization's private schema. When the 293 value "private" is used, ext-SpecID element MUST be used. 295 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 296 specifies the format of a structured cybersecurity information. 297 When this element is used, the value of SpecID element must be 298 "private." 300 AttackPatternID: OPTIONAL. STRING. An identifier of an attack 301 pattern to be reported. This attribute SHOULD be used whenever 302 such identifier is available. Both RawData and Reference elements 303 MUST NOT be used when this attribute is used, while either of them 304 MUST be used if this attribute is omitted. 306 The AttackPattern class is composed of the following aggregate 307 classes. 309 RawData: Zero or more. XMLDATA. A complete document that is 310 formatted according to the specification and its version 311 identified by the SpecID/ext-SpecID. When this element is used, 312 writers/senders MUST ensure that the namespace specified by 313 SpecID/ext-SpecID and the one used in the RawData element are 314 consistent; if not, the namespace identified by SpecID SHOULD be 315 prefered, and the inconsistency SHOULD be logged so a human can 316 correct the problem. 318 Reference: Zero or more of iodef:Reference [RFC5070]. This element 319 allows an IODEF document to include a link to a structured 320 information instead of directly embedding it into a RawData 321 element. 323 Platform: Zero or more. An identifier of software platform involved 324 in the specific attack pattern, which is elaborated in 325 Section 4.3.2. 327 4.3.2. Platform 329 A Platform identifies a software platform. It is recommended that 330 AttackPattern, Vulnerability, Weakness, and System classes contain 331 this elements whenever available. 333 A Platform element is structured as follows. 335 +----------------------+ 336 | Platform | 337 +----------------------+ 338 | ENUM SpecID |<>--(0..*)-[ RawData ] 339 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 340 | STRING PlatformID | 341 +----------------------+ 343 Figure 3: Platform class 345 This class has the following attributes. 347 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 348 as that of the AttackPattern class (Section 4.3.1). 350 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 351 same as that of the AttackPattern class (Section 4.3.1). 353 PlatformID: OPTIONAL. STRING. An identifier of a platform to be 354 reported. This attribute SHOULD be used whenever such identifier 355 is available. Both RawData and Reference elements MUST NOT be 356 used when this attribute is used, while either of them MUST be 357 used if this attribute is omitted. 359 This class is composed of the following aggregate classes. 361 RawData: Zero or more. XMLDATA. The meaning of this element is the 362 same as that of the AttackPattern class (Section 4.3.1). 364 Reference: Zero or more of iodef:Reference [RFC5070]. The meaning 365 of this element is the same as that of the AttackPattern class 366 (Section 4.3.1). 368 4.3.3. Vulnerability 370 A Vulnerability consists of an extension to the 371 Incident.Method.AdditionalData element with a dtype of "xml". The 372 extension describes the (candidate) vulnerabilities of incidents or 373 events. 375 It is recommended that Method class SHOULD contain one or more of the 376 extension elements whenever available. 378 A Vulnerability element is structured as follows. 380 +------------------------+ 381 | Vulnerability | 382 +------------------------+ 383 | ENUM SpecID |<>--(0..*)-[ RawData ] 384 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 385 | STRING VulnerabilityID |<>--(0..*)-[ Platform ] 386 | |<>--(0..*)-[ Scoring ] 387 +------------------------+ 389 Figure 4: Vulnerability class 391 This class has the following attributes. 393 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 394 as that of the AttackPattern class (Section 4.3.1). 396 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 397 same as that of the AttackPattern class (Section 4.3.1). 399 VulnerabilityID: OPTIONAL. STRING. An identifier of a 400 vulnerability to be reported. This attribute SHOULD be used 401 whenever such identifier is available. Both RawData and Reference 402 elements MUST NOT be used when this attribute is used, while 403 either of them MUST be used if this attribute is omitted. 405 This class is composed of the following aggregate classes. 407 RawData: Zero or more. XMLDATA. The meaning of this element is the 408 same as that of the AttackPattern class (Section 4.3.1). 410 Reference: Zero or more of iodef:Reference [RFC5070]. The meaning 411 of this element is the same as that of the AttackPattern class 412 (Section 4.3.1). 414 Platform: Zero or more. An identifier of software platform affected 415 by the vulnerability, which is elaborated in Section 4.3.2. 417 Scoring: Zero or more. An indicator of the severity of the 418 vulnerability, such as CVSS and CCSS scores, which is elaborated 419 in Section 4.3.4. Some of the structured information may include 420 scores within it. In this case, the Scoring element SHOULD NOT be 421 used since the RawData element contains the scores. If a reader/ 422 receiver detects scores in both RawData and Scoring elements and 423 their inconsistency, it SHOULD prefer the scores derived from the 424 RawData element, and SHOULD log the inconsistency so a human can 425 correct the problem. 427 4.3.4. Scoring 429 A Scoring class describes the scores of the severity in terms of 430 security. It is recommended that Vulnerability and Weakness classes 431 contain the elements whenever available. 433 A Scoring class is structured as follows. 435 +----------------------+ 436 | Scoring | 437 +----------------------+ 438 | ENUM SpecID |<>---------[ ScoreSet ] 439 | STRING ext-SpecID | 440 +----------------------+ 442 Figure 5: Scoring class 444 This class has two attributes. 446 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 447 as that of the AttackPattern class (Section 4.3.1). 449 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 450 same as that of the AttackPattern class (Section 4.3.1). 452 This class is composed of an aggregate class. 454 ScoreSet: One. XMLDATA. A complete document that is formatted 455 according to the specification and its version identified by the 456 SpecID/ext-SpecID. This element includes a set of score 457 information. When this element is used, writers/senders MUST 458 ensure that the namespace specified by SpecID/ext-SpecID and the 459 one used in the RawData element are consistent; if not, the 460 namespace identified by SpecID SHOULD be prefered, and the 461 inconsistency SHOULD be logged so a human can correct the problem. 463 Writers/senders MUST ensure the specification name and version 464 identified by the SpecID are consistent with the contents of the 465 Score; if a reader/receiver detects an inconsistency, it SHOULD 466 prefer the specification name and version derived from the content, 467 and SHOULD log the inconsistency so a human can correct the problem. 469 4.3.5. Weakness 471 A Weakness consists of an extension to the 472 Incident.Method.AdditionalData element with a dtype of "xml". The 473 extension describes the weakness types of incidents or events. 475 It is recommended that Method class SHOULD contain one or more of the 476 extension elements whenever available. 478 A Weakness element is structured as follows. 480 +----------------------+ 481 | Weakness | 482 +----------------------+ 483 | ENUM SpecID |<>--(0..*)-[ RawData ] 484 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 485 | STRING WeaknessID |<>--(0..*)-[ Platform ] 486 | |<>--(0..*)-[ Scoring ] 487 +----------------------+ 489 Figure 6: Weakness class 491 This class has the following attributes. 493 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 494 as that of the AttackPattern class (Section 4.3.1). 496 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 497 same as that of the AttackPattern class (Section 4.3.1). 499 WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be 500 reported. This attribute SHOULD be used whenever such identifier 501 is available/ Both RawData and Reference elements MUST NOT be used 502 when this attribute is used, while either of them MUST be used if 503 this attribute is omitted. 505 This class is composed of the following aggregate classes. 507 RawData: Zero or more. XMLDATA. The meaning of this element is the 508 same as that of the AttackPattern class (Section 4.3.1). 510 Reference: Zero or more of iodef:Reference [RFC5070]. The meaning 511 of this element is the same as that of the AttackPattern class 512 (Section 4.3.1). 514 Platform: Zero or more. An identifier of software platform affected 515 by the weakness, which is elaborated in Section 4.3.2. 517 Scoring: Zero or more. An indicator of the severity of the 518 weakness, such as CWSS score, which is elaborated in 519 Section 4.3.4. 521 4.3.6. EventReport 523 An EventReport consists of an extension to the 524 Incident.EventData.Record.RecordData.RecordItem element with a dtype 525 of "xml". The extension embeds structured event reports. 527 It is recommended that RecordItem class SHOULD contain one or more of 528 the extension elements whenever available. 530 An EventReport element is structured as follows. 532 +----------------------+ 533 | EventReport | 534 +----------------------+ 535 | ENUM SpecID |<>--(0..*)-[ RawData ] 536 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 537 | STRING EventID | 538 +----------------------+ 540 Figure 7: EventReport class 542 This class has the following attributes. 544 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 545 as that of the AttackPattern class (Section 4.3.1). 547 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 548 same as that of the AttackPattern class (Section 4.3.1). 550 EventID: OPTIONAL. STRING. An identifier of an event to be 551 reported. This attribute SHOULD be used whenever such identifier 552 is available. Both RawData and Reference elements MUST NOT be 553 used when this attribute is used, while either of them MUST be 554 used if this attribute is omitted. 556 This class is composed of three aggregate classes. 558 RawData: Zero or more. XMLDATA. The meaning of this element is the 559 same as that of the AttackPattern class (Section 4.3.1). 561 Reference: Zero or more of iodef:Reference [RFC5070]. The meaning 562 of this element is the same as that of the AttackPattern class 563 (Section 4.3.1). 565 This class MUST contain at least one of RawData or Reference 566 elements. Writers/senders MUST ensure the specification name and 567 version identified by the SpecID are consistent with the contents of 568 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 569 prefer the specification name and version derived from the content, 570 and SHOULD log the inconsistency so a human can correct the problem. 572 4.3.7. Verifcation 574 A Verification consists of an extension to the 575 Incident.AdditionalData element with a dtype of "xml". The extension 576 elements describes incident on vefifying incidents. 578 A Verification class is structured as follows. 580 +----------------------+ 581 | Verification | 582 +----------------------+ 583 | ENUM SpecID |<>--(0..*)-[ RawData ] 584 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 585 | STRING VerificationID| 586 +----------------------+ 588 Figure 8: Verification class 590 This class has the following attributes. 592 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 593 as that of the AttackPattern class (Section 4.3.1). 595 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 596 same as that of the AttackPattern class (Section 4.3.1). 598 VerificationID: OPTIONAL. STRING. An identifier of an check item 599 to be reported. This attribute SHOULD be used whenever such 600 identifier is available. Both RawData and Reference elements MUST 601 NOT be used when this attribute is used, while either of them MUST 602 be used if this attribute is omitted. 604 This class is composed of two aggregate classes. 606 RawData: Zero or more. XMLDATA. The meaning of this element is the 607 same as that of the AttackPattern class (Section 4.3.1). 609 Reference: Zero or more of iodef:Reference [RFC5070]. The meaning 610 of this element is the same as that of the AttackPattern class 611 (Section 4.3.1). 613 This class MUST contain at least either of RawData and Reference 614 elements. Writers/senders MUST ensure the specification name and 615 version identified by the SpecID are consistent with the contents of 616 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 617 prefer the specification name and version derived from the content, 618 and SHOULD log the inconsistency so a human can correct the problem. 620 4.3.8. Remediation 622 A Remediation consists of an extension to the Incident.AdditionalData 623 element with a dtype of "xml". The extension elements describes 624 incident remediation information including instructions. 626 It is recommended that Incident class SHOULD contain one or more of 627 this extension elements whenever available. 629 A Remediation class is structured as follows. 631 +----------------------+ 632 | Remediation | 633 +----------------------+ 634 | ENUM SpecID |<>--(0..*)-[ RawData ] 635 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 636 | String RemediationID | 637 +----------------------+ 639 Figure 9: Remediation class 641 This class has the following attributes. 643 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 644 as that of the AttackPattern class (Section 4.3.1). 646 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 647 same as that of the AttackPattern class (Section 4.3.1). 649 RemediationID: OPTIONAL. STRING. An identifier of a remediation 650 information to be reported. This attribute SHOULD be used 651 whenever such identifier is available. Both RawData and Reference 652 elements MUST NOT be used when this attribute is used, while 653 either of them MUST be used if this attribute is omitted. 655 This class is composed of two aggregate classes. 657 RawData: Zero or more. XMLDATA. The meaning of this element is the 658 same as that of the AttackPattern class (Section 4.3.1). 660 Reference: Zero or more of iodef:Reference [RFC5070]. The meaning 661 of this element is the same as that of the AttackPattern class 662 (Section 4.3.1). 664 This class MUST contain at least either of RawData and Reference 665 elements. Writers/senders MUST ensure the specification name and 666 version identified by the SpecID are consistent with the contents of 667 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 668 prefer the specification name and version derived from the content, 669 and SHOULD log the inconsistency so a human can correct the problem. 671 5. Mandatory to Implement features 673 The implementation of this draft MUST be capable of sending and 674 receiving the XML conforming to the specification listed in the 675 initial IANA table described in Section 4.1 without error. 677 The receiver MUST be capable of validating received XML documents 678 that are embedeed inside that against their schemata. Note that the 679 receiver can look up the namespace in the IANA table to understand 680 what specifications the embedded XML documents follows. 682 6. Security Considerations 684 This document specifies a format for encoding a particular class of 685 security incidents appropriate for exchange across organizations. As 686 merely a data representation, it does not directly introduce security 687 issues. However, it is guaranteed that parties exchanging instances 688 of this specification will have certain concerns. For this reason, 689 the underlying message format and transport protocol used MUST ensure 690 the appropriate degree of confidentiality, integrity, and 691 authenticity for the specific environment. 693 Organizations that exchange data using this document are URGED to 694 develop operating procedures that document the following areas of 695 concern. 697 6.1. Transport-Specific Concerns 699 The underlying messaging format and protocol used to exchange 700 instances of the IODEF MUST provide appropriate guarantees of 701 confidentiality, integrity, and authenticity. The use of a 702 standardized security protocol is encouraged. The Real-time Inter- 703 network Defense (RID) protocol [RFC6045] and its associated transport 704 binding [RFC6046] provide such security. 706 The critical security concerns are that these structured information 707 may be falsified or they may become corrupt during transit. In areas 708 where transmission security or secrecy is questionable, the 709 application of a digital signature and/or message encryption on each 710 report will counteract both of these concerns. We expect that each 711 exchanging organization will determine the need, and mechanism, for 712 transport protection. 714 7. IANA Considerations 716 This document uses URNs to describe XML namespaces and XML schemata 717 [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism 718 described in [RFC3688]. 720 Registration request for the IODEF structured cybersecurity 721 information extension namespace: 723 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 725 Registrant Contact: Refer here to the authors' addresses section 726 of the document. 728 XML: None 730 Registration request for the IODEF structured cybersecurity 731 information extension XML schema: 733 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 735 Registrant Contact: Refer here to the authors' addresses section 736 of the document. 738 XML: Refer here to the XML Schema in the appendix of the document. 740 This memo creates the following registry for IANA to manage: 742 Name of the registry: "IODEF Structured Cyber Security Information 743 Specifications" 745 Namespace details: A registry entry for a Structured Cyber 746 Security Information Specification (SCI specification) consists 747 of: 749 Namespace: A URI [RFC3986] that is the XML namespace name used 750 by the registered SCI specification. 752 Specification Name: A string containing the spelled-out name of 753 the SCI specification in human-readable form. 755 Reference URI: A list of one or more of the URIs [RFC3986] from 756 which the registered specification can be obtained. The 757 registered specification MUST be readily and publicly available 758 from that URI. 760 Applicable Classes: A list of one or more of the Extended 761 Classes specified in Section 4.3 of this document. The 762 registered SCI specification MUST only be used with the 763 Extended Classes in the registry entry. 765 Information that must be provided to assign a new value: The above 766 list of information. 768 Fields to record in the registry: Namespace/Specification Name/ 769 Version/Applicable Classes. 771 Initial registry contents: none 773 Allocation Policy: Expert Review [RFC5226] and Specification 774 Required [RFC5226]. 776 The Designated Expert is expected to consult with the mile (Managed 777 Incident Lightweight Exchange) working group or its successor if any 778 such WG exists (e.g., via email to the working group's mailing list). 779 The Designated Expert is expected to retrieve the SCI specification 780 from the provided URI in order to check the public availability of 781 the specification and verify the correctness of the URI. An 782 important responsibility of the Designated Expert is to ensure that 783 the registered Applicable Classes are appropriate for the registered 784 SCI specification. 786 8. Acknowledgment 788 We would like to acknowledge Mr. David Black from EMC, who kindly 789 provided generous support, especially on the IANA registry issues. 790 We also would like to thank Jon Baker from MITRE, Paul Cichonski from 791 NIST, Panos Kampanakis from CISCO, Robert Martin from MITRE, Kathleen 792 Moriarty from EMC, Lagadec Philippe from NATO, Shuhei Yamaguchi from 793 NICT, Anthony Rutkowski from Yaana Technology, Brian Trammel from 794 CERT/NetSA, and David Waltermire from NIST for their sincere 795 discussion and feedback on this document. 797 9. Appendix I: XML Schema Definition for Extension 799 The XML Schema describing the elements defined in the Extension 800 Definition section is given here. Each of the examples in Section 11 801 should be verified to validate against this schema by automated 802 tools. 804 806 812 815 819 823 824 825 826 827 829 830 831 832 833 834 835 836 837 839 843 844 845 846 848 849 850 852 853 855 859 860 861 862 863 865 867 868 870 871 872 874 876 877 879 883 884 885 886 887 889 891 892 894 896 897 898 900 902 903 905 909 910 911 912 913 915 917 918 920 922 923 924 926 928 929 931 935 936 937 938 939 941 943 944 945 946 948 950 951 953 957 958 959 960 961 962 963 964 965 966 968 970 971 973 977 978 979 980 981 982 983 984 985 986 988 990 991 993 997 998 999 1000 1001 1002 1003 1004 1005 1006 1008 1010 1011 1013 1015 10. Appendix II: Candidate Specifications for the IANA Table 1017 This draft defined the structure of the IANA table in Section 4.1. 1018 Though the management of the table is up to IANA, this appendix 1019 provides candidate entries. Note that OVAL and CVE are registered 1020 trademarks, and CAPEC, CCE, CEE, CPE, CWE, CWSS, MAEC, and OCIL are 1021 trademarks, of The MITRE Corporation. 1023 1. CAPEC 1.6 1025 Namespace: http://capec.mitre.org/observables 1026 Specification Name: Common Attack Pattern Enumeration and Classification 1027 Version: 1.6 1028 Reference URI: http://capec.mitre.org/ 1029 Applicable Classes: AttackPattern 1031 2. CCE 5.0 1033 Namespace: http://cce.mitre.org 1034 Specification Name: Common Configuration Enumeration 1035 Version: 5.0 1036 Reference URI: http://cce.mitre.org/ 1037 Applicable Classes: Verification 1039 3. CCSS 1.0 1041 Namespace: N/A 1042 Specification Name: Common Configuration Scoring System 1043 Version: 1.0 1044 Reference URI: http://csrc.nist.gov/publications/PubsNISTIRs.html 1045 #NIST-IR-7502 1046 Applicable Classes: Scoring 1047 4. CEE 1.0 alpha 1049 Namespace: http://cee.mitre.org 1050 Specification Name: Common Event Expression 1051 Version: 1.0 alpha 1052 Reference URI: http://cee.mitre.org/ 1053 Applicable Classes: EventReport 1055 5. CPE 2.3 Language 1057 Namespace: http://cpe.mitre.org/language/2.0 1058 Specification Name: Common Platform Enumeration Reference 1059 Version: 2.3 1060 Reference URI: http://scap.nist.gov/specifications/cpe/, 1061 http://csrc.nist.gov/publications/PubsNISTIRs.html 1062 #NIST-IR-7695 1063 Applicable Classes: Platform 1065 6. CPE 2.3 Dictionary 1067 Namespace: http://cpe.mitre.org/dictionary/2.0 1068 Specification Name: Common Platform Enumeration Dictionary 1069 Version: 2.3 1070 Reference URI: http://scap.nist.gov/specifications/cpe/, 1071 http://csrc.nist.gov/publications/PubsNISTIRs.html 1072 #NIST-IR-7697 1073 Applicable Classes: Platform 1075 7. CVE 1.0 1077 Namespace: http://cve.mitre.org/cve/downloads/1.0 1078 Specification Name: Common Vulnerability and Exposures 1079 Version: 1.0 1080 Reference URI: http://cve.mitre.org/ 1081 Applicable Classes: Vulnerability 1083 8. CVRF 1.0 1084 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 1085 Specification Name: Common Vulnerability Reporting Format 1086 Version: 1.0 1087 Reference URI: http://www.icasi.org/cvrf 1088 Applicable Classes: Vulnerability 1090 9. CVSS 2.0 1092 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 1093 Specification Name: Common Vulnerability Scoring System 1094 Version: 2 1095 Reference URI: http://www.first.org/cvss 1096 Applicable Classes: Scoring 1098 10. CWE 5.0 1100 Namespace: N/A 1101 Specification Name: Common Weakness Enumeration 1102 Version: 5.1 1103 Reference URI: http://cwe.mitre.org/ 1104 Applicable Classes: Weakness 1106 11. CWSS 0.8 1108 Namespace: N/A 1109 Specification Name: Common Weakness Scoring System 1110 Version: 0.8 1111 Reference URI: http://cwe.mitre.org/cwss/ 1112 Applicable Classes: Scoring 1114 12. MAEC 2.0 1116 Namespace: http://maec.mitre.org/XMLSchema/maec-core-2 1117 Specification Name: Malware Attribute Enumeration and Characterization 1118 Version: 2.0 1119 Reference URI: http://maec.mitre.org/ 1120 Applicable Classes: EventReport, AttackPattern 1121 13. OCIL 2.0 1123 Namespace: http://scap.nist.gov/schema/ocil/2.0 1124 Specification Name: Open Checklist Interactive Language 1125 Version: 2.0 1126 Reference URI: http://scap.nist.gov/specifications/ocil/, 1127 http://csrc.nist.gov/publications/PubsNISTIRs.html 1128 #NIST-IR-7692 1129 Applicable Classes: Verification 1131 14. OVAL 5.10.1 Definitions 1133 Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 1134 Specification Name: Open Vulnerability and Assessment Language 1135 Version: 5.10.1 1136 Reference URI: http://oval.mitre.org/ 1137 Applicable Classes: Verification 1139 15. OVAL 5.10.1 Results 1141 Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 1142 Specification Name: Open Vulnerability and Assessment Language 1143 Version: 5.10.1 1144 Reference URI: http://oval.mitre.org/ 1145 Applicable Classes: Verification 1147 16. OVAL 5.10.1 Common 1149 Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 1150 Specification Name: Open Vulnerability and Assessment Language 1151 Version: 5.10.1 1152 Reference URI: http://oval.mitre.org/ 1153 Applicable Classes: Verification 1155 17. XCCDF 1.2 1157 Namespace: http://checklists.nist.gov/xccdf/1.2 1158 Specification Name: Extensible Configuration Checklist Description Format 1159 Version: 1.2 1160 Reference URI: http://scap.nist.gov/specifications/xccdf/, 1161 http://csrc.nist.gov/publications/PubsNISTIRs.html 1162 #NIST-IR-7275-r4 1163 Applicable Classes: Verification 1165 11. Appendix III: An XML Example 1167 This section provides an example of an incident encoded in the IODEF. 1168 This do not necessarily represent the only way to encode a particular 1169 incident. This example reports an attack to a CSIRT and is extended 1170 from the example described in [RFC5070]. It uses identifiers whose 1171 dictionary follows CVE 1.0 schema, and it aembeds XML following CEE 1172 0.6. 1174 1175 1180 1181 189493 1182 2001-09-13T23:19:24+00:00 1183 Incident report in company xx 1184 1185 1186 1187 1188 An identifier of a vulnerability is embedded 1189 1190 1193 1194 1195 1196 Example.com CSIRT 1197 example-com 1198 contact@csirt.example.com 1199 1200 1201 1202 1203 1204
192.0.2.200
1205 57 1206
1207
1208 1209 1210
192.0.2.16/28
1211
1212 1213 80 1214 1215 1216 1218 1219
1220
1221 1222 1223 1224 1225 1226 2001-09-13T18:11:21+02:00 1227 a Web-server event record 1228 1229 1230 1231 1233 1234 system.example.com 1235 auth 1236 1237 application 1238 123 1239 10 1240 login 1241 app 1242 account 1243 web 1244 success 1245 1246 1247 1248 1249 1251 1252 1253
1254 1255 1256 1257 2001-09-14T08:19:01+00:00 1258 Notification sent to 1259 constituency-contact@192.0.2.200 1260 1261 1262
1263
1265 12. References 1267 12.1. Normative References 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, March 1997. 1272 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1273 Resource Identifier (URI): Generic Syntax", STD 66, 1274 RFC 3986, January 2005. 1276 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1277 Object Description Exchange Format", RFC 5070, 1278 December 2007. 1280 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1281 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1282 May 2008. 1284 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1285 RFC 6045, November 2010. 1287 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1288 Inter-network Defense (RID) Messages", RFC 6046, 1289 November 2010. 1291 [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, 1292 "Malware Metadata Exchange Format". 1294 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1295 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1296 Edition)", W3C Recommendation, November 2008. 1298 [XMLschemaPart1] 1299 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1300 "XML Schema Part 1: Structures Second Edition", 1301 W3C Recommendation, October 2004. 1303 [XMLschemaPart2] 1304 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1305 Second Edition", W3C Recommendation, October 2004. 1307 [XMLNames] 1308 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1309 Thomson, ""Namespaces in XML (Third Edition)", 1310 W3C Recommendation, December 2009. 1312 12.2. Informative References 1314 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1315 Internet: Timestamps", RFC 3339, July 2002. 1317 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1318 Text on Security Considerations", BCP 72, RFC 3552, 1319 July 2003. 1321 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1322 January 2004. 1324 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1325 October 2008. 1327 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1328 Uniform Resource Identifiers (URI) Dynamic Delegation 1329 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1330 March 2011. 1332 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1333 and Classification (CAPEC)". 1335 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1336 (CCE)". 1338 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1339 Scoring System (CCSS)", NIST Interagency Report 7502, 1340 December 2010. 1342 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1344 [CPE] National Institute of Standards and Technology, "Common 1345 Platform Enumeration", June 2011. 1347 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1348 (CVE)". 1350 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1352 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1353 Common Vulnerability Scoring System (CVSS) and Its 1354 Applicability to Federal Agency Systems". 1356 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1357 (CWE)". 1359 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1360 (CWSS)". 1362 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1363 Open Checklist Interactive Language (OCIL) Version 2.0", 1364 April 2011. 1366 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1367 Language (OVAL)". 1369 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 1370 Halbardier, "The Technical Specification for the Security 1371 Content Automation Protocol (SCAP): SCAP Version 1.2", 1372 NIST Special Publication 800-126 Revision 2, 1373 September 2011. 1375 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1376 and Neal Ziring, "Specification for the Extensible 1377 Configuration Checklist Description Format (XCCDF) version 1378 1.2 (DRAFT)", July 2011. 1380 Authors' Addresses 1382 Takeshi Takahashi 1383 National Institute of Information and Communications Technology 1384 4-2-1 Nukui-Kitamachi Koganei 1385 184-8795 Tokyo 1386 Japan 1388 Phone: +80 423 27 5862 1389 Email: takeshi_takahashi@nict.go.jp 1390 Kent Landfield 1391 McAfee, Inc 1392 5000 Headquarters Drive 1393 Plano, TX 75024 1394 USA 1396 Email: Kent_Landfield@McAfee.com 1398 Thomas Millar 1399 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1400 245 Murray Lane SW, Building 410, MS #732 1401 Washington, DC 20598 1402 USA 1404 Phone: +1 888 282 0870 1405 Email: thomas.millar@us-cert.gov 1407 Youki Kadobayashi 1408 Nara Institute of Science and Technology 1409 8916-5 Takayama, Ikoma 1410 630-0192 Nara 1411 Japan 1413 Email: youki-k@is.aist-nara.ac.jp