An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information
Extracted elements (26)
Structured cybersecurity information formats (CAPEC, CVE, CVSS, CWE, CPE, etc.) already exist; embedding them into IODEF documents rather than reinventing description formats enables machine-readable data exchange and better automation of security operations on the receiver side.
This document extends IODEF rather than defining a new report format because IODEF is already a flexible and extensible format supporting granular specificity. Defining an extension avoids duplication and reuses the existing ecosystem.
Automatic download of SCI specifications from IANA's website is not recommended because the site is not designed for mass retrieval by multiple devices; implementations should look up the table manually or cache locally.
Implementations are not required to support all specifications listed in the IANA SCI table; however, at minimum the initial MMDEF v1.2 entry must be supported. If an implementation receives unsupported data, it may expand functionality by consulting the IANA table or notify the sender of its inability to parse.
Although ContentID, RawData, and Reference are individually optional, at least one of them MUST be used to convey structured information in each extension class instance.
Any transport protocol used to exchange instances of IODEF documents MUST provide appropriate guarantees of confidentiality, integrity, and authenticity.
Implementations compliant with this document MUST be capable of sending and receiving extended IODEF documents containing XML documents conforming to the specification listed in the initial IANA table (MMDEF v1.2) without error.
The ext-SpecID attribute MUST be used only when the value of the SpecID element is 'private'.
The extended IODEF document MUST be well-formed XML and MUST be valid according to schemata, including extension schemata, available to the validator and applicable to the document.
The underlying message format and transport protocol used MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific exchange environment.
When RawData is used, writers/senders MUST ensure that the namespace specified by SpecID/ext-SpecID and the schema of the embedded XML are consistent; if not, the namespace identified by SpecID SHOULD be preferred and the inconsistency SHOULD be logged.
When the SpecID value is 'private', the ext-SpecID element MUST be used to convey the private schema identifier.
Incident information is often sensitive and may contain privacy-related data about individuals, organizations, or endpoints. Organizations SHOULD establish policies and legal reviews prior to data exchange, anonymize identifying information where possible, and may use information brokers to further anonymize the source.
All extension classes share a BasicStructure with three attributes (SpecID REQUIRED ENUM, ext-SpecID OPTIONAL STRING, ContentID OPTIONAL STRING) and two elements (RawData zero-or-more XMLDATA, Reference zero-or-more iodef:Reference).
AttackPattern extends Incident.Method.AdditionalData (dtype='xml') and additionally contains zero or more Platform child elements identifying software platforms involved in the attack pattern.
Eight extension classes are defined: AttackPattern, Platform, Vulnerability, Scoring, Weakness, EventReport, Verification, and Remediation. All are embedded as element contents of the IODEF AdditionalData or RecordItem classes with dtype 'xml'.
EventReport extends Incident.EventData.Record.RecordData.RecordItem (dtype='xml') and embeds structured event reports such as computer event logs.
Verification and Remediation both extend Incident.AdditionalData (dtype='xml'); Verification carries security checklists and Remediation carries incident remediation instructions.
Vulnerability extends Incident.Method.AdditionalData (dtype='xml') and contains zero or more Platform elements (affected platform) and zero or more Scoring elements (severity indicators).
Weakness extends Incident.Method.AdditionalData (dtype='xml') and contains zero or more Platform elements and zero or more Scoring elements, mirroring the Vulnerability structure but for weakness types.
This document creates the 'Structured Cybersecurity Information (SCI) Specifications' registry under the IODEF parent registry at IANA. Each entry records a Namespace URI, Specification Name, Version, Reference URI, and Applicable Classes. Allocation policy is Specification Required (Expert Review). The initial entry is Malware Metadata Exchange Format (MMDEF) v1.2 applicable to the AttackPattern class.
This document registers the XML namespace 'urn:ietf:params:xml:ns:iodef-sci-1.0' and the XML schema 'urn:ietf:params:xml:schema:iodef-sci-1.0' in the IETF XML Registry per RFC 3688.
Applications and servers storing or exchanging IODEF documents with SCI extensions are targets for attacks. It is RECOMMENDED they be properly secured, have minimal services enabled, and maintain access controls and monitoring.
Structured information exchanged in IODEF documents may be falsified, accessed by unintended entities, or become corrupt during transit. XML digital signatures and/or encryption SHOULD be applied in areas where transmission security is questionable.
The IODEF 'restriction' attribute (four values) SHOULD be used at the application level prior to transport to indicate data sensitivity, and XML encryption triggered by these markers (as defined in RID RFC 6545 Section 9.1) MAY be applied for object-level security even when RID transport is not used.
The XMLDATA data type is defined as a restriction of iodef:ExtensionType with the 'dtype' attribute fixed to 'xml' and 'ext-dtype' prohibited. It accepts any XML namespace content with lax processing.