Security Data Works

Original analysis · Crosswalk map · Tier B

The whole chain, and where it gets cheap

The controls-layer essay walks the chain from an OCSF telemetry class out to a governance control, hop by hop. This is that chain as one figure, built from the same measured graph and colored by the part most crosswalks leave out, which is how cheap each joint's proxy actually is. The links you can compute from a shipped artifact look one way; the link inferred from a shared digital artifact, which says a defense could see an attack rather than that it does, looks another, and the figure is built so you can tell the two apart at a glance.

OCSF class → D3FEND base technique → ATT&CK tactic → SCF control domain. Flow width is the count of underlying edges; flow color is the hop's proxy quality. Hover any flow for what that joint rests on, and a legend swatch for the honesty note. The amber band is the cheapest joint.

Four columns, one object

Every column is a different framework describing the same artifact.

Read left to right. The first column is the OCSF event classes, the schema your telemetry lands in. Each class is a normalized statement about a digital artifact: a DNS lookup, a process, a file. The second column is the D3FEND base techniques, each defined by the artifact it observes, and an OCSF class reaches a defense because D3FEND models the event and the defense around the same artifact. The third column is the ATT&CK tactics those defenses counter, inferred from where an offensive technique produces an artifact a defensive technique watches. The fourth is the SCF control domains, reached because each ATT&CK technique that a control framework addresses ties back to the defense that counters it.

None of this is a new mapping. Every edge traces to a shipped artifact: the D3FEND v1.4.0 ontology, the OCSF 1.8.0 schema, the Center for Threat-Informed Defense's control mappings, the Secure Controls Framework workbook. What the figure adds is the one thing those sources don't carry: a label, per edge, for how much the join can actually bear.

Dated note, 2026-11-09: this map is still built on D3FEND v1.4.0 and OCSF 1.8.0, while the neighbouring D3FEND Wall has been rebuilt on D3FEND v1.6.0 (released 31 August 2026). That rebuild moved the wall by one attack and eleven connections and left its 120 defenses unchanged, so I don't expect the shape here to move much, but I haven't rebuilt this figure on v1.6.0 yet and the version labels above stay accurate until I do.

Proxy quality

A documentation link and a measured field are not the same fact.

Most crosswalk diagrams draw every connection as a plain line, which quietly tells you the whole chain is equally solid. It isn't, and pretending otherwise is how a confident wrong answer gets built on a weak join. So each hop carries its proxy quality as a color. The OCSF↔D3FEND links are documentation hyperlinks, reciprocal but not machine-checkable axioms and not per-record fields, so they're a design-time map and colored as one. The event-to-artifact link is a real ontology restriction. The defense-to-control link is D3FEND's own SKOS-typed analysis against 800-53.

The amber band, defense to offense, is the cheapest joint in the chain, and the figure colors it to stand out rather than hide it. It's inferred from a shared digital artifact: an attack produces an artifact, a defense observes the same one, so the defense could see the attack. That's a possibility of coverage, not a guarantee that any deployment tuned a rule to catch it, because the inference is blind to intent, which is the open D3FEND modeling question (#520). Naming that out loud, in the same picture that draws the link, is the discipline the map is for. The contribution here isn't a tidier graph, since this overlaps MITRE and CTID's own mappings by design; it's the refusal to launder a cheap join into a confident one.

Reading it, and where it stops short

The thin left edge is a finding, not a rendering bug.

Only a handful of OCSF classes reach a defense through the artifact path, and that sparseness is real. Most telemetry classes describe an artifact that none of the defensive techniques is modeled to observe. The defenses here are counted at base grain, so the 120 atomic defenses on the D3FEND Wall roll up to the 28 base techniques in the second column, which is why the counts on the two pages differ. That leaves the schema-to-defense hop as the weakest-connected part of the whole chain, which is the gap the crosswalk work keeps surfacing, shown here rather than smoothed over. The dense middle and right, by contrast, are where the offense-defense inference and the control mappings actually carry weight.

Two honest boundaries. The defenses and tactics are rolled to their base grain so the figure stays legible, which trades the per-technique detail for a readable shape. And the controls column is shown at SCF domain grain as derived counts, not the raw per-control mapping cells, because the SCF workbook is CC-BY-ND; for the weighted control consensus itself, the control-consensus map is the deeper view. This figure is the chain that connects it back to the telemetry.

The figure shows the chain in aggregate, with flow width and color standing in for many edges at once, but the same graph is also navigable edge by edge through a small read-only MCP server, scg, and this page is where I describe it. It is a concept-only graph of 1,442 nodes and 7,618 deduped edges with no telemetry-event nodes, built on D3FEND v1.4.0, the same release as the figure, and it ships the public chain the figure draws (OCSF, D3FEND, ATT&CK, NIST 800-53 and CCI). Every edge keeps a proxy_quality tag for how well it is actually supported, from a measured or SKOS-typed link down through a curated mapping to the intent-blind artifact_cooccurrence inferences that share an artifact without knowing the attacker meant to produce it, and those inferred edges are by far the largest class, roughly 6,000 of the 7,618. A multi-hop answer is reported as no more trustworthy than its weakest edge, so a path that leans on one of those guesses comes back flagged as a lead rather than an established fact. I want to be careful about what that buys, though, because when I measured it, grounding a model in this graph was close to inert against a plain check that the field mapping was schema-valid, and the graph's structure changed a retrieval answer on only one of nine incident-reconstruction queries. So the server is navigation with its provenance attached and not a way to make a model more accurate, the overlap with MITRE and CTID's own mappings is deliberate, and the contribution is the provenance layer and the measured brittleness, with no rival map intended.