RFC 7203
An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information
Bestie, RFC 7203 is by T. Takahashi (NICT), K. Landfield (McAfee), and Y. Kadobayashi (NAIST) 🫶. It's a Standards Track document, ISSN 2070-1721, dated April 2014, and it's the An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information 🎀. The header doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC 💅.
Abstract 🌸
So this doc extends the Incident Object Description Exchange Format (IODEF) from RFC 5070 so security experts at different orgs can swap richer cybersecurity info and get their ops done faster ✨. It gives you a well-defined pattern for embedding structured info consistently, like identifier-based and XML-based info 🧚.
Status of This Memo
This is an Internet Standards Track document. 🌈
It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥. You can find more on Internet Standards in Section 2 of RFC 5741 💜.
Want the current status, any errata, or a way to send feedback? Check out http://www.rfc-editor.org/info/rfc7203 🍓.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully because they spell out your rights and restrictions 👀. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅.
Table of Contents 📖
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Applicability ...................................................4
4. Extension Definition ............................................5
4.1. IANA Table for Structured Cybersecurity Information ........5
4.2. Extended Data Type: XMLDATA ................................6
4.3. Extending IODEF ............................................6
4.4. Basic Structure of the Extension Classes ...................8
4.5. Defining Extension Classes .................................9
4.5.1. AttackPattern .......................................9
4.5.2. Platform ...........................................10
4.5.3. Vulnerability ......................................11
4.5.4. Scoring ............................................11
4.5.5. Weakness ...........................................12
4.5.6. EventReport ........................................13
4.5.7. Verification .......................................14
4.5.8. Remediation ........................................15
5. Mandatory-to-Implement Features ................................15
5.1. An Example XML Document ...................................16
5.2. An XML Schema for the Extension ...........................18
6. Security Considerations ........................................20
6.1. Transport-Specific Concerns ...............................20
6.2. Protection of Sensitive and Private Information ...........21
6.3. Application and Server Security ...........................22
7. IANA Considerations ............................................22
8. Acknowledgments ................................................24
9. References .....................................................24
9.1. Normative References ......................................24
9.2. Informative References ....................................261. Introduction ✨
The number of incidents in cyber society is growing day by day 📈. Incident info needs to be reported, exchanged, and shared among orgs so everyone can cope 🫶. IODEF is one of the tools already in use that makes that exchange possible 🎀.
Machine-readable info is a must if you want efficient security ops 🤖. IODEF lets you describe incident info, but it often needs to carry all sorts of unstructured incident data to explain exactly what's happening 🌸. More structure inside IODEF makes the doc more machine-readable, which means better automation for certain security ops ⭐.
The security community already has a bunch of ways to specify structured descriptions of cybersecurity info, like [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], [CVRF], [CVSS], [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and [XCCDF] 📚. In this context, cybersecurity info covers a broad range of structured data representation types that can be used to assess or report on the security posture of an asset or a set of assets 🛡️. Structured descriptions help you understand an incident better and make automated security ops way more streamlined 🧚. So it's really valuable to embed and convey these types of info inside IODEF docs 💖.
This doc extends IODEF to embed and convey various types of structured info 🦋. IODEF is flexible, extensible, and granular, so this doc defines an extension to IODEF instead of inventing a new report format 💅. For clarity, and to avoid duplication, it only provides the extra structures needed to exchange that structured info 🍓.
2. Terminology 📝
The terminology in this doc follows the terminology defined in RFC 5070 [RFC5070] 💜.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥.
3. Applicability 🌈
To keep up with the constantly changing security threat landscape, orgs need to exchange cybersecurity info. That includes attack patterns, platform info, vulnerabilities and weaknesses, countermeasure instructions, computer event logs, and severity assessments 👀. IODEF gives you a scheme to describe and exchange that info among interested parties. It doesn't define the detailed formats for specifying it, though 🙈.
Plenty of structured, detailed formats already exist for these types of info, and they can help with the exchange. They include [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], [CVRF], [CVSS], [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and [XCCDF] 🧚. When you embed them in an IODEF doc, the doc can give receivers more detailed context, and the doc becomes easy to reuse 💖.
Structured info makes more advanced security ops possible on the receiver side ⚡. Since the info is machine-readable, computers can process it, which means better automation of security ops 🤖.
Here's one example. An org wants to report a security incident and describe which vulnerability was exploited. The sender can simply use IODEF and embed an XML-based [XML1.0] attack pattern record that follows the syntax and vocabulary of an industry specification, instead of writing everything as free-form text 🎀. The receiver can find the needed attack pattern details by looking up some of the XML tags the specification defines 🔍. The receiver can then store the attack pattern record in its database and distribute it to interested parties as needed, all without human intervention 🫶.
Another example: an administrator is investigating an incident and has detected a configuration problem. They want to share it with a partner org so the same event doesn't happen there too 🤝. To confirm the configuration really was vulnerable, they use an internal repository to pull configuration info that was gathered before the initial attack and that's specific to a new vulnerability alert 🕵️. They use that info to automatically generate an XML-based software configuration description, embed it in an IODEF doc, and send the result to the partner org 💌.
4. Extension Definition 🎀
This doc extends IODEF to embed structured info by introducing new classes that can be embedded consistently inside an IODEF doc, as element contents of the AdditionalData and RecordItem classes [RFC5070] 💅.
4.1. IANA Table for Structured Cybersecurity Information 🗂️
This extension embeds structured cybersecurity information (SCI) defined by other specifications 🌸. IANA manages the list of supported specifications, and this doc defines the fields needed for each entry in that list ✨.
Each entry for each specification has the namespace [XMLNames], a specification name, a version, a reference URI, and applicable classes 📋. Arbitrary URIs that help readers understand the specification could be embedded inside the Reference URI field, but it is recommended that a standard/informational URI describing the specification be prepared and embedded here 🦋.
The initial IANA table has only one entry, as follows 👑:
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Version: 1.2
Reference URI: <http://standards.ieee.org/develop
/indconn/icsg/mmdef.html>,
<http://grouper.ieee.org/groups
/malware/malwg/Schema1.2/>
Applicable Classes: AttackPatternThe specification was developed by The Institute of Electrical and Electronics Engineers, Incorporated (IEEE), through the Industry Connections Security Group (ICSG) of its Standards Association 🧚.
The table is managed by IANA, following the allocation policy specified in Section 7 💜.
The SpecID attributes of extension classes (Section 4.5) must allow the values of the specifications' namespace fields, but implementations are otherwise not required to support all specifications of the IANA table, and they may choose which specifications to support 🌈. However, at a minimum, the specification listed in the initial IANA table needs to be supported, as described in Section 5 ⭐. If an implementation receives data it doesn't support, it may expand its functionality by looking up the IANA table, or it may notify the sender that it can't parse the data 🙈. The lookup could be done manually or automatically, but automatic download of data from IANA's website is not recommended, since that site isn't designed for mass retrieval of data by multiple devices 🚫.
4.2. Extended Data Type: XMLDATA ✨
okay so this extension inherits every data type from the IODEF data model 💖 and then adds exactly one new one: XMLDATA 🎀. That's the type for embedded XML data. It's defined as an extension to iodef:ExtensionType [RFC5070], with the dtype attribute set to "xml" 🫶.
4.3. Extending IODEF 🦋
so this doc defines eight extension classes: AttackPattern, Platform, Vulnerability, Scoring, Weakness, EventReport, Verification, and Remediation 🌈. Figure 1 shows how the IODEF Incident class [RFC5070] connects to all the new ones. It's drawn in UML syntax, per RFC 5070 [RFC5070] 📐. The UML is just for illustrating things, though. The real definitions are the XML elements in Section 5.2 🔥.
+---------------+
| Incident |
+---------------+
| ENUM purpose |<>---------[IncidentID]
| STRING |<>--{0..1}-[AlternativeID]
| ext-purpose |<>--{0..1}-[RelatedActivity]
| ENUM lang |<>--{0..1}-[DetectTime]
| ENUM |<>--{0..1}-[StartTime]
| restriction |<>--{0..1}-[EndTime]
| |<>---------[ReportTime]
| |<>--{0..*}-[Description]
| |<>--{1..*}-[Assessment]
| |<>--{0..*}-[Method]
| | |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[AttackPattern]
| | |<>--{0..*}-[Vulnerability]
| | |<>--{0..*}-[Weakness]
| |<>--{1..*}-[Contact]
| |<>--{0..*}-[EventData]
| | |<>--{0..*}-[Flow]
| | | |<>--{1..*}-[System]
| | | |<>--{0..*}-[AdditionalData]
| | | |<>--{0..*}-[Platform]
| | |<>--{0..*}-[Expectation]
| | |<>--{0..1}-[Record]
| | |<>--{1..*}-[RecordData]
| | |<>--{1..*}-[RecordItem]
| | |<>--{0..*}-[EventReport]
| |<>--{0..1}-[History]
| |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[Verification]
| | |<>--{0..*}-[Remediation]
+---------------+
Figure 1: Incident Class4.4. Basic Structure of the Extension Classes 🧩
Figure 2 is the basic skeleton every extension class shares 💅. Some classes have extra bits on top, which you'll see in Section 4.5, but the core stays the same.
+---------------------+
| New Class Name |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 2: Basic Structurethere are three attributes 👑:
- SpecID: REQUIRED. ENUM. This is the identifier for the spec that defines the format of the structured info 🎀. The value should be picked from the namespaces [XMLNames] in the IANA table (Section 4.1), or it's
"private"."private"is for when your format isn't in the table. It's usually for data that follows an organization's own private schema. When the value is"private", theext-SpecIDelement MUST be used. - ext-SpecID: OPTIONAL. STRING. Another identifier for the spec that defines the format of the structured info ✨. This is usually there to support a private schema that isn't in the IANA table (Section 4.1). This attribute MUST be used only when the value of the
SpecIDelement is"private." - ContentID: OPTIONAL. STRING. An identifier for the structured info 🦋. What the content looks like depends on the extension class. This attribute lets an IODEF document carry the ID of the structured info instead of the info itself.
and there are two elements too 💜:
- RawData: Zero or more. XMLDATA. An XML document with the structured info 📄. It's a complete document, formatted according to the spec and version identified by
SpecID/ext-SpecID. When this element is used, writers/senders MUST ensure that the namespace given bySpecID/ext-SpecIDand the schema of the XML are consistent. If they aren't, the namespace identified bySpecIDSHOULD be preferred, and the inconsistency SHOULD be logged so a human can fix it 🙈. - Reference: Zero or more of iodef:Reference [RFC5070]. A reference to the structured info 🔗. It lets an IODEF document link to the info, instead of embedding it directly in a
RawDataelement.
Though ContentID is an optional attribute, and RawData and Reference are optional elements, one of them MUST be used to convey structured information. Also, to keep the receiver from getting confused, only one of them SHOULD be used 💀.
4.5. Defining Extension Classes 🌸
This document defines eight extension classes, each one described in the subsections below 🫶.
4.5.1. AttackPattern ⚔️
An AttackPattern is an extension class to the Incident.Method.AdditionalData element, with a dtype of "xml" 🔥. It describes the attack patterns of incidents or events. It is RECOMMENDED that the Method class [RFC5070] contain the extension elements whenever they're available 💖. Here's how an AttackPattern class is laid out:
+---------------------+
| AttackPattern |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
+---------------------+
Figure 3: AttackPattern Classthis class has these attributes 🎀:
- SpecID: REQUIRED. ENUM. See Section 4.4.
- ext-SpecID: OPTIONAL. STRING. See Section 4.4.
- ContentID: OPTIONAL. STRING. An identifier of attack pattern info. See Section 4.4.
and these elements too 🧚:
- RawData: Zero or more. XMLDATA. An XML document of attack pattern info. See Section 4.4.
- Reference: Zero or more. A reference to attack pattern info. See Section 4.4.
- Platform: Zero or more. An identifier of the software platform involved in the specific attack pattern. See Section 4.5.2.
4.5.2. Platform 💻
A Platform is an extension class that identifies a software platform 🍓. It is RECOMMENDED that the AttackPattern, Vulnerability, Weakness, and System [RFC5070] classes contain the extension elements whenever they're available 💅. Here's the layout:
+---------------------+
| Platform |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 4: Platform Classthis class has these attributes ✨:
- SpecID: REQUIRED. ENUM. See Section 4.4.
- ext-SpecID: OPTIONAL. STRING. See Section 4.4.
- ContentID: OPTIONAL. STRING. An identifier of platform info. See Section 4.4.
and these elements 🌈:
- RawData: Zero or more. XMLDATA. An XML document of platform info. See Section 4.4.
- Reference: Zero or more. A reference to platform info. See Section 4.4.
4.5.3. Vulnerability 🐛
A Vulnerability is an extension class to the Incident.Method.AdditionalData element, with a dtype of "xml" 🫶. This extension describes the vulnerabilities that were exposed or exploited in incidents. It is RECOMMENDED that the Method class contain the extension elements whenever they're available 🔥. A Vulnerability element is laid out like this:
+---------------------+
| Vulnerability |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 5: Vulnerability Classthis class has these attributes 👑:
- SpecID: REQUIRED. ENUM. See Section 4.4.
- ext-SpecID: OPTIONAL. STRING. See Section 4.4.
- ContentID: OPTIONAL. STRING. An identifier of vulnerability info. See Section 4.4.
and these elements 💜:
- RawData: Zero or more. XMLDATA. An XML document of vulnerability info. See Section 4.4.
- Reference: Zero or more. A reference to vulnerability info. See Section 4.4.
- Platform: Zero or more. An identifier of the software platform affected by the vulnerability. See Section 4.5.2.
- Scoring: Zero or more. An indicator of how severe the vulnerability is. See Section 4.5.4.
4.5.4. Scoring 📊
A Scoring is an extension class that describes severity scores in terms of security 🦋. It is RECOMMENDED that the Vulnerability and Weakness classes contain the extension elements whenever they're available 🌸.
A Scoring class is laid out like this:
+---------------------+
| Scoring |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 6: Scoring Classthis class has these attributes 🎀:
- SpecID: REQUIRED. ENUM. See Section 4.4.
- ext-SpecID: OPTIONAL. STRING. See Section 4.4.
- ContentID: OPTIONAL. STRING. An identifier of a score set. See Section 4.4.
and these elements ✨:
- RawData: Zero or more. XMLDATA. An XML document of a score set. See Section 4.4.
- Reference: Zero or more. A reference to a score set. See Section 4.4.
4.5.5. Weakness ✨
okay so a Weakness is an extension class that hangs off the Incident.Method.AdditionalData element, with a dtype of "xml" 💅 it describes the weakness types that are exposed or were exploited in incidents 🔥 it is RECOMMENDED that the Method class contain the extension elements whenever available ✨ a Weakness element looks like this:
+---------------------+
| Weakness |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 7: Weakness Classthis class has the following attributes 🎀
SpecID: REQUIRED. ENUM. See Section 4.4.ext-SpecID: OPTIONAL. STRING. See Section 4.4.ContentID: OPTIONAL. STRING. An identifier of weakness information. See Section 4.4.
it also has these elements 🦋
RawData: Zero or more. XMLDATA. An XML document of weakness information. See Section 4.4.Reference: Zero or more. A reference to weakness information. See Section 4.4.Platform: Zero or more. An identifier of the software platform affected by the weakness. See Section 4.5.2.Scoring: Zero or more. An indicator of the severity of the weakness. See Section 4.5.4.
4.5.6. EventReport 🌸
an EventReport is an extension class that hangs off the Incident.EventData.Record.RecordData.RecordItem element, with a dtype of "xml" 🧚 it's basically the way to embed structured event reports 💖 it is RECOMMENDED that the RecordItem class contain the extension elements whenever available ✨ an EventReport element is structured like so:
+---------------------+
| EventReport |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 8: EventReport Classthis class has the following attributes 🎀
SpecID: REQUIRED. ENUM. See Section 4.4.ext-SpecID: OPTIONAL. STRING. See Section 4.4.ContentID: OPTIONAL. STRING. An identifier of an event report. See Section 4.4.
it also has these elements 🦋
RawData: Zero or more. XMLDATA. An XML document of an event report. See Section 4.4.Reference: Zero or more. A reference to an event report. See Section 4.4.
4.5.7. Verification 🔍
a Verification is an extension class that hangs off the Incident.AdditionalData element, with a dtype of "xml" 💅 the extension elements describe information on verifying security (think a checklist 📝) so you can cope with incidents 🫶 it is RECOMMENDED that the Incident class contain the extension elements whenever available ✨ a Verification class is structured like this:
+---------------------+
| Verification |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 9: Verification Classthis class has the following attributes 🎀
SpecID: REQUIRED. ENUM. See Section 4.4.ext-SpecID: OPTIONAL. STRING. See Section 4.4.ContentID: OPTIONAL. STRING. An identifier of verification information. See Section 4.4.
it also has these elements 🦋
RawData: Zero or more. XMLDATA. An XML document of verification information. See Section 4.4.Reference: Zero or more. A reference to verification information. See Section 4.4.
4.5.8. Remediation 🛠️
a Remediation is an extension class that hangs off the Incident.AdditionalData element, with a dtype of "xml" 💖 the extension elements describe incident remediation information, including instructions 📣 it is RECOMMENDED that the Incident class contain the extension elements whenever available ✨ a Remediation class is structured as follows:
+---------------------+
| Remediation |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| String ContentID |
+---------------------+
Figure 10: Remediation Classthis class has the following attributes 🎀
SpecID: REQUIRED. ENUM. See Section 4.4.ext-SpecID: OPTIONAL. STRING. See Section 4.4.ContentID: OPTIONAL. STRING. An identifier of remediation information. See Section 4.4.
it also has these elements 🦋
RawData: Zero or more. XMLDATA. An XML document of remediation information. See Section 4.4.Reference: Zero or more. A reference to remediation information. See Section 4.4.
5. Mandatory-to-Implement Features 🎀
okay this part is important bestie 😭 implementations that follow this document MUST be able to send and receive the extended IODEF documents that contain XML documents matching the specification listed in the initial IANA table from Section 4.1, and they have to do it without error 💅 the extended IODEF document is an XML document that MUST be well-formed and MUST be valid against the schemata (including extension schemata) that the validator has access to and that apply to the XML document 🔥 also, the receiver can look up the namespace in the IANA table to figure out which specifications the embedded XML documents follow 🧐
to make the mandatory-to-implement features easier to get, the next subsections give you an XML document that conforms to this memo, plus a matching schema 🦋
5.1. An Example XML Document 🍓
so here's an example IODEF document you can use to check that your implementation is conformant 💖 it carries Malware Metadata Exchange Format (MMDEF) metadata 🧪 the metadata was generated by genMMDEF [MMDEF] using EICAR [EICAR] files 🙈 some line breaks got added to this example because of the 72-characters-per-line limit, so don't panic if things look a little wrapped 💜
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Incident purpose="reporting">
<IncidentID name="sci.example.com">189493</IncidentID>
<ReportTime>2013-06-18T23:19:24+00:00</ReportTime>
<Description>a candidate security incident</Description>
<Assessment>
<Impact completion="failed" type="admin" />
</Assessment>
<Method>
<Description>A candidate attack event</Description>
<AdditionalData dtype="xml">
<sci:AttackPattern SpecID=
"urn:ietf:params:xml:ns:mile:mmdef:1.2">
<sci:RawData dtype="xml">
<malwareMetaData xmlns="http://xml/metadataSharing.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xml/metadataSharing.xsd
file:metadataSharing.xsd" version="1.200000" id="10000">
<company>N/A</company>
<author>MMDEF Generation Script</author>
<comment>Test MMDEF v1.2 file generated using genMMDEF
</comment>
<timestamp>2013-03-23T15:12:50.726000</timestamp>
<objects>
<file id="6ce6f415d8475545be5ba114f208b0ff">
<md5>6ce6f415d8475545be5ba114f208b0ff</md5>
<sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1>
<sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e464
9b934ca495991b7852b855</sha256>
<sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b
5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff83
18d2877eec2f63b931bd47417a81a538327af927
da3e</sha512>
<size>184</size>
<filename>eicar_com.zip</filename>
<MIMEType>application/zip</MIMEType>
</file>
<file id="44d88612fea8a8f36de82e1278abb02f">
<md5>44d88612fea8a8f36de82e1278abb02f</md5>
<sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1>
<sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec
2fe2a2c4538aabf651fd0f</sha256>
<sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b88551
8f4e565e68847223b8e6b85cb48f3afad842726d99
239c9e36505c64b0dc9a061d9e507d833277ada3
36ab</sha512>
<size>68</size>
<crc32>1750191932</crc32>
<filename>eicar.com</filename>
<filenameWithinInstaller>eicar.com
</filenameWithinInstaller>
</file>
</objects>
<relationships>
<relationship type="createdBy" id="1">
<source>
<ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]
</ref>
</source>
<target>
<ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]
</ref>
</target>
<timestamp>2013-03-23T15:12:50.744000</timestamp>
</relationship>
</relationships>
</malwareMetaData>
</sci:RawData>
</sci:AttackPattern>
</AdditionalData>
</Method>
<Contact role="creator" type="organization">
<ContactName>sci.example.com</ContactName>
<RegistryHandle registry="arin">sci.example-com
</RegistryHandle>
<Email>contact@csirt.example.com</Email>
</Contact>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Service ip_protocol="4">
<Port>80</Port>
</Service>
</System>
</Flow>
<Expectation action="block-host" />
<Expectation action="other" />
</EventData>
</Incident>
</IODEF-Document>5.2. An XML Schema for the Extension 📜
last up is the XML schema that describes the elements defined in this document 💅 here it is, no cap ✨
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/><xsd:complexType name="XMLDATA">
<xsd:complexContent>
<xsd:restriction base="iodef:ExtensionType">
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="dtype" type="iodef:dtype-type"
use="required" fixed="xml"/>
<xsd:attribute name="ext-dtype" type="xsd:string"
use="prohibited"/>
<xsd:attribute name="meaning" type="xsd:string"/>
<xsd:attribute name="formatid" type="xsd:string"/>
<xsd:attribute name="restriction" type="iodef:restriction-type"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="BasicStructure">
<xsd:sequence>
<xsd:choice>
<xsd:element name="RawData" type="sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="SpecID" type="xsd:string" use="required"/>
<xsd:attribute name="ext-SpecID" type="xsd:string"/>
<xsd:attribute name="ContentID" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="Scoring" type="sci:BasicStructure"/>
<xsd:element name="Platform" type="sci:BasicStructure"/>
<xsd:element name="EventReport" type="sci:BasicStructure"/>
<xsd:element name="Verification" type="sci:BasicStructure"/>
<xsd:element name="Remediation" type="sci:BasicStructure"/>
<xsd:element name="AttackPattern">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Vulnerability">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="sci:Scoring" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Weakness">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="sci:Scoring" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>6. Security Considerations 🔐✨
Okay bestie, this document is just a data format 🫶, so on its own it doesn't directly bring in any security issues. BUT ngl, the parties swapping these instances are guaranteed to have some concerns, so the underlying message format and transport protocol MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific environment. The automated exchanges get the detailed security scoop in Sections 9 and 10 of "Real-time Inter-network Defense (RID)" [RFC6545] and Section 4 of "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS" [RFC6546] 💅.
It is RECOMMENDED that organizations that exchange data using this document develop operating procedures that consider, at a minimum, the following areas of concern. Main character energy: plan ahead 📝.
6.1. Transport-Specific Concerns 🚚
Okay so IODEF has data markers that flag how sensitive a class is, plus one for the whole XML document 🏷️. The "restriction" attribute handles this with four attribute values in IODEF [RFC5070]. These values are RECOMMENDED for use at the application level, before transport, to protect the data as needed. There's a standard way to apply XML encryption that uses these attribute values as triggers, and it's defined in RID [RFC6545], Section 9.1. It's iconic because it works whether or not the RID protocol [RFC6545] and its associated transport binding [RFC6546] are used in the exchange. The goal is object-level security, so intermediary systems or middleboxes can't access the data being exchanged 🧚.
Where transmission security or secrecy is questionable, applying an XML digital signature [XMLDSIG] and/or encryption on each report will counteract both of these concerns 🔥. The data markers are RECOMMENDED for use by applications for managing access controls 🔑. Just know that access controls and managing them are out of scope for this document, so that's not on this spec 🙅♀️. If you want, options like the eXtensible Access Control Markup Language [XACML] can express authorization policies, which helps source and destination systems line up their policy expressions 🦋.
Any transport protocol used to exchange instances of IODEF documents MUST provide appropriate guarantees of confidentiality, integrity, and authenticity 🫡. Using a standardized security protocol is encouraged 💜. The RID protocol [RFC6545] and its associated transport binding [RFC6546] provide that security, with options for mutual authentication and session encryption, and they also cover application-level stuff like policy and workflow 🎀.
The critical security concerns are that structured information may be falsified, accessed by unintended entities, or become corrupt during transit 😭. Each exchanging organization will decide whether it needs transport protection, and which mechanism to use 🌸.
6.2. Protection of Sensitive and Private Information 🙈
For a complete review of privacy considerations when transporting incident-related information, check out RID [RFC6545], Section 9.5 📖. Whether or not you use RID, privacy considerations matter, because incident info is often sensitive and can contain privacy-related info about individuals, organizations, or endpoints involved 🥺. Organizations often need legal reviews and formal policies that spell out exactly what info can be shared with specific entities ⚖️. Identifying info is typically anonymized where possible and appropriate 🫶. Sometimes information brokers are used to further anonymize the source of shared info, so other entities don't know where a detected threat came from, whether or not that threat was realized 🕵️♀️.
It is RECOMMENDED that policies and procedures for the exchange of cybersecurity information be established prior to participation in data exchanges 🗂️. Policy and workflow procedures for exchanging cybersecurity information often need executive-level approvals and legal reviews to set limits on what can be exchanged with specific organizations 👔. RID [RFC6545], Section 9.6 lays out options and considerations that application developers can look at for policy and workflow design 🧠.
6.3. Application and Server Security 🛡️
The cybersecurity information extension is merely a data format 💅. Applications and transport protocols that store or exchange IODEF documents that use info represented through this extension WILL be a target for attacks 💀. It is RECOMMENDED that systems and applications storing or exchanging this information be properly secured, have minimal services enabled, and maintain access controls and monitoring procedures 🔒🚨.
7. IANA Considerations 📋
This document uses URNs to describe XML namespaces and XML schemata [XMLschemaPart1] [XMLschemaPart2], conforming to a registry mechanism described in [RFC3688] 🦄.
The following IODEF structured cybersecurity information extension namespace has been registered ✨:
URI: urn:ietf:params:xml:ns:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of
this document.
XML: None.The following IODEF structured cybersecurity information extension XML schema has been registered 🎀:
URI: urn:ietf:params:xml:schema:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of
this document.
XML: Refer to the XML schema in Section 5.2 of this document.This memo creates the following registry, which is managed by IANA 🗃️:
Name of the registry: "Structured Cybersecurity Information (SCI)
Specifications"
Name of its parent registry: "Incident Object Description Exchange
Format (IODEF)"
URL of the registry: <http://www.iana.org/assignments/iodef>
Namespace details: A registry entry for a Structured Cybersecurity
Information Specification (SCI specification) consists of:
Namespace: A URI [RFC3986] that identifies the XML namespace
used by the registered SCI specification. In the case where
the registrant does not request a particular URI, the IANA will
assign it a Uniform Resource Name (URN) that follows RFC 3553
[RFC3553].
Specification Name: A string containing the spelled-out name of
the SCI specification in human-readable form.
Reference URI: A list of one or more of the URIs [RFC3986] from
which the registered specification can be obtained. The
registered specification MUST be readily and publicly available
from that URI.
Applicable Classes: A list of one or more of the extension
classes specified in Section 4.5 of this document. The
registered SCI specification MUST only be used with the
extension classes in the registry entry.
Information that must be provided to assign a new value: The above
list of information.
Fields to record in the registry: Namespace/Specification Name/
Version/Reference URI/Applicable Classes. Note that it is not
necessary to include a defining reference for all assignments in
this new registry.
Initial registry contents: Only one entry, with the following
values:
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Version: 1.2
Reference URI:
<http://standards.ieee.org/develop/indconn/icsg/mmdef.html>,
<http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>
Applicable Classes: AttackPattern
Allocation policy: Specification Required (which includes Expert
Review) [RFC5226].The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group, or its successor if any such working group exists (e.g., via email to the working group's mailing list) 📬. The Designated Expert is also expected to retrieve the SCI specification from the provided URI, to check that the specification is publicly available and to verify the correctness of the URI 🔍. An important responsibility of the Designated Expert is making sure the registered applicable classes are appropriate for the registered SCI specification 💖.
8. Acknowledgments ✨
Okay bestie, this is the thank-you list 🫶 Huge shoutout to David Black from EMC, who gave so much support, especially on the IANA registry issues 💖 We also owe a big thanks to Jon Baker from MITRE, Eric Burger from Georgetown University, Paul Cichonski from NIST, Panos Kampanakis from Cisco, Ivan Kirillov from MITRE, Pearl Liang from IANA, Robert Martin from MITRE, Alexey Melnikov from Isode, Thomas Millar from US-CERT, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Sean Turner from IECA, Inc., Anthony Rutkowski from Yaana Technology, Brian Trammell from ETH Zurich, David Waltermire from NIST, James Wendorf from IEEE, and Shuhei Yamaguchi from NICT 🌸 Every one of them gave real discussion and feedback on this document, and that's iconic ✨
9. References 🦋
9.1. Normative References
These are the must-reads, the ones this document leans on 📚
[MMDEF]ICSG Malware Metadata Exchange Format Working Group, "Malware Metadata Exchange Format", IEEE Standards Association, November 2011,http://grouper.ieee.org/groups/malware/malwg/Schema1.2/.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.[RFC5070]Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[RFC6545]Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012.[RFC6546]Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012.[XML1.0]Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008,http://www.w3.org/TR/xml/.[XMLschemaPart1]Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004,http://www.w3.org/TR/xmlschema-1/.[XMLschemaPart2]Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004,http://www.w3.org/TR/xmlschema-2/.[XMLNames]Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation, December 2009,http://www.w3.org/TR/xml-names/.
9.2. Informative References
These are the extra-credit reads that give the bigger picture 🌈
[RFC3553]Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.[RFC3688]Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.[CAPEC]The MITRE Corporation, "Common Attack Pattern Enumeration and Classification (CAPEC)",http://capec.mitre.org/.[CCE]National Institute of Standards and Technology, "Common Configuration Enumeration (CCE)",http://nvd.nist.gov/cce/index.cfm.[CCSS]Scarfone, K. and P. Mell, "The Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration Vulnerabilities", NIST Interagency Report 7502, December 2010,http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf.[CEE]The MITRE Corporation, "Common Event Expression (CEE)",http://cee.mitre.org/.[CPE]National Institute of Standards and Technology, "Common Platform Enumeration", June 2011,http://scap.nist.gov/specifications/cpe/.[CVE]The MITRE Corporation, "Common Vulnerabilities and Exposures (CVE)",http://cve.mitre.org/.[CVRF]ICASI, "The Common Vulnerability Reporting Framework (CVRF)",http://www.icasi.org/cvrf.[CVSS]Mell, P., Scarfone, K., and S. Romanosky, "The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems", NIST Interagency Report 7435, August 2007,http://csrc.nist.gov/publications/nistir/ir7435/NISTIR-7435.pdf.[CWE]The MITRE Corporation, "Common Weakness Enumeration (CWE)",http://cwe.mitre.org/.[CWSS]The MITRE Corporation, "Common Weakness Scoring System (CWSS(TM))",http://cwe.mitre.org/cwss/.[EICAR]EICAR - European Expert Group for IT-Security, "Anti-Malware Testfile", 2003,http://www.eicar.org/86-0-Intended-use.html.[MAEC]The MITRE Corporation, "Malware Attribute Enumeration and Characterization",http://maec.mitre.org/.[OCIL]Waltermire, D., Scarfone, K., and M. Casipe, "Specification for the Open Checklist Interactive Language (OCIL) Version 2.0", NIST Interagency Report 7692, April 2011,http://csrc.nist.gov/publications/nistir/ir7692/nistir-7692.pdf.[OVAL]The MITRE Corporation, "Open Vulnerability and Assessment Language (OVAL)",http://oval.mitre.org/.[SCAP]Waltermire, D., Quinn, S., Scarfone, K., and A. Halbardier, "The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2", NIST Special Publication 800-126 Revision 2, September 2011,http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf.[XACML]Rissanen, E., "eXtensible Access Control Markup Language (XACML) Version 3.0", January 2013,http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf.[XCCDF]Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring, "Specification for the Extensible Configuration Checklist Description Format (XCCDF) version 1.2 (DRAFT)", NIST Interagency Report 7275, Revision 4, September 2011,http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf.[XMLDSIG]W3C Recommendation, "XML Signature Syntax and Processing (Second Edition)", June 2008,http://www.w3.org/TR/xmldsig-core/.
Authors' Addresses 💜
Takeshi Takahashi
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi Koganei
184-8795 Tokyo
Japan
Phone: +80 423 27 5862
EMail: takeshi_takahashi@nict.go.jp
Kent Landfield
McAfee, Inc.
5000 Headquarters Drive
Plano, TX 75024
USA
EMail: Kent_Landfield@McAfee.com
Youki Kadobayashi
Nara Institute of Science and Technology
8916-5 Takayama, Ikoma
630-0192 Nara
Japan
EMail: youki-k@is.aist-nara.ac.jp📦 where this page comes from
- ietf: rfc7203 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms