MILE Working Group
Internet Engineering Task Force (IETF)                      T. Takahashi
Internet-Draft
Request for Comments: 7203                                          NICT
Intended status:
Category: Standards Track                                   K. Landfield
Expires: July 18, 2014
ISSN: 2070-1721                                                   McAfee
                                                               T. Millar
                                                                  USCERT
                                                          Y. Kadobayashi
                                                                   NAIST
                                                            Jan 14,
                                                              April 2014

        IODEF-extension

    An Incident Object Description Exchange Format (IODEF) Extension
                for structured cybersecurity information
                       draft-ietf-mile-sci-13.txt Structured Cybersecurity Information

Abstract

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

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 July 18, 2014.
   http://www.rfc-editor.org/info/rfc7203.

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

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 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 information, such
   as [CAPEC][CCE][CCSS][CEE][CPE][CVE][CVRF][CVSS][CWE][CWSS][MAEC]
   [OCIL][OVAL][SCAP][XCCDF]. [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 facilitates 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 one 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].

3.  Applicability

   To maintain awareness of the continually changing security threat
   landscape, organization needs 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 exists 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][XCCDF]. [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 formats facilitates more
   advanced security operations on the receiver side.  Since the
   information is machine readable, the data can be processed by computers
   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 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 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 interventions. 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.  He
   accesses occurring at the
   partner organization.  To confirm that the configuration information 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 to confirm the configuration was in fact vulnerable. 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.

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. 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 for each specification. classes.
   Arbitrary URIs that may help readers to understand the specification
   could be embedded inside the Reference URI field, but it is
   recommended that a standard/informational URI describing the
   specification is be prepared and is embedded here.

   The initial IANA table has only one entry, as below. 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/      <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 to be managed by IANA 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 otherwise,
   implementations are otherwise not required to support all
   specifications of the IANA table and may choose which specifications
   to support, though support.  However, at a minimum, the specification listed in the
   initial IANA table needs to be minimally supported, as described in Section 5.  In case
   If an implementation received a data that 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.  Note that the look-up lookup
   could be done manually or automatically, but automatic download of
   data from IANA's website is not recommended 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.  An embedded  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
   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 as with the
   per RFC 5070 [RFC5070].  The UML representation is for illustrative
   purposes only; elements are specified in XML as defined in
   Section 5.2.

+---------------+
| 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 Class

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 below. indicated below:

   SpecID:  REQUIRED.  ENUM.  A specification's identifier that
      specifies the format of a 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 a 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 a structured
      information.  Depending on the extension classes, the content of
      the structured information differs.  This attribute enables IODEF
      documents to covey convey the identifier of a the structured information
      instead of conveying the information itself.

   Likewise, three two elements are defined as below. indicated below:

   RawData:  Zero or more.  XMLDATA.  An XML document of a 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
      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 a structured information.  This element allows an IODEF document
      to include a link to a structured information instead of directly
      embedding it into a RawData element.

   Though ContentID, RawData, ContentID is an optional attribute, and RawData and Reference
   are optional attribute and elements, one of them MUST be used to convey structured
   information.  Note that that, in order to avoid confusing the receiver,
   only one of them SHOULD be used to avoid confusing the
   receiver. used.

4.5.  Defining Extension Classes

   This document defines the following seven eight extension classes. 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. follows:

             +---------------------+
             | AttackPattern       |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |<>--(0..*)-[ Platform ]
             +---------------------+

                       Figure 3: AttackPattern class Class

   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of an attack pattern
      information.  See Section 4.4.

   Likewise, this class has the following elements. elements:

   RawData:  Zero or more.  XMLDATA.  An XML document of an attack pattern
      information.  See Section 4.4.

   Reference:  Zero or more.  A reference to an 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. follows:

             +---------------------+
             | Platform            |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |
             +---------------------+

                         Figure 4: Platform class Class

   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of a platform
      information.  See Section 4.4.

   Likewise, this class has the following elements. elements:

   RawData:  Zero or more.  XMLDATA.  An XML document of a platform
      information.  See Section 4.4.

   Reference:  Zero or more.  A reference to a platform information.  See
      Section 4.4.

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. follows:

             +---------------------+
             | Vulnerability       |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |<>--(0..*)-[ Platform ]
             |                     |<>--(0..*)-[ Scoring ]
             +---------------------+

                       Figure 5: Vulnerability class Class

   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of a vulnerability
      information.  See Section 4.4.

   Likewise, this class has the following elements. elements:

   RawData:  Zero or more.  XMLDATA.  An XML document of a vulnerability
      information.  See Section 4.4.

   Reference:  Zero or more.  A reference to a 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.

   A Scoring class is structured as follows. follows:

             +---------------------+
             | Scoring             |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |
             +---------------------+

                          Figure 6: Scoring class Class

   This class has two attributes. 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. 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. follows:

             +---------------------+
             | Weakness            |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |<>--(0..*)-[ Platform ]
             |                     |<>--(0..*)-[ Scoring ]
             +---------------------+

                         Figure 7: Weakness class Class
   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of a weakness
      information.  See Section 4.4.

   Likewise, this class has the following elements. elements:

   RawData:  Zero or more.  XMLDATA.  An XML document of a weakness
      information.  See Section 4.4.

   Reference:  Zero or more.  A reference to a 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. follows:

             +---------------------+
             | EventReport         |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |
             +---------------------+

                        Figure 8: EventReport class Class

   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of an event report.
      See Section 4.4.

   Likewise, this class has the following elements. 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 describes 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. follows:

             +---------------------+
             | Verification        |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | STRING ContentID    |
             +---------------------+

                       Figure 9: Verification class Class

   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of a verification
      information.  See Section 4.4.

   Likewise, this class has the following elements. elements:

   RawData:  Zero or more.  XMLDATA.  An XML document of a verification
      information.  See Section 4.4.

   Reference:  Zero or more.  A reference to a verification information.
      See Section 4.4.

4.5.8.  Remediation

   A Remediation is an extension class to the Incident.AdditionalData
   element with a dtype of "xml".  The extension elements describes describe
   incident remediation information information, including instructions.  It is
   RECOMMENDED that the Incident class contain the extension elements
   whenever available.  A Remediation class is structured as follows. follows:

             +---------------------+
             | Remediation         |
             +---------------------+
             | ENUM SpecID         |<>--(0..*)-[ RawData ]
             | STRING ext-SpecID   |<>--(0..*)-[ Reference ]
             | String ContentID    |
             +---------------------+

                       Figure 10: Remediation class Class

   This class has the following attributes. attributes:

   SpecID:  REQUIRED.  ENUM.  See Section 4.4.

   ext-SpecID:  OPTIONAL.  STRING.  See Section 4.4.

   ContentID:  OPTIONAL.  STRING.  An identifier of a remediation
      information.  See Section 4.4.

   Likewise, this class has the following elements. elements:

   RawData:  Zero or more.  XMLDATA.  An XML document of a remediation
      information.  See Section 4.4.

   Reference:  Zero or more.  A reference to a remediation information.
      See Section 4.4.

5.  Mandatory to Implement features

   The implementation of  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.  An SCI  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 follows. follow.

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

5.1.  An Example XML Document

   An example IODEF document for checking an implementation's MTI conformity
   with mandatory-to-implement features is provided here.  The document
   carries MMDEF 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:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-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="iodef-sci.example.com">189493</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">
        <iodef-sci:AttackPattern
         SpecID="http://xml/metadataSharing.xsd">
          <iodef-sci:RawData
         <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>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca4
                          95991b7852b855</sha256>
                  <sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83
                          f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b9
                          31bd47417a81a538327af927da3e</sha512>
                   <sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e464
                           9b934ca495991b7852b855</sha256>
                   <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>275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4
                          538aabf651fd0f</sha256>
                  <sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b885518f4e565e
                          68847223b8e6b85cb48f3afad842726d99239c9e36505c64b0
                          dc9a061d9e507d833277ada336ab</sha512>
                   <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>
                   <ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]
                   </ref>
                 </source>
                 <target>
                  <ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]</ref>
                   <ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]
                   </ref>
                 </target>
                 <timestamp>2013-03-23T15:12:50.744000</timestamp>
                 </relationship>
               </relationships>
             </malwareMetaData>
          </iodef-sci:RawData>
        </iodef-sci:AttackPattern>
           </sci:RawData>
         </sci:AttackPattern>
       </AdditionalData>
     </Method>
     <Contact role="creator" type="organization">
      <ContactName>iodef-sci.example.com</ContactName>
       <ContactName>sci.example.com</ContactName>
       <RegistryHandle registry="arin">iodef-sci.example-com registry="arin">sci.example-com
       </RegistryHandle>
       <Email>contact@csirt.example.com</Email>
     </Contact>
     <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:iodef-sci="urn:ietf:params:xml:ns:iodef-sci-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="urn:ietf:params:xml:schema: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"/>
      <xsd:attribute name="ext-dtype" type="xsd:string" use="optional"/>
       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:element name="Scoring">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="ScoreSet" type="iodef-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"
       use="optional"/>
      <xsd:attribute name="ContentID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

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

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

  <xsd:element name="Weakness">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>

<xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/> name="Scoring" type="sci:BasicStructure"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
           maxOccurs="unbounded"/>
        </xsd:choice> name="Platform" type="sci:BasicStructure"/>
<xsd:element ref="iodef-sci:Platform" minOccurs="0"
         maxOccurs="unbounded"/>
        <xsd:element ref="iodef-sci:Scoring" minOccurs="0"
         maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="SpecID" type="xsd:string" use="required"/>
      <xsd:attribute name="ext-SpecID" type="xsd:string"
       use="optional"/>
      <xsd:attribute name="ContentID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element> name="EventReport" type="sci:BasicStructure"/>
<xsd:element name="Platform">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:choice> name="Verification" type="sci:BasicStructure"/>
<xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/> name="Remediation" type="sci:BasicStructure"/>
<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"
       use="optional"/>
      <xsd:attribute name="ContentID" type="xsd:string"
       use="optional"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="EventReport"> name="AttackPattern">
  <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA"
           minOccurs="0" maxOccurs="unbounded"/>
    <xsd:complexContent>
      <xsd:extension base="sci:BasicStructure">
        <sequence>
          <xsd:element ref="iodef:Reference" ref="sci:Platform" 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"
       use="optional"/>
      <xsd:attribute name="ContentID" type="xsd:string"
       use="optional"/>
        </sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:element>
<xsd:element name="Verification"> name="Vulnerability">
  <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
    <xsd:complexContent>
      <xsd:extension base="sci:BasicStructure">
        <sequence>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA" ref="sci:Platform" minOccurs="0"
           maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" ref="sci:Scoring" 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"
       use="optional"/>
      <xsd:attribute name="ContentID" type="xsd:string"
       use="optional"/>
        </sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:element>
<xsd:element name="Remediation"> name="Weakness">
  <xsd:complexType>
      <xsd:sequence>
        <xsd:choice>
    <xsd:complexContent>
      <xsd:extension base="sci:BasicStructure">
        <sequence>
          <xsd:element name="RawData" type="iodef-sci:XMLDATA" ref="sci:Platform" minOccurs="0"
           maxOccurs="unbounded"/>
          <xsd:element ref="iodef:Reference" ref="sci:Scoring" 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"
       use="optional"/>
      <xsd:attribute name="ContentID" type="xsd:string"
       use="optional"/>
           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 Real-
   time automated; see
   Sections 9 and 10 of "Real-time Inter-network Defense (RID) (RID)"
   [RFC6545] and Section 9 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 who that exchange data using this
   document develop operating procedures that minimally consider 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"
   attribute accomplishes this with four attribute values in IODEF. 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] [RFC6545], Section 9.1.  This
   mechanism may be used whether or not the RID protocol [RFC6545] and RID Transport
   its associated transport binding [RFC6546] are used in the exchange
   to provide object level object-level security on the data to prevent possible
   intermediary systems or middle-boxes middleboxes from having access to the data
   being exchanged.  In areas where transmission security or secrecy is
   questionable, the application of a an XML digital signature [xmldsig] [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 controls; however, access controls and management
   of those controls are out-of-scope out of scope for this document.  Options such
   as the usage of a standard language (e.g.  XACML (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 levels application-level
   concerns such as policy and work flow. workflow.

   The critical security concerns are that these structured information may be
   falsified, accessed by unintended entities, or they may 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
   incident-related information, please see RID [RFC6545] [RFC6545], Section 9.5.
   Whether or not the RID protocol is used, the privacy considerations
   are important to consider consider, as incident information is often sensitive
   and may contain privacy related privacy-related information about individuals/
   organizations or endpoints involved.  Often times, organizations  Organizations will often
   require the establishment of legal review reviews and formal polices to be established which 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.

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

6.3.  Application and Server Security

   The Cybersecurity Information 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 are 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].

   Registration request for the

   The following IODEF structured cybersecurity information extension namespace:
   namespace has been registered:

      URI: urn:ietf:params:xml:ns:iodef-sci-1.0

      Registrant Contact: Refer here to the authors' addresses Authors' Addresses section of the
      this document.

      XML: None.

   Registration request for the

   The following IODEF structured cybersecurity information extension
   XML schema: schema has been registered:

      URI: urn:ietf:params:xml:schema:iodef-sci-1.0

      Registrant Contact: Refer here to the authors' addresses Authors' Addresses section of the
      this document.

      XML: Refer here to the XML Schema schema in Section 5.2. 5.2 of this document.

   This memo creates the following registry for IANA to manage: registry, which is managed by IANA:

      Name of the registry: "Structured Cybersecurity Information (SCI)
      specifications"
      Specifications"

      Name of its parent registry: "Incident Object Description Exchange
      Format (IODEF)"

      URL address of the registry: http://www.iana.org/assignments/iodef <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]
         [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 Only one entry entry, with the following
      values.
      values:

         Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.0 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/

         <http://standards.ieee.org/develop/indconn/icsg/mmdef.html>,
         <http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>

         Applicable Classes: AttackPattern

      Allocation Policy: policy: Specification Required (which includes Expert
      Review) [RFC5226].

   The Designated Expert is expected to consult with the mile MILE (Managed
   Incident Lightweight Exchange) working group group, or its successor if any
   such WG 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 applicable classes are appropriate for the
   registered SCI specification.

8.  Acknowledgment  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, Pearl Liang from IANA, 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 IECA, Inc., Shuhei
   Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology,
   Brian Trammell from ETH Zurich, David Waltermire from NIST, and 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]    IEEE    ICSG Malware Metadata Exchange Format Working Group,
              "Malware Metadata Exchange Format". 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.

   [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., Maler, E., Paoli, J., Sperberg-McQueen, C., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", W3C Recommendation, November 2008. 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. 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. 2004,
              <http://www.w3.org/TR/xmlschema-2/>.

   [XMLNames]
              Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
              Thomson, ""Namespaces
              Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C
              Recommendation, December 2009. 2009,
              <http://www.w3.org/TR/xml-names/>.

9.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.

   [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.

   [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)". (CAPEC)", <http://capec.mitre.org/>.

   [CCE]      The MITRE Corporation,      National Institute of Standards and Technology, "Common
              Configuration Enumeration
              (CCE)". (CCE)",
              <http://nvd.nist.gov/cce/index.cfm>.

   [CCSS]     Scarfone, K. and P. Mell, "The Common Configuration
              Scoring System (CCSS)", (CCSS): Metrics for Software Security
              Configuration Vulnerabilities", NIST Interagency
              Report 7502, December 2010. 2010, <http://csrc.nist.gov/
              publications/nistir/ir7502/nistir-7502_CCSS.pdf>.

   [CEE]      The MITRE Corporation, "Common Event Expression (CEE)". (CEE)",
              <http://cee.mitre.org/>.

   [CPE]      National Institute of Standards and Technology, "Common
              Platform Enumeration", June 2011. 2011,
              <http://scap.nist.gov/specifications/cpe/>.

   [CVE]      The MITRE Corporation, "Common Vulnerability Vulnerabilities and
              Exposures
              (CVE)". (CVE)", <http://cve.mitre.org/>.

   [CVRF]     ICASI, "Common "The Common Vulnerability Reporting Framework (CVRF)".
              (CVRF)", <http://www.icasi.org/cvrf>.

   [CVSS]     Peter     Mell, Karen P., Scarfone, K., and Sasha S. Romanosky, "The Common
              Vulnerability Scoring System (CVSS) and Its Applicability
              to Federal Agency Systems". 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)".
              (CWE)", <http://cwe.mitre.org/>.

   [CWSS]     The MITRE Corporation, "Common Weakness Scoring System
              (CWSS)".
              (CWSS(TM))", <http://cwe.mitre.org/cwss/>.

   [EICAR]    EICAR - European Expert Group for IT-Security,
              "Anti-Malware Testfile", 2003. 2003,
              <http://www.eicar.org/86-0-Intended-use.html>.

   [MAEC]     The MITRE Corporation, "Malware Attribute Enumeration and
              Characterization".
              Characterization", <http://maec.mitre.org/>.

   [OCIL]     David Waltermire and Karen Scarfone     Waltermire, D., Scarfone, K., and Maria M. Casipe, "The
              "Specification for the Open Checklist Interactive Language
              (OCIL) Version 2.0", NIST Interagency Report 7692,
              April 2011. 2011, <http://csrc.nist.gov/publications/nistir/
              ir7692/nistir-7692.pdf>.

   [OVAL]     The MITRE Corporation, "Open Vulnerability and Assessment
              Language (OVAL)". (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. 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/
              <http://docs.oasis-open.org/xacml/3.0/
              xacml-3.0-core-spec-os-en.pdf>.

   [XCCDF]    David Waltermire and Charles Schmidt and Karen Scarfone    Waltermire, D., Schmidt, C., Scarfone, K., and Neal N. Ziring,
              "Specification for the Extensible Configuration Checklist
              Description Format (XCCDF) version 1.2 (DRAFT)", July 2011.

   [xmldsig] 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. 2008,
              <http://www.w3.org/TR/xmldsig-core/>.

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:
   EMail: takeshi_takahashi@nict.go.jp

   Kent Landfield
   McAfee, Inc Inc.
   5000 Headquarters Drive
   Plano, TX  75024
   USA

   Email:

   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:

   EMail: youki-k@is.aist-nara.ac.jp