The Incident Object Description Exchange Format
obsoleted by
- rfc-7970 — The Incident Object Description Exchange Format Version 2
updated by
- rfc-6685 — Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry
Extracted elements (27)
IODEF intentionally avoids defining a precise notion of 'incident', adopting a broad understanding flexible enough for most operators. The design goal is a framework for commonly exchanged information with ample extensibility, not exhaustive incident description, because the security analysis domain is not fully standardized.
The IODEF data model is explicitly a transport format, not an optimal representation for on-disk storage, long-term archiving, or in-memory processing. XML was chosen for extensibility and multi-character-encoding support, though it is acknowledged as inherently inefficient for binary data or high-volume exchange.
The 'restriction' attribute defaults to 'private' at the Incident class level and is logically inherited by all child classes. Child classes may override the parent's disclosure policy—either more restrictively or more permissively—allowing granular per-class access control within a single document.
Enumerated attribute values may be extended via the 'ext-value' escape token combined with a corresponding 'ext-*' STRING attribute (e.g., ext-purpose, ext-dtype, ext-action). Entire class structures may be extended by embedding foreign-namespace XML in AdditionalData with dtype='xml'. Both mechanisms require out-of-band coordination with recipients.
Several IODEF classes (Assessment, Impact, Node, Address, Service, Confidence) were derived from the Intrusion Detection Message Exchange Format (IDMEF), facilitating reuse of IDMEF-based tooling. The IODEF was designed to be complementary to other security data representations being standardized at the time.
At least one instance of Impact, TimeImpact, or MonetaryImpact MUST be present in the Assessment class.
Either a Port or Portlist class MUST be specified for each Service instance. When Portlist is used in both source and target within a Flow, there MUST be symmetry in the number and sequence of ports so that the n-th source port corresponds to the n-th target port.
For the Node class, NodeName MUST be provided if no Address information is given; if no NodeName is provided, at least one Address MUST be specified. If both are specified, DateTime SHOULD also be provided to record when the name-to-address resolution was performed.
INTEGER data MUST be encoded in Base 10. REAL (floating-point) data MUST also be encoded in Base 10.
The IncidentID 'name' attribute MUST use the fully qualified domain name of the CSIRT to achieve a globally unique identifier. The combination of name and element content MUST be globally unique, and documents MUST NOT reuse the same value unless referencing the same incident.
The version attribute of the IODEF-Document class MUST be '1.00', identifying conformance with this IODEF specification.
When EventData and Incident class information conflict, the interpretation of the more specific EventData MUST supersede the more generic information provided in the Incident class.
The AdditionalData class provides the primary extension mechanism for information not represented elsewhere. It supports typed atomic values (integer, string, byte, packet, XML, CSV, Windows registry, etc.) via the 'dtype' attribute and can encapsulate entire XML documents conforming to other schemas such as IDMEF.
The Address class represents hardware (layer-2), network (layer-3), or application (layer-7) addresses. The 'category' attribute supports asn, atm, e-mail, ipv4-addr, ipv4-net, ipv4-net-mask, ipv6-addr, ipv6-net, ipv6-net-mask, and mac, with a default of 'ipv4-addr'. Optional vlan-name and vlan-num attributes allow VLAN identification.
The Assessment class characterizes the impact of an incident. At least one of Impact (technical), TimeImpact (downtime/labor), or MonetaryImpact (financial loss) MUST be present. An optional Confidence class conveys the analytical validity of the assessment as a categorical or numeric value.
The Contact class describes organizational and personnel contact information for incident participants. It is recursively self-aggregating so that hierarchical contacts can be expressed without duplication; child Contact instances inherit data from their ancestors.
The EventData class describes a specific event within an incident, including involved systems (Flow), attack methods, assessment, forensic records (Record), and requested actions (Expectation). It is recursively defined; only leaf EventData instances (those containing no child EventData) represent actual events.
The Expectation class conveys the actions the sender requests of the recipient, scoped to the containing EventData. The 'action' attribute enumerates request types including contact-source-site, block-host, block-network, rate-limit-host, investigate, remediate-other, status-triage, and status-new-info.
The History class is a log of significant events and actions performed during incident handling, composed of one or more HistoryItem entries. Each HistoryItem carries a required DateTime, a required 'action' attribute classifying the performed action, and optional Contact and Description elements.
The Incident class is the core representation of a security incident. It carries a required 'purpose' attribute (traceback, mitigation, reporting, other), an optional 'restriction' attribute governing disclosure inheritance, and aggregates IncidentID, timing classes, Assessment, Contact, EventData, History, and AdditionalData.
The IODEF-Document class is the top-level container for all IODEF documents. It requires a 'version' attribute (MUST be '1.00'), a 'lang' RFC 4646 language code, and an optional 'formatid' for out-of-band processing instructions. It contains one or more Incident instances.
The System class describes a host or network involved in an incident event, categorized by role via 'category': source, target, intermediate, sensor, or infrastructure. A 'spoofed' attribute indicates confidence in whether this system is the true attacker or victim.
RFC 5070 registers the IODEF XML namespace 'urn:ietf:params:xml:ns:iodef-1.0' in the IETF XML namespace registry per RFC 3688, and registers the MIME media type 'application/iodef+xml' for IODEF document exchange.
IODEF documents encode sensitive incident information including host addresses, vulnerabilities, and attack methods. Section 9 notes that the format does not address the procedural, trust, and legal considerations that govern inter-CSIRT information sharing; operational deployments must manage these concerns independently.
The 'restriction' attribute conveys disclosure guidelines but provides no security, as there are no specified technical means to ensure that recipients handle information as requested. Operational IODEF implementations must address confidentiality, integrity, and authentication through transport-layer mechanisms (e.g., S/MIME, TLS) negotiated out-of-band.
IODEF is encoded as UTF-8 XML conforming to the XML Schema defined in Section 8. The IODEF namespace is 'urn:ietf:params:xml:ns:iodef-1.0'. Binary data (BYTE[]) is base64-encoded; hexadecimal data (HEXBIN) uses two-hex-digit tuples; special characters in strings use XML entity references.
Timestamps use the DATETIME type formatted as a subset of ISO 8601:2000 per RFC 3339 (xs:dateTime). Port lists (PORTLIST) use a comma-separated list of numbers and ranges matching '\d+(\-\d+)?(,\d+(\-\d+)?)*', e.g., '2,5-15,30,32'. Timezone offsets follow 'Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]'.