idnits 2.17.1 draft-ietf-mile-sci-12.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 10 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 (Dec 1, 2013) is 3799 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 1211, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'RFC6116' is defined on line 1228, 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) -- 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: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group T. Takahashi 3 Internet-Draft NICT 4 Intended status: Standards Track K. Landfield 5 Expires: June 4, 2014 McAfee 6 T. Millar 7 USCERT 8 Y. Kadobayashi 9 NAIST 10 Dec 1, 2013 12 IODEF-extension for structured cybersecurity information 13 draft-ietf-mile-sci-12.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 security experts at organizations and 20 facilitates their operations. It provides a well-defined pattern to 21 consistently embed structured information, such as identifier- and 22 XML-based information. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 4, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. IANA Table for Structured Cybersecurity Information . . . 5 63 4.2. Extended Data Type: XMLDATA . . . . . . . . . . . . . . . 6 64 4.3. Extending IODEF . . . . . . . . . . . . . . . . . . . . . 6 65 4.4. Basic Structure of the Extension Classes . . . . . . . . . 7 66 4.5. Defining Extension Classes . . . . . . . . . . . . . . . . 9 67 4.5.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 9 68 4.5.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.5.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 10 70 4.5.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.5.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.5.6. EventReport . . . . . . . . . . . . . . . . . . . . . 13 73 4.5.7. Verification . . . . . . . . . . . . . . . . . . . . . 14 74 4.5.8. Remediation . . . . . . . . . . . . . . . . . . . . . 15 75 5. Mandatory to Implement features . . . . . . . . . . . . . . . 15 76 5.1. An Example XML . . . . . . . . . . . . . . . . . . . . . . 16 77 5.2. An XML Schema for the Extension . . . . . . . . . . . . . 18 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 22 80 6.2. Protection of Sensitive and Private Information . . . . . 23 81 6.3. Application and Server Security . . . . . . . . . . . . . 24 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 89 1. Introduction 91 The number of incidents in cyber society is growing day by day. 92 Incident information needs to be reported, exchanged, and shared 93 among organizations in order to cope with the situation. IODEF is 94 one of the tools already in use that enables such an exchange. 96 To more efficiently run security operations, information exchanged 97 between organizations needs to be machine readable. IODEF provides a 98 means to describe the incident information, but it often needs to 99 include various non-structured types of incident-related data in 100 order to convey more specific details about what is occurring. 101 Further structure within IODEF increases the machine-readability of 102 the document thus providing a means for better automating certain 103 security operations. 105 Within the security community there exist various means for 106 specifying structured descriptions of cybersecurity information such 107 as [CAPEC][CCE][CCSS][CEE][CPE][CVE][CVRF][CVSS][CWE][CWSS][MAEC] 108 [OCIL][OVAL][SCAP][XCCDF]. In this context, cybersecurity 109 information encompasses a broad range of structured data 110 representation types that may be used to assess or report on the 111 security posture of an asset or set of assets. Such structured 112 descriptions facilitates a better understanding of an incident while 113 enabling more streamlined automated security operations. Because of 114 this, it would be beneficial to embed and convey these types of 115 information inside IODEF documents. 117 This document extends IODEF to embed and convey various types of 118 structured information. Since IODEF defines a flexible and 119 extensible format and supports a granular level of specificity, this 120 document defines an extension to IODEF instead of defining a new 121 report format. For clarity, and to eliminate duplication, only the 122 additional structures necessary for describing the exchange of such 123 structured information are provided. 125 2. Terminology 127 The terminology used in this document follows the one defined in RFC 128 5070 [RFC5070]. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 3. Applicability 136 To maintain awareness of the continually changing security threat 137 landscape, organization needs to exchange cybersecurity information, 138 which includes the following information: attack pattern, platform 139 information, vulnerability and weakness, countermeasure instruction, 140 computer event logs, and severity assessments. IODEF provides a 141 scheme to describe and exchange such information among interested 142 parties. However, it does not define the detailed formats to specify 143 such information. 145 There already exists structured and detailed formats for describing 146 these types of information that can be used in facilitating such an 147 exchange. They include [CAPEC][CCE][CCSS][CEE][CPE] 148 [CVE][CVRF][CVSS][CWE][CWSS][MAEC][OCIL][OVAL][SCAP][XCCDF]. By 149 embedding them into the IODEF document, the document can convey more 150 detailed context information to the receivers, and the document can 151 be easily reused. 153 The use of structured information formats facilitates more advanced 154 security operations on the receiver side. Since the information is 155 machine readable, the data can be processed by computers thus 156 allowing better automation of security operations. 158 For instance, an organization wishing to report a security incident 159 wants to describe what vulnerability was exploited. In this case the 160 sender can simply use IODEF, where an XML-based [XML1.0] attack 161 pattern record that follows the syntax and vocabulary defined by an 162 industry specification is embedded, instead of describing everything 163 in free form text. The receiver can identify the needed details of 164 the attack pattern by looking up some of the XML tags defined by the 165 specification. The receiver can accumulate the attack pattern record 166 in its database and could distribute it to the interested parties as 167 needed, all without requiring human interventions. 169 In another example, an administrator is investigating an incident and 170 detected a configuration problem that he wishes to share with a 171 partner organization to prevent the same event from occurring. He 172 accesses configuration information in an internal repository that was 173 gathered prior to the initial attack specific to a new vulnerability 174 alert to confirm the configuration was in fact vulnerable. He uses 175 this information to automatically generate an XML-based software 176 configuration description, embed it in an IODEF document, and send 177 the resulting IODEF document to the partner organization. 179 4. Extension Definition 181 This document extends IODEF to embed structured information by 182 introducing new classes that can be embedded consistently inside an 183 IODEF document as element contents of the AdditionalData and 184 RecordItem classes. 186 4.1. IANA Table for Structured Cybersecurity Information 188 This extension embeds structured cybersecurity information defined by 189 other specifications. The list of supported specifications is 190 managed by IANA, and this document defines the needed fields for the 191 list's entry. 193 Each entry has namespace [XMLNames], specification name, version, 194 reference URI, and applicable classes for each specification. 195 Arbitrary URIs that may help readers to understand the specification 196 could be embedded inside the Reference URI field, but it is 197 recommended that standard/informational URI describing the 198 specification is prepared and is embedded here. 200 The initial IANA table has only one entry, as below. 202 Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2 203 Specification Name: Malware Metadata Exchange Format 204 Version: 1.2 205 Reference URI: http://standards.ieee.org/develop 206 /indconn/icsg/mmdef.html, 207 http://grouper.ieee.org/groups 208 /malware/malwg/Schema1.2/ 209 Applicable Classes: AttackPattern 211 Note that the specification was developed by The Institute of 212 Electrical and Electronics Engineers, Incorporated (IEEE), through 213 the Industry Connections Security Group (ICSG) of its Standards 214 Association. 216 The table is to be managed by IANA following the allocation policy 217 specified in Section 7. 219 The SpecID attributes of extension classes (Section 4.5) must allow 220 the values of the specifications' namespace fields, but otherwise, 221 implementations are not required to support all specifications of the 222 IANA table and may choose which specifications to support, though the 223 specification listed in the initial table needs to be minimally 224 supported, as described in Section 5. In case an implementation 225 received a data it does not support, it may expand its functionality 226 by looking up the IANA table or notify the sender of its inability to 227 parse the data. Note that the look-up could be done manually or 228 automatically, but automatic download of data from IANA's website is 229 not recommended since it is not designed for mass retrieval of data 230 by multiple devices. 232 4.2. Extended Data Type: XMLDATA 234 This extension inherits all of the data types defined in the IODEF 235 data model. One data type is added: XMLDATA. An embedded XML data 236 is represented by the XMLDATA data type. This type is defined as the 237 extension to the iodef:ExtensionType [RFC5070], whose dtype attribute 238 is set to "xml". 240 4.3. Extending IODEF 242 This document defines eight extension classes, namely AttackPattern, 243 Platform, Vulnerability, Scoring, Weakness, EventReport, Verification 244 and Remediation. Figure 1 describes the relationships between the 245 IODEF Incident class [RFC5070] and the newly defined classes. It is 246 expressed in Unified Modeling Language (UML) syntax as with the RFC 247 5070 [RFC5070]. The UML representation is for illustrative purposes 248 only; elements are specified in XML as defined in Section 5.2. 250 +---------------+ 251 | Incident | 252 +---------------+ 253 | ENUM purpose |<>---------[IncidentID] 254 | STRING |<>--{0..1}-[AlternativeID] 255 | ext-purpose |<>--{0..1}-[RelatedActivity] 256 | ENUM lang |<>--{0..1}-[DetectTime] 257 | ENUM |<>--{0..1}-[StartTime] 258 | restriction |<>--{0..1}-[EndTime] 259 | |<>---------[ReportTime] 260 | |<>--{0..*}-[Description] 261 | |<>--{1..*}-[Assessment] 262 | |<>--{0..*}-[Method] 263 | | |<>--{0..*}-[AdditionalData] 264 | | |<>--{0..*}-[AttackPattern] 265 | | |<>--{0..*}-[Vulnerability] 266 | | |<>--{0..*}-[Weakness] 267 | |<>--{1..*}-[Contact] 268 | |<>--{0..*}-[EventData] 269 | | |<>--{0..*}-[Flow] 270 | | | |<>--{1..*}-[System] 271 | | | |<>--{0..*}-[AdditionalData] 272 | | | |<>--{0..*}-[Platform] 273 | | |<>--{0..*}-[Expectation] 274 | | |<>--{0..1}-[Record] 275 | | |<>--{1..*}-[RecordData] 276 | | |<>--{1..*}-[RecordItem] 277 | | |<>--{0..*}-[EventReport] 278 | |<>--{0..1}-[History] 279 | |<>--{0..*}-[AdditionalData] 280 | | |<>--{0..*}-[Verification] 281 | | |<>--{0..*}-[Remediation] 282 +---------------+ 284 Figure 1: Incident class 286 4.4. Basic Structure of the Extension Classes 288 Figure 2 shows the basic structure of the extension classes. Some of 289 the extension classes have extra elements as defined in Section 4.5, 290 but the basic structure is the same. 292 +---------------------+ 293 | New Class Name | 294 +---------------------+ 295 | ENUM SpecID |<>--(0..*)-[ RawData ] 296 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 297 | STRING ContentID | 298 +---------------------+ 300 Figure 2: Basic Structure 302 Three attributes are defined as below. 304 SpecID: REQUIRED. ENUM. A specification's identifier that 305 specifies the format of a structured information. The value 306 should be chosen from the namespaces [XMLNames] listed in the IANA 307 table (Section 4.1) or "private". The value "private" is prepared 308 for conveying structured information based on a format that is not 309 listed in the table. This is usually used for conveying data 310 formatted according to an organization's private schema. When the 311 value "private" is used, ext-SpecID element MUST be used. 313 ext-SpecID: OPTIONAL. STRING. A specification's identifier that 314 specifies the format of a structured information. This is usually 315 used to support private schema that is not listed in the IANA 316 table (Section 4.1). This attribute MUST be used only when the 317 value of SpecID element is "private." 319 ContentID: OPTIONAL. STRING. An identifier of a structured 320 information. Depending on the extension classes, the content of 321 the structured information differs. This attribute enables IODEF 322 documents to covey the identifier of a structured information 323 instead of conveying the information itself. 325 Likewise, three elements are defined as below. 327 RawData: Zero or more. XMLDATA. An XML of a structured 328 information. This is a complete document that is formatted 329 according to the specification and its version identified by the 330 SpecID/ext-SpecID. When this element is used, writers/senders 331 MUST ensure that the namespace specified by SpecID/ext-SpecID and 332 the schema of the XML are consistent; if not, the namespace 333 identified by SpecID SHOULD be preferred, and the inconsistency 334 SHOULD be logged so a human can correct the problem. 336 Reference: Zero or more of iodef:Reference [RFC5070]. A reference 337 to a structured information. This element allows an IODEF 338 document to include a link to a structured information instead of 339 directly embedding it into a RawData element. 341 Though ContentID, RawData, and Reference are optional attribute and 342 elements, one of them MUST be used to convey structured information. 343 Note that only one of them SHOULD be used to avoid confusing the 344 receiver. 346 4.5. Defining Extension Classes 348 This document defines the following seven extension classes. 350 4.5.1. AttackPattern 352 An AttackPattern is an extension class to the 353 Incident.Method.AdditionalData element with a dtype of "xml". It 354 describes attack patterns of incidents or events. It is RECOMMENDED 355 that Method class contain the extension elements whenever available. 356 An AttackPattern class is structured as follows. 358 +---------------------+ 359 | AttackPattern | 360 +---------------------+ 361 | ENUM SpecID |<>--(0..*)-[ RawData ] 362 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 363 | STRING ContentID |<>--(0..*)-[ Platform ] 364 +---------------------+ 366 Figure 3: AttackPattern class 368 This class has the following attributes. 370 SpecID: REQUIRED. ENUM. See Section 4.4. 372 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 374 ContentID: OPTIONAL. STRING. An identifier of an attack pattern 375 information. See Section 4.4. 377 Likewise, this class has the following elements. 379 RawData: Zero or more. XMLDATA. An XML of an attack pattern 380 information. See Section 4.4. 382 Reference: Zero or more. A reference to an attack pattern 383 information. See Section 4.4. 385 Platform: Zero or more. An identifier of software platform involved 386 in the specific attack pattern. See Section 4.5.2. 388 4.5.2. Platform 390 A Platform is an extension class that identifies a software platform. 391 It is RECOMMENDED that AttackPattern, Vulnerability, Weakness, and 392 System classes contain the extension elements whenever available. A 393 Platform element is structured as follows. 395 +---------------------+ 396 | Platform | 397 +---------------------+ 398 | ENUM SpecID |<>--(0..*)-[ RawData ] 399 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 400 | STRING ContentID | 401 +---------------------+ 403 Figure 4: Platform class 405 This class has the following attributes. 407 SpecID: REQUIRED. ENUM. See Section 4.4. 409 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 411 ContentID: OPTIONAL. STRING. An identifier of a platform 412 information. See Section 4.4. 414 Likewise, this class has the following elements. 416 RawData: Zero or more. XMLDATA. An XML of a platform information. 417 See Section 4.4. 419 Reference: Zero or more. A reference to a platform information. 420 See Section 4.4. 422 4.5.3. Vulnerability 424 A Vulnerability is an extension class to the 425 Incident.Method.AdditionalData element with a dtype of "xml". The 426 extension describes the vulnerabilities that are exposed or were 427 exploited in incidents. It is RECOMMENDED that Method class contain 428 the extension elements whenever available. A Vulnerability element 429 is structured as follows. 431 +---------------------+ 432 | Vulnerability | 433 +---------------------+ 434 | ENUM SpecID |<>--(0..*)-[ RawData ] 435 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 436 | STRING ContentID |<>--(0..*)-[ Platform ] 437 | |<>--(0..*)-[ Scoring ] 438 +---------------------+ 440 Figure 5: Vulnerability class 442 This class has the following attributes. 444 SpecID: REQUIRED. ENUM. See Section 4.4. 446 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 448 ContentID: OPTIONAL. STRING. An identifier of a vulnerability 449 information. See Section 4.4. 451 Likewise, this class has the following elements. 453 RawData: Zero or more. XMLDATA. An XML of a vulnerability 454 information. See Section 4.4. 456 Reference: Zero or more. A reference to a vulnerability 457 information. See Section 4.4. 459 Platform: Zero or more. An identifier of software platform affected 460 by the vulnerability. See Section 4.5.2. 462 Scoring: Zero or more. An indicator of the severity of the 463 vulnerability. See Section 4.5.4. 465 4.5.4. Scoring 467 A Scoring is an extension class that describes the severity scores in 468 terms of security. It is RECOMMENDED that Vulnerability and Weakness 469 classes contain the extension elements whenever available. A Scoring 470 class is structured as follows. 472 +---------------------+ 473 | Scoring | 474 +---------------------+ 475 | ENUM SpecID |<>--(0..*)-[ RawData ] 476 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 477 | STRING ContentID | 478 +---------------------+ 480 Figure 6: Scoring class 482 This class has two attributes. 484 SpecID: REQUIRED. ENUM. See Section 4.4. 486 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 488 ContentID: OPTIONAL. STRING. An identifier of a score set. See 489 Section 4.4. 491 Likewise, this class has the following elements. 493 RawData: Zero or more. XMLDATA. An XML of a score set. See 494 Section 4.4. 496 Reference: Zero or more. A reference to a score set. See 497 Section 4.4. 499 4.5.5. Weakness 501 A Weakness is an extension class to the 502 Incident.Method.AdditionalData element with a dtype of "xml". The 503 extension describes the weakness types that are exposed or were 504 exploited in incidents. It is RECOMMENDED that Method class contain 505 the extension elements whenever available. A Weakness element is 506 structured as follows. 508 +---------------------+ 509 | Weakness | 510 +---------------------+ 511 | ENUM SpecID |<>--(0..*)-[ RawData ] 512 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 513 | STRING ContentID |<>--(0..*)-[ Platform ] 514 | |<>--(0..*)-[ Scoring ] 515 +---------------------+ 517 Figure 7: Weakness class 519 This class has the following attributes. 521 SpecID: REQUIRED. ENUM. See Section 4.4. 523 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 525 ContentID: OPTIONAL. STRING. An identifier of a weakness 526 information. See Section 4.4. 528 Likewise, this class has the following elements. 530 RawData: Zero or more. XMLDATA. An XML of a weakness information. 531 See Section 4.4. 533 Reference: Zero or more. A reference to a weakness information. 534 See Section 4.4. 536 Platform: Zero or more. An identifier of software platform affected 537 by the weakness. See Section 4.5.2. 539 Scoring: Zero or more. An indicator of the severity of the 540 weakness. See Section 4.5.4. 542 4.5.6. EventReport 544 An EventReport is an extension class to the 545 Incident.EventData.Record.RecordData.RecordItem element with a dtype 546 of "xml". The extension embeds structured event reports. It is 547 RECOMMENDED that RecordItem class contain the extension elements 548 whenever available. An EventReport element is structured as follows. 550 +---------------------+ 551 | EventReport | 552 +---------------------+ 553 | ENUM SpecID |<>--(0..*)-[ RawData ] 554 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 555 | STRING ContentID | 556 +---------------------+ 558 Figure 8: EventReport class 560 This class has the following attributes. 562 SpecID: REQUIRED. ENUM. See Section 4.4. 564 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 566 ContentID: OPTIONAL. STRING. An identifier of an event report. 567 See Section 4.4. 569 Likewise, this class has the following elements. 571 RawData: Zero or more. XMLDATA. An XML of an event report. See 572 Section 4.4. 574 Reference: Zero or more. A reference to an event report. See 575 Section 4.4. 577 4.5.7. Verification 579 A Verification is an extension class to the Incident.AdditionalData 580 element with a dtype of "xml". The extension elements describes 581 information on verifying security, e.g., checklist, to cope with 582 incidents. It is RECOMMENDED that Incident class contain the 583 extension elements whenever available. A Verification class is 584 structured as follows. 586 +---------------------+ 587 | Verification | 588 +---------------------+ 589 | ENUM SpecID |<>--(0..*)-[ RawData ] 590 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 591 | STRING ContentID | 592 +---------------------+ 594 Figure 9: Verification class 596 This class has the following attributes. 598 SpecID: REQUIRED. ENUM. See Section 4.4. 600 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 602 ContentID: OPTIONAL. STRING. An identifier of a verification 603 information. See Section 4.4. 605 Likewise, this class has the following elements. 607 RawData: Zero or more. XMLDATA. An XML of a verification 608 information. See Section 4.4. 610 Reference: Zero or more. A reference to a verification information. 611 See Section 4.4. 613 4.5.8. Remediation 615 A Remediation is an extension class to the Incident.AdditionalData 616 element with a dtype of "xml". The extension elements describes 617 incident remediation information including instructions. It is 618 RECOMMENDED that Incident class contain the extension elements 619 whenever available. A Remediation class is structured as follows. 621 +---------------------+ 622 | Remediation | 623 +---------------------+ 624 | ENUM SpecID |<>--(0..*)-[ RawData ] 625 | STRING ext-SpecID |<>--(0..*)-[ Reference ] 626 | String ContentID | 627 +---------------------+ 629 Figure 10: Remediation class 631 This class has the following attributes. 633 SpecID: REQUIRED. ENUM. See Section 4.4. 635 ext-SpecID: OPTIONAL. STRING. See Section 4.4. 637 ContentID: OPTIONAL. STRING. An identifier of a remediation 638 information. See Section 4.4. 640 Likewise, this class has the following elements. 642 RawData: Zero or more. XMLDATA. An XML of a remediation 643 information. See Section 4.4. 645 Reference: Zero or more. A reference to a remediation information. 646 See Section 4.4. 648 5. Mandatory to Implement features 650 The implementation of this document MUST be capable of sending and 651 receiving the XML conforming to the specification listed in the 652 initial IANA table described in Section 4.1 without error. The 653 receiver MUST be capable of validating received XML documents that 654 are embedded inside that against their schemata. Note that the 655 receiver can look up the namespace in the IANA table to understand 656 what specifications the embedded XML documents follows. 658 For the purpose of facilitating the understanding of mandatory to 659 implement features, the following subsections provide an XML 660 conformant to this document, and a schema for that. 662 5.1. An Example XML 664 An example IODEF document for checking implementation's MTI 665 conformity is provided here. The document carries MMDEF metadata. 666 Note that the metadata is generated by genMMDEF [MMDEF] with EICAR 667 [EICAR] files. Implementations of this specification must be capable 668 of parsing the example XML since MMDEF is specified as the document's 669 MTI specification. 671 672 677 678 189493 679 2013-06-18T23:19:24+00:00 680 a candidate security incident 681 682 683 684 685 A candidate attack event 686 687 689 690 694 N/A 695 MMDEF Generation Script 696 Test MMDEF v1.2 file generated using genMMDEF 697 698 2013-03-23T15:12:50.726000 699 700 701 6ce6f415d8475545be5ba114f208b0ff 702 da39a3ee5e6b4b0d3255bfef95601890afd80709 703 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4 704 95991b7852b855 705 cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83 706 f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9 707 31bd47417a81a538327af927da3e 708 184 709 eicar_com.zip 710 application/zip 711 712 713 44d88612fea8a8f36de82e1278abb02f 714 3395856ce81f2b7382dee72602f798b642f14140 715 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4 716 538aabf651fd0f 717 cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e 718 68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0 719 dc9a061d9e507d833277ada336ab 720 68 721 1750191932 722 eicar.com 723 eicar.com 724 725 726 727 728 729 730 file[@id="6ce6f415d8475545be5ba114f208b0ff"] 731 732 733 file[@id="44d88612fea8a8f36de82e1278abb02f"] 734 735 2013-03-23T15:12:50.744000 736 737 738 739 740 741 742 743 744 iodef-sci.example.com 745 iodef-sci.example-com 746 747 contact@csirt.example.com 748 749 750 751 752 753
192.0.2.200
754 57 755 756 757 758 759
192.0.2.16/28
760 761 762 80 763 764 765 766 767 768 769 770 772 5.2. An XML Schema for the Extension 774 An XML Schema describing the elements defined in this document is 775 given here. Any XMLs compliant to this document including the ones 776 in Section 5.1 should be verified against this schema by automated 777 tools. 779 781 787 790 791 792 793 794 796 797 799 800 801 802 803 804 805 807 808 809 810 811 813 815 816 817 818 820 822 823 825 826 827 828 829 831 833 834 836 837 838 840 842 843 845 846 847 848 849 851 853 854 856 858 859 860 862 864 865 867 868 869 870 871 873 875 876 878 880 881 882 884 886 887 889 890 891 892 893 895 897 899 900 901 903 905 906 908 909 910 911 912 914 916 917 918 919 921 923 924 926 927 928 929 930 932 934 935 936 937 939 941 942 944 945 946 947 948 950 952 953 954 955 957 959 960 962 964 6. Security Considerations 966 This document specifies a format for encoding a particular class of 967 security incidents appropriate for exchange across organizations. As 968 merely a data representation, it does not directly introduce security 969 issues. However, it is guaranteed that parties exchanging instances 970 of this specification will have certain concerns. For this reason, 971 the underlying message format and transport protocol used MUST ensure 972 the appropriate degree of confidentiality, integrity, and 973 authenticity for the specific environment. Specific security 974 considerations are detailed in the messaging and transport documents, 975 where the exchange of formatted information is automated. See Real- 976 time Inter-network Defense (RID) [RFC6545] Section 9 for a detailed 977 overview of security requirements and considerations. 979 It is RECOMMENDED that organizations who exchange data using this 980 document develop operating procedures that minimally consider the 981 following areas of concern. 983 6.1. Transport-Specific Concerns 985 The underlying messaging format, IODEF, provides data markers to 986 indicate the sensitivity level of specific classes within the 987 structure as well as for the entire XML document. The "restriction" 988 attribute accomplishes this with four attribute values in IODEF. 989 These values are RECOMMENDED for use at the application level, prior 990 to transport, to protect data as appropriate. A standard mechanism 991 to apply XML encryption using these attribute values as triggers is 992 defined in RID [RFC6545] Section 9.1. This mechanism may be used 993 whether or not the RID and RID Transport binding [RFC6546] are used 994 in the exchange to provide object level security on the data to 995 prevent possible intermediary systems or middle-boxes from having 996 access to the data being exchanged. In areas where transmission 997 security or secrecy is questionable, the application of a XML digital 998 signature [xmldsig] and/or encryption on each report will counteract 999 both of these concerns. The data markers are RECOMMENDED for use by 1000 applications for managing access controls, however access controls 1001 and management of those controls are out-of-scope for this document. 1002 Options such as the usage of a standard language (e.g. XACML 1003 [XACML]) for the expression of authorization policies can be used to 1004 enable source and destination systems to better coordinate and align 1005 their respective policy expressions. 1007 Any transport protocol used to exchange instances of IODEF documents 1008 MUST provide appropriate guarantees of confidentiality, integrity, 1009 and authenticity. The use of a standardized security protocol is 1010 encouraged. The RID protocol [RFC6545] and its associated transport 1011 binding [RFC6546] provide such security with options for mutual 1012 authentication session encryption and include application levels 1013 concerns such as policy and work flow. 1015 The critical security concerns are that these structured information 1016 may be falsified, accessed by unintended entities, or they may become 1017 corrupt during transit. We expect that each exchanging organization 1018 will determine the need, and mechanism, for transport protection. 1020 6.2. Protection of Sensitive and Private Information 1022 For a complete review of privacy considerations when transporting 1023 incident related information, please see RID [RFC6545] Section 9.5. 1024 Whether or not the RID protocol is used, the privacy considerations 1025 are important to consider as incident information is often sensitive 1026 and may contain privacy related information about individuals/ 1027 organizations or endpoints involved. Often times, organizations will 1028 require legal review and formal polices to be established which 1029 outline specific details of what information can be exchanged with 1030 specific entities. Typically, identifying information is anonymized 1031 where possible and appropriate. In some cases, information brokers 1032 are used to further anonymize the source of exchanged information so 1033 that other entities are unaware of the origin of a detected threat, 1034 whether or not that threat was realized. 1036 It is RECOMMENDED that policies and procedures for the exchange of 1037 cybersecurity information are established prior to participation in 1038 data exchanges. Policy and workflow procedures for the exchange of 1039 cybersecurity information often require executive level approvals and 1040 legal reviews to appropriately establish limits on what information 1041 can be exchanged with specific organizations. RID [RFC6545] Section 1042 9.6 outlines options and considerations for application developers to 1043 consider for the policy and workflow design. 1045 6.3. Application and Server Security 1047 The Cybersecurity Information extension is merely a data format. 1048 Applications and transport protocols that store or exchange IODEF 1049 documents using information that can be represented through this 1050 extension will be a target for attacks. It is RECOMMENDED that 1051 systems and applications storing or exchanging this information are 1052 properly secured, have minimal services enabled, maintain access 1053 controls and monitoring procedures. 1055 7. IANA Considerations 1057 This document uses URNs to describe XML namespaces and XML schemata 1058 [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism 1059 described in [RFC3688]. 1061 Registration request for the IODEF structured cybersecurity 1062 information extension namespace: 1064 URI: urn:ietf:params:xml:ns:iodef-sci-1.0 1066 Registrant Contact: Refer here to the authors' addresses section 1067 of the document. 1069 XML: None. 1071 Registration request for the IODEF structured cybersecurity 1072 information extension XML schema: 1074 URI: urn:ietf:params:xml:schema:iodef-sci-1.0 1076 Registrant Contact: Refer here to the authors' addresses section 1077 of the document. 1079 XML: Refer here to the XML Schema in Section 5.2. 1081 This memo creates the following registry for IANA to manage: 1083 Name of the registry: "Structured Cybersecurity Information (SCI) 1084 specifications" 1086 Name of its parent registry: "Incident Object Description Exchange 1087 Format (IODEF)" 1088 URL address of the registry: http://www.iana.org/assignments/iodef 1090 Namespace details: A registry entry for a Structured Cybersecurity 1091 Information Specification (SCI specification) consists of: 1093 Namespace: A URI [RFC3986] that identifies the XML namespace 1094 used by the registered SCI specification. In the case where 1095 the registrant does not request a particular URI, the IANA will 1096 assign it a Uniform Resource Name (URN) that follows RFC 3553 1097 [RFC3553] 1099 Specification Name: A string containing the spelled-out name of 1100 the SCI specification in human-readable form. 1102 Reference URI: A list of one or more of the URIs [RFC3986] from 1103 which the registered specification can be obtained. The 1104 registered specification MUST be readily and publicly available 1105 from that URI. 1107 Applicable Classes: A list of one or more of the extension 1108 classes specified in Section 4.5 of this document. The 1109 registered SCI specification MUST only be used with the 1110 extension classes in the registry entry. 1112 Information that must be provided to assign a new value: The above 1113 list of information. 1115 Fields to record in the registry: Namespace/Specification Name/ 1116 Version/Reference URI/Applicable Classes. Note that it is not 1117 necessary to include defining reference for all assignments in 1118 this new registry. 1120 Initial registry contents: only one entry with the following 1121 values. 1123 Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.0 1125 Specification Name: Malware Metadata Exchange Format 1127 Version: 1.2 1129 Reference URI: http://standards.ieee.org/develop/indconn/icsg/ 1130 mmdef.html,http://grouper.ieee.org/groups/malware/malwg/ 1131 Schema1.2/ 1133 Applicable Classes: AttackPattern 1135 Allocation Policy: Specification Required (which includes Expert 1136 Review) [RFC5226]. 1138 The Designated Expert is expected to consult with the mile (Managed 1139 Incident Lightweight Exchange) working group or its successor if any 1140 such WG exists (e.g., via email to the working group's mailing list). 1141 The Designated Expert is expected to retrieve the SCI specification 1142 from the provided URI in order to check the public availability of 1143 the specification and verify the correctness of the URI. An 1144 important responsibility of the Designated Expert is to ensure that 1145 the registered Applicable Classes are appropriate for the registered 1146 SCI specification. 1148 8. Acknowledgment 1150 We would like to acknowledge David Black from EMC, who kindly 1151 provided generous support, especially on the IANA registry issues. 1152 We also would like to thank Jon Baker from MITRE, Eric Burger from 1153 Georgetown University, Paul Cichonski from NIST, Panos Kampanakis 1154 from CISCO, Pearl Liang from IANA, Ivan Kirillov from MITRE, Robert 1155 Martin from MITRE, Alexey Melnikov from Isode, Kathleen Moriarty from 1156 EMC, Lagadec Philippe from NATO, Sean Turner from IECA Inc., Shuhei 1157 Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, Brian 1158 Trammell from ETH Zurich, David Waltermire from NIST, and James 1159 Wendorf from IEEE, for their sincere discussion and feedback on this 1160 document. 1162 9. References 1164 9.1. Normative References 1166 [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, 1167 "Malware Metadata Exchange Format". 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, March 1997. 1172 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1173 Resource Identifier (URI): Generic Syntax", STD 66, 1174 RFC 3986, January 2005. 1176 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1177 Object Description Exchange Format", RFC 5070, 1178 December 2007. 1180 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1181 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1182 May 2008. 1184 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", 1185 RFC 6545, April 2012. 1187 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 1188 Defense (RID) Messages over HTTP/TLS", RFC 6546, 1189 April 2012. 1191 [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and 1192 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1193 Edition)", W3C Recommendation, November 2008. 1195 [XMLschemaPart1] 1196 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1197 "XML Schema Part 1: Structures Second Edition", 1198 W3C Recommendation, October 2004. 1200 [XMLschemaPart2] 1201 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1202 Second Edition", W3C Recommendation, October 2004. 1204 [XMLNames] 1205 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1206 Thomson, ""Namespaces in XML (Third Edition)", 1207 W3C Recommendation, December 2009. 1209 9.2. Informative References 1211 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1212 Internet: Timestamps", RFC 3339, July 2002. 1214 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1215 Text on Security Considerations", BCP 72, RFC 3552, 1216 July 2003. 1218 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1219 IETF URN Sub-namespace for Registered Protocol 1220 Parameters", BCP 73, RFC 3553, June 2003. 1222 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1223 January 2004. 1225 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1226 October 2008. 1228 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1229 Uniform Resource Identifiers (URI) Dynamic Delegation 1230 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1231 March 2011. 1233 [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration 1234 and Classification (CAPEC)". 1236 [CCE] The MITRE Corporation, "Common Configuration Enumeration 1237 (CCE)". 1239 [CCSS] Scarfone, K. and P. Mell, "The Common Configuration 1240 Scoring System (CCSS)", NIST Interagency Report 7502, 1241 December 2010. 1243 [CEE] The MITRE Corporation, "Common Event Expression (CEE)". 1245 [CPE] National Institute of Standards and Technology, "Common 1246 Platform Enumeration", June 2011. 1248 [CVE] The MITRE Corporation, "Common Vulnerability and Exposures 1249 (CVE)". 1251 [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". 1253 [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The 1254 Common Vulnerability Scoring System (CVSS) and Its 1255 Applicability to Federal Agency Systems". 1257 [CWE] The MITRE Corporation, "Common Weakness Enumeration 1258 (CWE)". 1260 [CWSS] The MITRE Corporation, "Common Weakness Scoring System 1261 (CWSS)". 1263 [EICAR] European Expert Group for IT-Security, "Anti-Malware 1264 Testfile", 2003. 1266 [MAEC] The MITRE Corporation, "Malware Attribute Enumeration and 1267 Characterization". 1269 [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The 1270 Open Checklist Interactive Language (OCIL) Version 2.0", 1271 April 2011. 1273 [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment 1274 Language (OVAL)". 1276 [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. 1278 Halbardier, "The Technical Specification for the Security 1279 Content Automation Protocol (SCAP): SCAP Version 1.2", 1280 NIST Special Publication 800-126 Revision 2, 1281 September 2011. 1283 [XACML] Rissanen, E., "eXtensible Access Control Markup Language 1284 (XACML) Version 3.0", January 2013, . 1288 [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone 1289 and Neal Ziring, "Specification for the Extensible 1290 Configuration Checklist Description Format (XCCDF) version 1291 1.2 (DRAFT)", July 2011. 1293 [xmldsig] W3C Recommendation, "XML Signature Syntax and Processing 1294 (Second Edition)", June 2008. 1296 Authors' Addresses 1298 Takeshi Takahashi 1299 National Institute of Information and Communications Technology 1300 4-2-1 Nukui-Kitamachi Koganei 1301 184-8795 Tokyo 1302 Japan 1304 Phone: +80 423 27 5862 1305 Email: takeshi_takahashi@nict.go.jp 1307 Kent Landfield 1308 McAfee, Inc 1309 5000 Headquarters Drive 1310 Plano, TX 75024 1311 USA 1313 Email: Kent_Landfield@McAfee.com 1314 Thomas Millar 1315 US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 1316 245 Murray Lane SW, Building 410, MS #732 1317 Washington, DC 20598 1318 USA 1320 Phone: +1 888 282 0870 1321 Email: thomas.millar@us-cert.gov 1323 Youki Kadobayashi 1324 Nara Institute of Science and Technology 1325 8916-5 Takayama, Ikoma 1326 630-0192 Nara 1327 Japan 1329 Email: youki-k@is.aist-nara.ac.jp