Summary
- RFC 3067 asked for a common incident object that kept observable events, supporting evidence, incident classification, actual damage, possible impact and confidence as separate fields rather than one verdict.
- The object was meant to evolve from alert through investigation, closure and archive, with per-element restrictions, evidence custody and actions by prior CSIRTs preserved for the next operator.
Before the schema, a theory of the handoff
Published in February 2001, RFC 3067 did not specify an Internet standard. It recorded TERENA's high-level requirements for the Incident Object Description and Exchange Format, or IODEF. The motivation was operational: computer attacks crossed borders, languages, cultures and constituencies, while response teams needed to exchange alerts, investigations, statistics and post-incident knowledge.
The proposed common object was not just a machine envelope. It was intended to be created and authorized by humans, readable with ordinary tools and processable by incident-handling systems. An intrusion-detection message might begin the story, but the incident description sat at a higher level. It had to carry what several teams learned, decided and did over time.
That is why the requirements began with vocabulary. An event was an observable occurrence or action directed at changing a target. Evidence was information that proved or supported a conclusion about an event. An incident involved a security violation. Damage described an actual consequence for the system or service. Impact described consequences for a user community. Confidence expressed how strongly the report information should be trusted.
These were not synonyms placed in different database columns. They were different reality layers.
An alert did not own the conclusion
Three failed logins in ten seconds might generate an alert. That observation did not by itself prove an attacker, a successful compromise, damage or community impact. A statistical detector might assign probability; a CSIRT might escalate the event under its policy; another team might correlate it with a distributed campaign. The common object needed to carry each step without rewriting the earliest signal as a final verdict.
RFC 3067 therefore required a degree of confidence, especially where automated systems estimated probabilities. It allowed possible impact to come from a standardized list when an attack was recognized or from a responsible team member's experience when no reference existed. Unknown attack types could use a temporary implementation-specific name until a common term was available.
That mix of structure and free language admitted uncertainty rather than hiding it. A controlled term supported aggregation; a narrative preserved what had not yet stabilized. A temporary value was evidence of an unresolved taxonomy boundary, not permission to pretend the event was already understood.
The incident description was also expected to grow. Early in handling, details might be sparse. Investigation and remediation would add the attack description, evidence, actors, targets, effects and actions. The record had to preserve what previous CSIRTs had done so the next team could determine what remained.
The object was therefore a changing dossier, not a frozen alarm.
Every compartment could have a different audience
Incident sharing promised coordination but also threatened disclosure. The requirements anticipated passwords, personal or organisational identifiers and forensic material inside the same object. They called for an access-restriction attribute on every element, not merely one classification banner over the whole report.
That granularity mattered. A receiving team might be allowed to see the attack type and affected network but not a victim's identity or a sealed evidence file. Statistics might retain aggregated impact while removing operational detail. Evidence could be referenced externally because its custody and permissions differed from the rest of the report.
Encryption was useful but insufficient as a universal answer. A message could be decrypted by an authorised system and then mishandled by an unauthorised person or downstream workflow. The restriction mark travelled as policy context for later processing.
The document also kept communications security under local policy and expected exchange normally to be approved by an operator or CSIRT manager. Machine readability assisted the human handoff; it did not automatically authorize it.
Evidence needed a history of custody
RFC 3067 treated evidence as more than an attachment. It named system dumps, logs, kernel statistics, cache, memory and temporary files as possible sources, required care for integrity, recommended encryption where needed, demanded a documented chain of custody and deferred to local law.
That meant a receiving CSIRT needed more than bytes. It needed to know who collected them, when, under what conditions, how they were preserved and whether the transfer altered them. RFC 3227 later elaborated operational principles such as order of volatility, minimizing change and documenting the process. Neither document could guarantee that a court, employer or foreign authority would accept the result. The format could carry custody facts; legal authority remained local.
Time carried a similar boundary. RFC 3067 required stages throughout the incident lifetime and asked for local time with a UTC offset so managers could normalize and correlate reports. A normalized timestamp could help connect distributed activity. It could not repair a wrong clock, an unknown collection delay or a mistaken causal inference.
The successors kept the constitutional limit
RFC 5070 eventually standardized an XML IODEF data model in 2007. It explicitly described the model as a transport format rather than an optimal storage or archival representation, and it declined to impose a universal definition of “incident.” RFC 7970 replaced that version in 2016 with a broader second-generation model.
Those successors supplied concrete schema where RFC 3067 supplied requirements. They did not abolish the original distribution of authority. The schema could define fields and relationships. The report creator controlled what it asserted. The sharing organisation controlled disclosure. The receiving team controlled interpretation and action under its constituency, policy and law. Evidence custody constrained later claims. Affected people and services bore the consequences.
Lu Heng's reality-layer lens makes the historical value clear. A shared object can make claims legible across institutions without collapsing registration, observation, inference, decision and outcome. Running code can validate a document, route it and render it. It cannot prove that the incident classification is correct or that the response succeeded.
RFC 3067 did not try to manufacture one verdict. It asked for a record strong enough that different teams could disagree without losing the evidence, permissions, confidence and action history on which responsible disagreement depends.
Sources
- https://www.rfc-editor.org/rfc/rfc3067.html
- https://www.rfc-editor.org/info/rfc3067/
- https://datatracker.ietf.org/doc/rfc3067/
- https://www.rfc-editor.org/rfc/rfc2350.html
- https://www.rfc-editor.org/rfc/rfc3227.html
- https://www.rfc-editor.org/rfc/rfc5070.html
- https://www.rfc-editor.org/rfc/rfc7970.html
- https://www.iana.org/assignments/xml-registry
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
