doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc7203.txt b/doc/rfc/rfc7203.txt
new file mode 100644
index 0000000..f315c9b
--- /dev/null
+++ b/doc/rfc/rfc7203.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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  |<>---------[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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+