Share the record, not a rewrite. Each audience gets exactly its layers.
Today the same issue is retyped for the SOC, the CISO, the group CERT and the vendor, and every copy drifts. A CIR record is written once. Sharing it means filtering it, and the filter is the TLP each layer already carries.
The export rule
- CLEAR
- GREEN
- AMBER
- AMBER+STRICT
- RED
- One TLP per layer
- Every layer present in a record carries its own
tlp. Typicallycoreandthreat_intelare CLEAR,postureAMBER,contextRED. - Exporting
- To send a record to an audience, drop every layer more restrictive than what that audience may receive. Nothing is redacted by hand.
- A ceiling
meta.tlp, when set, applies to the whole record: no layer of its own may be less restrictive than it.- Public exports
internalidentifiers (ticket, pentest report ID) are forbidden in public records and dropped by any export to a public audience.
One record, three exports
CIR-2021-GRP-0003 is a subsidiary's record on Log4Shell. It extends the public
CIR-2021-00-0001 and adds its own posture and context.
- coreinherited
- threat_intelinherited
- posturedropped
- contextdropped
What remains is the public parent. Nothing says this subsidiary was ever involved.
- coreinherited
- threat_intelinherited
- posturekept
- contextdropped
The CERT learns how the entity stands: mitigated, egress filtering blocks, detection partial. Not which asset, nor the incident.
- coreinherited
- threat_intelinherited
- posturekept
- contextkept
The full record: the customer portal, ticket SEC-3321, the CISO's decision, who was told and when.
What the CERT actually receives
metaidentifies the record and its parent, so the CERT can group every entity's posture on the same issue.entityis a pseudonymous ID the CERT assigned. Never the entity's name.- Every value is an enum, a boolean or a date. There is nowhere to write a hostname.
# CIR-2021-GRP-0003, exported for TLP:AMBER. context (RED) was dropped.
cir_version: "0.1"
meta:
id: CIR-2021-GRP-0003
based_on: CIR-2021-00-0001
tlp: AMBER
posture:
tlp: AMBER
updated: 2021-12-14
entity: GRP-ENT-07
status: { state: mitigated }
exposure: { reachability: internet, prevalence: common }
controls:
- { control: waf, effect: reduces, coverage: partial, validated: true }
- { control: egress_filtering, effect: blocks, coverage: full, validated: true }
- { control: edr, effect: detects, coverage: partial, validated: false }
detection: { capability: partial, layers: [waf, network, endpoint], validated: true }
impact: { enables: [code_execution, lateral_movement], blast_radius: segment }
remediation: { feasibility: hard, constraints: [vendor_dependency, legacy] }What a CERT can do with it
Collect the posture of every entity on the same CIR and the picture appears, without a single asset name. For instance, Log4Shell across twelve subsidiaries illustrative figures:
mitigated, 3 fixed, 2 still affected.
block egress, fully and validated: contained.
have tested their detection.
assets, tickets or names learned.
The two entities still affected and internet-facing are where the CERT calls first.
Their own score tells them the same thing: a KEV-listed issue with an open exposure is never below high.
Out to VEX
posture.status is aligned with VEX, so an entity's posture can be published as a VEX statement
for its customers or its regulator.
CIR posture.status.state | VEX status |
|---|---|
not_affected | not_affected, with the required justification |
affected | affected |
mitigated | affected, with the controls as action statement |
fixed | fixed |
under_investigation | under_investigation |