Summary

  • IODEF disclosure restrictions follow a hierarchy. A child can explicitly narrow or widen the sender’s guidance; a single report-level badge does not describe every nested item.
  • An extract needs its relevant sharing context. Preserving the incident facts while losing an inherited restriction can change how the recipient interprets the material.
  • The old IODEF value amber and FIRST’s current TLP:AMBER do not describe identical recipient populations. A vocabulary conversion needs an accountable decision, not merely matching colours.

Consider a hypothetical incident dossier marked for a closed circle of partners. It contains a contact record that has no separate sharing instruction, and another contact record explicitly restricted from further sharing. An analyst extracts the first contact into a collaboration workspace. The name and address arrive intact. The enclosing instruction does not.

Nothing in this example requires a forged incident, broken encryption or an altered address. The loss is relational: the contact’s place in the dossier helped determine its disclosure conditions. Copying its visible fields was not the same as copying everything needed to interpret them. This is a possible failure mode derived from the format, not a report of a tested product defect.

IODEF, the Incident Object Description Exchange Format, makes that dependency unusually explicit. RFC 7970, published in November 2016 and currently recorded as a Proposed Standard, describes the second version of an XML representation for incident reports and security indicators. Its purpose is to make operational cooperation more intelligible. It does not make all the conditions for cooperation self-contained inside each reported fact. RFC 7970, publication record.

The hierarchy is doing work

Section 3.3.1 gives the restriction attribute two important properties. Its disclosure guidance applies to the class carrying it and to its children. A child can override that guidance in either direction: tighter restrictions are possible, but so is a relaxation. Where the attribute is absent, the closest specified ancestor supplies the inherited value. The general rule gives the Incident class a default of private.

The distinction between inheritance and a local exception is not merely a parser detail. Imagine a private incident dossier containing a Contact class explicitly marked public: the format permits the sender to identify that contact information as distributable without offering the same treatment to the whole dossier. Conversely, an incident intended for partners can contain a private contact. These examples describe encoded sender guidance. They do not certify that the sender possesses every right required to release the information. RFC 7970, section 3.3.1.

A report-level display can consequently fail in opposite ways. Showing only the parent label can conceal a more restricted child. Applying the tightest label found anywhere to everything can conceal an intended, useful exception. The second choice may be a deliberate conservative local policy. It is not a faithful description of every class’s own disclosure guidance, and should not be passed off as one.

For a security team, the cost of excessive restriction is not imaginary simply because it is harder to count than a leak. A shareable contact can help another operator reach the right responder without circulating the sensitive report around it. If the system cannot preserve that distinction, staff must either withhold useful information or ask a human to reconstruct the permission context. The standard establishes the distinction; it provides no measurement of the delays or losses a particular organisation incurs when it discards it.

There is another trap in an apparently reassuring word. An explicit value of default does not mean “no value was supplied”. It points to an information-disclosure policy arranged between the communicating parties. Omission and that named value can therefore lead to different interpretive work. One asks which ancestor supplies the instruction. The other asks which agreement supplies its meaning. Treating both as a generic application default silently merges two different dependencies. IANA Restriction registry.

A familiar colour can widen the audience

The registry is also a warning against treating recognisable terminology as timeless. IODEF’s registered colour aliases retain their older definitions: white corresponds to public, green to partner, amber to need-to-know, and red to private. In that vocabulary, need-to-know describes sharing within the organisation with those who need the information. These entries remain visible in the registry checked for this article. IANA.

FIRST’s current TLP version 2.0, authoritative since August 2022, has a different relevant boundary. TLP:AMBER allows protective, need-to-know sharing within the recipient organisation and with its clients. TLP:AMBER+STRICT confines it to the organisation. Sources may impose additional restrictions; wider sharing requires explicit source permission. The labels themselves remain unchanged when surrounding content is written in another language. FIRST TLP 2.0.

It follows that replacing IODEF’s amber with an unqualified contemporary TLP:AMBER is not reliably a cosmetic conversion. It could introduce clients into the receiving population. That conclusion compares the published definitions; it is not evidence that a particular exchange has made the mistake. Nor does the comparison establish a universally approved replacement rule. A receiving profile must also account for additional instructions and the meaning of the parties’ organisational boundary.

The temptation is to call this a documentation problem. It is more accurately an ownership problem at the point of transformation. Someone chooses what the outgoing label means. If that choice is hidden in a mapping table which no operational owner reviews, the organisation has delegated a disclosure decision without necessarily recognising it as one.

Correctly formed is not fully understood

RFC 7970 itself resists equating machine readability with semantic completion. Section 4.3 requires well-formed XML, recommends schema conformance and says that additional constraints in the information model must also be considered. Passing the schema alone is not enough. This matters when the same intake process both accepts a document and interprets its operational significance. Acceptance should not be confused with proof that every sharing condition has been understood.

The official correction to the Confidence schema supplies a useful, limited illustration. Verified erratum 5543, approved in November 2018, allows the numerical content discussed in the specification. It repairs a representation inconsistency. It does not give confidence numbers a common meaning; numerical interpretation remains outside the RFC’s definition. A system can become more faithful to the corrected schema while still needing agreement about what the number means. RFC 7970, erratum 5543.

The same discipline applies to ambiguous defaults. This article’s inheritance examples use Contact and explicit restrictions, rather than assuming that every class-specific default description is unproblematic. The general rule, some class descriptions and the schema require careful reconciliation. Neither the confidence erratum nor a successful XML parse licenses an operator to invent a universal answer. An exchange can document explicit values and an agreed profile without claiming to settle the standard’s every textual edge case.

Delivery protection ends before the work does

IODEF requires confidentiality, integrity and authenticity from its underlying exchange. It also says that its disclosure guidance contains no technical guarantee that the recipient will comply. The privacy discussion extends beyond transmission to stored documents and derived analysis. Information about third parties and identifiers that become more revealing through correlation remain relevant after the original delivery has succeeded. RFC 7970, section 9.

The older RID specification, RFC 6545, makes a complementary distinction. Its privacy and sharing-profile discussion considers agreements about data, onward distribution and protection. A response can report mitigation without revealing the attack source’s identity. Cooperation need not always mean exposing the fullest available record. Its treatment of protection at successive hops also shows why an encrypted connection does not, by itself, settle who can see information across an entire exchange. These are protocol-design observations, not contemporary legal permission to share. RFC 6545, sections 9.5–9.6.

An extract therefore deserves review as an output, not merely as a successful copy. Does it preserve the effective restriction and the instruction from which that restriction came? Does a prearranged policy still apply to these recipients? Has a colour label crossed vocabulary versions? Can the receiving system retain a local exception without treating it as permission for its neighbours? Those are proposed operating questions, not additional requirements written into RFC 7970.

Lu Heng’s distinction between symbolic descriptions and executable power is helpful here if used with care. A disclosure label describes an intended boundary. The software that constructs an extract, the person who approves its recipient list and the receiving organisation’s handling arrangements are among the places where that boundary is actually made or lost. The lesson is not that labels are useless. It is that a useful label needs the context and decisions that allow it to mean what its sender intended. Lu Heng’s essay on reality layers.

The narrow conclusion is more demanding than “keep the report confidential”. Preserve enough context to release the right fragment to the right audience, and identify who is responsible when the context changes. Otherwise, a cleaner report can be a less intelligible agreement.