One document matched: draft-ietf-mile-sci-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-ietf-mile-sci-04.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="IODEF-ext-sci"> IODEF-extension to support 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='May' day='10' year='2012' />
<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 facilitate enriched cybersecurity information exchange among cybersecurity entities. It provides the capability of embedding 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> Cyber attacks are getting more sophisticated, and their number is increasing day by
day. To cope with such situation, incident information needs to be reported,
exchanged, and shared among organizations. IODEF is one of the tools enabling such
exchange, and is already in use. </t>
<t> To efficiently run cybersecurity operations, these exchanged information needs to
be machine-readable. IODEF provides a structured means to describe the
information, but it needs to embed various non-structured such information in order
to convey detailed information. Further structure within IODEF increases IODEF
documents' machine-readability and thus facilitates streamlining cybersecurity
operations. </t>
<t> On the other hand, there exist various other activities facilitating detailed and
structured description of cybersecurity information, major of which includes
<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>. Since such structured description
facilitates cybersecurity operations, it would be beneficial to embed and convey
these information inside IODEF document. </t>
<t> To enable that, this document extends the IODEF to embed and convey various structured
cybersecurity information, with which cybersecurity operations can be
facilitated. Since IODEF defines a flexible and extensible format and supports a
granular level of specificity, this document defines an extension to IODEF instead
of defining a new report format. For clarity, and to eliminate duplication, only the
additional structures necessary for describing the exchange of such structured
information are provided. </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 cybersecurity, organization needs to exchange cybersecurity
information, which includes the following information: attack pattern, platform
information, vulnerability and weakness, countermeasure instruction, computer
event log, and the severity.</t>
<t>IODEF provides a scheme to exchange such information among interested parties.
However, the detailed common format to describe such information is not defined in
the IODEF base document.</t>
<t>On the other hand, structured formats for that already exist to describe those
information and to facilitate such exchange. Major of them are CAPEC, CEE, CPE, CVE,
CVRF, CVSS, CWE, CWSS, OCIL, OVAL, and XCCDF. By embedding them into the IODEF
document, the document can convey more detailed contents 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>These structured cybersecurity information facilitates cybersecurity operation
at the receiver side. Since the information is machine-readable, the data can be
processed by computers. That expedites the automation of cybersecurity
operations</t>
<t>For instance, an organization wishing to report a security incident wants to describe
what vulnerability was exploited. Then the sender can simply use IODEF, where an
CAPEC record is embedded instead of describing everything in free format text.
Receiver can also identify the needed details of the attack pattern by looking up some
of the
<xref target="XML1.0">xml</xref> tags defined by CAPEC. Receiver can accumulate
the attack pattern information (CAPEC record) in its database and could distribute
it to the interested parties if needed, without needing human interventions.</t>
<t> Antoer example is that, when an administrator wishes to check the configuration of
host computers in his organization, he may send a query to host computers, which may
automatically generate XML-based software configuration information upon
receiving thequery by running a software and may embed that to an IODEF document,
which is then sent back to the administrator. </t>
</section>
<section title="Extension Definition" anchor="ext-definition">
<t>This draft extends IODEF to embed structured cybersecurity information by
introducing new classes, with which these information can be embedded inside IODEF
document as element contents of AdditionalData and RecordItem classes. </t>
<section
title="List of Supported Structured Cybersecurity Information Specifictions"
anchor="SpecificationList">
<t> This extension embeds structured cybersecurity information defined by the
other specifications. The list of supported specifications is managed by IANA,
and this draft defines the needed field for the list's entry.</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 table is to be managed by IANA using the
<xref target='RFC5226'>Expert Review</xref> and
<xref target='RFC5226'>Specification Required</xref> allocation policies
as further specified in
<xref target="ext-iana"/>.</t>
<t> The SpecID attributes of
<xref target='ExtendedClasses'>extended classes</xref> must allow the
values of the specifications' namespace fields, but otherwise,
implementations are not required to support all the above specifications.
Implementations may choose which specifications to support, though
identifier and xml-data following
<xref target="CVE">CVE 1.0</xref> need 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.</t>
</section>
<!--****************************************************
Extended Data Types
*****************************************************-->
<section title="Extended Data Types">
<t>This extension inherits all of the data types defined in the IODEF model. One data
type is added: XMLDATA.</t>
<section title="XMLDATA">
<t>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>
</section>
<!--****************************************************
Extended Classes
*****************************************************-->
<section title="Extended Classes" anchor="ExtendedClasses">
<t>The
<xref target='RFC5070'>IODEF Incident element</xref> is summarized below.
It is expressed in Unified Modeling Language (UML) syntax as used in the IODEF
specification. The UML representation is for illustrative purposes only;
elements are specified in XML as defined in Appendix A.</t>
<figure anchor="fig_incident" title="Incident class">
<artwork>
<![CDATA[
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>---------[IncidentID]
| STRING ext-purpose |<>--{0..1}-[AlternativeID]
| ENUM lang |<>--{0..1}-[RelatedActivity]
| ENUM restriction |<>--{0..1}-[DetectTime]
| |<>--{0..1}-[StartTime]
| |<>--{0..1}-[EndTime]
| |<>---------[ReportTime]
| |<>--{0..*}-[Description]
| |<>--{1..*}-[Assessment]
| |<>--{0..*}-[Method]
| | |<>--[AdditionalData]
| | |<>--[AttackPattern]
| | |<>--[Vulnerability]
| | |<>--[Weakness]
| |<>--{1..*}-[Contact]
| |<>--{0..*}-[EventData]
| | |<>--[Flow]
| | | |<>--[System]
| | | |<>--[AdditionalData]
| | | |<>--[Platform]
| | |<>--[Expectation]
| | |<>--[Record]
| | |<>--[RecordData]
| | |<>--[RecordItem]
| | |<>--[EventReport]
| |<>--{0..1}-[History]
| |<>--{0..*}-[AdditionalData]
| | |<>--[Verification]
| | |<>--[Remediation]
+--------------------+
]]>
</artwork>
</figure>
<t>This extension defines the following seven elements.</t>
<!--****************************************************
AttackPattern Class
*****************************************************-->
<section title="AttackPattern">
<t>An AttackPattern consists of an extension to the
Incident.Method.AdditionalData element with a dtype of "xml". The
extension describes attack patterns of incidents or events.</t>
<t>It is recommended that Method class SHOULD contain one or more of the
extension elements whenever available.</t>
<t>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 AttackPatternID |<>--(0..*)-[ Platform ]
+------------------------+
]]>
</artwork>
</figure>
<t>This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="AttackPatternID:">OPTIONAL. STRING. An identifier of
an attack pattern to be reported. This attribute SHOULD be used
whenever such identifier is available. Both RawData and
Reference elements MUST NOT be used when this attribute is used,
while either of them MUST be used if this attribute is omitted.
<!--
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.
--> </t>
</list>
</t>
<t>The AttackPattern class is composed of the following aggregate
classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem.</t>
<t hangText="Reference:">Zero or more of
<xref target='RFC5070'>iodef:Reference </xref>. This element
allows an IODEF document to include a link to a structured
information instead of directly embedding it into a RawData
element.</t>
<t hangText="Platform:">Zero or more. An identifier of software
platform involved in the specific attack pattern, which is
elaborated in
<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 identifies a software platform. It is recommended that
AttackPattern, Vulnerability, Weakness, and System classes contain this
elements whenever available.</t>
<t>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 PlatformID |
+----------------------+
]]>
</artwork>
</figure>
<t>This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="PlatformID:">OPTIONAL. STRING. An identifier of a
platform to be reported. This attribute SHOULD be used whenever
such identifier is available. Both RawData and Reference
elements MUST NOT be used when this attribute is used, while either
of them MUST be used if this attribute is omitted. </t>
</list>
</t>
<t>This class is composed of the following aggregate classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem.</t>
<t hangText="Reference:">Zero or more of
<xref target='RFC5070'>iodef:Reference </xref>. 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>
</section>
<!--****************************************************
Vulnerability Class
*****************************************************-->
<section title="Vulnerability">
<t>A Vulnerability consists of an extension to the
Incident.Method.AdditionalData element with a dtype of "xml". The
extension describes the (candidate) vulnerabilities of incidents or
events.</t>
<t>It is recommended that Method class SHOULD contain one or more of the
extension elements whenever available.</t>
<t>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 VulnerabilityID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+------------------------+
]]>
</artwork>
</figure>
<t>This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="VulnerabilityID:">OPTIONAL. STRING. An identifier of
a vulnerability to be reported. This attribute SHOULD be used
whenever such identifier is available. Both RawData and
Reference elements MUST NOT be used when this attribute is used,
while either of them MUST be used if this attribute is omitted. </t>
</list>
</t>
<t>This class is composed of the following aggregate classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or one. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem.</t>
<t hangText="Reference:">Zero or one of
<xref target='RFC5070'>iodef:Reference</xref>. This element
allows an IODEF document to include a link to a structured
information instead of directly embedding it into a RawData
element.</t>
<t hangText="Platform:">Zero or more. An identifier of software
platform affected by the vulnerability, which is elaborated in
<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, such as CVSS and CCSS scores, which is
elaborated in
<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 class describes the scores of the severity in terms of security. It
is recommended that Vulnerability and Weakness classes contain the
elements whenever available.</t>
<t>A Scoring class is structured as follows.</t>
<figure anchor="fig_Scoring" title="Scoring class">
<artwork>
<![CDATA[
+----------------------+
| Scoring |
+----------------------+
| ENUM SpecID |<>---------[ ScoreSet ]
| STRING ext-SpecID |
+----------------------+
]]>
</artwork>
</figure>
<t>This class has two attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
</list>
</t>
<t>This class is composed of an aggregate class.</t>
<t>
<list style="hanging">
<t hangText="ScoreSet:">One. XMLDATA. A complete document that is
formatted according to the specification and its version
identified by the SpecID/ext-SpecID. This element includes a set
of score information. When this element is used, writers/senders
MUST ensure that the namespace specified by SpecID/ext-SpecID
and the one used in the RawData element are consistent; if not, the
namespace identified by SpecID SHOULD be prefered, and the
inconsistency SHOULD be logged so a human can correct the problem.
</t>
</list>
</t>
<t>Writers/senders MUST ensure the specification name and version identified
by the SpecID are consistent with the contents of the Score; if a
reader/receiver detects an inconsistency, it SHOULD prefer the
specification name and version derived from the content, and SHOULD log the
inconsistency so a human can correct the problem.</t>
</section>
<!--****************************************************
Weakness Class
*****************************************************-->
<section title="Weakness">
<t>A Weakness consists of an extension to the Incident.Method.AdditionalData
element with a dtype of "xml". The extension describes the weakness types of
incidents or events.</t>
<t>It is recommended that Method class SHOULD contain one or more of the
extension elements whenever available.</t>
<t>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 WeaknessID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+----------------------+
]]>
</artwork>
</figure>
<t> This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="WeaknessID:">OPTIONAL. STRING. An identifier of a
weakness to be reported. This attribute SHOULD be used whenever
such identifier is available/ Both RawData and Reference
elements MUST NOT be used when this attribute is used, while either
of them MUST be used if this attribute is omitted. </t>
</list>
</t>
<t>This class is composed of the following aggregate classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or more. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem. </t>
<t hangText="Reference:">Zero or one of
<xref target='RFC5070'>iodef:Reference</xref>. This element
allows an IODEF document to include a link to a structured
information instead of directly embedding it into a RawData
element.</t>
<t hangText="Platform:">Zero or more. An identifier of software
platform affected by the weakness, which is elaborated in
<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, such as CWSS score, which is elaborated in
<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 consists of an extension to the
Incident.EventData.Record.RecordData.RecordItem element with a dtype
of "xml". The extension embeds structured event reports.</t>
<t>It is recommended that RecordItem class SHOULD contain one or more of the
extension elements whenever available.</t>
<t>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 EventID |
+----------------------+
]]>
</artwork>
</figure>
<t> This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="EventID:">OPTIONAL. STRING. An identifier of an event
to be reported. This attribute SHOULD be used whenever such
identifier is available. Both RawData and Reference elements
MUST NOT be used when this attribute is used, while either of them
MUST be used if this attribute is omitted. </t>
</list>
</t>
<t> This class is composed of three aggregate classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or one. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem.</t>
<t hangText="Reference:">Zero or one of
<xref target='RFC5070'>iodef:Reference</xref>. 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>This class MUST contain at least one of RawData or Reference elements.
Writers/senders MUST ensure the specification name and version
identified by the SpecID are consistent with the contents of the RawData; if
a reader/receiver detects an inconsistency, it SHOULD prefer the
specification name and version derived from the content, and SHOULD log the
inconsistency so a human can correct the problem.</t>
</section>
<!--****************************************************
Verification Class
*****************************************************-->
<section title="Verifcation">
<t>A Verification consists of an extension to the Incident.AdditionalData
element with a dtype of "xml". The extension elements describes incident on
vefifying incidents. </t>
<t>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 VerificationID|
+----------------------+
]]>
</artwork>
</figure>
<t> This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="VerificationID:">OPTIONAL. STRING. An identifier of
an check item to be reported. This attribute SHOULD be used
whenever such identifier is available. Both RawData and
Reference elements MUST NOT be used when this attribute is used,
while either of them MUST be used if this attribute is omitted. </t>
</list>
</t>
<t> This class is composed of two aggregate classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or one. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem.</t>
<t hangText="Reference:">Zero or one of
<xref target='RFC5070'>iodef:Reference</xref>. 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>This class MUST contain at least either of RawData and Reference elements.
Writers/senders MUST ensure the specification name and version
identified by the SpecID are consistent with the contents of the RawData; if
a reader/receiver detects an inconsistency, it SHOULD prefer the
specification name and version derived from the content, and SHOULD log the
inconsistency so a human can correct the problem.</t>
</section>
<!--****************************************************
Remediation Class
*****************************************************-->
<section title="Remediation">
<t>A Remediation consists of an extension to the Incident.AdditionalData
element with a dtype of "xml". The extension elements describes incident
remediation information including instructions. </t>
<t>It is recommended that Incident class SHOULD contain one or more of this
extension elements whenever available.</t>
<t>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 RemediationID |
+----------------------+
]]>
</artwork>
</figure>
<t> This class has the following attributes.</t>
<t>
<list style="hanging">
<t hangText="SpecID:">REQUIRED. ENUM. A specification's
identifier that specifies the format of a structured
cybersecurity 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 RawData
based on a format that is not listed in the table. This is usually
used for conveying data formatted according to an organization's
private schema. When the value "private" is used, ext-SpecID
element MUST be used. </t>
<t hangText="ext-SpecID:">OPTIONAL. STRING. A specification's
identifier that specifies the format of a structured
cybersecurity information. When this element is used, the value
of SpecID element must be "private." </t>
<t hangText="RemediationID:">OPTIONAL. STRING. An identifier of a
remediation information to be reported. This attribute SHOULD be
used whenever such identifier is available. Both RawData and
Reference elements MUST NOT be used when this attribute is used,
while either of them MUST be used if this attribute is omitted. </t>
</list>
</t>
<t> This class is composed of two aggregate classes.</t>
<t>
<list style="hanging">
<t hangText="RawData:">Zero or one. XMLDATA. A complete document
that is formatted according to the specification and its version
identified by the SpecID/ext-SpecID. When this element is used,
writers/senders MUST ensure that the namespace specified by
SpecID/ext-SpecID and the one used in the RawData element are
consistent; if not, the namespace identified by SpecID SHOULD be
prefered, and the inconsistency SHOULD be logged so a human can
correct the problem.</t>
<t hangText="Reference:">Zero or one of
<xref target='RFC5070'>iodef:Reference</xref>. 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>This class MUST contain at least either of RawData and Reference elements.
Writers/senders MUST ensure the specification name and version
identified by the SpecID are consistent with the contents of the RawData; if
a reader/receiver detects an inconsistency, it SHOULD prefer the
specification name and version derived from the content, and SHOULD log the
inconsistency so a human can correct the problem.</t>
</section>
</section>
</section>
<section title="Mandatory to Implement features" anchor="MTI">
<t>
The implementation of this draft 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>
</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.</t>
<t>Organizations that exchange data using this document are URGED to
develop operating procedures that document the following areas of
concern.</t>
<section title="Transport-Specific Concerns">
<t>The underlying messaging format and protocol used to exchange
instances of the IODEF MUST provide appropriate guarantees of
confidentiality, integrity, and authenticity. The use of a
standardized security protocol is encouraged. The <xref target='RFC6045'>Real-time Inter-
network Defense (RID) protocol</xref> and <xref target='RFC6046'>its associated transport
binding </xref> provide such security.</t>
<t>The critical security concerns are that these structured information may
be falsified or they may become corrupt during transit.
In areas where transmission security or secrecy is questionable, the
application of a digital signature and/or message encryption on each
report will counteract both of these concerns. We expect that each
exchanging organization will determine the need, and mechanism, for
transport protection. </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 the appendix of the document.</t>
</list></t>
<t>This memo creates the following registry for IANA to manage:</t>
<t><list>
<t>Name of the registry: "IODEF Structured Cyber Security Information Specifications"</t>
<t>Namespace details: A registry entry for a Structured Cyber Security Information Specification (SCI specification) consists of:
<list>
<t>Namespace: A <xref target='RFC3986'>URI</xref> that is the XML namespace name used by the registered SCI specification.</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 Extended Classes specified in <xref target='ExtendedClasses'/> of this document. The registered SCI specification MUST only be used with the Extended 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/Applicable Classes.</t>
<t>Initial registry contents: none</t>
<t>Allocation Policy: <xref target='RFC5226'>Expert Review</xref> and <xref target='RFC5226'>Specification Required</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 Mr. 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, Paul Cichonski from NIST, Robert Martin from MITRE, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Shuhei Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology, Brian Trammel from CERT/NetSA, and David Waltermire from NIST 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>
<section title="Appendix I: XML Schema Definition for Extension"
anchor="ext-schema">
<t>The XML Schema describing the elements defined in the Extension Definition section is
given here. Each of the examples in
<xref target="ext-examples"/> should be verified to validate against this schema
by automated tools.</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="iodef_schema.xsd"/>
<!--
schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"/>
-->
<!--================================================================
== XMLDATA ==
==================================================================-->
<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>
<!--================================================================
== Scoring Class ==
==================================================================-->
<xsd:element name="Scoring">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ScoreSet" type="iodef-sci:XMLDATA"
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:complexType>
</xsd:element>
<!--================================================================
== AttackPattern Class ==
==================================================================-->
<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="AttackPatternID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!--================================================================
== Vulnerability Class ==
==================================================================-->
<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="VulnerabilityID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!--=================================================================
== Weakness Class ==
==================================================================-->
<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="WeaknessID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!--=================================================================
== Platform Class ==
==================================================================-->
<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="PlatformID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!--================================================================
== EventReport Class ==
=================================================================-->
<xsd:element name="EventReport">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element name="RawData" type="iodef-sci:XMLDATA"/>
<xsd:element ref="iodef:Reference"/>
</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="EventID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!--================================================================
== Verification Class ==
=================================================================-->
<xsd:element name="Verification">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element name="RawData" type="iodef-sci:XMLDATA"/>
<xsd:element ref="iodef:Reference"/>
</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="VerificationID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<!--================================================================
== Remediation Class ==
=================================================================-->
<xsd:element name="Remediation">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element name="RawData" type="iodef-sci:XMLDATA"/>
<xsd:element ref="iodef:Reference"/>
</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="RemediationID" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
]]>
</artwork>
</figure>
</section>
<!--****************************************************
Examples
*****************************************************-->
<section title="Appendix II: XML Examples" anchor="ext-examples">
<t>This section provides an example of an incident encoded in the IODEF. This do not
necessarily represent the only way to encode a particular incident. Below is an
example of a CSIRT reporting an attack.</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="csirt.example.com">189493</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
<Description>Incident report in company xx</Description>
<Assessment>
<Impact completion="failed" type="admin"/>
</Assessment>
<Method>
<Description>Structured information on attack pattern, exploited
vulnerability, and weakness</Description>
<AdditionalData dtype="xml">
<iodef-sci:AttackPattern
SpecID="http://capec.mitre.org/observables">
<Reference>
<ReferenceName>Link to Capec-14</ReferenceName>
<URL>http://capec.mitre.org/data/definitions/14.html</URL>
</Reference>
</iodef-sci:AttackPattern>
<iodef-sci:Vulnerability
SpecID="http://cve.mitre.org/cve/downloads/1.0"
VulnerabilityID="CVE-2010-3653"/>
<iodef-sci:Vulnerability
SpecID="http://cve.mitre.org/cve/downloads/1.0">
<iodef-sci:RawData dtype="xml">
<cve xsi:noNamespaceSchemaLocation=
"http://cve.mitre.org/schema/cve/cve_1.0.xsd"
xmlns="http://cve.mitre.org/cve/downloads"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<item seq="1999-0002" name="CVE-1999-0002" type="CVE">
...
</item>
</cve>
</iodef-sci:RawData>
<iodef-sci:Platform SpecID="http://cpe.mitre.org/dictionary/2.0"
PlatformID="[CPE ID]"/>
<iodef-sci:Scoring
SpecID="http://scap.nist.gov/schema/cvss-v2/1.0">
<iodef-sci:ScoreSet dtype="xml">
<base_metrics>
<score>9.3</score>
<access-vector>NETWORK</access-vector>
<access-complexity>MEDIUM</access-complexity>
<authentication>NONE</authentication>
<confidentiality-impact>COMPLETE</confidentiality-impact>
<integrity-impact>COMPLETE</integrity-impact>
<availability-impact>COMPLETE</availability-impact>
<source>http://nvd.nist.gov</source>
<generated-on-datetime>2012-01-11T09:55:00.000-05:00
</generated-on-datetime>
</base_metrics>
</iodef-sci:ScoreSet>
</iodef-sci:Scoring>
</iodef-sci:Vulnerability>
<iodef-sci:Weakness SpecID="http://cwe.mitre.org/"
WeaknessID="CWE-119">
<iodef-sci:RawData dtype="xml">
<Weakness_Catalog
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Catalog_Name="VIEW LIST: CWE-1000: Research Concepts"
Catalog_Version="2.1" Catalog_Date="2011-09-13"
xsi:noNamespaceSchemaLocation=
"http://cwe.mitre.org/data/xsd/cwe_schema_v5.1.xsd">
<Views>.....</Views>
</Weakness_Catalog>
</iodef-sci:RawData>
</iodef-sci:Weakness>
</AdditionalData>
</Method>
<Contact role="creator" type="organization">
<ContactName>Example.com CSIRT</ContactName>
<RegistryHandle registry="arin">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="6">
<Port>80</Port>
</Service>
<AdditionalData dtype="xml">
<iodef-sci:Platform SpecID="http://cpe.mitre.org/dictionary/2.0"
PlatformID="[CPE ID]"/>
</AdditionalData>
</System>
</Flow>
<Expectation action="block-host" />
<Expectation action="other"/>
<!-- <RecordItem> has an excerpt from a log -->
<Record>
<RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>a Web-server event record</Description>
<RecordItem dtype="xml">
<iodef-sci:EventReport SpecID="http://cee.mitre.org">
<iodef-sci:RawData dtype="xml">
<CEE xmlns="http://cee.mitre.org">
.....
</CEE>
</iodef-sci:RawData>
</iodef-sci:EventReport>
</RecordItem>
</RecordData>
</Record>
</EventData>
<History>
<!-- Contact was previously made with the source network owner -->
<HistoryItem action="contact-source-site">
<DateTime>2001-09-14T08:19:01+00:00</DateTime>
<Description>Notification sent to
constituency-contact@192.0.2.200</Description>
</HistoryItem>
</History>
<AdditionalData dtype="xml">
<iodef-sci:Verification
SpecID="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<iodef-sci:RawData dtype="xml">
<oval_definitions
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5"
xmlns:ind-def=
"http://oval.mitre.org/XMLSchema/oval-definitions-5#independent"
xmlns:linux-def=
"http://oval.mitre.org/XMLSchema/oval-definitions-5#linux"
xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
xmlns:oval-def=
"http://oval.mitre.org/XMLSchema/oval-definitions-5"
xmlns:unix-def=
"http://oval.mitre.org/XMLSchema/oval-definitions-5#unix"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
.....
</oval_definitions>
</iodef-sci:RawData>
</iodef-sci:Verification>
<iodef-sci:Verification SpecID="http://checklists.nist.gov/xccdf/1.2">
<iodef-sci:RawData dtype="xml">
<xccdf:Benchmark id="xccdf_org.example_benchmark_example1"
xml:lang="en" Id="toSign"
xmlns:htm="http://www.w3.org/1999/xhtml"
xmlns:xccdf="http://checklists.nist.gov/xccdf/1.2"
xmlns:cpe2-dict="http://cpe.mitre.org/dictionary/2.0">
.....
</xccdf:Benchmark>
</iodef-sci:RawData>
</iodef-sci:Verification>
</AdditionalData>
</Incident>
</IODEF-Document>
]]>
</artwork>
</figure>
</section>
<section title="Appendix III: Candidate Specifications listed to the IANA table" anchor="candidate-specs">
<t>This draft defined the structure of the IANA table in <xref target="SpecificationList"/>. Though the management of the table is up to IANA, this appendix provides candidate entries. </t>
<t>
<list style='numbers'>
<t>CAPEC 1.6
<figure><artwork><![CDATA[
Namespace: http://capec.mitre.org/observables
Specification Name: Common Attack Pattern Enumeration and Classification
Version: 1.6
Reference URI: http://capec.mitre.org/
Applicable Classes: AttackPattern
]]></artwork></figure>
</t>
<t>CCE 5.0
<figure><artwork><![CDATA[
Namespace: http://cce.mitre.org
Specification Name: Common Configuration Enumeration
Version: 5.0
Reference URI: http://cce.mitre.org/
Applicable Classes: Verification
]]></artwork></figure>
</t>
<t>CCSS 1.0
<figure><artwork><![CDATA[
Namespace: N/A
Specification Name: Common Configuration Scoring System
Version: 1.0
Reference URI: http://csrc.nist.gov/publications/PubsNISTIRs.html
#NIST-IR-7502
Applicable Classes: Scoring
]]></artwork></figure>
</t>
<t>CEE 0.6
<figure><artwork><![CDATA[
Namespace: http://cee.mitre.org
Specification Name: Common Event Expression
Version: 0.6
Reference URI: http://cee.mitre.org/
Applicable Classes: EventReport
]]></artwork></figure></t>
<t>CPE 2.3 Language
<figure><artwork><![CDATA[
Namespace: http://cpe.mitre.org/language/2.0
Specification Name: Common Platform Enumeration Reference
Version: 2.3
Reference URI: http://scap.nist.gov/specifications/cpe/,
http://csrc.nist.gov/publications/PubsNISTIRs.html
#NIST-IR-7695
Applicable Classes: Platform
]]></artwork></figure>
</t>
<t>CPE 2.3 Dictionary
<figure><artwork><![CDATA[
Namespace: http://cpe.mitre.org/dictionary/2.0
Specification Name: Common Platform Enumeration Dictionary
Version: 2.3
Reference URI: http://scap.nist.gov/specifications/cpe/,
http://csrc.nist.gov/publications/PubsNISTIRs.html
#NIST-IR-7697
Applicable Classes: Platform
]]></artwork></figure>
</t>
<t>CVE 1.0
<figure><artwork><![CDATA[
Namespace: http://cve.mitre.org/cve/downloads/1.0
Specification Name: Common Vulnerability and Exposures
Version: 1.0
Reference URI: http://cve.mitre.org/
Applicable Classes: Vulnerability
]]></artwork></figure>
</t>
<t>CVRF 1.0
<figure><artwork><![CDATA[
Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0
Specification Name: Common Vulnerability Reporting Format
Version: 1.0
Reference URI: http://www.icasi.org/cvrf
Applicable Classes: Vulnerability
]]></artwork></figure>
</t>
<t>CVSS 2.0
<figure><artwork><![CDATA[
Namespace: http://scap.nist.gov/schema/cvss-v2/1.0
Specification Name: Common Vulnerability Scoring System
Version: 2
Reference URI: http://www.first.org/cvss
Applicable Classes: Scoring
]]></artwork></figure>
</t>
<t>CWE 5.0
<figure><artwork><![CDATA[
Namespace: N/A
Specification Name: Common Weakness Enumeration
Version: 5.1
Reference URI: http://cwe.mitre.org/
Applicable Classes: Weakness
]]></artwork></figure>
</t>
<t>CWSS 0.8
<figure><artwork><![CDATA[
Namespace: N/A
Specification Name: Common Weakness Scoring System
Version: 0.8
Reference URI: http://cwe.mitre.org/cwss/
Applicable Classes: Scoring
]]></artwork></figure>
</t>
<t>MAEC 2.0
<figure><artwork><![CDATA[
Namespace: http://maec.mitre.org/XMLSchema/maec-core-2
Specification Name: Malware Attribute Enumeration and Characterization
Version: 2.0
Reference URI: http://maec.mitre.org/
Applicable Classes: EventReport, AttackPattern
]]></artwork></figure>
</t>
<t>OCIL 2.0
<figure><artwork><![CDATA[
Namespace: http://scap.nist.gov/schema/ocil/2.0
Specification Name: Open Checklist Interactive Language
Version: 2.0
Reference URI: http://scap.nist.gov/specifications/ocil/,
http://csrc.nist.gov/publications/PubsNISTIRs.html
#NIST-IR-7692
Applicable Classes: Verification
]]></artwork></figure>
</t>
<t>OVAL 5.10.1 Definitions
<figure><artwork><![CDATA[
Namespace: http://oval.mitre.org/XMLSchema/oval-definitions-5
Specification Name: Open Vulnerability and Assessment Language
Version: 5.10.1
Reference URI: http://oval.mitre.org/
Applicable Classes: Verification
]]></artwork></figure>
</t>
<t>OVAL 5.10.1 Results
<figure><artwork><![CDATA[
Namespace: http://oval.mitre.org/XMLSchema/oval-results-5
Specification Name: Open Vulnerability and Assessment Language
Version: 5.10.1
Reference URI: http://oval.mitre.org/
Applicable Classes: Verification
]]></artwork></figure>
</t>
<t>OVAL 5.10.1 Common
<figure><artwork><![CDATA[
Namespace: http://oval.mitre.org/XMLSchema/oval-common-5
Specification Name: Open Vulnerability and Assessment Language
Version: 5.10.1
Reference URI: http://oval.mitre.org/
Applicable Classes: Verification
]]></artwork></figure>
</t>
<t>XCCDF 1.2
<figure><artwork><![CDATA[
Namespace: http://checklists.nist.gov/xccdf/1.2
Specification Name: Extensible Configuration Checklist Description Format
Version: 1.2
Reference URI: http://scap.nist.gov/specifications/xccdf/,
http://csrc.nist.gov/publications/PubsNISTIRs.html
#NIST-IR-7275-r4
Applicable Classes: Verification
]]></artwork></figure>
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<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>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.5070" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.6045" ?>
<?rfc include="reference.RFC.6046" ?>
<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.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="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="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="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>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 06:27:46 |