One document matched: draft-ietf-mile-sci-13.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-ietf-mile-sci-13.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="IODEF-SCI"> IODEF-extension for structured cybersecurity information</title>
<author initials="T." surname="Takahashi" fullname="Takeshi Takahashi">
<organization abbrev="NICT"> National Institute of Information and Communications Technology</organization>
<address>
<postal>
<street>4-2-1 Nukui-Kitamachi Koganei</street>
<city>184-8795 Tokyo</city>
<country>Japan</country>
</postal>
<phone>+80 423 27 5862</phone>
<email>takeshi_takahashi@nict.go.jp</email>
</address>
</author>
<author initials="K." surname="Landfield" fullname="Kent Landfield">
<organization abbrev="McAfee"> McAfee, Inc </organization>
<address>
<postal>
<street>5000 Headquarters Drive</street>
<city>Plano, TX 75024</city>
<country>USA</country>
</postal>
<!-- <phone>xxx</phone> -->
<email>Kent_Landfield@McAfee.com</email>
</address>
</author>
<author initials="T." surname="Millar" fullname="Thomas Millar">
<organization abbrev="USCERT"> US Department of Homeland
Security,
NPPD/CS&C/NCSD/US-CERT </organization>
<address>
<postal>
<street>245 Murray Lane SW, Building 410, MS #732</street>
<city>Washington, DC 20598</city>
<country>USA</country>
</postal>
<phone>+1 888 282 0870</phone>
<email>thomas.millar@us-cert.gov</email>
</address>
</author>
<author initials="Y." surname="Kadobayashi" fullname="Youki Kadobayashi">
<organization abbrev="NAIST"> Nara Institute of Science and Technology</organization>
<address>
<postal>
<street>8916-5 Takayama, Ikoma</street>
<city>630-0192 Nara</city>
<country>Japan</country>
</postal>
<email>youki-k@is.aist-nara.ac.jp</email>
</address>
</author>
<date month='Jan' day='14' year='2014' />
<area>Security</area>
<workgroup>MILE Working Group</workgroup>
<abstract>
<t>This document extends the Incident Object Description Exchange Format (IODEF) defined in <xref target='RFC5070'>RFC 5070</xref> to exchange enriched cybersecurity information among security experts at organizations and facilitates their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.</t>
<!-- formatted by specifications, including <xref target='CAPEC'>CAPEC™</xref>,
<xref target='CEE'>CEE™</xref>, <xref target='CPE'>CPE™</xref>,
<xref target='CVE'>CVE®</xref>, <xref target='CVRF'>CVRF</xref>, <xref
target='CVSS'>CVSS</xref>, <xref target='CWE'>CWE™</xref>, <xref target='CWSS'>CWSS™</xref>,
<xref target='OCIL'>OCIL</xref>, <xref target='OVAL'>OVAL®</xref>, and
<xref target='XCCDF'>XCCDF</xref>.</t> -->
</abstract>
</front>
<middle>
<section title="Introduction" anchor="ext-intro">
<t>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.</t>
<t>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.</t>
<t>Within the security community there exist various means for specifying structured descriptions of cybersecurity information such as <xref target='CAPEC'/><xref target='CCE'/><xref target='CCSS'/><xref target='CEE'/><xref target='CPE'/><xref target='CVE'/><xref target='CVRF'/><xref target='CVSS'/><xref target='CWE'/><xref target='CWSS'/><xref target='MAEC'/> <xref target='OCIL'/><xref target='OVAL'/><xref target='SCAP'/><xref target='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 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.</t>
<t>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.</t>
</section>
<section title="Terminology" anchor="ext-terminology">
<t>The terminology used in this document follows the one defined in <xref target="RFC5070">RFC 5070</xref>.</t>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Applicability" anchor="ext-applicability">
<t>To maintain awareness of the continually changing security threat landscape, organization needs 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.</t>
<t>There already exists structured and detailed formats for describing these types of information that can be used in facilitating such an exchange. They include <xref target='CAPEC'/><xref target='CCE'/><xref target='CCSS'/><xref target='CEE'/><xref target='CPE'/> <xref target='CVE'/><xref target='CVRF'/><xref target='CVSS'/><xref target='CWE'/><xref target='CWSS'/><xref target='MAEC'/><xref target='OCIL'/><xref target='OVAL'/><xref target='SCAP'/><xref target='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.
<!-- Note that interactive communication is needed in some cases, and
some of these structured information, e.g., OCIL information, solicits reply
from recipients. These reply could be also embedded inside the IODEF document. -->
</t>
<t>The use of 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 thus allowing better automation of security operations.</t>
<t>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 <xref target="XML1.0">XML-based</xref> 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 interventions.</t>
<t> In another example, an administrator is investigating an incident and detected a configuration problem that he wishes to share with a partner organization to prevent the same event from occurring. He accesses configuration information in an internal repository that was gathered prior to the initial attack specific to a new vulnerability alert to confirm the configuration was in fact vulnerable. 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.</t>
</section>
<!--************************ Extension Definition ************************* -->
<section title="Extension Definition" anchor="ext-definition">
<t>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.</t>
<section title="IANA Table for Structured Cybersecurity Information"
anchor="SpecificationList">
<t> This extension embeds structured cybersecurity information 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.</t>
<t>Each entry has <xref target="XMLNames">namespace</xref>, specification name, version, reference URI, and applicable classes for each specification. Arbitrary URIs that may help readers to understand the specification could be embedded inside the Reference URI field, but it is recommended that standard/informational URI describing the specification is prepared and is embedded here.</t>
<t>The initial IANA table has only one entry, as below.</t>
<figure><artwork>
<![CDATA[
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
]]>
</artwork></figure>
<t>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.</t>
<t>The table is to be managed by IANA following the allocation policy specified in <xref target="ext-iana" />.</t>
<t>The SpecID attributes of <xref target='ExtensionClasses'>extension classes</xref> must allow the values of the specifications' namespace fields, but otherwise, implementations are not required to support all specifications of the IANA table and may choose which specifications to support, though the specification listed in the initial table needs to be minimally supported, as described in <xref target='MTI' />.
<!--
In case an implementation received a data it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to parse the data by using any means defined outside the scope of this specification.
-->
In case an implementation received a data it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to parse the data. Note that the look-up 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.</t>
</section>
<!--************************ Extended Data Type ************************* -->
<section title="Extended Data Type: XMLDATA">
<t>
This extension inherits all of the data types defined in the IODEF data model.
One data type is added: XMLDATA. An embedded XML data is
represented by
the XMLDATA data type. This type is defined as the
extension to the <xref target='RFC5070'>iodef:ExtensionType</xref>, whose dtype
attribute is set to "xml".
</t>
</section>
<!--************************ Extension Classes ************************* -->
<section title="Extending IODEF" anchor="ExtendingIODEF">
<t>
This document defines eight extension classes, namely AttackPattern, Platform, Vulnerability, Scoring, Weakness, EventReport, Verification and Remediation.
<xref target='fig_incident'/> describes the relationships between the <xref target='RFC5070'>IODEF Incident class</xref> and the newly defined classes.
It is expressed in Unified Modeling Language (UML) syntax as with the <xref target='RFC5070'>RFC 5070</xref>.
The UML representation is for illustrative purposes only; elements are specified in XML as defined in <xref target='ext-schema'/>.
</t>
<figure anchor="fig_incident" title="Incident class"><artwork>
<![CDATA[
+---------------+
| 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]
+---------------+
]]>
</artwork></figure>
</section>
<!--******************* Basic Structure of the Extension Classes ******************** -->
<section title="Basic Structure of the Extension Classes" anchor="CommonStructure">
<t><xref target="fig_BasicStructure"/> shows the basic structure of the extension classes. Some of the extension classes have extra elements as defined in <xref target="ExtensionClasses"/>, but the basic structure is the same.</t>
<figure anchor="fig_BasicStructure" title="Basic Structure"><artwork><![CDATA[
+---------------------+
| New Class Name |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
]]></artwork></figure>
<t>Three attributes are defined as below.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's identifier that specifies the format of a structured information. The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in the <xref target="SpecificationList">IANA table</xref> 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.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's identifier that specifies the format of a structured information. This is usually used to support private schema that is not listed in the <xref target="SpecificationList">IANA table</xref>. This attribute MUST be used only when the value of SpecID element is "private."</t>
<t hangText="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 the identifier of a structured information instead of conveying the information itself.</t>
</list></t>
<t>Likewise, three elements are defined as below.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML 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.</t>
<t hangText="Reference:">Zero or more of <xref target='RFC5070'>iodef:Reference</xref>. 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.</t>
</list></t>
<t>Though ContentID, RawData, and Reference are optional attribute and elements, one of them MUST be used to convey structured information. Note that only one of them SHOULD be used to avoid confusing the receiver.</t>
<!-- In case a RawData or Reference element is provided along with this attribute, writers/senders MUST ensure that this value is consistent with the one provided by the element; if a reader/receiver detects an inconsistency, it SHOULD prefer this attribute's value, and SHOULD log the inconsistency so a human can correct the problem. -->
</section>
<!--************************ Extension Classes ************************* -->
<section title="Defining Extension Classes" anchor="ExtensionClasses">
<t>This document defines the following seven extension classes.</t>
<!--************************ AttackPattern Class ************************* -->
<section title="AttackPattern" anchor="AttackPattern">
<t>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 Method class contain the extension elements whenever available. An AttackPattern class is structured as follows.</t>
<figure anchor="fig_AttackPattern" title="AttackPattern class"><artwork>
<![CDATA[
+---------------------+
| AttackPattern |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
+---------------------+
]]>
</artwork></figure>
<t>This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of an attack pattern information. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of an attack pattern information. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to an attack pattern information. See <xref target="CommonStructure"/>.</t>
<t hangText="Platform:">Zero or more. An identifier of software platform involved in the specific attack pattern. See <xref target="sec_Platform" />.</t>
<!-- If the structured information identified or embedded in this
class already specify platform within it, this element SHOULD NOT be used.
If a reader/receiver detects the identifiers in both RawData and Platform
elements and their inconsistency, it SHOULD prefer the identifiers derived
from this element, and SHOULD log the inconsistency so a human can correct
the problem. -->
</list></t>
</section>
<!--************************ Platform Class ************************* -->
<section title="Platform" anchor="sec_Platform">
<t>A Platform is an extension class that identifies a software platform. It is RECOMMENDED that AttackPattern, Vulnerability, Weakness, and System classes contain the extension elements whenever available. A Platform element is structured as follows.</t>
<figure anchor="fig_Platform" title="Platform class"><artwork>
<![CDATA[
+---------------------+
| Platform |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
]]>
</artwork></figure>
<t>This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of a platform information. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of a platform information. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to a platform information. See <xref target="CommonStructure"/>.</t>
</list></t>
</section>
<!--************************ Vulnerability Class ************************* -->
<section title="Vulnerability">
<t>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 Method class contain the extension elements whenever available.
A Vulnerability element is structured as follows.</t>
<figure anchor="fig_Vulnerability" title="Vulnerability class"><artwork>
<![CDATA[
+---------------------+
| Vulnerability |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
]]>
</artwork></figure>
<t>This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of a vulnerability information. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of a vulnerability information. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to a vulnerability information. See <xref target="CommonStructure"/>.</t>
<t hangText="Platform:">Zero or more. An identifier of software platform affected by the vulnerability. See <xref target="sec_Platform" />.</t>
<!-- Some of the structured information embedded in the RawData element
may include the identifier within it.</t> In this case, this element SHOULD
NOT be used. If a reader/receiver detects the identifiers in both RawData
and Platform elements and their inconsistency, it SHOULD prefer the identifiers
derived from the Platform element, and SHOULD log the inconsistency so a
human can correct the problem.</t> -->
<t hangText="Scoring:">
Zero or more. An indicator of the severity of the vulnerability. See <xref target="sec_Scoring" />.
<!--
Some of the structured information may include scores within it.
In this case, the Scoring element SHOULD NOT be used since the RawData element contains the scores.
If a reader/receiver detects scores in both RawData and Scoring elements and their inconsistency, it SHOULD prefer the scores derived from the RawData element, and SHOULD log the inconsistency so a human can correct the problem.
-->
</t>
</list></t>
</section>
<!--*************************** Scoring Class **************************** -->
<section title="Scoring" anchor="sec_Scoring">
<t>A Scoring is an extension class that describes the severity scores in terms of security. It is RECOMMENDED that Vulnerability and Weakness classes contain the extension elements whenever available. A Scoring class is structured as follows.</t>
<figure anchor="fig_Scoring" title="Scoring class"><artwork>
<![CDATA[
+---------------------+
| Scoring |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
]]>
</artwork></figure>
<t>This class has two attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of a score set. See <xref target="CommonStructure"/>.</t>
</list>
</t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of a score set. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to a score set. See <xref target="CommonStructure"/>.</t>
</list></t>
</section>
<!--*************************** Weakness Class ************************* -->
<section title="Weakness">
<t>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 Method class contain the extension elements whenever available. A Weakness element is structured as follows.</t>
<figure anchor="fig_Weakness" title="Weakness class"><artwork><![CDATA[
+---------------------+
| Weakness |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
]]></artwork></figure>
<t> This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of a weakness information. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of a weakness information. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to a weakness information. See <xref target="CommonStructure"/>.</t>
<t hangText="Platform:">Zero or more. An identifier of software platform affected by the weakness. See <xref target="sec_Platform" />.</t>
<!-- Some of the structured information embedded in the RawData element
may include the identifier within it. In this case, this element SHOULD NOT
be used. If a reader/receiver detects the identifiers in both RawData and
Platform elements and their inconsistency, it SHOULD prefer the identifiers
derived from the Platform element, and SHOULD log the inconsistency so a
human can correct the problem.</t> -->
<t hangText="Scoring:">Zero or more. An indicator of the severity of the weakness. See <xref target="sec_Scoring"/>.</t>
<!-- Some of the structured information may include scores within
it. In this case, the Scoring element SHOULD NOT be used since the RawData
element contains the scores. If a reader/receiver detects scores in both
RawData and Scoring elements and their inconsistency, it SHOULD prefer the
scores derived from the RawData element, and SHOULD log the inconsistency
so a human can correct the problem.</t> -->
</list></t>
</section>
<!--************************ EventReport Class ************************* -->
<section title="EventReport">
<t>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 RecordItem class contain the extension elements whenever available. An EventReport element is structured as follows.</t>
<figure anchor="fig_EventReport" title="EventReport class"><artwork><![CDATA[
+---------------------+
| EventReport |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
]]></artwork></figure>
<t> This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of an event report. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of an event report. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to an event report. See <xref target="CommonStructure"/>.</t>
</list></t>
</section>
<!--************************ Verification Class ************************* -->
<section title="Verification">
<t>A Verification is an extension class to the Incident.AdditionalData element with a dtype of "xml". The extension elements describes information on verifying security, e.g., checklist, to cope with incidents. It is RECOMMENDED that Incident class contain the extension elements whenever available. A Verification class is structured as follows.</t>
<figure anchor="fig_Verification" title="Verification class"><artwork><![CDATA[
+---------------------+
| Verification |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
]]></artwork></figure>
<t> This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of a verification information. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of a verification information. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to a verification information. See <xref target="CommonStructure"/>.</t>
</list></t>
</section>
<!--************************ Remediation Class ************************* -->
<section title="Remediation">
<t>A Remediation is an extension class to the Incident.AdditionalData element with a dtype of "xml". The extension elements describes incident remediation information including instructions. It is RECOMMENDED that Incident class contain the extension elements whenever available. A Remediation class is structured as follows.</t>
<figure anchor="fig_Remediation" title="Remediation class"><artwork><![CDATA[
+---------------------+
| Remediation |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| String ContentID |
+---------------------+
]]></artwork></figure>
<t> This class has the following attributes.</t>
<t><list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. See <xref target="CommonStructure"/>.</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. See <xref target="CommonStructure"/>.</t>
<t hangText="ContentID:">OPTIONAL. STRING. An identifier of a remediation information. See <xref target="CommonStructure"/>.</t>
</list></t>
<t>Likewise, this class has the following elements.</t>
<t><list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. An XML of a remediation information. See <xref target="CommonStructure"/>.</t>
<t hangText="Reference:">Zero or more. A reference to a remediation information. See <xref target="CommonStructure"/>.</t>
</list></t>
</section>
</section>
</section>
<section title="Mandatory to Implement features" anchor="MTI">
<!-- <t> The implementation of this document needs to suffice the following.
</t> <t> <list> <t> The CVE SpecID value and related values (e.g., namespace)
MUST be implemented (implementation is capable of sending and receiving well-formed
CVE 1.0 XML documents without error).</t> <t>The receiver MUST implement
validation of received CVE 1.0 XML documents against the CVE 1.0 XML schema
in order to detect invalid CVE documents.</t> <t>The receiver SHOULD validate
all received CVE 1.0 XML documents as described in the above item.</t> </list>
</t> -->
<t>The implementation of this document MUST be capable of sending and receiving the XML conforming to the specification listed in the initial IANA table described in <xref target="SpecificationList" /> without error. An SCI 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.</t>
<t>For the purpose of facilitating the understanding of mandatory to implement features, the following subsections provide an XML conformant to this document, and a schema for that.</t>
<!--************************ Examples ********************************* -->
<section title="An Example XML" anchor="MTI-examples">
<t>An example IODEF document for checking implementation's MTI conformity is provided here. The document carries MMDEF metadata. Note that the metadata is generated by <xref target='MMDEF'>genMMDEF</xref> with <xref target='EICAR'>EICAR</xref> files.</t>
<figure><artwork><![CDATA[
<?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:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Incident purpose="reporting">
<IncidentID name="iodef-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 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>
<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>
<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>
</iodef-sci:RawData>
</iodef-sci:AttackPattern>
</AdditionalData>
</Method>
<Contact role="creator" type="organization">
<ContactName>iodef-sci.example.com</ContactName>
<RegistryHandle registry="arin">iodef-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>
]]></artwork></figure>
</section>
<section title="An XML Schema for the Extension" anchor="ext-schema">
<t>An XML schema describing the elements defined in this document is given here.</t>
<figure><artwork><![CDATA[
<?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"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"/>
<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"/>
<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: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: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>
<xsd:element name="Weakness">
<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: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>
<xsd:element name="Platform">
<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: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">
<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: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="Verification">
<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: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="Remediation">
<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: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:schema>
]]></artwork></figure>
</section>
</section>
<section title="Security Considerations" anchor="ext-security">
<t>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 <xref target='RFC6545'>Real-time Inter-network Defense (RID)</xref> Section 9 for a detailed overview of security requirements and considerations.</t>
<t>It is RECOMMENDED that organizations who exchange data using this document develop operating procedures that minimally consider the following areas of concern.</t>
<section title="Transport-Specific Concerns">
<t>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. 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 <xref target='RFC6545'>RID</xref> Section 9.1. This mechanism may be used whether or not the RID and <xref target='RFC6546'>RID Transport binding </xref> are used in the exchange to provide object level security on the data to prevent possible intermediary systems or middle-boxes from having access to the data being exchanged. In areas where transmission security or secrecy is questionable, the application of a <xref target='xmldsig'>XML digital signature</xref> 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. <xref target='XACML'>XACML</xref>) for the expression of authorization policies can be used to enable source and destination systems to better coordinate and align their respective policy expressions.</t>
<t>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 <xref target='RFC6545'>RID protocol</xref> and <xref target='RFC6546'>its associated transport binding</xref> provide such security with options for mutual authentication session encryption and include application levels concerns such as policy and work flow.</t>
<t>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.</t>
</section>
<section title="Protection of Sensitive and Private Information">
<t>For a complete review of privacy considerations when transporting incident related information, please see <xref target='RFC6545'>RID</xref> 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. Often times, organizations will require legal review and formal polices to be established which 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.</t>
<t>It is RECOMMENDED that policies and procedures for the exchange of cybersecurity information are 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. <xref target='RFC6545'>RID</xref> Section 9.6 outlines options and considerations for application developers to consider for the policy and workflow design. </t>
</section>
<section title="Application and Server Security">
<t>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 are properly secured, have minimal services enabled, maintain access controls and monitoring procedures.</t>
</section>
</section>
<section title="IANA Considerations" anchor="ext-iana">
<t>
This document uses URNs to describe XML namespaces and XML schemata
<xref target="XMLschemaPart1" />
<xref target="XMLschemaPart2" />
conforming to a registry mechanism
described in <xref target='RFC3688' />.
</t>
<t>Registration request for the IODEF structured cybersecurity information extension namespace:</t>
<t>
<list>
<t>URI: urn:ietf:params:xml:ns:iodef-sci-1.0 </t>
<t>Registrant Contact: Refer here to the authors' addresses section of the document.</t>
<t>XML: None. </t>
</list>
</t>
<t>Registration request for the IODEF structured cybersecurity information extension XML schema:</t>
<t>
<list>
<t>URI: urn:ietf:params:xml:schema:iodef-sci-1.0 </t>
<t>Registrant Contact: Refer here to the authors' addresses section of the document.</t>
<t>XML: Refer here to the XML Schema in <xref target='ext-schema'/>.</t>
</list>
</t>
<t>This memo creates the following registry for IANA to manage:</t>
<t>
<list>
<t>Name of the registry: "Structured Cybersecurity Information (SCI) specifications"</t>
<t>Name of its parent registry: "Incident Object Description Exchange Format (IODEF)"</t>
<t>URL address of the registry: http://www.iana.org/assignments/iodef</t>
<t>Namespace details: A registry entry for a Structured Cybersecurity Information Specification (SCI specification) consists of:
<list>
<t>Namespace: A <xref target='RFC3986'>URI</xref> 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 <xref target='RFC3553'>RFC 3553</xref></t>
<t>Specification Name: A string containing the spelled-out name of the SCI specification in human-readable form.</t>
<t>Reference URI: A list of one or more of the <xref target='RFC3986'>URIs</xref> from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI.</t>
<t>Applicable Classes: A list of one or more of the extension classes specified in <xref target='ExtensionClasses' /> of this document.
The registered SCI specification MUST only be used with the extension classes in the registry entry.</t>
</list>
</t>
<t>Information that must be provided to assign a new value: The above list of information.</t>
<t>Fields to record in the registry: Namespace/Specification Name/Version/Reference URI/Applicable Classes. Note that it is not necessary to include defining reference for all assignments in this new registry.</t>
<t>Initial registry contents: only one entry with the following values.
<list>
<t>Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.0</t>
<t>Specification Name: Malware Metadata Exchange Format</t>
<t>Version: 1.2</t>
<t>Reference URI: http://standards.ieee.org/develop/indconn/icsg/mmdef.html,http://grouper.ieee.org/groups/malware/malwg/Schema1.2/</t>
<t>Applicable Classes: AttackPattern</t>
</list>
</t>
<t>Allocation Policy: <xref target='RFC5226'>Specification Required (which includes Expert Review)</xref>.</t>
</list>
</t>
<t>The Designated Expert is expected to consult with the mile (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to retrieve the SCI specification from the provided URI in order to check the public availability of the specification and verify the correctness of the URI. An important responsibility of the Designated Expert is to ensure that the registered Applicable Classes are appropriate for the registered SCI specification.</t>
</section>
<section title="Acknowledgment">
<t>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, Ivan Kirillov from MITRE, Robert Martin from MITRE, Alexey Melnikov from Isode, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Sean Turner from 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, for their sincere discussion and feedback on this document.</t>
<!-- <t>The following groups and individuals, listed alphabetically, contributed
substantially to this document and should be recognized for their efforts.</t>
<t><list> <t>David Black, EMC</t> <t>Paul Cichonski, NIST</t> <t>Robert Martin,
MITRE</t> <t>Kathleen Moriarty, EMC</t> <t>Lagadec Philippe, NATO</t> <t>Shuhei
Yamaguchi, NICT</t> <t>Anthony Rutkowski, Yaana Technology</t> <t>Brian Trammell,
CERT/NetSA</t> </list></t> -->
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="MMDEF">
<front>
<title>Malware Metadata Exchange Format</title>
<author>
<organization>IEEE ICSG Malware Metadata Exchange Format Working
Group</organization>
</author>
<date year="" />
</front>
<format type="TXT"
target="https://standards.ieee.org/develop/indconn/icsg/mmdef.html" />
</reference>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.5070" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.6545" ?>
<?rfc include="reference.RFC.6546" ?>
<reference anchor="XML1.0">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth
Edition)</title>
<author initials="T." surname="Bray" fullname="Bray, T." />
<author initials="E." surname="Maler" fullname="Maler, E." />
<author initials="J." surname="Paoli" fullname="Paoli, J." />
<author initials="C." surname="Sperberg-McQueen" fullname="Sperberg-McQueen, C." />
<author initials="F." surname="Yergeau" fullname="Yergeau, F." />
<date month='November' year="2008" />
</front>
<seriesInfo name="W3C" value="Recommendation" />
<format type="TXT" target="http://www.w3.org/TR/xml/" />
</reference>
<reference anchor="XMLschemaPart1">
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author initials="H. " surname="Thompson" fullname="Thompson, H." />
<author initials="D. " surname="Beech" fullname="Beech, D." />
<author initials="M. " surname="Maloney" fullname="Maloney, M." />
<author initials="N. " surname="Mendelsohn" fullname="Mendelsohn, N." />
<date month='October' year="2004" />
</front>
<seriesInfo name="W3C" value="Recommendation" />
<format type="TXT" target="http://www.w3.org/TR/xmlschema-1/" />
</reference>
<reference anchor="XMLschemaPart2">
<front>
<title>XML Schema Part 2: Datatypes Second Edition</title>
<author initials="P. " surname="Biron" fullname="Biron, P." />
<author initials="A. " surname="Malhotra" fullname="Malhotra, A." />
<date month='October' year="2004" />
</front>
<seriesInfo name="W3C" value="Recommendation" />
<format type="TXT" target="http://www.w3.org/TR/xmlschema-2/" />
</reference>
<reference anchor="XMLNames">
<front>
<title>"Namespaces in XML (Third Edition)</title>
<author initials="T." surname="Bray" fullname="Bray, T." />
<author initials="D." surname="Hollander" fullname="Hollander, D." />
<author initials="A." surname="Layman" fullname="Layman, A." />
<author initials="R." surname="Tobin" fullname="Tobin, R." />
<author initials="H." surname="Thomson" fullname="Thomson, H." />
<date month='December' year="2009" />
</front>
<seriesInfo name="W3C" value="Recommendation" />
<format type="TXT" target="http://www.w3.org/TR/xml-names/" />
</reference>
</references>
<references title="Informative References">
<!-- <?rfc include="reference.RFC.2373" ?> -->
<?rfc include="reference.RFC.3339" ?>
<?rfc include="reference.RFC.3552" ?>
<?rfc include="reference.RFC.3553" ?>
<?rfc include="reference.RFC.3688" ?>
<!-- <?rfc include="reference.RFC.4519" ?> <?rfc include="reference.RFC.5226"
?> -->
<?rfc include="reference.RFC.5322" ?>
<?rfc include="reference.RFC.6116" ?>
<reference anchor="CAPEC">
<front>
<title>Common Attack Pattern Enumeration and Classification
(CAPEC)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://capec.mitre.org/" />
</reference>
<reference anchor="CCE">
<front>
<title>Common Configuration Enumeration (CCE)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://cce.mitre.org/" />
</reference>
<reference anchor="CCSS">
<front>
<title>The Common Configuration Scoring System (CCSS)</title>
<author initials="K. " surname="Scarfone" fullname="Scarfone, K." />
<author initials="P. " surname="Mell" fullname="Mell, P." />
<date month="December" year="2010" />
</front>
<seriesInfo name="NIST Interagency Report" value="7502" />
<format type="TXT"
target="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf" />
</reference>
<reference anchor="CEE">
<front>
<title>Common Event Expression (CEE)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://cee.mitre.org/" />
</reference>
<reference anchor="CPE">
<front>
<title>Common Platform Enumeration</title>
<author>
<organization>National Institute of Standards and
Technology</organization>
</author>
<date month='June' year="2011" />
</front>
<format type="TXT" target="http://scap.nist.gov/specifications/cpe/" />
</reference>
<reference anchor="CVE">
<front>
<title>Common Vulnerability and Exposures (CVE)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://cve.mitre.org/" />
</reference>
<reference anchor="CVRF">
<front>
<title>Common Vulnerability Reporting Framework (CVRF)</title>
<author>
<organization>ICASI</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://www.icasi.org/cvrf" />
</reference>
<reference anchor="CVSS">
<front>
<title>The Common Vulnerability Scoring System (CVSS) and Its
Applicability to Federal Agency Systems</title>
<author>
<organization>Peter Mell, Karen Scarfone, and Sasha
Romanosky</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://www.first.org/cvss" />
</reference>
<reference anchor="CWE">
<front>
<title>Common Weakness Enumeration (CWE)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://cwe.mitre.org/" />
</reference>
<reference anchor="CWSS">
<front>
<title>Common Weakness Scoring System (CWSS)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://cwe.mitre.org/cwss/" />
</reference>
<reference anchor="EICAR">
<front>
<title>Anti-Malware Testfile</title>
<author>
<organization>European Expert Group for IT-Security</organization>
</author>
<date year="2003" />
</front>
<format type="TXT" target="http://www.eicar.org/86-0-Intended-use.html" />
</reference>
<reference anchor="MAEC">
<front>
<title>Malware Attribute Enumeration and Characterization</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT"
target="http://maec.mitre.org/" />
</reference>
<reference anchor="OCIL">
<front>
<title>The Open Checklist Interactive Language (OCIL) Version
2.0</title>
<author>
<organization>David Waltermire and Karen Scarfone and Maria
Casipe</organization>
</author>
<date month='April' year="2011" />
</front>
<format type="TXT" target="http://scap.nist.gov/specifications/ocil/" />
</reference>
<reference anchor="OVAL">
<front>
<title>Open Vulnerability and Assessment Language (OVAL)</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="" />
</front>
<format type="TXT" target="http://oval.mitre.org/" />
</reference>
<reference anchor="SCAP">
<front>
<title>The Technical Specification for the Security Content
Automation Protocol (SCAP): SCAP Version 1.2</title>
<author initials="D. " surname="Waltermire" fullname="Waltermire, D." />
<author initials="S. " surname="Quinn" fullname="Quinn, S." />
<author initials="K. " surname="Scarfone" fullname="Scarfone, K." />
<author initials="A. " surname="Halbardier" fullname="Halbardier, A." />
<date month="September" year="2011" />
</front>
<seriesInfo name="NIST Special Publication" value="800-126 Revision 2" />
<format type="TXT"
target="http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf" />
</reference>
<reference anchor="XACML" target="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf">
<front>
<title>eXtensible Access Control Markup Language (XACML) Version 3.0</title>
<author initials="E." surname="Rissanen" fullname="Erik Rissanen">
<organization/>
</author>
<date day="22" month="January" year="2013"/>
</front>
</reference>
<reference anchor="XCCDF">
<front>
<title>Specification for the Extensible Configuration Checklist
Description Format (XCCDF) version 1.2 (DRAFT)</title>
<author>
<organization>David Waltermire and Charles Schmidt and Karen
Scarfone and Neal Ziring</organization>
</author>
<date month='July' year="2011" />
</front>
<format type="TXT" target="http://scap.nist.gov/specifications/xccdf/" />
</reference>
<reference anchor="xmldsig">
<front>
<title>XML Signature Syntax and Processing (Second Edition)</title>
<author>
<organization>W3C Recommendation</organization>
</author>
<date month='June' year="2008" />
</front>
<format type="TXT" target="http://scap.nist.gov/specifications/xccdf/" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 06:27:46 |