MILE Working Group T. Takahashi Internet-Draft NICT Intended status: Standards Track K. Landfield Expires: January 5, 2014 McAfee T. Millar USCERT Y. Kadobayashi NAIST Jul 4, 2013 IODEF-extension for structured cybersecurity information draft-ietf-mile-sci-08.txt Abstract This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Takahashi, et al. Expires January 5, 2014 [Page 1] Internet-Draft IODEF-SCI Jul 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 4.1. IANA Table for Structured Cybersecurity Information . . . 4 4.2. Extended Data Type: XMLDATA . . . . . . . . . . . . . . . 5 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 7 4.3.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 9 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 12 4.3.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 13 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 14 5. Mandatory to Implement features . . . . . . . . . . . . . . . 16 5.1. An Example XML . . . . . . . . . . . . . . . . . . . . . . 16 5.2. An XML Schema for the Extension . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Appendix I: Candidate Specifications for the IANA Table . . . 25 10. Appendix II: MMDEF version 1.2 scheema . . . . . . . . . . . . 29 11. Appendix III: An Example XML using Candidate Specifications . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Takahashi, et al. Expires January 5, 2014 [Page 2] Internet-Draft IODEF-SCI Jul 2013 1. Introduction The number of cyber attacks is growing day by day, and incident information needs to be reported, exchanged, and shared among organizations in order to cope with the situation. IODEF is one of the tools enabling such exchange, and is already in use. To efficiently run cybersecurity operations, these exchanged information needs to be machine-readable. IODEF provides a structured means to describe the information, but it needs to embed various non-structured such information in order to convey detailed information. Further structure within IODEF increases IODEF documents' machine-readability and thus facilitates streamlining cybersecurity operations. On the other hand, there exist various other activities facilitating detailed and structured description of cybersecurity information, as listed in Section 9 . Since such structured description facilitates cybersecurity operations, it would be beneficial to embed and convey these information inside IODEF document. To enable that, this document extends the IODEF to embed and convey various structured cybersecurity information, with which cybersecurity operations can be facilitated. Since IODEF defines a flexible and extensible format and supports a granular level of specificity, this document defines an extension to IODEF instead of defining a new report format. For clarity, and to eliminate duplication, only the additional structures necessary for describing the exchange of such structured information are provided. 2. Terminology The terminology used in this document follows the one defined in RFC 5070 [RFC5070] . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] . 3. Applicability To maintain cybersecurity, organization needs to exchange cybersecurity information, which includes the following information: attack pattern, platform information, vulnerability and weakness, countermeasure instruction, computer event log, and the severity. Takahashi, et al. Expires January 5, 2014 [Page 3] Internet-Draft IODEF-SCI Jul 2013 IODEF provides a scheme to describe and exchange such information among interested parties. However, it does not define the detailed format to describe such information. On the other hand, there already exist structured and detailed formats for describing those information and facilitating such exchange. Major of them are listed in Section 9 . By embedding them into the IODEF document, the document can convey more detailed contents to the receivers, and the document can be easily reused. These structured cybersecurity information facilitates cybersecurity operation at the receiver side. Since the information is machine- readable, the data can be processed by computers. That expedites the automation of cybersecurity operations For instance, an organization wishing to report a security incident wants to describe what vulnerability was exploited. Then the sender can simply use IODEF, where an XML [XML1.0] -based attack pattern record that follows the syntax and vocabulary defined by an industry specification is embedded instead of describing everything in free format text. Receiver can identify the needed details of the attack pattern by looking up some of the XML tags defined by the specification. Receiver can accumulate the attack pattern record in its database and could distribute it to the interested parties if needed, without needing human interventions. Another example is that, when an administrator wishes to check the configuration of host computers in his organization, he may send a query to host computers, which may automatically generate XML-based software configuration information upon receiving thequery by running a software and may embed that to an IODEF document, which is then sent back to the administrator. 4. Extension Definition This draft extends IODEF to embed structured cybersecurity information by introducing new classes, with which these information can be embedded inside IODEF document as element contents of AdditionalData and RecordItem classes. 4.1. IANA Table for Structured Cybersecurity Information This extension embeds structured cybersecurity information defined by the other specifications. The list of supported specifications is managed by IANA, and this draft defines the needed field for the list's entry. Takahashi, et al. Expires January 5, 2014 [Page 4] Internet-Draft IODEF-SCI Jul 2013 Each entry has namespace [XMLNames] , specification name, version, reference URI, and applicable classes for each specification. Arbitrary URIs that may help readers to understand the specification could be embedded inside the Reference URI field, but it is recommended that standard/informational URI describing the specification is prepared and is embedded here. The initial IANA table has only one entry, as below. Namespace: http://xml/metadataSharing.xsd Specification Name: Malware Metadata Exchange Format Version: 1.2 Reference URI: http://standards.ieee.org/develop indconn/icsg/mmdef.html Applicable Classes: AttackPattern Note that the specification was developed by The Institute of Electrical and Electronics Engineers, Incorporated (IEEE), through the Industry Connections Security Group (ICSG) of its Standards Association. The table is to be managed by IANA using the Expert Review [RFC5226] and Specification Required [RFC5226] allocation policies as further specified in Section 7 . The SpecID attributes of extended classes (Section 4.3) must allow the values of the specifications' namespace fields, but otherwise, implementations are not required to support all specifications of the IANA table and may choose which specifications to support, though the specification listed in the initial table needs to be minimally supported, as described in Section 5. In case an implementation received a data it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to parse the data by using any means defined outside the scope of this specification. 4.2. Extended Data Type: XMLDATA This extension inherits all of the data types defined in the IODEF model. One data type is added: XMLDATA. An embedded XML data is represented by the XMLDATA data type. This type is defined as the extension to the iodef:ExtensionType [RFC5070] , whose dtype attribute is set to "xml." Takahashi, et al. Expires January 5, 2014 [Page 5] Internet-Draft IODEF-SCI Jul 2013 4.3. Extended Classes The IODEF Incident element [RFC5070] is summarized below. It is expressed in Unified Modeling Language (UML) syntax as used in the IODEF specification. The UML representation is for illustrative purposes only; elements are specified in XML as defined in Appendix A. +---------------+ | Incident | +---------------+ | ENUM purpose |<>---------[IncidentID] | STRING |<>--{0..1}-[AlternativeID] | ext-purpose |<>--{0..1}-[RelatedActivity] | ENUM lang |<>--{0..1}-[DetectTime] | ENUM |<>--{0..1}-[StartTime] | restriction |<>--{0..1}-[EndTime] | |<>---------[ReportTime] | |<>--{0..*}-[Description] | |<>--{1..*}-[Assessment] | |<>--{0..*}-[Method] | | |<>--{0..*}-[AdditionalData] | | |<>--{0..*}-[AttackPattern] | | |<>--{0..*}-[Vulnerability] | | |<>--{0..*}-[Weakness] | |<>--{1..*}-[Contact] | |<>--{0..*}-[EventData] | | |<>--{0..*}-[Flow] | | | |<>--{1..*}-[System] | | | |<>--{0..*}-[AdditionalData] | | | |<>--{0..*}-[Platform] | | |<>--{0..*}-[Expectation] | | |<>--{0..1}-[Record] | | |<>--{1..*}-[RecordData] | | |<>--{1..*}-[RecordItem] | | |<>--{0..*}-[EventReport] | |<>--{0..1}-[History] | |<>--{0..*}-[AdditionalData] | | |<>--{0..*}-[Verification] | | |<>--{0..*}-[Remediation] +---------------+ Figure 1: Incident class This extension defines the following seven elements. Takahashi, et al. Expires January 5, 2014 [Page 6] Internet-Draft IODEF-SCI Jul 2013 4.3.1. AttackPattern An AttackPattern consists of an extension to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes attack patterns of incidents or events. It is recommended that Method class SHOULD contain one or more of the extension elements whenever available. An AttackPattern class is structured as follows. +------------------------+ | AttackPattern | +------------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING AttackPatternID |<>--(0..*)-[ Platform ] +------------------------+ Figure 2: AttackPattern class This class has the following attributes. SpecID: REQUIRED. ENUM. A specification's identifier that specifies the format of a structured cybersecurity information. The value should be chosen from the namespaces [XMLNames] listed in the IANA table (Section 4.1) or "private". The value "private" is prepared for conveying RawData based on a format that is not listed in the table. This is usually used for conveying data formatted according to an organization's private schema. When the value "private" is used, ext-SpecID element MUST be used. ext-SpecID: OPTIONAL. STRING. A specification's identifier that specifies the format of a structured cybersecurity information. When this element is used, the value of SpecID element must be "private." AttackPatternID: OPTIONAL. STRING. An identifier of an attack pattern to be reported. This attribute SHOULD be used whenever such identifier is available. Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. The AttackPattern class is composed of the following aggregate classes. Takahashi, et al. Expires January 5, 2014 [Page 7] Internet-Draft IODEF-SCI Jul 2013 RawData: Zero or more. XMLDATA. A complete document that is formatted according to the specification and its version identified by the SpecID/ext-SpecID. When this element is used, writers/senders MUST ensure that the namespace specified by SpecID/ext-SpecID and the one used in the RawData element are consistent; if not, the namespace identified by SpecID SHOULD be prefered, and the inconsistency SHOULD be logged so a human can correct the problem. Reference: Zero or more of iodef:Reference [RFC5070] . This element allows an IODEF document to include a link to a structured information instead of directly embedding it into a RawData element. Platform: Zero or more. An identifier of software platform involved in the specific attack pattern, which is elaborated in Section 4.3.2 . 4.3.2. Platform A Platform identifies a software platform. It is recommended that AttackPattern, Vulnerability, Weakness, and System classes contain this elements whenever available. A Platform element is structured as follows. +----------------------+ | Platform | +----------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING PlatformID | +----------------------+ Figure 3: Platform class This class has the following attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . Takahashi, et al. Expires January 5, 2014 [Page 8] Internet-Draft IODEF-SCI Jul 2013 PlatformID: OPTIONAL. STRING. An identifier of a platform to be reported. This attribute SHOULD be used whenever such identifier is available. Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. This class is composed of the following aggregate classes. RawData: Zero or more. XMLDATA. The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Reference: Zero or more of iodef:Reference [RFC5070] . The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . 4.3.3. Vulnerability A Vulnerability consists of an extension to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes the (candidate) vulnerabilities of incidents or events. It is recommended that Method class SHOULD contain one or more of the extension elements whenever available. A Vulnerability element is structured as follows. +------------------------+ | Vulnerability | +------------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING VulnerabilityID |<>--(0..*)-[ Platform ] | |<>--(0..*)-[ Scoring ] +------------------------+ Figure 4: Vulnerability class This class has the following attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . Takahashi, et al. Expires January 5, 2014 [Page 9] Internet-Draft IODEF-SCI Jul 2013 ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . VulnerabilityID: OPTIONAL. STRING. An identifier of a vulnerability to be reported. This attribute SHOULD be used whenever such identifier is available. Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. This class is composed of the following aggregate classes. RawData: Zero or more. XMLDATA. The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Reference: Zero or more of iodef:Reference [RFC5070] . The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Platform: Zero or more. An identifier of software platform affected by the vulnerability, which is elaborated in Section 4.3.2 . Scoring: Zero or more. An indicator of the severity of the vulnerability, such as CVSS and CCSS scores, which is elaborated in Section 4.3.4 . Some of the structured information may include scores within it. In this case, the Scoring element SHOULD NOT be used since the RawData element contains the scores. If a reader/ receiver detects scores in both RawData and Scoring elements and their inconsistency, it SHOULD prefer the scores derived from the RawData element, and SHOULD log the inconsistency so a human can correct the problem. 4.3.4. Scoring A Scoring class describes the scores of the severity in terms of security. It is recommended that Vulnerability and Weakness classes contain the elements whenever available. A Scoring class is structured as follows. +----------------------+ | Scoring | +----------------------+ | ENUM SpecID |<>---------[ ScoreSet ] | STRING ext-SpecID | +----------------------+ Takahashi, et al. Expires January 5, 2014 [Page 10] Internet-Draft IODEF-SCI Jul 2013 Figure 5: Scoring class This class has two attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . This class is composed of an aggregate class. ScoreSet: One. XMLDATA. A complete document that is formatted according to the specification and its version identified by the SpecID/ext-SpecID. This element includes a set of score information. When this element is used, writers/senders MUST ensure that the namespace specified by SpecID/ext-SpecID and the one used in the RawData element are consistent; if not, the namespace identified by SpecID SHOULD be prefered, and the inconsistency SHOULD be logged so a human can correct the problem. Writers/senders MUST ensure the specification name and version identified by the SpecID are consistent with the contents of the Score; if a reader/receiver detects an inconsistency, it SHOULD prefer the specification name and version derived from the content, and SHOULD log the inconsistency so a human can correct the problem. 4.3.5. Weakness A Weakness consists of an extension to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes the weakness types of incidents or events. It is recommended that Method class SHOULD contain one or more of the extension elements whenever available. A Weakness element is structured as follows. +----------------------+ | Weakness | +----------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING WeaknessID |<>--(0..*)-[ Platform ] | |<>--(0..*)-[ Scoring ] +----------------------+ Takahashi, et al. Expires January 5, 2014 [Page 11] Internet-Draft IODEF-SCI Jul 2013 Figure 6: Weakness class This class has the following attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be reported. This attribute SHOULD be used whenever such identifier is available/ Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. This class is composed of the following aggregate classes. RawData: Zero or more. XMLDATA. The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Reference: Zero or more of iodef:Reference [RFC5070] . The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Platform: Zero or more. An identifier of software platform affected by the weakness, which is elaborated in Section 4.3.2 . Scoring: Zero or more. An indicator of the severity of the weakness, such as CWSS score, which is elaborated in Section 4.3.4 . 4.3.6. EventReport An EventReport consists of an extension to the Incident.EventData.Record.RecordData.RecordItem element with a dtype of "xml". The extension embeds structured event reports. It is recommended that RecordItem class SHOULD contain one or more of the extension elements whenever available. An EventReport element is structured as follows. Takahashi, et al. Expires January 5, 2014 [Page 12] Internet-Draft IODEF-SCI Jul 2013 +----------------------+ | EventReport | +----------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING EventID | +----------------------+ Figure 7: EventReport class This class has the following attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . EventID: OPTIONAL. STRING. An identifier of an event to be reported. This attribute SHOULD be used whenever such identifier is available. Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. This class is composed of three aggregate classes. RawData: Zero or more. XMLDATA. The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Reference: Zero or more of iodef:Reference [RFC5070] . The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . This class MUST contain at least one of RawData or Reference elements. Writers/senders MUST ensure the specification name and version identified by the SpecID are consistent with the contents of the RawData; if a reader/receiver detects an inconsistency, it SHOULD prefer the specification name and version derived from the content, and SHOULD log the inconsistency so a human can correct the problem. 4.3.7. Verifcation A Verification consists of an extension to the Incident.AdditionalData element with a dtype of "xml". The extension elements describes incident on vefifying incidents. A Verification class is structured as follows. Takahashi, et al. Expires January 5, 2014 [Page 13] Internet-Draft IODEF-SCI Jul 2013 +----------------------+ | Verification | +----------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING VerificationID| +----------------------+ Figure 8: Verification class This class has the following attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . VerificationID: OPTIONAL. STRING. An identifier of an check item to be reported. This attribute SHOULD be used whenever such identifier is available. Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. This class is composed of two aggregate classes. RawData: Zero or more. XMLDATA. The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Reference: Zero or more of iodef:Reference [RFC5070] . The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . This class MUST contain at least either of RawData and Reference elements. Writers/senders MUST ensure the specification name and version identified by the SpecID are consistent with the contents of the RawData; if a reader/receiver detects an inconsistency, it SHOULD prefer the specification name and version derived from the content, and SHOULD log the inconsistency so a human can correct the problem. 4.3.8. Remediation A Remediation consists of an extension to the Incident.AdditionalData element with a dtype of "xml". The extension elements describes incident remediation information including instructions. It is recommended that Incident class SHOULD contain one or more of Takahashi, et al. Expires January 5, 2014 [Page 14] Internet-Draft IODEF-SCI Jul 2013 this extension elements whenever available. A Remediation class is structured as follows. +----------------------+ | Remediation | +----------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | String RemediationID | +----------------------+ Figure 9: Remediation class This class has the following attributes. SpecID: REQUIRED. ENUM. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . ext-SpecID: OPTIONAL. STRING. The meaning of this attribute is the same as that of the AttackPattern class (Section 4.3.1) . RemediationID: OPTIONAL. STRING. An identifier of a remediation information to be reported. This attribute SHOULD be used whenever such identifier is available. Both RawData and Reference elements MUST NOT be used when this attribute is used, while either of them MUST be used if this attribute is omitted. This class is composed of two aggregate classes. RawData: Zero or more. XMLDATA. The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . Reference: Zero or more of iodef:Reference [RFC5070] . The meaning of this element is the same as that of the AttackPattern class (Section 4.3.1) . This class MUST contain at least either of RawData and Reference elements. Writers/senders MUST ensure the specification name and version identified by the SpecID are consistent with the contents of the RawData; if a reader/receiver detects an inconsistency, it SHOULD prefer the specification name and version derived from the content, and SHOULD log the inconsistency so a human can correct the problem. Takahashi, et al. Expires January 5, 2014 [Page 15] Internet-Draft IODEF-SCI Jul 2013 5. Mandatory to Implement features The implementation of this draft MUST be capable of sending and receiving the XML conforming to the specification listed in the initial IANA table described in Section 4.1, i.e., MMDEF version 1.2, without error. The receiver MUST be capable of validating received XML documents that are embedeed inside that against their schemata. Note that the receiver can look up the namespace in the IANA table to understand what specifications the embedded XML documents follows. This section provides an XML comformant to this draft, and a scehma for that. Note that the schema of MMDEF version 1.2 is found in Section 10. 5.1. An Example XML An example IODEF document for checking implementation's MTI conformity is provided here. The document carries MMDEF metadata. Note that the metadata is generated by genMMDEF [MMDEF] with EICAR [EICAR] files. Implementations of this specification must be capable of parsing the example XML since MMDEF is specified as the draft's MTI specification. 189493 2013-06-18T23:19:24+00:00 a candidate security incident A candidate attack event N/A MMDEF Generation Script Test MMDEF v1.2 file generated using genMMDEF 2013-03-23T15:12:50.726000 6ce6f415d8475545be5ba114f208b0ff da39a3ee5e6b4b0d3255bfef95601890afd80709 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b9 34ca495991b7852b855 cf83e1357eefb8bdf1542850d66d8007d620e4050b571 5dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d287 7eec2f63b931bd47417a81a538327af927da3e 184 eicar_com.zip application/zip 44d88612fea8a8f36de82e1278abb02f 3395856ce81f2b7382dee72602f798b642f14140 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe 2a2c4538aabf651fd0f cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4 e565e68847223b8e6b85cb48f3afad842726d99239c9e 36505c64b0dc9a061d9e507d833277ada336ab 68 1750191932 eicar.com eicar.com file[@id="6ce6f415d8475545be5ba114f208b0ff"] file[@id="44d88612fea8a8f36de82e1278abb02f"] Takahashi, et al. Expires January 5, 2014 [Page 17] Internet-Draft IODEF-SCI Jul 2013 2013-03-23T15:12:50.744000 iodef-sci.example.com iodef-sci.example-com contact@csirt.example.com
192.0.2.200
57
192.0.2.16/28
80
5.2. An XML Schema for the Extension An XML Schema describing the elements defined in this draft is given here. Any XMLs compliant to this draft including the ones in Section 5.1 and Section 11 should be verified against this schema by automated tools. Takahashi, et al. Expires January 5, 2014 [Page 19] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 20] Internet-Draft IODEF-SCI Jul 2013 6. Security Considerations This document specifies a format for encoding a particular class of security incidents appropriate for exchange across organizations. As merely a data representation, it does not directly introduce security issues. However, it is guaranteed that parties exchanging instances of this specification will have certain concerns. For this reason, the underlying message format and transport protocol used MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific environment. Organizations that exchange data using this document are URGED to develop operating procedures that document the following areas of concern. Takahashi, et al. Expires January 5, 2014 [Page 22] Internet-Draft IODEF-SCI Jul 2013 6.1. Transport-Specific Concerns The underlying messaging format and protocol used to exchange instances of the IODEF MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. The use of a standardized security protocol is encouraged. The Real-time Inter- network Defense (RID) protocol [RFC6045] and its associated transport binding [RFC6046] provide such security. The critical security concerns are that these structured information may be falsified or they may become corrupt during transit. In areas where transmission security or secrecy is questionable, the application of a digital signature and/or message encryption on each report will counteract both of these concerns. We expect that each exchanging organization will determine the need, and mechanism, for transport protection. 7. IANA Considerations This document uses URNs to describe XML namespaces and XML schemata [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism described in [RFC3688] . Registration request for the IODEF structured cybersecurity information extension namespace: URI: urn:ietf:params:xml:ns:iodef-sci-1.0 Registrant Contact: Refer here to the authors' addresses section of the document. XML: None Registration request for the IODEF structured cybersecurity information extension XML schema: URI: urn:ietf:params:xml:schema:iodef-sci-1.0 Registrant Contact: Refer here to the authors' addresses section of the document. XML: Refer here to the XML Schema in the appendix of the document. This memo creates the following registry for IANA to manage: Takahashi, et al. Expires January 5, 2014 [Page 23] Internet-Draft IODEF-SCI Jul 2013 Name of the registry: "IODEF Structured Cyber Security Information Specifications" Namespace details: A registry entry for a Structured Cyber Security Information Specification (SCI specification) consists of: Namespace: A URI [RFC3986] that is the XML namespace name used by the registered SCI specification. Specification Name: A string containing the spelled-out name of the SCI specification in human-readable form. Reference URI: A list of one or more of the URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. Applicable Classes: A list of one or more of the Extended Classes specified in Section 4.3 of this document. The registered SCI specification MUST only be used with the Extended Classes in the registry entry. Information that must be provided to assign a new value: The above list of information. Fields to record in the registry: Namespace/Specification Name/ Version/Applicable Classes. Initial registry contents: none Allocation Policy: Expert Review [RFC5226] and Specification Required [RFC5226] . The Designated Expert is expected to consult with the mile (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to retrieve the SCI specification from the provided URI in order to check the public availability of the specification and verify the correctness of the URI. An important responsibility of the Designated Expert is to ensure that the registered Applicable Classes are appropriate for the registered SCI specification. 8. Acknowledgment We would like to acknowledge Mr. David Black from EMC, who kindly Takahashi, et al. Expires January 5, 2014 [Page 24] Internet-Draft IODEF-SCI Jul 2013 provided generous support, especially on the IANA registry issues. We also would like to thank Jon Baker from MITRE, Paul Cichonski from NIST, Panos Kampanakis from CISCO, Ivan Kirillov from MITRE, Robert Martin from MITRE, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Shuhei Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, Brian Trammel from CERT/NetSA, David Waltermire from NIST, and James Wendorf from IEEE, for their sincere discussion and feedback on this document. 9. Appendix I: Candidate Specifications for the IANA Table This draft defined the structure of the IANA table in Section 4.1 . Though the management of the table is up to IANA, this appendix provides candidate entries. Note that OVAL and CVE are registered trademarks, and CAPEC, CCE, CEE, CPE, CWE, CWSS, MAEC, and OCIL are trademarks, of The MITRE Corporation. 1. CAPEC 1.6 Namespace: http://capec.mitre.org/observables Specification Name: Common Attack Pattern Enumeration and Classification Version: 1.6 Reference URI: http://capec.mitre.org/ Applicable Classes: AttackPattern 2. CCE 5.0 Namespace: http://cce.mitre.org Specification Name: Common Configuration Enumeration Version: 5.0 Reference URI: http://cce.mitre.org/ Applicable Classes: Verification 3. CCSS 1.0 Namespace: N/A Specification Name: Common Configuration Scoring System Version: 1.0 Reference URI: http://csrc.nist.gov/publications/PubsNISTIRs.html #NIST-IR-7502 Applicable Classes: Scoring Takahashi, et al. Expires January 5, 2014 [Page 25] Internet-Draft IODEF-SCI Jul 2013 4. CEE 1.0 alpha Namespace: http://cee.mitre.org Specification Name: Common Event Expression Version: 1.0 alpha Reference URI: http://cee.mitre.org/ Applicable Classes: EventReport 5. CPE 2.3 Language Namespace: http://cpe.mitre.org/language/2.0 Specification Name: Common Platform Enumeration Reference Version: 2.3 Reference URI: http://scap.nist.gov/specifications/cpe/, http://csrc.nist.gov/publications/PubsNISTIRs.html #NIST-IR-7695 Applicable Classes: Platform 6. CPE 2.3 Dictionary Namespace: http://cpe.mitre.org/dictionary/2.0 Specification Name: Common Platform Enumeration Dictionary Version: 2.3 Reference URI: http://scap.nist.gov/specifications/cpe/, http://csrc.nist.gov/publications/PubsNISTIRs.html #NIST-IR-7697 Applicable Classes: Platform 7. CVE 1.0 Namespace: http://cve.mitre.org/cve/downloads/1.0 Specification Name: Common Vulnerability and Exposures Version: 1.0 Reference URI: http://cve.mitre.org/ Applicable Classes: Vulnerability 8. CVRF 1.0 Takahashi, et al. Expires January 5, 2014 [Page 26] Internet-Draft IODEF-SCI Jul 2013 Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0 Specification Name: Common Vulnerability Reporting Format Version: 1.0 Reference URI: http://www.icasi.org/cvrf Applicable Classes: Vulnerability 9. CVSS 2.0 Namespace: http://scap.nist.gov/schema/cvss-v2/1.0 Specification Name: Common Vulnerability Scoring System Version: 2 Reference URI: http://www.first.org/cvss Applicable Classes: Scoring 10. CWE 5.0 Namespace: N/A Specification Name: Common Weakness Enumeration Version: 5.1 Reference URI: http://cwe.mitre.org/ Applicable Classes: Weakness 11. CWSS 0.8 Namespace: N/A Specification Name: Common Weakness Scoring System Version: 0.8 Reference URI: http://cwe.mitre.org/cwss/ Applicable Classes: Scoring 12. MAEC 2.0 Namespace: http://maec.mitre.org/XMLSchema/maec-core-2 Specification Name: Malware Attribute Enumeration and Characterization Version: 2.0 Reference URI: http://maec.mitre.org/ Applicable Classes: EventReport, AttackPattern Takahashi, et al. Expires January 5, 2014 [Page 27] Internet-Draft IODEF-SCI Jul 2013 13. OCIL 2.0 Namespace: http://scap.nist.gov/schema/ocil/2.0 Specification Name: Open Checklist Interactive Language Version: 2.0 Reference URI: http://scap.nist.gov/specifications/ocil/, http://csrc.nist.gov/publications/PubsNISTIRs.html #NIST-IR-7692 Applicable Classes: Verification 14. OVAL 5.10.1 Definitions Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5 Specification Name: Open Vulnerability and Assessment Language Version: 5.10.1 Reference URI: http://oval.mitre.org/ Applicable Classes: Verification 15. OVAL 5.10.1 Results Namespace: http://oval.mitre.org/XMLSchema/oval-results-5 Specification Name: Open Vulnerability and Assessment Language Version: 5.10.1 Reference URI: http://oval.mitre.org/ Applicable Classes: Verification 16. OVAL 5.10.1 Common Namespace: http://oval.mitre.org/XMLSchema/oval-common-5 Specification Name: Open Vulnerability and Assessment Language Version: 5.10.1 Reference URI: http://oval.mitre.org/ Applicable Classes: Verification 17. XCCDF 1.2 Takahashi, et al. Expires January 5, 2014 [Page 28] Internet-Draft IODEF-SCI Jul 2013 Namespace: http://checklists.nist.gov/xccdf/1.2 Specification Name: Extensible Configuration Checklist Description Format Version: 1.2 Reference URI: http://scap.nist.gov/specifications/xccdf/, http://csrc.nist.gov/publications/PubsNISTIRs.html #NIST-IR-7275-r4 Applicable Classes: Verification 10. Appendix II: MMDEF version 1.2 scheema This draft identified MMDEF version 1.2 as its MTI, and its schema (without annotations) is provided here. Takahashi, et al. Expires January 5, 2014 [Page 29] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 30] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 31] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 32] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 33] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 34] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 35] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 36] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 37] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 38] Internet-Draft IODEF-SCI Jul 2013 Takahashi, et al. Expires January 5, 2014 [Page 39] Internet-Draft IODEF-SCI Jul 2013 11. Appendix III: An Example XML using Candidate Specifications This section provides an example of an incident encoded in the IODEF. This do not necessarily represent the only way to encode a particular incident. This example reports an attack to a CSIRT and is extended from the example described in [RFC5070] . It uses identifiers whose dictionary follows CVE 1.0 schema, and it aembeds XML following CEE 0.6. Though these specifications are not listed in the IANA table at this moment, this section shows the example to demonstrate the usability of the draft. 189493 2001-09-13T23:19:24+00:00 Incident report in company xx An identifier of a vulnerability is embedded Takahashi, et al. Expires January 5, 2014 [Page 40] Internet-Draft IODEF-SCI Jul 2013 Example.com CSIRT example-com contact@csirt.example.com
192.0.2.200
57
192.0.2.16/28
80
2001-09-13T18:11:21+02:00 a Web-server event record system.example.com auth application 123 10 login app account Takahashi, et al. Expires January 5, 2014 [Page 41] Internet-Draft IODEF-SCI Jul 2013 web success
2001-09-14T08:19:01+00:00 Notification sent to constituency-contact@192.0.2.200
12. References 12.1. Normative References [MMDEF] IEEE ICSG Malware Metadata Exchange Format Working Group, "Malware Metadata Exchange Format". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010. Takahashi, et al. Expires January 5, 2014 [Page 42] Internet-Draft IODEF-SCI Jul 2013 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time Inter-network Defense (RID) Messages", RFC 6046, November 2010. [EICAR] European Expert Group for IT-Security, "Anti-Malware Testfile", 2003. [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008. [XMLschemaPart1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004. [XMLschemaPart2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004. [XMLNames] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thomson, ""Namespaces in XML (Third Edition)", W3C Recommendation, December 2009. 12.2. Informative References [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011. [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration and Classification (CAPEC)". Takahashi, et al. Expires January 5, 2014 [Page 43] Internet-Draft IODEF-SCI Jul 2013 [CCE] The MITRE Corporation, "Common Configuration Enumeration (CCE)". [CCSS] Scarfone, K. and P. Mell, "The Common Configuration Scoring System (CCSS)", NIST Interagency Report 7502, December 2010. [CEE] The MITRE Corporation, "Common Event Expression (CEE)". [CPE] National Institute of Standards and Technology, "Common Platform Enumeration", June 2011. [CVE] The MITRE Corporation, "Common Vulnerability and Exposures (CVE)". [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)". [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems". [CWE] The MITRE Corporation, "Common Weakness Enumeration (CWE)". [CWSS] The MITRE Corporation, "Common Weakness Scoring System (CWSS)". [MAEC] The MITRE Corporation, "Malware Attribute Enumeration and Characterization". [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The Open Checklist Interactive Language (OCIL) Version 2.0", April 2011. [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment Language (OVAL)". [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. Halbardier, "The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2", NIST Special Publication 800-126 Revision 2, September 2011. [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone and Neal Ziring, "Specification for the Extensible Configuration Checklist Description Format (XCCDF) version 1.2 (DRAFT)", July 2011. Takahashi, et al. Expires January 5, 2014 [Page 44] Internet-Draft IODEF-SCI Jul 2013 Authors' Addresses Takeshi Takahashi National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei 184-8795 Tokyo Japan Phone: +80 423 27 5862 Email: takeshi_takahashi@nict.go.jp Kent Landfield McAfee, Inc 5000 Headquarters Drive Plano, TX 75024 USA Email: Kent_Landfield@McAfee.com Thomas Millar US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT 245 Murray Lane SW, Building 410, MS #732 Washington, DC 20598 USA Phone: +1 888 282 0870 Email: thomas.millar@us-cert.gov Youki Kadobayashi Nara Institute of Science and Technology 8916-5 Takayama, Ikoma 630-0192 Nara Japan Email: youki-k@is.aist-nara.ac.jp Takahashi, et al. Expires January 5, 2014 [Page 45]