rfc-7970

The Incident Object Description Exchange Format Version 2

R. Danyliw
date2016-11 streamIETF areasec wgmile statusPROPOSED STANDARD pages172 canonicalhttps://www.rfc-editor.org/rfc/rfc7970 doi10.17487/RFC7970 errataview
The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685.

obsoletes

Extracted elements (32)

design-rationale §1.3

IODEF is explicitly designed as a transport format for CSIRT-to-CSIRT machine-to-machine exchange rather than an archival or in-memory format, deliberately balancing automated-processing structure against free-form flexibility for information without a well-defined taxonomy.

security

design-rationale §3.3.1

The restriction attribute was mapped to Traffic Light Protocol (TLP) aliases (white=public, green=partner, amber=need-to-know, red=private) to align IODEF's disclosure labeling with the convention already in widespread operational use among CSIRTs.

security

interoperability-note §4.4

IODEF v2 (RFC 7970) introduces incompatible changes relative to v1 (RFC 5070) documented in Section 4.4. The document version attribute ("2.00") is the primary discriminator; implementations supporting both versions must handle structural differences explicitly.

security

interoperability-note §5.3

Private attribute extensions using ext-value must be deconflicted using the IODEF-Document private-enum-name (FQDN of CSIRT) and private-enum-id attributes. Recipients encountering an unknown ext-value use these fields to identify the defining organization and obtain semantics out of band.

security

normative-requirement §3.10.1 MUST

A DetectionPattern element MUST contain at least one instance of either Description or DetectionConfiguration.

security

normative-requirement §3.9 MUST

At least one aggregate child class MUST be present in every instance of the Contact class.

security

normative-requirement §3.12 MUST

At least one instance of an impact class (SystemImpact, BusinessImpact, TimeImpact, MonetaryImpact, or IntendedImpact) MUST be present in every Assessment element.

security

normative-requirement §2.15 MUST

At least one of SoftwareReference, URL, or Description MUST be present in a SoftwareType instance. The SoftwareReference dtype attribute MUST be set when spec-name is "custom".

security

normative-requirement §2.3 MUST

Special characters in STRING and CHARACTER content MUST be encoded using XML entity references.

security

normative-requirement §3.4 MUST NOT

The combination of the IncidentID name attribute and element content MUST be a globally unique identifier. CSIRTs MUST NOT reuse the same IncidentID value unless referencing the same incident.

security

normative-requirement §3.4 MUST

The IncidentID name attribute MUST use the fully qualified domain name (FQDN) associated with the CSIRT to achieve global uniqueness across organizations.

security

normative-requirement §3.1 MUST

The private-enum-name attribute MUST be the FQDN of the generating CSIRT when used for private extension deconfliction. If private-enum-id is set, private-enum-name MUST also be set.

security

normative-requirement §3.6 MUST

The RelatedActivity class MUST contain at least one instance of: IncidentID, URL, ThreatActor, Campaign, Description, or AdditionalData.

security

normative-requirement §3.1 MUST

The version attribute of the IODEF-Document class MUST be set to "2.00" to indicate conformance with this specification.

security

privacy-consideration §9.2

IODEF documents frequently contain PII such as contact names, email addresses, IP addresses, and hostnames. Senders must evaluate the sensitivity of personal data included in reports and apply appropriate restriction attribute values to limit downstream disclosure.

privacy, security

protocol-element §3.12

The Assessment class characterizes incident impact via five optional subclasses: SystemImpact (technical), BusinessImpact (organizational), TimeImpact (time cost), MonetaryImpact (financial), and IntendedImpact (attacker's intent). The occurrence attribute distinguishes actual from potential impact.

security

protocol-element §3.9

The Contact class is recursive and describes organizations or individuals involved in an incident. Required attributes are role (creator/reporter/admin/tech/irt/abuse/leo/victim/cc/leo/vendor etc.) and type (person/organization); child Contact elements inherit ancestor contact data.

security, privacy

protocol-element §3.10

The Discovery class describes how an incident was detected via 19 enumerated source values (nidps, hips, siem, av, third-party-monitoring, network-flow, passive-dns, audit, internal-notification, external-notification, leo, actor, unknown, etc.) and optional DetectionPattern children.

security

protocol-element §2.16

The ExtensionType (EXTENSION data type) is the generic extension mechanism. Its required dtype attribute selects from 21 types (boolean, byte, bytes, date-time, integer, portlist, real, string, file, path, frame, packet, ipv4-packet, ipv6-packet, url, csv, winreg, xml, etc.).

security, registry

protocol-element §3.2

The Incident class is the primary container for incident information, with required purpose (traceback/mitigation/reporting/watch/other) and GenerationTime fields, and optional timing fields DetectTime, StartTime, EndTime, RecoveryTime, ReportTime. Default restriction value is "private".

security

protocol-element §3.29

The Indicator class (within IndicatorData) represents a shareable threat indicator with an IndicatorID (FQDN+value, globally unique), Observable children, IndicatorExpression for boolean combinations, and AttackPhase for kill-chain attribution.

security

protocol-element §3.29.4

The IndicatorExpression class supports boolean logic (AND, OR, NOT via the operator attribute) over observables and nested indicator references, enabling compositional threat indicator definitions from atomic observables tagged with observable-id.

security

protocol-element §3.1

The IODEF-Document class is the top-level XML container for all IODEF data. Required attributes are version (STRING, must be "2.00") and at least one Incident child; optional attributes include xml:lang, format-id, private-enum-name, and private-enum-id for extension deconfliction.

security

protocol-element §2.4

The MLStringType (ML_STRING) extends xs:string with an xml:lang attribute (RFC 5646 language tag) and a translation-id attribute to relate peer sibling instances as translations of the same text under a common parent.

security

protocol-element §3.3.2

The observable-id attribute (type xs:ID, document-scoped unique) tags any class instance as a named observable so that ObservableReference and IndicatorExpression elements can cite it when constructing indicator definitions without duplication.

security

protocol-element §3.3.1

The restriction attribute conveys disclosure guidelines (public, partner, need-to-know, private, default, and TLP aliases white/green/amber/red). Its value is logically inherited by descendant elements; a child may override a parent's value to tighten or relax disclosure.

security, privacy

protocol-element §3.12.1

The SystemImpact class enumerates 24 technical impact types including account/service/system takeover, data breach categories (breach-proprietary, breach-privacy, breach-credential, breach-configuration), integrity violations, cyber-physical damage/manipulation, traffic redirection, and monitoring.

security

protocol-element §3.7

The ThreatActor and Campaign classes (new in IODEF v2) support attribution by associating incident activity in RelatedActivity with named threat actors or campaigns identified by strings, URLs, and free-form descriptions.

security

registry §10.2

RFC 7970 creates many IANA expert-review registries for IODEF enumerated values, including: Incident-purpose, Incident-status, Restriction, Contact-role, Contact-type, RegistryHandle-registry, PostalAddress-type, Email-type, Telephone-type, Discovery-source, SystemImpact-type, BusinessImpact-type, BusinessImpact-severity, ExtensionType-dtype, SoftwareReference-spec-id, and SoftwareReference-dtype.

security, registry

security-consideration §9.1

The restriction attribute conveys disclosure guidelines but provides no technical enforcement. Recipients are trusted to honor the sender's disclosure intent. IODEF documents containing sensitive data MUST be protected using transport-layer or message-level confidentiality and integrity mechanisms.

security

state-machine §3.2

The Incident status attribute defines a workflow state machine: new (no action taken) → in-progress (under investigation) → forwarded (handed to another party) → resolved (investigation concluded). The additional value "future" represents predicted activity not yet detected.

security

wire-format §4.1

IODEF documents are encoded as XML conforming to the normative XML schema in Section 8. Integers use xs:integer (Base 10), real numbers use xs:float (Base 10), dates use xs:dateTime, binary data uses xs:base64Binary or xs:hexBinary, and port lists use the PortlistType regex "\d+(\-\d+)?(,\d+(\-\d+)?)*".

security