idnits 2.17.1 draft-ietf-mile-sci-09.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 8 instances of too long lines in the document, the longest one being 4 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 (Sep 29, 2013) is 3861 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3339' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'OVAL' is defined on line 1213, 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 (~~), 6 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: April 2, 2014 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Sep 29, 2013 12 IODEF-extension for structured cybersecurity information 13 draft-ietf-mile-sci-09.txt 15 Abstract 17 This document extends the Incident Object Description Exchange Format 18 (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched 19 cybersecurity information among cybersecurity entities and facilitate 20 their operations. It provides the capability of embedding structured 21 information, such as identifier- and XML-based information. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 2, 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 . . . . . . . . . . . . . . . . . . . . . 14 71 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 15 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 84 1. Introduction 86 The number of cyber attacks is growing day by day, and incident 87 information needs to be reported, exchanged, and shared among 88 organizations in order to cope with the situation. IODEF is one of 89 the tools enabling such exchange, and is already in use. 91 To efficiently run cybersecurity operations, these exchanged 92 information needs to be machine-readable. IODEF provides a 93 structured means to describe the information, but it needs to embed 94 various non-structured such information in order to convey detailed 95 information. Further structure within IODEF increases IODEF 96 documents' machine-readability and thus facilitates streamlining 97 cybersecurity operations. 99 On the other hand, there exist various other activities facilitating 100 detailed and structured description of cybersecurity information 101 [CAPEC][CCE][CCSS][CEE][CPE][CVE][CVRF][CVSS][CWE][CWSS][MAEC][OCIL][ 102 OVAL][SCAP][XCCDF]. 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 138 [CAPEC][CCE][CCSS][CEE][CPE][CVE][CVRF][CVSS][CWE][CWSS][MAEC][OCIL][ 139 OVAL][SCAP][XCCDF]. By embedding them into the IODEF document, the 140 document can convey more detailed contents to the receivers, and the 141 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 http://grouper.ieee.org/groups 195 /malware/malwg/Schema1.2/ 196 Applicable Classes: AttackPattern 198 Note that the specification was developed by The Institute of 199 Electrical and Electronics Engineers, Incorporated (IEEE), through 200 the Industry Connections Security Group (ICSG) of its Standards 201 Association. 203 The table is to be managed by IANA using the Expert Review [RFC5226] 204 and Specification Required [RFC5226] allocation policies as further 205 specified in Section 7 . 207 The SpecID attributes of extended classes (Section 4.3) must allow 208 the values of the specifications' namespace fields, but otherwise, 209 implementations are not required to support all specifications of the 210 IANA table and may choose which specifications to support, though the 211 specification listed in the initial table needs to be minimally 212 supported, as described in Section 5. In case an implementation 213 received a data it does not support, it may expand its functionality 214 by looking up the IANA table or notify the sender of its inability to 215 parse the data by using any means defined outside the scope of this 216 specification. 218 4.2. Extended Data Type: XMLDATA 220 This extension inherits all of the data types defined in the IODEF 221 model. One data type is added: XMLDATA. An embedded XML data is 222 represented by the XMLDATA data type. This type is defined as the 223 extension to the iodef:ExtensionType [RFC5070] , whose dtype 224 attribute is set to "xml." 226 4.3. Extended Classes 228 The IODEF Incident element [RFC5070] is summarized below. It is 229 expressed in Unified Modeling Language (UML) syntax as used in the 230 IODEF specification. The UML representation is for illustrative 231 purposes only; elements are specified in XML as defined in 232 Section 5.2. 234 +---------------+ 235 | Incident | 236 +---------------+ 237 | ENUM purpose |<>---------[IncidentID] 238 | STRING |<>--{0..1}-[AlternativeID] 239 | ext-purpose |<>--{0..1}-[RelatedActivity] 240 | ENUM lang |<>--{0..1}-[DetectTime] 241 | ENUM |<>--{0..1}-[StartTime] 242 | restriction |<>--{0..1}-[EndTime] 243 | |<>---------[ReportTime] 244 | |<>--{0..*}-[Description] 245 | |<>--{1..*}-[Assessment] 246 | |<>--{0..*}-[Method] 247 | | |<>--{0..*}-[AdditionalData] 248 | | |<>--{0..*}-[AttackPattern] 249 | | |<>--{0..*}-[Vulnerability] 250 | | |<>--{0..*}-[Weakness] 251 | |<>--{1..*}-[Contact] 252 | |<>--{0..*}-[EventData] 253 | | |<>--{0..*}-[Flow] 254 | | | |<>--{1..*}-[System] 255 | | | |<>--{0..*}-[AdditionalData] 256 | | | |<>--{0..*}-[Platform] 257 | | |<>--{0..*}-[Expectation] 258 | | |<>--{0..1}-[Record] 259 | | |<>--{1..*}-[RecordData] 260 | | |<>--{1..*}-[RecordItem] 261 | | |<>--{0..*}-[EventReport] 262 | |<>--{0..1}-[History] 263 | |<>--{0..*}-[AdditionalData] 264 | | |<>--{0..*}-[Verification] 265 | | |<>--{0..*}-[Remediation] 266 +---------------+ 268 Figure 1: Incident class 270 This extension defines the following seven elements. 272 4.3.1. AttackPattern 274 An AttackPattern consists of an extension to the 275 Incident.Method.AdditionalData element with a dtype of "xml". The 276 extension describes attack patterns of incidents or events. 278 It is recommended that Method class SHOULD contain one or more of the 279 extension elements whenever available. 281 An AttackPattern class is structured as follows. 283 +------------------------+ 284 | AttackPattern | 285 +------------------------+ 286 | ENUM SpecID |<>--(0..*)-[ RawData ] 287 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 288 | STRING AttackPatternID |<>--(0..*)-[ Platform ] 289 +------------------------+ 291 Figure 2: AttackPattern class 293 This class has the following attributes. 295 SpecID: REQUIRED. ENUM. A specification's identifier that 296 specifies the format of a structured cybersecurity information. 297 The value should be chosen from the namespaces [XMLNames] listed 298 in the IANA table (Section 4.1) or "private". The value "private" 299 is prepared for conveying RawData based on a format that is not 300 listed in the table. This is usually used for conveying data 301 formatted according to an organization's private schema. When the 302 value "private" is used, ext-SpecID element MUST be used. 304 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 305 specifies the format of a structured cybersecurity information. 306 When this element is used, the value of SpecID element must be 307 "private." 309 AttackPatternID: OPTIONAL. STRING. An identifier of an attack 310 pattern to be reported. This attribute SHOULD be used whenever 311 such identifier is available. Both RawData and Reference elements 312 MUST NOT be used when this attribute is used, while either of them 313 MUST be used if this attribute is omitted. 315 The AttackPattern class is composed of the following aggregate 316 classes. 318 RawData: Zero or more. XMLDATA. A complete document that is 319 formatted according to the specification and its version 320 identified by the SpecID/ext-SpecID. When this element is used, 321 writers/senders MUST ensure that the namespace specified by 322 SpecID/ext-SpecID and the one used in the RawData element are 323 consistent; if not, the namespace identified by SpecID SHOULD be 324 prefered, and the inconsistency SHOULD be logged so a human can 325 correct the problem. 327 Reference: Zero or more of iodef:Reference [RFC5070] . This element 328 allows an IODEF document to include a link to a structured 329 information instead of directly embedding it into a RawData 330 element. 332 Platform: Zero or more. An identifier of software platform involved 333 in the specific attack pattern, which is elaborated in 334 Section 4.3.2 . 336 4.3.2. Platform 338 A Platform identifies a software platform. It is recommended that 339 AttackPattern, Vulnerability, Weakness, and System classes contain 340 this elements whenever available. 342 A Platform element is structured as follows. 344 +----------------------+ 345 | Platform | 346 +----------------------+ 347 | ENUM SpecID |<>--(0..*)-[ RawData ] 348 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 349 | STRING PlatformID | 350 +----------------------+ 352 Figure 3: Platform class 354 This class has the following attributes. 356 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 357 as that of the AttackPattern class (Section 4.3.1) . 359 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 360 same as that of the AttackPattern class (Section 4.3.1) . 362 PlatformID: OPTIONAL. STRING. An identifier of a platform to be 363 reported. This attribute SHOULD be used whenever such identifier 364 is available. Both RawData and Reference elements MUST NOT be 365 used when this attribute is used, while either of them MUST be 366 used if this attribute is omitted. 368 This class is composed of the following aggregate classes. 370 RawData: Zero or more. XMLDATA. The meaning of this element is the 371 same as that of the AttackPattern class (Section 4.3.1) . 373 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 374 of this element is the same as that of the AttackPattern class 375 (Section 4.3.1) . 377 4.3.3. Vulnerability 379 A Vulnerability consists of an extension to the 380 Incident.Method.AdditionalData element with a dtype of "xml". The 381 extension describes the (candidate) vulnerabilities of incidents or 382 events. 384 It is recommended that Method class SHOULD contain one or more of the 385 extension elements whenever available. 387 A Vulnerability element is structured as follows. 389 +------------------------+ 390 | Vulnerability | 391 +------------------------+ 392 | ENUM SpecID |<>--(0..*)-[ RawData ] 393 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 394 | STRING VulnerabilityID |<>--(0..*)-[ Platform ] 395 | |<>--(0..*)-[ Scoring ] 396 +------------------------+ 398 Figure 4: Vulnerability class 400 This class has the following attributes. 402 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 403 as that of the AttackPattern class (Section 4.3.1) . 405 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 406 same as that of the AttackPattern class (Section 4.3.1) . 408 VulnerabilityID: OPTIONAL. STRING. An identifier of a 409 vulnerability to be reported. This attribute SHOULD be used 410 whenever such identifier is available. Both RawData and Reference 411 elements MUST NOT be used when this attribute is used, while 412 either of them MUST be used if this attribute is omitted. 414 This class is composed of the following aggregate classes. 416 RawData: Zero or more. XMLDATA. The meaning of this element is the 417 same as that of the AttackPattern class (Section 4.3.1) . 419 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 420 of this element is the same as that of the AttackPattern class 421 (Section 4.3.1) . 423 Platform: Zero or more. An identifier of software platform affected 424 by the vulnerability, which is elaborated in Section 4.3.2 . 426 Scoring: Zero or more. An indicator of the severity of the 427 vulnerability, such as CVSS and CCSS scores, which is elaborated 428 in Section 4.3.4 . Some of the structured information may include 429 scores within it. In this case, the Scoring element SHOULD NOT be 430 used since the RawData element contains the scores. If a reader/ 431 receiver detects scores in both RawData and Scoring elements and 432 their inconsistency, it SHOULD prefer the scores derived from the 433 RawData element, and SHOULD log the inconsistency so a human can 434 correct the problem. 436 4.3.4. Scoring 438 A Scoring class describes the scores of the severity in terms of 439 security. It is recommended that Vulnerability and Weakness classes 440 contain the elements whenever available. 442 A Scoring class is structured as follows. 444 +----------------------+ 445 | Scoring | 446 +----------------------+ 447 | ENUM SpecID |<>---------[ ScoreSet ] 448 | STRING ext-SpecID | 449 +----------------------+ 451 Figure 5: Scoring class 453 This class has two attributes. 455 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 456 as that of the AttackPattern class (Section 4.3.1) . 458 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 459 same as that of the AttackPattern class (Section 4.3.1) . 461 This class is composed of an aggregate class. 463 ScoreSet: One. XMLDATA. A complete document that is formatted 464 according to the specification and its version identified by the 465 SpecID/ext-SpecID. This element includes a set of score 466 information. When this element is used, writers/senders MUST 467 ensure that the namespace specified by SpecID/ext-SpecID and the 468 one used in the RawData element are consistent; if not, the 469 namespace identified by SpecID SHOULD be prefered, and the 470 inconsistency SHOULD be logged so a human can correct the problem. 472 Writers/senders MUST ensure the specification name and version 473 identified by the SpecID are consistent with the contents of the 474 Score; if a reader/receiver detects an inconsistency, it SHOULD 475 prefer the specification name and version derived from the content, 476 and SHOULD log the inconsistency so a human can correct the problem. 478 4.3.5. Weakness 480 A Weakness consists of an extension to the 481 Incident.Method.AdditionalData element with a dtype of "xml". The 482 extension describes the weakness types of incidents or events. 484 It is recommended that Method class SHOULD contain one or more of the 485 extension elements whenever available. 487 A Weakness element is structured as follows. 489 +----------------------+ 490 | Weakness | 491 +----------------------+ 492 | ENUM SpecID |<>--(0..*)-[ RawData ] 493 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 494 | STRING WeaknessID |<>--(0..*)-[ Platform ] 495 | |<>--(0..*)-[ Scoring ] 496 +----------------------+ 498 Figure 6: Weakness class 500 This class has the following attributes. 502 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 503 as that of the AttackPattern class (Section 4.3.1) . 505 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 506 same as that of the AttackPattern class (Section 4.3.1) . 508 WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be 509 reported. This attribute SHOULD be used whenever such identifier 510 is available/ Both RawData and Reference elements MUST NOT be used 511 when this attribute is used, while either of them MUST be used if 512 this attribute is omitted. 514 This class is composed of the following aggregate classes. 516 RawData: Zero or more. XMLDATA. The meaning of this element is the 517 same as that of the AttackPattern class (Section 4.3.1) . 519 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 520 of this element is the same as that of the AttackPattern class 521 (Section 4.3.1) . 523 Platform: Zero or more. An identifier of software platform affected 524 by the weakness, which is elaborated in Section 4.3.2 . 526 Scoring: Zero or more. An indicator of the severity of the 527 weakness, such as CWSS score, which is elaborated in Section 4.3.4 528 . 530 4.3.6. EventReport 532 An EventReport consists of an extension to the 533 Incident.EventData.Record.RecordData.RecordItem element with a dtype 534 of "xml". The extension embeds structured event reports. 536 It is recommended that RecordItem class SHOULD contain one or more of 537 the extension elements whenever available. 539 An EventReport element is structured as follows. 541 +----------------------+ 542 | EventReport | 543 +----------------------+ 544 | ENUM SpecID |<>--(0..*)-[ RawData ] 545 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 546 | STRING EventID | 547 +----------------------+ 549 Figure 7: EventReport class 551 This class has the following attributes. 553 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 554 as that of the AttackPattern class (Section 4.3.1) . 556 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 557 same as that of the AttackPattern class (Section 4.3.1) . 559 EventID: OPTIONAL. STRING. An identifier of an event to be 560 reported. This attribute SHOULD be used whenever such identifier 561 is available. Both RawData and Reference elements MUST NOT be 562 used when this attribute is used, while either of them MUST be 563 used if this attribute is omitted. 565 This class is composed of three aggregate classes. 567 RawData: Zero or more. XMLDATA. The meaning of this element is the 568 same as that of the AttackPattern class (Section 4.3.1) . 570 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 571 of this element is the same as that of the AttackPattern class 572 (Section 4.3.1) . 574 This class MUST contain at least one of RawData or Reference 575 elements. Writers/senders MUST ensure the specification name and 576 version identified by the SpecID are consistent with the contents of 577 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 578 prefer the specification name and version derived from the content, 579 and SHOULD log the inconsistency so a human can correct the problem. 581 4.3.7. Verifcation 583 A Verification consists of an extension to the 584 Incident.AdditionalData element with a dtype of "xml". The extension 585 elements describes incident on vefifying incidents. 587 A Verification class is structured as follows. 589 +----------------------+ 590 | Verification | 591 +----------------------+ 592 | ENUM SpecID |<>--(0..*)-[ RawData ] 593 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 594 | STRING VerificationID| 595 +----------------------+ 597 Figure 8: Verification class 599 This class has the following attributes. 601 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 602 as that of the AttackPattern class (Section 4.3.1) . 604 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 605 same as that of the AttackPattern class (Section 4.3.1) . 607 VerificationID: OPTIONAL. STRING. An identifier of an check item 608 to be reported. This attribute SHOULD be used whenever such 609 identifier is available. Both RawData and Reference elements MUST 610 NOT be used when this attribute is used, while either of them MUST 611 be used if this attribute is omitted. 613 This class is composed of two aggregate classes. 615 RawData: Zero or more. XMLDATA. The meaning of this element is the 616 same as that of the AttackPattern class (Section 4.3.1) . 618 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 619 of this element is the same as that of the AttackPattern class 620 (Section 4.3.1) . 622 This class MUST contain at least either of RawData and Reference 623 elements. Writers/senders MUST ensure the specification name and 624 version identified by the SpecID are consistent with the contents of 625 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 626 prefer the specification name and version derived from the content, 627 and SHOULD log the inconsistency so a human can correct the problem. 629 4.3.8. Remediation 631 A Remediation consists of an extension to the Incident.AdditionalData 632 element with a dtype of "xml". The extension elements describes 633 incident remediation information including instructions. 635 It is recommended that Incident class SHOULD contain one or more of 636 this extension elements whenever available. 638 A Remediation class is structured as follows. 640 +----------------------+ 641 | Remediation | 642 +----------------------+ 643 | ENUM SpecID |<>--(0..*)-[ RawData ] 644 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 645 | String RemediationID | 646 +----------------------+ 648 Figure 9: Remediation class 650 This class has the following attributes. 652 SpecID: REQUIRED. ENUM. The meaning of this attribute is the same 653 as that of the AttackPattern class (Section 4.3.1) . 655 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the 656 same as that of the AttackPattern class (Section 4.3.1) . 658 RemediationID: OPTIONAL. STRING. An identifier of a remediation 659 information to be reported. This attribute SHOULD be used 660 whenever such identifier is available. Both RawData and Reference 661 elements MUST NOT be used when this attribute is used, while 662 either of them MUST be used if this attribute is omitted. 664 This class is composed of two aggregate classes. 666 RawData: Zero or more. XMLDATA. The meaning of this element is the 667 same as that of the AttackPattern class (Section 4.3.1) . 669 Reference: Zero or more of iodef:Reference [RFC5070] . The meaning 670 of this element is the same as that of the AttackPattern class 671 (Section 4.3.1) . 673 This class MUST contain at least either of RawData and Reference 674 elements. Writers/senders MUST ensure the specification name and 675 version identified by the SpecID are consistent with the contents of 676 the RawData; if a reader/receiver detects an inconsistency, it SHOULD 677 prefer the specification name and version derived from the content, 678 and SHOULD log the inconsistency so a human can correct the problem. 680 5. Mandatory to Implement features 682 The implementation of this draft MUST be capable of sending and 683 receiving the XML conforming to the specification listed in the 684 initial IANA table described in Section 4.1 without error. 686 The receiver MUST be capable of validating received XML documents 687 that are embedeed inside that against their schemata. Note that the 688 receiver can look up the namespace in the IANA table to understand 689 what specifications the embedded XML documents follows. 691 This section provides an XML comformant to this draft, and a scehma 692 for that. 694 5.1. An Example XML 696 An example IODEF document for checking implementation's MTI 697 conformity is provided here. The document carries MMDEF metadata. 698 Note that the metadata is generated by genMMDEF [MMDEF] with EICAR 699 [EICAR] files. Implementations of this specification must be capable 700 of parsing the example XML since MMDEF is specified as the draft's 701 MTI specification. 703 704 709 710 189493 711 2013-06-18T23:19:24+00:00 712 a candidate security incident 713 714 715 716 717 A candidate attack event 718 719 721 722 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 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4 736 95991b7852b855 737 cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83 738 f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9 739 31bd47417a81a538327af927da3e 740 184 741 eicar_com.zip 742 application/zip 743 744 745 44d88612fea8a8f36de82e1278abb02f 746 3395856ce81f2b7382dee72602f798b642f14140 747 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4 748 538aabf651fd0f 749 cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e 750 68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0 751 dc9a061d9e507d833277ada336ab 752 68 753 1750191932 754 eicar.com 755 eicar.com 756 757 758 759 760 761 762 file[@id="6ce6f415d8475545be5ba114f208b0ff"] 763 764 765 file[@id="44d88612fea8a8f36de82e1278abb02f"] 766 767 2013-03-23T15:12:50.744000 768 769 770 771 772 773 774 775 776 iodef-sci.example.com 777 iodef-sci.example-com 778 779 contact@csirt.example.com 780 781 782 783 784 785
192.0.2.200
786 57 787 788 789 790 791
192.0.2.16/28
792 793 794 80 795 796 797 798 799 800 801 802 804 5.2. An XML Schema for the Extension 806 An XML Schema describing the elements defined in this draft is given 807 here. Any XMLs compliant to this draft including the ones in 808 Section 5.1 should be verified against this schema by automated 809 tools. 811 812 818 821 822 823 824 825 827 828 830 831 832 833 834 835 836 838 839 840 841 843 844 845 847 848 850 851 852 853 854 856 858 859 861 862 863 865 867 868 870 871 872 873 874 876 878 879 881 883 884 885 887 889 890 892 893 894 895 896 898 900 901 903 905 906 907 909 911 912 914 915 916 917 918 920 922 923 924 925 927 929 930 932 933 934 935 936 938 940 941 942 943 945 947 948 950 951 952 953 954 957 959 960 961 962 964 966 967 969 970 971 972 973 975 977 978 979 980 982 984 985 987 989 6. Security Considerations 991 This document specifies a format for encoding a particular class of 992 security incidents appropriate for exchange across organizations. As 993 merely a data representation, it does not directly introduce security 994 issues. However, it is guaranteed that parties exchanging instances 995 of this specification will have certain concerns. For this reason, 996 the underlying message format and transport protocol used MUST ensure 997 the appropriate degree of confidentiality, integrity, and 998 authenticity for the specific environment. 1000 Organizations that exchange data using this document are URGED to 1001 develop operating procedures that document the following areas of 1002 concern. 1004 6.1. Transport-Specific Concerns 1006 The underlying messaging format and protocol used to exchange 1007 instances of the IODEF MUST provide appropriate guarantees of 1008 confidentiality, integrity, and authenticity. The use of a 1009 standardized security protocol is encouraged. The Real-time Inter- 1010 network Defense (RID) protocol [RFC6045] and its associated transport 1011 binding [RFC6046] provide such security. 1013 The critical security concerns are that these structured information 1014 may be falsified or they may become corrupt during transit. In areas 1015 where transmission security or secrecy is questionable, the 1016 application of a digital signature and/or message encryption on each 1017 report will counteract both of these concerns. We expect that each 1018 exchanging organization will determine the need, and mechanism, for 1019 transport protection. 1021 7. IANA Considerations 1023 This document uses URNs to describe XML namespaces and XML schemata 1024 [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism 1025 described in [RFC3688] . 1027 Registration request for the IODEF structured cybersecurity 1028 information extension namespace: 1030 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 1032 Registrant Contact: Refer here to the authors' addresses section 1033 of the document. 1035 XML: None 1037 Registration request for the IODEF structured cybersecurity 1038 information extension XML schema: 1040 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 1042 Registrant Contact: Refer here to the authors' addresses section 1043 of the document. 1045 XML: Refer here to the XML Schema in Section 5.2. 1047 This memo creates the following registry for IANA to manage: 1049 Name of the registry: "IODEF Structured Cyber Security Information 1050 Specifications" 1052 Namespace details: A registry entry for a Structured Cyber 1053 Security Information Specification (SCI specification) consists 1054 of: 1056 Namespace: A URI [RFC3986] that is the XML namespace name used 1057 by the registered SCI specification. 1059 Specification Name: A string containing the spelled-out name of 1060 the SCI specification in human-readable form. 1062 Reference URI: A list of one or more of the URIs [RFC3986] from 1063 which the registered specification can be obtained. The 1064 registered specification MUST be readily and publicly available 1065 from that URI. 1067 Applicable Classes: A list of one or more of the Extended 1068 Classes specified in Section 4.3 of this document. The 1069 registered SCI specification MUST only be used with the 1070 Extended Classes in the registry entry. 1072 Information that must be provided to assign a new value: The above 1073 list of information. 1075 Fields to record in the registry: Namespace/Specification Name/ 1076 Version/Applicable Classes. 1078 Initial registry contents: none 1080 Allocation Policy: Expert Review [RFC5226] and Specification 1081 Required [RFC5226] . 1083 The Designated Expert is expected to consult with the mile (Managed 1084 Incident Lightweight Exchange) working group or its successor if any 1085 such WG exists (e.g., via email to the working group's mailing list). 1086 The Designated Expert is expected to retrieve the SCI specification 1087 from the provided URI in order to check the public availability of 1088 the specification and verify the correctness of the URI. An 1089 important responsibility of the Designated Expert is to ensure that 1090 the registered Applicable Classes are appropriate for the registered 1091 SCI specification. 1093 8. Acknowledgment 1095 We would like to acknowledge Mr. David Black from EMC, who kindly 1096 provided generous support, especially on the IANA registry issues. 1097 We also would like to thank Jon Baker from MITRE, Eric Burger from 1098 Georgetown University, Paul Cichonski from NIST, Panos Kampanakis 1099 from CISCO, Ivan Kirillov from MITRE, Robert Martin from MITRE, 1100 Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Shuhei 1101 Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, Brian 1102 Trammell from ETH Zurich, David Waltermire from NIST, and James 1103 Wendorf from IEEE, for their sincere discussion and feedback on this 1104 document. 1106 9. References 1108 9.1. Normative References 1110 [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, 1111 "Malware Metadata Exchange Format". 1113 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1114 Requirement Levels", BCP 14, RFC 2119, March 1997. 1116 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1117 Resource Identifier (URI): Generic Syntax", STD 66, 1118 RFC 3986, January 2005. 1120 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1121 Object Description Exchange Format", RFC 5070, 1122 December 2007. 1124 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1125 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1126 May 2008. 1128 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 1129 RFC 6045, November 2010. 1131 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 1132 Inter-network Defense (RID) Messages", RFC 6046, 1133 November 2010. 1135 [EICAR] European Expert Group for IT-Security, "Anti-Malware 1136 Testfile", 2003. 1138 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1139 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1140 Edition)", W3C Recommendation, November 2008. 1142 [XMLschemaPart1] 1143 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1144 "XML Schema Part 1: Structures Second Edition", 1145 W3C Recommendation, October 2004. 1147 [XMLschemaPart2] 1148 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1149 Second Edition", W3C Recommendation, October 2004. 1151 [XMLNames] 1152 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1153 Thomson, ""Namespaces in XML (Third Edition)", 1154 W3C Recommendation, December 2009. 1156 9.2. Informative References 1158 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1159 Internet: Timestamps", RFC 3339, July 2002. 1161 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1162 Text on Security Considerations", BCP 72, RFC 3552, 1163 July 2003. 1165 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1166 January 2004. 1168 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1169 October 2008. 1171 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1172 Uniform Resource Identifiers (URI) Dynamic Delegation 1173 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1174 March 2011. 1176 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1177 and Classification (CAPEC)". 1179 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1180 (CCE)". 1182 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1183 Scoring System (CCSS)", NIST Interagency Report 7502, 1184 December 2010. 1186 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1188 [CPE] National Institute of Standards and Technology, "Common 1189 Platform Enumeration", June 2011. 1191 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1192 (CVE)". 1194 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1196 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1197 Common Vulnerability Scoring System (CVSS) and Its 1198 Applicability to Federal Agency Systems". 1200 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1201 (CWE)". 1203 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1204 (CWSS)". 1206 [MAEC] The MITRE Corporation, "Malware Attribute Enumeration and 1207 Characterization". 1209 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1210 Open Checklist Interactive Language (OCIL) Version 2.0", 1211 April 2011. 1213 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1214 Language (OVAL)". 1216 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 1217 Halbardier, "The Technical Specification for the Security 1218 Content Automation Protocol (SCAP): SCAP Version 1.2", 1219 NIST Special Publication 800-126 Revision 2, 1220 September 2011. 1222 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1223 and Neal Ziring, "Specification for the Extensible 1224 Configuration Checklist Description Format (XCCDF) version 1225 1.2 (DRAFT)", July 2011. 1227 Authors' Addresses 1229 Takeshi Takahashi 1230 National Institute of Information and Communications Technology 1231 4-2-1 Nukui-Kitamachi Koganei 1232 184-8795 Tokyo 1233 Japan 1235 Phone: +80 423 27 5862 1236 Email: takeshi_takahashi@nict.go.jp 1237 Kent Landfield 1238 McAfee, Inc 1239 5000 Headquarters Drive 1240 Plano, TX 75024 1241 USA 1243 Email: Kent_Landfield@McAfee.com 1245 Thomas Millar 1246 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1247 245 Murray Lane SW, Building 410, MS #732 1248 Washington, DC 20598 1249 USA 1251 Phone: +1 888 282 0870 1252 Email: thomas.millar@us-cert.gov 1254 Youki Kadobayashi 1255 Nara Institute of Science and Technology 1256 8916-5 Takayama, Ikoma 1257 630-0192 Nara 1258 Japan 1260 Email: youki-k@is.aist-nara.ac.jp