GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7203

Internet Engineering Task Force (IETF) T. Takahashi Request for Comments: 7203 NICT Category: Standards Track K. Landfield ISSN: 2070-1721 McAfee

                                                        Y. Kadobayashi
                                                                 NAIST
                                                            April 2014
  An Incident Object Description Exchange Format (IODEF) Extension
              for Structured Cybersecurity Information

Abstract

 This document extends the Incident Object Description Exchange Format
 (IODEF) defined in RFC 5070 to exchange enriched cybersecurity
 information among security experts at organizations and facilitate
 their operations.  It provides a well-defined pattern to consistently
 embed structured information, such as identifier- and XML-based
 information.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7203.

Takahashi, et al. Standards Track [Page 1] RFC 7203 IODEF-SCI April 2014

Copyright Notice

 Copyright (c) 2014 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
 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 ...................................................4
 4. Extension Definition ............................................5
    4.1. IANA Table for Structured Cybersecurity Information ........5
    4.2. Extended Data Type: XMLDATA ................................6
    4.3. Extending IODEF ............................................6
    4.4. Basic Structure of the Extension Classes ...................8
    4.5. Defining Extension Classes .................................9
         4.5.1. AttackPattern .......................................9
         4.5.2. Platform ...........................................10
         4.5.3. Vulnerability ......................................11
         4.5.4. Scoring ............................................11
         4.5.5. Weakness ...........................................12
         4.5.6. EventReport ........................................13
         4.5.7. Verification .......................................14
         4.5.8. Remediation ........................................15
 5. Mandatory-to-Implement Features ................................15
    5.1. An Example XML Document ...................................16
    5.2. An XML Schema for the Extension ...........................18
 6. Security Considerations ........................................20
    6.1. Transport-Specific Concerns ...............................20
    6.2. Protection of Sensitive and Private Information ...........21
    6.3. Application and Server Security ...........................22
 7. IANA Considerations ............................................22
 8. Acknowledgments ................................................24
 9. References .....................................................24
    9.1. Normative References ......................................24
    9.2. Informative References ....................................26

Takahashi, et al. Standards Track [Page 2] RFC 7203 IODEF-SCI April 2014

1. Introduction

 The number of incidents in cyber society is growing day by day.
 Incident information needs to be reported, exchanged, and shared
 among organizations in order to cope with the situation.  IODEF is
 one of the tools already in use that enables such an exchange.
 To more efficiently run security operations, information exchanged
 between organizations needs to be machine readable.  IODEF provides a
 means to describe the incident information, but it often needs to
 include various non-structured types of incident-related data in
 order to convey more specific details about what is occurring.
 Further structure within IODEF increases the machine-readability of
 the document, thus providing a means for better automating certain
 security operations.
 Within the security community there exist various means for
 specifying structured descriptions of cybersecurity information, such
 as [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], [CVRF], [CVSS],
 [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and [XCCDF].  In this
 context, cybersecurity information encompasses a broad range of
 structured data representation types that may be used to assess or
 report on the security posture of an asset or set of assets.  Such
 structured descriptions facilitate a better understanding of an
 incident while enabling more streamlined automated security
 operations.  Because of this, it would be beneficial to embed and
 convey these types of information inside IODEF documents.
 This document extends IODEF to embed and convey various types of
 structured information.  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 terminology 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].

Takahashi, et al. Standards Track [Page 3] RFC 7203 IODEF-SCI April 2014

3. Applicability

 To maintain awareness of the continually changing security threat
 landscape, organizations need to exchange cybersecurity information,
 which includes the following information: attack pattern, platform
 information, vulnerability and weakness, countermeasure instruction,
 computer event logs, and severity assessments.  IODEF provides a
 scheme to describe and exchange such information among interested
 parties.  However, it does not define the detailed formats to specify
 such information.
 There already exist structured and detailed formats for describing
 these types of information that can be used in facilitating such an
 exchange.  They include [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE],
 [CVRF], [CVSS], [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and
 [XCCDF].  By embedding them into the IODEF document, the document can
 convey more detailed context information to the receivers, and the
 document can be easily reused.
 The use of formats for structured information facilitates more
 advanced security operations on the receiver side.  Since the
 information is machine readable, the data can be processed by
 computers, thus allowing better automation of security operations.
 For instance, an organization wishing to report a security incident
 wants to describe what vulnerability was exploited.  In this case,
 the sender can simply use IODEF, where an XML-based [XML1.0] attack
 pattern record that follows the syntax and vocabulary defined by an
 industry specification is embedded, instead of describing everything
 in free-form text.  The receiver can identify the needed details of
 the attack pattern by looking up some of the XML tags defined by the
 specification.  The receiver can accumulate the attack pattern record
 in its database and could distribute it to the interested parties as
 needed, all without requiring human intervention.
 In another example, an administrator is investigating an incident and
 has detected a configuration problem that he wishes to share with a
 partner organization to prevent the same event from occurring at the
 partner organization.  To confirm that the configuration was in fact
 vulnerable, he uses an internal repository to access configuration
 information that was gathered prior to the initial attack and that is
 specific to a new vulnerability alert.  He uses this information to
 automatically generate an XML-based software configuration
 description, embed it in an IODEF document, and send the resulting
 IODEF document to the partner organization.

Takahashi, et al. Standards Track [Page 4] RFC 7203 IODEF-SCI April 2014

4. Extension Definition

 This document extends IODEF to embed structured information by
 introducing new classes that can be embedded consistently inside an
 IODEF document as element contents of the AdditionalData and
 RecordItem classes [RFC5070].

4.1. IANA Table for Structured Cybersecurity Information

 This extension embeds structured cybersecurity information (SCI)
 defined by other specifications.  The list of supported
 specifications is managed by IANA, and this document defines the
 needed fields for the list's entry.
 Each entry for each specification has the namespace [XMLNames],
 specification name, version, reference URI, and applicable classes.
 Arbitrary URIs that may help readers understand the specification
 could be embedded inside the Reference URI field, but it is
 recommended that a standard/informational URI describing the
 specification be prepared and embedded here.
 The initial IANA table has only one entry, as follows:
    Namespace:          urn:ietf:params:xml:ns:mile:mmdef:1.2
    Specification Name: Malware Metadata Exchange Format
    Version:            1.2
    Reference URI:      <http://standards.ieee.org/develop
                        /indconn/icsg/mmdef.html>,
                        <http://grouper.ieee.org/groups
                        /malware/malwg/Schema1.2/>
    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 managed by IANA, following the allocation policy
 specified in Section 7.
 The SpecID attributes of extension classes (Section 4.5) must allow
 the values of the specifications' namespace fields, but
 implementations are otherwise not required to support all
 specifications of the IANA table and may choose which specifications
 to support.  However, at a minimum, the specification listed in the
 initial IANA table needs to be supported, as described in Section 5.
 If an implementation received data that it does not support, it may
 expand its functionality by looking up the IANA table or notify the

Takahashi, et al. Standards Track [Page 5] RFC 7203 IODEF-SCI April 2014

 sender of its inability to parse the data.  Note that the lookup
 could be done manually or automatically, but automatic download of
 data from IANA's website is not recommended, since it is not designed
 for mass retrieval of data by multiple devices.

4.2. Extended Data Type: XMLDATA

 This extension inherits all of the data types defined in the IODEF
 data model.  One data type is added: XMLDATA.  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".

4.3. Extending IODEF

 This document defines eight extension classes, namely AttackPattern,
 Platform, Vulnerability, Scoring, Weakness, EventReport,
 Verification, and Remediation.  Figure 1 describes the relationships
 between the IODEF Incident class [RFC5070] and the newly defined
 classes.  It is expressed in Unified Modeling Language (UML) syntax
 per RFC 5070 [RFC5070].  The UML representation is for illustrative
 purposes only; elements are specified in XML as defined in
 Section 5.2.

Takahashi, et al. Standards Track [Page 6] RFC 7203 IODEF-SCI April 2014

+—————+

Incident

+—————+

ENUM purpose
STRING
ext-purpose
ENUM lang
ENUM
restriction

+—————+

                       Figure 1: Incident Class

Takahashi, et al. Standards Track [Page 7] RFC 7203 IODEF-SCI April 2014

4.4. Basic Structure of the Extension Classes

 Figure 2 shows the basic structure of the extension classes.  Some of
 the extension classes have extra elements as defined in Section 4.5,
 but the basic structure is the same.
           +---------------------+
           | New Class Name      |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |
           +---------------------+
                       Figure 2: Basic Structure
 Three attributes are defined as indicated below:
 SpecID:  REQUIRED.  ENUM.  A specification's identifier that
    specifies the format of structured 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 structured information 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 structured information.  This is usually
    used to support a private schema that is not listed in the IANA
    table (Section 4.1).  This attribute MUST be used only when the
    value of the SpecID element is "private."
 ContentID:  OPTIONAL.  STRING.  An identifier of structured
    information.  Depending on the extension classes, the content of
    the structured information differs.  This attribute enables IODEF
    documents to convey the identifier of the structured information
    instead of conveying the information itself.
 Likewise, two elements are defined as indicated below:
 RawData:  Zero or more.  XMLDATA.  An XML document of structured
    information.  This is 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

Takahashi, et al. Standards Track [Page 8] RFC 7203 IODEF-SCI April 2014

    the schema of the XML are consistent; if not, the namespace
    identified by SpecID SHOULD be preferred, and the inconsistency
    SHOULD be logged so a human can correct the problem.
 Reference:  Zero or more of iodef:Reference [RFC5070].  A reference
    to structured information.  This element allows an IODEF document
    to include a link to structured information instead of directly
    embedding it into a RawData element.
 Though ContentID is an optional attribute, and RawData and Reference
 are optional elements, one of them MUST be used to convey structured
 information.  Note that, in order to avoid confusing the receiver,
 only one of them SHOULD be used.

4.5. Defining Extension Classes

 This document defines eight extension classes, as described in the
 subsections that follow.

4.5.1. AttackPattern

 An AttackPattern is an extension class to the
 Incident.Method.AdditionalData element with a dtype of "xml".  It
 describes attack patterns of incidents or events.  It is RECOMMENDED
 that the Method class [RFC5070] contain the extension elements
 whenever available.  An AttackPattern class is structured as follows:
           +---------------------+
           | AttackPattern       |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |<>--(0..*)-[ Platform ]
           +---------------------+
                     Figure 3: AttackPattern Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of attack pattern
    information.  See Section 4.4.

Takahashi, et al. Standards Track [Page 9] RFC 7203 IODEF-SCI April 2014

 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of attack pattern
    information.  See Section 4.4.
 Reference:  Zero or more.  A reference to attack pattern information.
    See Section 4.4.
 Platform:  Zero or more.  An identifier of the software platform
    involved in the specific attack pattern.  See Section 4.5.2.

4.5.2. Platform

 A Platform is an extension class that identifies a software platform.
 It is RECOMMENDED that the AttackPattern, Vulnerability, Weakness,
 and System [RFC5070] classes contain the extension elements whenever
 available.  A Platform element is structured as follows:
           +---------------------+
           | Platform            |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |
           +---------------------+
                       Figure 4: Platform Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of platform
    information.  See Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of platform
    information.  See Section 4.4.
 Reference:  Zero or more.  A reference to platform information.  See
    Section 4.4.

Takahashi, et al. Standards Track [Page 10] RFC 7203 IODEF-SCI April 2014

4.5.3. Vulnerability

 A Vulnerability is an extension class to the
 Incident.Method.AdditionalData element with a dtype of "xml".  The
 extension describes the vulnerabilities that are exposed or were
 exploited in incidents.  It is RECOMMENDED that the Method class
 contain the extension elements whenever available.  A Vulnerability
 element is structured as follows:
           +---------------------+
           | Vulnerability       |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |<>--(0..*)-[ Platform ]
           |                     |<>--(0..*)-[ Scoring ]
           +---------------------+
                     Figure 5: Vulnerability Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of vulnerability
    information.  See Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of vulnerability
    information.  See Section 4.4.
 Reference:  Zero or more.  A reference to vulnerability information.
    See Section 4.4.
 Platform:  Zero or more.  An identifier of the software platform
    affected by the vulnerability.  See Section 4.5.2.
 Scoring:  Zero or more.  An indicator of the severity of the
    vulnerability.  See Section 4.5.4.

4.5.4. Scoring

 A Scoring is an extension class that describes the severity scores in
 terms of security.  It is RECOMMENDED that the Vulnerability and
 Weakness classes contain the extension elements whenever available.

Takahashi, et al. Standards Track [Page 11] RFC 7203 IODEF-SCI April 2014

 A Scoring class is structured as follows:
           +---------------------+
           | Scoring             |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |
           +---------------------+
                        Figure 6: Scoring Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of a score set.  See
    Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of a score set.
    See Section 4.4.
 Reference:  Zero or more.  A reference to a score set.  See
    Section 4.4.

4.5.5. Weakness

 A Weakness is an extension class to the
 Incident.Method.AdditionalData element with a dtype of "xml".  The
 extension describes the weakness types that are exposed or were
 exploited in incidents.  It is RECOMMENDED that the Method class
 contain the extension elements whenever available.  A Weakness
 element is structured as follows:
           +---------------------+
           | Weakness            |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |<>--(0..*)-[ Platform ]
           |                     |<>--(0..*)-[ Scoring ]
           +---------------------+
                       Figure 7: Weakness Class

Takahashi, et al. Standards Track [Page 12] RFC 7203 IODEF-SCI April 2014

 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of weakness
    information.  See Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of weakness
    information.  See Section 4.4.
 Reference:  Zero or more.  A reference to weakness information.  See
    Section 4.4.
 Platform:  Zero or more.  An identifier of the software platform
    affected by the weakness.  See Section 4.5.2.
 Scoring:  Zero or more.  An indicator of the severity of the
    weakness.  See Section 4.5.4.

4.5.6. EventReport

 An EventReport is an extension class to the
 Incident.EventData.Record.RecordData.RecordItem element with a dtype
 of "xml".  The extension embeds structured event reports.  It is
 RECOMMENDED that the RecordItem class contain the extension elements
 whenever available.  An EventReport element is structured as follows:
           +---------------------+
           | EventReport         |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |
           +---------------------+
                      Figure 8: EventReport Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

Takahashi, et al. Standards Track [Page 13] RFC 7203 IODEF-SCI April 2014

 ContentID:  OPTIONAL.  STRING.  An identifier of an event report.
    See Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of an event
    report.  See Section 4.4.
 Reference:  Zero or more.  A reference to an event report.  See
    Section 4.4.

4.5.7. Verification

 A Verification is an extension class to the Incident.AdditionalData
 element with a dtype of "xml".  The extension elements describe
 information on verifying security, e.g., a checklist, to cope with
 incidents.  It is RECOMMENDED that the Incident class contain the
 extension elements whenever available.  A Verification class is
 structured as follows:
           +---------------------+
           | Verification        |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | STRING ContentID    |
           +---------------------+
                     Figure 9: Verification Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of verification
    information.  See Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of verification
    information.  See Section 4.4.
 Reference:  Zero or more.  A reference to verification information.
    See Section 4.4.

Takahashi, et al. Standards Track [Page 14] RFC 7203 IODEF-SCI April 2014

4.5.8. Remediation

 A Remediation is an extension class to the Incident.AdditionalData
 element with a dtype of "xml".  The extension elements describe
 incident remediation information, including instructions.  It is
 RECOMMENDED that the Incident class contain the extension elements
 whenever available.  A Remediation class is structured as follows:
           +---------------------+
           | Remediation         |
           +---------------------+
           | ENUM SpecID         |<>--(0..*)-[ RawData ]
           | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
           | String ContentID    |
           +---------------------+
                     Figure 10: Remediation Class
 This class has the following attributes:
 SpecID:  REQUIRED.  ENUM.  See Section 4.4.
 ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.
 ContentID:  OPTIONAL.  STRING.  An identifier of remediation
    information.  See Section 4.4.
 Likewise, this class has the following elements:
 RawData:  Zero or more.  XMLDATA.  An XML document of remediation
    information.  See Section 4.4.
 Reference:  Zero or more.  A reference to remediation information.
    See Section 4.4.

5. Mandatory-to-Implement Features

 Implementations compliant with this document MUST be capable of
 sending and receiving the extended IODEF documents that contain XML
 documents conforming to the specification listed in the initial IANA
 table described in Section 4.1 without error.  The extended IODEF
 document is an XML document that MUST be well-formed and MUST be
 valid according to schemata, including extension schemata, available
 to the validator and applicable to the XML document.  Note that the
 receiver can look up the namespace in the IANA table to understand
 what specifications the embedded XML documents follow.

Takahashi, et al. Standards Track [Page 15] RFC 7203 IODEF-SCI April 2014

 For the purpose of facilitating the understanding of mandatory-to-
 implement features, the following subsections provide an XML document
 conformant to this memo, and a corresponding schema.

5.1. An Example XML Document

 An example IODEF document for checking an implementation's conformity
 with mandatory-to-implement features is provided here.  The document
 carries Malware Metadata Exchange Format (MMDEF) metadata.  Note that
 the metadata is generated by genMMDEF [MMDEF] with EICAR [EICAR]
 files.  Due to the limit of 72 characters per line, some line breaks
 were added in this example.

<?xml version="1.0" encoding="UTF-8"?> <IODEF-Document version="1.00" lang="en"

xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <Incident purpose="reporting">
   <IncidentID name="sci.example.com">189493</IncidentID>
   <ReportTime>2013-06-18T23:19:24+00:00</ReportTime>
   <Description>a candidate security incident</Description>
   <Assessment>
     <Impact completion="failed" type="admin" />
   </Assessment>
   <Method>
     <Description>A candidate attack event</Description>
     <AdditionalData dtype="xml">
       <sci:AttackPattern SpecID=
              "urn:ietf:params:xml:ns:mile:mmdef:1.2">
         <sci:RawData dtype="xml">
           <malwareMetaData xmlns="http://xml/metadataSharing.xsd"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://xml/metadataSharing.xsd
            file:metadataSharing.xsd" version="1.200000" id="10000">
             <company>N/A</company>
             <author>MMDEF Generation Script</author>
             <comment>Test MMDEF v1.2 file generated using genMMDEF
             </comment>
             <timestamp>2013-03-23T15:12:50.726000</timestamp>
             <objects>
               <file id="6ce6f415d8475545be5ba114f208b0ff">
                 <md5>6ce6f415d8475545be5ba114f208b0ff</md5>
                 <sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1>
                 <sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e464
                         9b934ca495991b7852b855</sha256>

Takahashi, et al. Standards Track [Page 16] RFC 7203 IODEF-SCI April 2014

                 <sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b
                         5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff83
                         18d2877eec2f63b931bd47417a81a538327af927
                         da3e</sha512>
                 <size>184</size>
                 <filename>eicar_com.zip</filename>
                 <MIMEType>application/zip</MIMEType>
               </file>
               <file id="44d88612fea8a8f36de82e1278abb02f">
                 <md5>44d88612fea8a8f36de82e1278abb02f</md5>
                 <sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1>
                 <sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec
                         2fe2a2c4538aabf651fd0f</sha256>
                 <sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b88551
                         8f4e565e68847223b8e6b85cb48f3afad842726d99
                         239c9e36505c64b0dc9a061d9e507d833277ada3
                         36ab</sha512>
                 <size>68</size>
                 <crc32>1750191932</crc32>
                 <filename>eicar.com</filename>
                 <filenameWithinInstaller>eicar.com
                 </filenameWithinInstaller>
               </file>
             </objects>
           <relationships>
             <relationship type="createdBy" id="1">
               <source>
                 <ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]
                 </ref>
               </source>
               <target>
                 <ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]
                 </ref>
               </target>
               <timestamp>2013-03-23T15:12:50.744000</timestamp>
               </relationship>
             </relationships>
           </malwareMetaData>
         </sci:RawData>
       </sci:AttackPattern>
     </AdditionalData>
   </Method>
   <Contact role="creator" type="organization">
     <ContactName>sci.example.com</ContactName>
     <RegistryHandle registry="arin">sci.example-com
     </RegistryHandle>
     <Email>contact@csirt.example.com</Email>
   </Contact>

Takahashi, et al. Standards Track [Page 17] RFC 7203 IODEF-SCI April 2014

   <EventData>
     <Flow>
       <System category="source">
         <Node>
           <Address category="ipv4-addr">192.0.2.200</Address>
           <Counter type="event">57</Counter>
         </Node>
       </System>
       <System category="target">
         <Node>
           <Address category="ipv4-net">192.0.2.16/28</Address>
         </Node>
         <Service ip_protocol="4">
           <Port>80</Port>
         </Service>
       </System>
     </Flow>
     <Expectation action="block-host" />
     <Expectation action="other" />
   </EventData>
 </Incident>

</IODEF-Document>

5.2. An XML Schema for the Extension

 An XML schema describing the elements defined in this document is
 given here.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="urn:ietf:params:xml:ns:iodef-sci-1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation= "http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/>

<xsd:complexType name="XMLDATA">

<xsd:complexContent>
  <xsd:restriction base="iodef:ExtensionType">
    <xsd:sequence>
      <xsd:any namespace="##any" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
    </xsd:sequence>
    <xsd:attribute name="dtype" type="iodef:dtype-type"
     use="required" fixed="xml"/>

Takahashi, et al. Standards Track [Page 18] RFC 7203 IODEF-SCI April 2014

    <xsd:attribute name="ext-dtype" type="xsd:string"
     use="prohibited"/>
    <xsd:attribute name="meaning" type="xsd:string"/>
    <xsd:attribute name="formatid" type="xsd:string"/>
    <xsd:attribute name="restriction" type="iodef:restriction-type"/>
  </xsd:restriction>
</xsd:complexContent>

</xsd:complexType> <xsd:complexType name="BasicStructure">

<xsd:sequence>
  <xsd:choice>
    <xsd:element name="RawData" type="sci:XMLDATA"
     minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="iodef:Reference" minOccurs="0"
     maxOccurs="unbounded"/>
  </xsd:choice>
</xsd:sequence>
<xsd:attribute name="SpecID" type="xsd:string" use="required"/>
<xsd:attribute name="ext-SpecID" type="xsd:string"/>
<xsd:attribute name="ContentID" type="xsd:string"/>

</xsd:complexType>

<xsd:element name="Scoring" type="sci:BasicStructure"/> <xsd:element name="Platform" type="sci:BasicStructure"/> <xsd:element name="EventReport" type="sci:BasicStructure"/> <xsd:element name="Verification" type="sci:BasicStructure"/> <xsd:element name="Remediation" type="sci:BasicStructure"/> <xsd:element name="AttackPattern">

<xsd:complexType>
  <xsd:complexContent>
    <xsd:extension base="sci:BasicStructure">
      <sequence>
        <xsd:element ref="sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
      </sequence>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

</xsd:element> <xsd:element name="Vulnerability">

<xsd:complexType>
  <xsd:complexContent>
    <xsd:extension base="sci:BasicStructure">
      <sequence>
        <xsd:element ref="sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
        <xsd:element ref="sci:Scoring" minOccurs="0"
         maxOccurs="unbounded"/>

Takahashi, et al. Standards Track [Page 19] RFC 7203 IODEF-SCI April 2014

      </sequence>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

</xsd:element> <xsd:element name="Weakness">

<xsd:complexType>
  <xsd:complexContent>
    <xsd:extension base="sci:BasicStructure">
      <sequence>
        <xsd:element ref="sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
        <xsd:element ref="sci:Scoring" minOccurs="0"
         maxOccurs="unbounded"/>
      </sequence>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

</xsd:element>

</xsd:schema>

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.  Specific security
 considerations are detailed in the messaging and transport documents,
 where the exchange of formatted information is automated; see
 Sections 9 and 10 of "Real-time Inter-network Defense (RID)"
 [RFC6545] and Section 4 of "Transport of Real-time Inter-network
 Defense (RID) Messages over HTTP/TLS" [RFC6546] for a detailed
 overview of security requirements and considerations.
 It is RECOMMENDED that organizations that exchange data using this
 document develop operating procedures that consider, at a minimum,
 the following areas of concern.

6.1. Transport-Specific Concerns

 The underlying messaging format, IODEF, provides data markers to
 indicate the sensitivity level of specific classes within the
 structure as well as for the entire XML document.  The "restriction"

Takahashi, et al. Standards Track [Page 20] RFC 7203 IODEF-SCI April 2014

 attribute accomplishes this with four attribute values in IODEF
 [RFC5070].  These values are RECOMMENDED for use at the application
 level, prior to transport, to protect data as appropriate.  A
 standard mechanism to apply XML encryption using these attribute
 values as triggers is defined in RID [RFC6545], Section 9.1.  This
 mechanism may be used whether or not the RID protocol [RFC6545] and
 its associated transport binding [RFC6546] are used in the exchange
 to provide object-level security on the data to prevent possible
 intermediary systems or middleboxes from having access to the data
 being exchanged.  In areas where transmission security or secrecy is
 questionable, the application of an XML digital signature [XMLDSIG]
 and/or encryption on each report will counteract both of these
 concerns.  The data markers are RECOMMENDED for use by applications
 for managing access controls; however, access controls and management
 of those controls are out of scope for this document.  Options such
 as the usage of a standard language (e.g., eXtensible Access Control
 Markup Language [XACML]) for the expression of authorization policies
 can be used to enable source and destination systems to better
 coordinate and align their respective policy expressions.
 Any transport protocol used to exchange instances of IODEF documents
 MUST provide appropriate guarantees of confidentiality, integrity,
 and authenticity.  The use of a standardized security protocol is
 encouraged.  The RID protocol [RFC6545] and its associated transport
 binding [RFC6546] provide such security with options for mutual
 authentication session encryption and include application-level
 concerns such as policy and workflow.
 The critical security concerns are that structured information may be
 falsified, accessed by unintended entities, or become corrupt during
 transit.  We expect that each exchanging organization will determine
 the need, and mechanism, for transport protection.

6.2. Protection of Sensitive and Private Information

 For a complete review of privacy considerations when transporting
 incident-related information, please see RID [RFC6545], Section 9.5.
 Whether or not the RID protocol is used, the privacy considerations
 are important to consider, as incident information is often sensitive
 and may contain privacy-related information about individuals/
 organizations or endpoints involved.  Organizations will often
 require the establishment of legal reviews and formal policies that
 outline specific details of what information can be exchanged with
 specific entities.  Typically, identifying information is anonymized
 where possible and appropriate.  In some cases, information brokers
 are used to further anonymize the source of exchanged information so
 that other entities are unaware of the origin of a detected threat,
 whether or not that threat was realized.

Takahashi, et al. Standards Track [Page 21] RFC 7203 IODEF-SCI April 2014

 It is RECOMMENDED that policies and procedures for the exchange of
 cybersecurity information be established prior to participation in
 data exchanges.  Policy and workflow procedures for the exchange of
 cybersecurity information often require executive-level approvals and
 legal reviews to appropriately establish limits on what information
 can be exchanged with specific organizations.  RID [RFC6545],
 Section 9.6 outlines options and considerations for application
 developers to consider for policy and workflow design.

6.3. Application and Server Security

 The cybersecurity information extension is merely a data format.
 Applications and transport protocols that store or exchange IODEF
 documents using information that can be represented through this
 extension will be a target for attacks.  It is RECOMMENDED that
 systems and applications storing or exchanging this information be
 properly secured, have minimal services enabled, and maintain access
 controls and monitoring procedures.

7. IANA Considerations

 This document uses URNs to describe XML namespaces and XML schemata
 [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism
 described in [RFC3688].
 The following IODEF structured cybersecurity information extension
 namespace has been registered:
    URI: urn:ietf:params:xml:ns:iodef-sci-1.0
    Registrant Contact: Refer to the Authors' Addresses section of
    this document.
    XML: None.
 The following IODEF structured cybersecurity information extension
 XML schema has been registered:
    URI: urn:ietf:params:xml:schema:iodef-sci-1.0
    Registrant Contact: Refer to the Authors' Addresses section of
    this document.
    XML: Refer to the XML schema in Section 5.2 of this document.

Takahashi, et al. Standards Track [Page 22] RFC 7203 IODEF-SCI April 2014

 This memo creates the following registry, which is managed by IANA:
    Name of the registry: "Structured Cybersecurity Information (SCI)
    Specifications"
    Name of its parent registry: "Incident Object Description Exchange
    Format (IODEF)"
    URL of the registry: <http://www.iana.org/assignments/iodef>
    Namespace details: A registry entry for a Structured Cybersecurity
    Information Specification (SCI specification) consists of:
       Namespace: A URI [RFC3986] that identifies the XML namespace
       used by the registered SCI specification.  In the case where
       the registrant does not request a particular URI, the IANA will
       assign it a Uniform Resource Name (URN) that follows RFC 3553
       [RFC3553].
       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 extension
       classes specified in Section 4.5 of this document.  The
       registered SCI specification MUST only be used with the
       extension 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/Reference URI/Applicable Classes.  Note that it is not
    necessary to include a defining reference for all assignments in
    this new registry.
    Initial registry contents: Only one entry, with the following
    values:
       Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
       Specification Name: Malware Metadata Exchange Format
       Version: 1.2

Takahashi, et al. Standards Track [Page 23] RFC 7203 IODEF-SCI April 2014

       Reference URI:
       <http://standards.ieee.org/develop/indconn/icsg/mmdef.html>,
       <http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>
       Applicable Classes: AttackPattern
    Allocation policy: Specification Required (which includes Expert
    Review) [RFC5226].
 The Designated Expert is expected to consult with the MILE (Managed
 Incident Lightweight Exchange) working group, or its successor if any
 such working group 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. Acknowledgments

 We would like to acknowledge David Black from EMC, who kindly
 provided generous support, especially on the IANA registry issues.
 We also would like to thank Jon Baker from MITRE, Eric Burger from
 Georgetown University, Paul Cichonski from NIST, Panos Kampanakis
 from Cisco, Ivan Kirillov from MITRE, Pearl Liang from IANA, Robert
 Martin from MITRE, Alexey Melnikov from Isode, Thomas Millar from
 US-CERT, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Sean
 Turner from IECA, Inc., Anthony Rutkowski from Yaana Technology,
 Brian Trammell from ETH Zurich, David Waltermire from NIST, James
 Wendorf from IEEE, and Shuhei Yamaguchi from NICT, for their sincere
 discussion and feedback on this document.

9. References

9.1. Normative References

 [MMDEF]    ICSG Malware Metadata Exchange Format Working Group,
            "Malware Metadata Exchange Format", IEEE Standards
            Association, November 2011,
            <http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

Takahashi, et al. Standards Track [Page 24] RFC 7203 IODEF-SCI April 2014

 [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.
 [RFC6545]  Moriarty, K., "Real-time Inter-network Defense (RID)",
            RFC 6545, April 2012.
 [RFC6546]  Trammell, B., "Transport of Real-time Inter-network
            Defense (RID) Messages over HTTP/TLS", RFC 6546,
            April 2012.
 [XML1.0]   Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
            F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
            Edition)", W3C Recommendation, November 2008,
            <http://www.w3.org/TR/xml/>.
 [XMLschemaPart1]
            Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
            "XML Schema Part 1: Structures Second Edition", W3C
            Recommendation, October 2004,
            <http://www.w3.org/TR/xmlschema-1/>.
 [XMLschemaPart2]
            Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
            Second Edition", W3C Recommendation, October 2004,
            <http://www.w3.org/TR/xmlschema-2/>.
 [XMLNames]
            Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
            Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C
            Recommendation, December 2009,
            <http://www.w3.org/TR/xml-names/>.

Takahashi, et al. Standards Track [Page 25] RFC 7203 IODEF-SCI April 2014

9.2. Informative References

 [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
            IETF URN Sub-namespace for Registered Protocol
            Parameters", BCP 73, RFC 3553, June 2003.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            January 2004.
 [CAPEC]    The MITRE Corporation, "Common Attack Pattern Enumeration
            and Classification (CAPEC)", <http://capec.mitre.org/>.
 [CCE]      National Institute of Standards and Technology, "Common
            Configuration Enumeration (CCE)",
            <http://nvd.nist.gov/cce/index.cfm>.
 [CCSS]     Scarfone, K. and P. Mell, "The Common Configuration
            Scoring System (CCSS): Metrics for Software Security
            Configuration Vulnerabilities", NIST Interagency
            Report 7502, December 2010, <http://csrc.nist.gov/
            publications/nistir/ir7502/nistir-7502_CCSS.pdf>.
 [CEE]      The MITRE Corporation, "Common Event Expression (CEE)",
            <http://cee.mitre.org/>.
 [CPE]      National Institute of Standards and Technology, "Common
            Platform Enumeration", June 2011,
            <http://scap.nist.gov/specifications/cpe/>.
 [CVE]      The MITRE Corporation, "Common Vulnerabilities and
            Exposures (CVE)", <http://cve.mitre.org/>.
 [CVRF]     ICASI, "The Common Vulnerability Reporting Framework
            (CVRF)", <http://www.icasi.org/cvrf>.
 [CVSS]     Mell, P., Scarfone, K., and S. Romanosky, "The Common
            Vulnerability Scoring System (CVSS) and Its Applicability
            to Federal Agency Systems", NIST Interagency Report 7435,
            August 2007, <http://csrc.nist.gov/publications/nistir/
            ir7435/NISTIR-7435.pdf>.
 [CWE]      The MITRE Corporation, "Common Weakness Enumeration
            (CWE)", <http://cwe.mitre.org/>.
 [CWSS]     The MITRE Corporation, "Common Weakness Scoring System
            (CWSS(TM))", <http://cwe.mitre.org/cwss/>.

Takahashi, et al. Standards Track [Page 26] RFC 7203 IODEF-SCI April 2014

 [EICAR]    EICAR - European Expert Group for IT-Security,
            "Anti-Malware Testfile", 2003,
            <http://www.eicar.org/86-0-Intended-use.html>.
 [MAEC]     The MITRE Corporation, "Malware Attribute Enumeration and
            Characterization", <http://maec.mitre.org/>.
 [OCIL]     Waltermire, D., Scarfone, K., and M. Casipe,
            "Specification for the Open Checklist Interactive Language
            (OCIL) Version 2.0", NIST Interagency Report 7692,
            April 2011, <http://csrc.nist.gov/publications/nistir/
            ir7692/nistir-7692.pdf>.
 [OVAL]     The MITRE Corporation, "Open Vulnerability and Assessment
            Language (OVAL)", <http://oval.mitre.org/>.
 [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, <http://csrc.nist.gov/publications/
            nistpubs/800-126-rev2/SP800-126r2.pdf>.
 [XACML]    Rissanen, E., "eXtensible Access Control Markup Language
            (XACML) Version 3.0", January 2013,
            <http://docs.oasis-open.org/xacml/3.0/
            xacml-3.0-core-spec-os-en.pdf>.
 [XCCDF]    Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring,
            "Specification for the Extensible Configuration Checklist
            Description Format (XCCDF) version 1.2 (DRAFT)", NIST
            Interagency Report 7275, Revision 4, September 2011,
            <http://csrc.nist.gov/publications/nistir/ir7275-rev4/
            NISTIR-7275r4.pdf>.
 [XMLDSIG]  W3C Recommendation, "XML Signature Syntax and Processing
            (Second Edition)", June 2008,
            <http://www.w3.org/TR/xmldsig-core/>.

Takahashi, et al. Standards Track [Page 27] RFC 7203 IODEF-SCI April 2014

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
 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. Standards Track [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7203.txt · Last modified: 2014/04/21 22:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki