One document matched: draft-ietf-mile-sci-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-ietf-mile-sci-03.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='Apr' day='11' 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 by embedding structured information 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 numbers are 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, to describe those information and to facilitate exchange, a structured format for that is already available. 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>
</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 from external specifications.
The initial list of supported specifications is listed below.
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>Future assignments are 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 <xref target="CVE_1.0">CVE 1.0</xref> 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.</t>
<section title="CAPEC 1.6" anchor="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="CVE 1.0" anchor="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="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>
</section>
<section title="XCCDF 1.2" anchor="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>
</section>
</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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/> or "private".
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="AttackPatternID:">OPTIONAL. STRING.
An identifier of an attack pattern to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided.
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 value of the SpecID with the <xref target="SpecificationList"/>.</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"/>.
Some of the structured information embedded in the RawData element may include the identifier within it.
In this case, this Platform 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>
</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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="PlatformID:">OPTIONAL. STRING.
An identifier of a platform to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available.
In this case, either RawData or Reference elements, or both of them, MUST be provided.
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>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 value of the SpecID with the <xref target="SpecificationList"/>.</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>
<t>Writers/senders MUST ensure the specification name and version identified by the SpecID are consistent with the contents of the ID; 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>
<!--****************************************************
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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="VulnerabilityID:">OPTIONAL. STRING.
An identifier of a vulnerability to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided.
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>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 value of the SpecID with the <xref target="SpecificationList"/>.</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"/>.
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 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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
In case a RawData or Reference element is provided along with this attribute, writers/senders MUST ensure that this namespace is consistent with the one provided by the element; if a reader/receiver detects an inconsistency, it SHOULD prefer the value of this attribute, and SHOULD log the inconsistency so a human can correct the problem.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>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 value of the SpecID with the <xref target="SpecificationList"/>.
This element includes a set of score information.
</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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="WeaknessID:">OPTIONAL. STRING.
An identifier of a weakness to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided.
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>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 value of the SpecID with the <xref target="SpecificationList"/>.</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"/>.
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"/>. 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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="EventID:">OPTIONAL. STRING.
An identifier of an event to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided.
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> 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 value of the SpecID with the <xref target="SpecificationList"/>.</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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="VerificationID:">OPTIONAL. STRING.
An identifier of an check item to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided.
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> 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 value of the SpecID with the <xref target="SpecificationList"/>.</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.
The identifier of the specification specifying the format of the RawData element.
The value should be chosen from the <xref target="XMLNames">namespaces</xref> listed in <xref target="SpecificationList"/>.
Note that the lists in <xref target="SpecificationList"/> will be developed further by IANA.
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.
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 needs to be used.
</t>
<t hangText="ext-SpecID:">OPTIONAL. STRING.
The identifier of the specification specifying the format of the RawData element.
When this element is used, the value of SpecID element must be "private."
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>
<t hangText="RemediationID:">OPTIONAL. STRING.
An identifier of a remediation information to be reported.
This attribute SHOULD be used whenever such identifier is available, but could be omitted if no such one is available. In this case, either RawData or Reference elements, or both of them, MUST be provided.
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> 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 value of the SpecID with the <xref target="SpecificationList"/>.</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: See sections from <xref target="CAPEC_1.6"/> through <xref target="XCCDF_1.2"/> above.</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:element name="RawData" type="iodef-sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
maxOccurs="unbounded"/>
<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:element name="RawData" type="iodef-sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
maxOccurs="unbounded"/>
<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:element name="RawData" type="iodef-sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
maxOccurs="unbounded"/>
<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:element name="RawData" type="iodef-sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" 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="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="CAPEC_1.6"
AttackPatternID="CAPEC-14">
<iodef-sci:RawData>
<Attack_Pattern_Catalog Catalog_Name="CAPEC"
Catalog_Version="1.6" Catalog_Date="2010-12-09"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:observables="http://capec.mitre.org/observables"
xsi:noNamespaceSchemaLocation=
"http://capec.mitre.org/data/xsd/ap_schema_v2.1.xsd">
<Views>.....</Views>
</Attack_Pattern_Catalog>
</iodef-sci:RawData>
<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="CVE_1.0"
VulnerabilityID="CVE-2010-3654">
<iodef-sci:RawData>
<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="CPE_2.3"
PlatformID="[CPE ID]"/>
<iodef-sci:Scoring SpecID="CVSS_2.0">
<iodef-sci:ScoreSet>
<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="CWE_5.0"
WeaknessID="CWE-119">
<iodef-sci:RawData>
<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="CPE_2.3"
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="CEE_0.6">
<iodef-sci:RawData>
<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="OVAL_5.10">
<iodef-sci:RawData>
<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="XCCDF_1.2">
<iodef-sci:RawData>
<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>
</middle>
<back>
<references title="Normative References">
<?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>
<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="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="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>
<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="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>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 06:27:46 |