OCSF & controls architecture

From field mappings to the controls layer.

The six schema-to-OCSF crosswalks answer a write-time question: which OCSF field holds a given source's telemetry, so dns.log's query becomes dns_query.hostname and ASIM's TargetUsername becomes user.name. A security buyer rarely stops at "the field is populated." The next question is whether the telemetry you just normalized actually supports a defense, and then whether that defense answers to anything a governance framework requires, and those two questions live one layer above the field table, in the controls-and-defenses world that ATT&CK, D3FEND, NIST 800-53, and the Secure Controls Framework occupy. This piece connects the two layers, and the connective tissue turns out to be the same object the whole crosswalk corpus has been circling without naming: the digital artifact.

Reading time: about 15 minutes. Evidence tiers are labeled throughout: A where I compute from a shipped artifact (the D3FEND v1.4.0 ontology, the SCF 2026.1.1 workbook, the OCSF 1.8.0 schema), B for the first-cut crosswalk walks, and one number left deliberately blank because it does not exist yet and I will not fabricate it.

The through-line

The digital artifact connects all four frameworks.

OCSF normalizes telemetry about things. An OCSF DNS Activity record is a normalized statement about a DNS lookup; a Process Activity record is a statement about a process; a File System Activity record is a statement about a file. Each of those things — the DNS lookup, the process, the file — is a digital artifact, and the artifact is exactly what MITRE's two defensive-side ontologies are built around. D3FEND models every defensive technique by the digital artifacts it observes or touches (a technique analyzes, monitors, or may-contain an artifact), and the artifact taxonomy is also how D3FEND connects to ATT&CK, because an offensive technique produces artifacts the same way a defensive technique observes them. A defense can counter an attack precisely when the two share an artifact (D3FEND v1.4.0, ontology sha256 81ad2f99…47114a23; Tier A, the published structure of the D3FEND ontology). So three layers describe the same object from three angles: an offensive technique produces the artifact, a defensive technique watches the artifact, and OCSF normalizes the telemetry that is the record of that artifact's existence.

The chain reads cleanest written out as one walk, and the OCSF crosswalk corpus is the leftmost hop:

source field ──①──► OCSF event class/field ──②──► digital artifact ──③──► D3FEND defense
   (the six crosswalks)   (e.g. dns_activity)      (e.g. DNS Lookup)     (e.g. DNS Analysis)
                                                          │
                                                          └──④──► ATT&CK offense (produces the same artifact)
                                                                       │
                                                                       └──⑤──► NIST 800-53 / SCF control

Hop ① (source field → OCSF): the six crosswalks. This is the measured, schema-grounded part, and it is where the corpus already lives.
Hop ② (OCSF class → digital artifact): documentation-level and reciprocal. OCSF event classes carry references to the matching D3FEND event entity, and D3FEND entities carry seeAlso back to OCSF: 69 seeAlso link-pairs across 68 D3FEND entities, of which 28 are event-class links resolving to 27 distinct OCSF event classes (Tier A, read from the D3FEND ontology and the OCSF schema). The honest caveat is that these are hyperlinks, not equivalentClass axioms and not per-record telemetry fields, so the join is a design-time map between schemas, never an automatic event-to-defense annotation. Leaf coverage is thin on this hop too: of 607 DigitalArtifact leaf classes only 14 carry an OCSF seeAlso, a 97.7% leaf-orphan rate.
Hop ③ (artifact → D3FEND defense): the D3FEND ontology's own structure, where a defensive technique is defined by the artifacts it observes.
Hop ④ (artifact → ATT&CK offense): the offense-defense inference. An ATT&CK technique that produces an artifact a D3FEND technique observes is, by that shared artifact, counter-able by it.
Hop ⑤ (defense/technique → control framework): D3FEND maps to NIST 800-53, and SCF maps a vast set of frameworks (including 800-53 and ATT&CK) to its own unified controls. This is where the governance argument attaches.

The reason this matters for the field-mapping work, and not as a separate exercise, is that hop ① is what makes the rest legible. A control framework asserts "you must monitor authentication" or "you must detect malicious DNS"; D3FEND names the defensive technique that does it; the technique is defined by the artifact it watches; and OCSF is the schema that says whether your telemetry about that artifact is even present and well-formed. The gaps the crosswalks document are therefore not just query-time inconveniences; they are exactly the places where the controls layer loses traction on the data. When CIM has no severity field and a mapper invents severity_id for ~67% of telemetry, a downstream control that says "alert on high-severity authentication failures" is resting on invented data. When a deny verdict has no disposition_id home on an activity class and falls to unmapped, a control that requires evidence of blocking has nothing typed to point at. The artifact through-line is what lets you say that a gap in the field mapping is also a gap in the controls layer, in the same breath.

D3FEND ↔ ATT&CK

The inferred offense-defense matrix.

D3FEND carries two ATT&CK relationships, and keeping them distinct is the whole tiering story for this hop. The first is a curated mapping the D3FEND team publishes directly: a defensive technique is asserted to mitigate specific ATT&CK techniques, technique-to-technique, by hand (D3FEND Resources, "ATT&CK Mitigations"; Tier A as an official artifact, but curated rather than computed). The second is the inferred relationship that falls out of the digital-artifact ontology: an ATT&CK technique produces an artifact, a D3FEND technique observes that artifact, and the reasoner infers the offense-defense edge from the shared artifact even where no human drew it (Tier A as the published inference, and the mechanism the vendor explainers all describe as the "bridge" between the two matrices).

I reconstructed that inferred matrix and validated it against D3FEND's own inference, which is what lets me cite it with measured numbers rather than vendor prose. Two number sets describe it depending on grain, and both are correct: the base-technique view (30 depth-1 base defensive techniques × 325 ATT&CK techniques that carry artifact relationships) and the leaf view (120 defenses × 435 attacks, 5,616 connections, 27 zero-defense techniques). The matching rule is the measured part worth carrying into any controls argument: naive exact-string artifact matching reproduced only 562 of D3FEND's own 1,904 inferred connections (dropping ~70% of the real coverage), and walking the artifact subclass tree — an attack artifact matches a defense artifact when it equals it or descends from it — reproduces all 1,904 with none missed (Tier A, validated against D3FEND's own join). That validation is the reason the coverage claims are reproduction of MITRE's inference rather than my assertion.

The honest limit is that an artifact-sharing relationship is a possibility of coverage, not a guarantee of one. A defense observing the same artifact an attack produces could detect it; it does not mean your specific deployment tuned a rule to catch it. So the inferred matrix measures the structure of coverage, and the efficacy question — does the control actually catch the attacker — is one the matrix does not answer. I keep the zero-defense and detection-blind findings at evidence Tier B-to-D, explicitly a "may," because they describe where D3FEND has mapped defenses, not what is undefendable in a real estate.

D3FEND ↔ NIST 800-53

Defenses to the federal control catalog.

D3FEND publishes an official mapping to NIST 800-53 Rev. 5, available as CSV, TSV, and JSON-LD (D3FEND Resources; Tier A as an official MITRE artifact). The construction is worth getting right, because it is a different shape from the ATT&CK relationship. Where the ATT&CK link runs through the digital-artifact ontology, the 800-53 mapping is direct semantic analysis: each row links an 800-53 R5 control to a D3FEND technique with a SKOS-style relationship type — broader, narrower, exactly, or related — capturing whether the defensive technique is more specific than the control, more general, an exact match, or merely topically connected. It is not artifact-inferred and it is not routed through ATT&CK; it is the D3FEND team's hand assessment of how each defensive technique sits against the control catalog.

That mapping is computable from the shipped v1.4.0 ontology rather than the rendered mapping page, and it is reproducible: counting only the SKOS edges where one endpoint is a NIST 800-53 R5 or CCI control and the other is a D3FEND defensive-technique class — which excludes the ATT&CK-mitigation (M####) nodes that carry the same predicates but are not control mappings — 79 distinct D3FEND defensive techniques map to 402 distinct controls (111 NIST 800-53 R5 controls and 291 CCI items) across 606 SKOS-typed edges, of which 362 are narrower, 198 broader, 25 exactly, and 21 related. I held off on a figure until it could come from the shipped artifact rather than an eyeballed page, because a made-up "D3FEND maps N techniques to M controls" would be exactly the unmeasured self-grade this corpus bans.

The relationship type matters more than a raw count would anyway. A broader edge (the D3FEND technique covers more than the control asks for) and a narrower edge (the technique is one specific way to satisfy a control that could be met other ways) are very different compliance arguments, and a controls-layer crosswalk that flattened them to "mapped/not-mapped" would lose the part a buyer actually needs: whether implementing a given detection satisfies a control or merely touches it.

The controls-consensus hub

SCF, and the one hop it cannot make directly.

The Secure Controls Framework is a metaframework: a set of unified controls, each cross-walked to a large set of external laws, standards, and regulations through one hub, using NIST IR 8477 Set Theory Relationship Mapping (STRM) rather than subjective "close enough" mapping. The public site states 1,400+ controls across 200+ frameworks and 33 domains; Tier C as marketing copy. The exact 2026.1.1 workbook is more precise and is the number to cite: 1,468 unified controls, 250 mapped frameworks, 33 domains (Tier A, read directly from the workbook tab). The frameworks span the NIST/ISO/PCI/CIS core, regional privacy and security regimes (APAC, EMEA, Americas, US state laws), the OT set (IEC 62443, NERC CIP, NIST 800-82), and the AI set (ISO 42001, NIST AI RMF, EU AI Act). The value SCF provides is consensus: read across the hub and you can see how many independent frameworks agree that a given control matters, which lets a single control inherit a weight ("backed by N frameworks") it would not carry alone.

Cross-standard consensus through the SCF hub: how many major frameworks agree on each control, and how heavily that agreement lands on a target standard you pick. Open the full tool →

Here is the asymmetry that decides how SCF attaches to the defensive layer, and it is a measured finding, not a guess. D3FEND is not one of SCF 2026.1.1's 250 mapped frameworks, confirmed two independent ways: zero hits in the built consensus data and zero occurrences of d3fend/d3f in the raw workbook's shared strings (Tier A, reproducible check against the data). The absence is not an oversight; it follows from what the two artifacts are. SCF maps a control to the threats it addresses, and ATT&CK is a threat (offense) taxonomy, so "control X mitigates techniques T1059, T1071…" is a natural assertion for a controls framework. D3FEND is not a controls framework at all; it is a defensive-technique ontology keyed to digital artifacts, so there is no "control → D3FEND" relation for SCF to populate the same way. The one MITRE framework SCF does carry is ATT&CK (fid 36, "MITRE ATT&CK 16"): 108 of the 1,468 SCF controls map to ATT&CK, referencing 511 distinct ATT&CK technique IDs (Tier A, direct count).

So ATT&CK is the bridge that lets the defensive wall reach the controls-consensus world: a D3FEND technique counters an ATT&CK technique (from the inferred matrix), that ATT&CK technique is mitigated by an SCF control, and that control carries a measurable cross-framework consensus. Of the 120 D3FEND techniques in the matrix, 118 (98%) reach at least one SCF control through the ATT&CK they counter; of the 108 ATT&CK-mapped SCF controls, 104 connect back to at least one D3FEND defense (Tier B, first-cut measured, with the grain caveats below). That lets a detection inherit a governance argument: this defense covers ATT&CK techniques that N consensus controls require you to address.

Two corrections keep this honest. First, SCF's ATT&CK mapping is not SCF-original: it is the Center for Threat-Informed Defense's NIST 800-53→ATT&CK mapping re-routed transitively through SCF's own 800-53 crosswalk, carrying uniform Intersects With / strength-3 typing, so SCF adds no independent ATT&CK signal over CTID, and the coverage characteristics are CTID's surfaced through SCF (Tier A, from inspecting the mapping's provenance). Second, there is a quieter bridge that needs no ATT&CK at all: D3FEND and SCF both map to NIST 800-53, so SCF→800-53→D3FEND links the control-consensus to D3FEND directly, which is why "ATT&CK is the only bridge" was too strong, and why the D3FEND↔800-53 hop two sections up is what this whole connection rests on.

The piece not yet built: a direct SCF↔D3FEND coverage extraction

The natural next artifact — for each D3FEND technique, the full set of SCF controls and downstream frameworks that back it, as a measured count — has not been run, and it cannot be run as a simple lift because the D3FEND column SCF would need does not exist in the workbook. Both paths to building it are scoped: route through ATT&CK (the cheaper two-hop walk, partly done above) or hand-crosswalk D3FEND→frameworks from D3FEND's own ATT&CK/CWE references and its official 800-53 mapping. Until that extraction runs, any statement of the form "D3FEND technique X is backed by N SCF controls across M frameworks" is Tier-D-pending: the structure is real and the bridge is populated, but the distinct per-technique counts are an unrun extraction, not a measured number, and this piece does not assert them.

What the piece can say today, measured: the OCSF crosswalks normalize telemetry about digital artifacts (hop ①, schema-grounded); OCSF event classes and D3FEND entities reference each other reciprocally at the class grain (hop ②, 69 link-pairs, documentation-level); the inferred offense-defense matrix reproduces D3FEND's own join over those artifacts (hops ③–④, validated); D3FEND maps officially to 800-53 R5 with SKOS-typed edges — 79 defensive techniques to 402 controls across 606 typed edges, computed from the v1.4.0 ontology (hop ⑤, Tier A); and the ATT&CK-mediated walk to SCF's controls-consensus holds at 98% reachability on the matrix's techniques (hop ⑤ alternate, Tier B). The one number deliberately left blank is the direct SCF↔D3FEND per-technique count, and it is blank on purpose.

Where the layers meet

The summary table is the argument.

Hop	From → To	Mechanism	Measured today	Tier
①	source field → OCSF class/field	field-level schema crosswalk	yes (six crosswalks)	A
②	OCSF event class ↔ D3FEND entity	`references` / `seeAlso` hyperlinks (doc-level, not axioms)	69 link-pairs / 68 entities; 28 event-class links → 27 OCSF classes; 14/607 leaf-linked	A
③	digital artifact → D3FEND defense	D3FEND ontology: technique observes artifact	structural (D3FEND v1.4.0)	A
④	digital artifact → ATT&CK offense	inferred offense-defense (shared artifact, subclass-walked)	30 base × 325 ATT&CK / 120 × 435 leaf; subclass match reproduces all 1,904 D3FEND connections	A
④'	D3FEND defense ↔ ATT&CK offense	curated technique-to-technique mitigation	official (count not extracted here)	A (curated)
⑤	D3FEND defense → NIST 800-53 R5	direct semantic analysis, SKOS edges	79 techniques → 402 controls (111 × 800-53, 291 × CCI); 606 edges (362 narrower / 198 broader / 25 exactly / 21 related)	A
⑤'	ATT&CK → SCF control → 250 frameworks	SCF crosswalk (STRM); ATT&CK is the shared key (CTID-derived)	108/1,468 SCF controls → 511 ATT&CK IDs; matrix→SCF 118/120 (98%) reach a control	A / B
⑤''	SCF control ↔ D3FEND technique (direct)	none — D3FEND absent from SCF's 250 frameworks	not possible as a lift; not yet extracted	A / D-pending

The shape of the table is the argument. The left two hops are the field-mapping work this corpus already owns, schema-grounded and measured. The middle hops are MITRE's own published structure, where the digital artifact connects the telemetry to the defensive and offensive techniques. The right hops are the controls layer, where the relationship to 800-53 is official and now measured (79 techniques → 402 controls), the ATT&CK-mediated walk to SCF's consensus is measured at first cut, and the one direct link that would be tidiest — SCF straight to D3FEND — is the one that does not exist and that I am refusing to fabricate a number for. The artifact is what holds all of it together: every hop is a different framework's statement about the same underlying object, and the OCSF crosswalk is the layer that decides whether the telemetry about that object is present and typed well enough for any of the rest to mean anything. The tiering this table carries is now walkable as a concept-only graph (1,442 nodes, 7,618 deduped edges) behind a small read-only scg server, where the same honesty rides on each edge as a proxy_quality running from measured down to the intent-blind artifact_cooccurrence inference that is the largest single class (~6,000 edges), so a multi-hop answer is reported as no more trustworthy than its weakest edge, and the hops that lean on that inference are flagged rather than asserted. It is the same provenance discipline made navigable; the graph does not make any answer more correct, because when I measured it, structure changed a retrieval answer on only 1 of 9 reconstruction queries and conceptual grounding read as roughly inert against a plain schema-validity check, so the value here is honest navigation with the weakest link named, not better grounding.

Provenance and tiering

What every number traces to.

D3FEND ontology v1.4.0 (released 2026-03-31), public, from d3fend.mitre.org. Official mappings: ATT&CK Mitigations (curated) and NIST 800-53 Rev. 5 (SKOS-typed, direct semantic analysis). Tier A as official artifacts.
D3FEND ↔ ATT&CK inferred matrix — a reconstruction validated against D3FEND's own 1,904 inferred connections via subclass-walked artifact matching. Tier A for the reproduction; Tier B-to-D for the gap-interpretation findings, kept as a "may."
OCSF ↔ D3FEND reciprocal class links — read from the D3FEND ontology and the OCSF 1.8.0 schema. Tier A. Documentation-level (seeAlso / references), not axioms, not per-record fields.
SCF — Secure Controls Framework 2026.1.1, securecontrolsframework.com, CC-BY-ND. The counts (1,468 controls / 250 frameworks / 33 domains; 108 controls → 511 ATT&CK IDs) are Tier A read directly from the workbook; the public-site "1,400+/200+" figures are Tier C marketing copy.
D3FEND-not-in-SCF — Tier A, reproducible (zero hits in the consensus data; zero d3fend/d3f in the workbook's shared strings).
SCF↔D3FEND direct per-technique counts — Tier-D-pending: extraction not run. The relationship is describable and the bridge (via ATT&CK, or via 800-53) is populated; the distinct counts are not asserted.