Ontology & grounding
How much ontology does security data actually need?
Security keeps being told its telemetry needs a formal ontology underneath it, something rigorous and machine-reasoned that says what every observation means. My answer, measured rather than asserted, is that the formal grounding security actually ships today is thin, and the architecture that would make a richer one pay off is adjacent and virtual rather than embedded and materialized. You use the formal model at design time, where reasoning over a few hundred concepts is cheap, and the pragmatic columnar schema at runtime, where the scans actually happen. That is the data-centric diagnosis kept and the triplestore prescription dropped, and it happens to be the line two very different data-modeling thinkers are circling from opposite sides.
Reading time: about 12 minutes. Evidence tier: B for the first-party robustness measurements of D3FEND's grounding (single analysis over the shipped OWL artifacts), B/C for the practitioner positions I cite from Dave McComb and Joe Reis, A for the federal ontology baselines and the ISO standard they rest on, and explicitly D for the design-time-formal / runtime-pragmatic synthesis, which is a hypothesis I am still testing in conversation with the people who build these standards, not a finding.
Two camps, and security has a foot in each
The formal pull and the columnar wall.
The E-ISAC data-quality working group is where I first heard about Dave McComb's The Data-Centric Revolution, and I was hungry enough for it that on New Year's Day of 2022 I rented an Airbnb just to read the thing straight through, then bought a stack of copies and handed one to every executive who would take it. McComb makes the most persuasive case I know that an organization's durable asset is a single, simple, extensible model, and that the reason enterprise data is such a mess is that we let each application invent its own. The diagnosis landed hard, because it is exactly the pathology I had watched in security: each tool with its own schema, each detection bound to one vendor's field names, the same entity meaning three different things across the firewall, the EDR, and the cloud log.
Then I hit the part of the prescription that does not survive contact with security volume, which is the triplestore. You cannot run an OWL reasoner over tens of billions of events a day, and you cannot compete with a columnar lakehouse by loading events into RDF. In fairness to McComb, he draws much the same line himself: on Joe Reis's show he said you should not try to put all of your big data in the graph because that is kind of pointless, and that the graph is for the medium-volume master data that stitches the business together. So the disagreement is narrower than rejecting the prescription. It is about where that line falls, and for security telemetry it falls with essentially the whole event volume on the columnar side and only the concepts above it in anything graph-shaped. The position is to keep the diagnosis, take McComb's own caveat seriously, and ask where the formal model earns its keep if not at runtime over the raw events.
A year later I was the only security person in a room full of data engineers at a dbt book signing in Atlanta, and the host, Joe Reis, asked everyone what they thought data modeling actually was. I brought up McComb's line that the goal is a single, extensible model, the one that had me renting Airbnbs over it, so I had a close-up sense of how near these two camps already sat. A few weeks later Reis closed the distance himself, hosting McComb twice that November and walking straight through the data-centric revolution, Software Wasteland, and the single-model thesis with him on air.¹ He platformed it warmly, said the work had genuinely changed his view, and still never ratified the maximalist version of the prescription, which is the posture the idea earns.
Reis is the pragmatic witness, and what is useful is where he stops. His serialized data-modeling work argues that semantics is the heart of modeling and, with AI now both consuming and generating data, no longer a second-class citizen, yet he treats an ontology as a means, a way to capture informal meaning in a formal model when integration failures and scattered definitions are the concrete pain, not a foundation you owe the data on principle, and in his own writing he reaches for the pragmatic wing of the field rather than McComb's formal prescription. His line on AI is the one that transfers cleanest: the machine is good at extraction and translation and drafting and not good at understanding a domain, so AI maps and accelerates while the modeling judgment, deciding what the data actually means in this business, stays human.
Security has a standard that already sits squarely between them, and it is D3FEND. It is MITRE's defensive-countermeasure knowledge graph, built as a real OWL ontology with a digital-artifact model, the formal counterpart to ATT&CK. It is the spot where the McComb-versus-Reis tension stops being abstract, because D3FEND is the formal-ontology commitment security has actually shipped, and OCSF on a columnar lakehouse is the pragmatic schema sitting next to it. So the real question, narrower and answerable than whether ontologies are good, is whether grounding security telemetry in D3FEND, and through it in the formal upper ontologies the standard reaches for, buys a measurable reduction in the kind of pain Reis says ontology has to earn its keep against, over a pragmatic schema that just normalizes the fields.
How well the grounding actually holds
Reciprocal at the top, orphaned at the leaves.
Rather than argue about whether D3FEND's grounding is rich enough, I measured it over the shipped artifacts, merging the D3FEND ontology with its published alignment to the Common Core Ontologies and computing the closure rather than trusting the prose. Three things come out, and they are more sobering than the standard's framing suggests.²
First, the crosswalk between OCSF and D3FEND is real and, better than an earlier read of mine, reciprocal: sixty-nine link-pairs across sixty-eight D3FEND entities, with the event-class links resolving to twenty-seven distinct OCSF classes, and the OCSF side now pointing back at the same entities. So at the event-class grain the two standards genuinely reference each other. The limit is what those links are. They are seeAlso and references documentation hyperlinks, not equivalentClass axioms a reasoner can traverse, and not fields carried on any actual telemetry record. It is a curated, reciprocal, class-level map, which is strong for design-time reasoning and useless as an automatic join from an event to the countermeasure that addresses it.
Second, the coverage is roof-shaped. Of the six hundred and seven digital-artifact leaf classes, fourteen carry an OCSF mapping, a 97.7% leaf-orphan rate. The crosswalk annotates roughly sixty-eight mostly interior anchor classes, and the roughly six hundred specific artifacts underneath inherit nothing directly. If the value of a formal grounding is supposed to be that a reasoner can connect a specific observation to a specific defense, the leaves are where that has to happen, and the leaves are bare.
Third, the link from D3FEND up to the formal upper ontology is thin and, in one place, wrong. The grounding to the Common Core Ontologies is fifteen top-class alignments, and on the digital-artifact subtree the merged ontology produces a materially false entailment: through the bridge axioms, a digital artifact subsumes to a material artifact, so the reasoner will cheerfully conclude that a log entry is a physical object. That is not a knock on the people building D3FEND, who are doing careful work on a hard problem, but the measured state of the grounding today, and it is the number that should set expectations. D3FEND occupies exactly the right place in the architecture. What it does not yet have is the deep, leaf-level, reasoner-usable grounding the formal case depends on.
That thinness has stakes beyond security, and they are easy to overstate, so let me be precise. In January 2024 the Department of Defense Chief Digital and AI Officer and the Intelligence Community Chief Data Officer jointly directed the use of the Basic Formal Ontology and the Common Core Ontologies as the baseline standards for formal ontology across the department and the community.³ BFO is an ISO standard, CCO is a designated baseline still working through its own standardization, the directive is about data interoperability rather than cybersecurity, and it preserves each agency's freedom to build its own. D3FEND is a separate lineage, NSA-funded and MITRE-built, and not itself grounded in BFO or CCO. So security sits between two federal ontology efforts that do not actually meet, the designated formal baseline on one side and the cyber knowledge graph on the other, and the measured bridge from D3FEND up to that baseline is the roof-only, partly-false link above. The grounding is thinnest at exactly the join a federal program standardizing on formal ontology would want strong.
Where the graph goes
The graph belongs beside the data.
Suppose the grounding did get deep enough to be worth running. The next decision is architectural, and it is the one most discussions skip: does the knowledge graph sit beside the data stack and reason over it, or does it become the data stack by materializing your events as triples. The options sort cleanly once you stop treating graph as an infrastructure choice and start treating it as the shape of the model.
| Option | What it is | The honest bound |
|---|---|---|
| Virtual / OBDA adjacent | An ontology over the columnar store (Ontop) that rewrites a concept query to SQL and lets the database run it. Triples are never materialized. | Restricted to the OWL2QL profile so the rewrite stays first-order, which means no recursion. It outperforms materialized triplestores on the conjunctive queries it can handle in the OBDA literature, and there is a working virtual-graph-over-Iceberg demonstration, but no published latency benchmark at security scale. |
| Materialized triplestore embedded | McComb's prescription: load the data as RDF and reason in SPARQL/OWL. | Full reasoning, and it does not survive event volume. This is the part of the data-centric program security has to leave behind. |
| Materialized index embedded | Palantir Foundry's Ontology, which ETL-indexes datasets into purpose-built object databases that queries hit instead of the source. | The existence proof that an operationalized ontology works at scale, achieved precisely by paying the materialization cost. It is evidence for the embedded path, so a virtual design has to argue why it can hit operational latency without the index Palantir found necessary. |
| GraphRAG embedded, for the tail | Materialize a concept graph from entities and let an LLM compose the query from graph context. | Flexible and unbounded, and unverified by construction. It is the right tool for the long-tail entity graph, not for the bulk event volume, and its answers carry no formal guarantee. |
The wrinkle that decides it for security is recursion. The queries that matter most for detection are process-ancestry and lateral-movement path traversal and identity-graph closure, and those are exactly the recursive shapes that fall outside what the virtual rewrite can push to SQL. So the virtual path is excellent for the subsumption-and-conjunctive core, the part where you ask which event class is a kind of which other and whether it carries a field, and it degrades to a heavier semantic layer the moment the question needs to walk a path, which is not a defect to hide so much as the line along which the architecture actually splits.
The answer that survives the volume
Formal at design time, pragmatic at runtime.
Put the measurement and the architecture together and the synthesis falls out, which I hold as a hypothesis to disconfirm rather than a conclusion to defend. The formal model does two jobs with opposite performance profiles, and conflating them is what makes people think they have to choose. At design time it is the validation oracle: a proposed source-to-OCSF mapping gets graded against the concept graph, its types and domains and subclass constraints, and because you are reasoning over a few hundred schema classes and never over the events, rich reasoning is cheap and batch and the triplestore-scale objection simply does not apply. At runtime it is a translator that sits in the planning path, not the scan path, rewriting concept queries to SQL against the columnar tables, virtual for the subsumption-and-conjunctive core and falling back to engine-side recursive SQL or the materialized entity graph above for the path-walking tail.
Read that way, McComb and Reis are describing the same boundary from two directions. McComb's durable single model is the design-time oracle, kept extensible rather than comprehensive, which is the one piece of his program that transfers cleanly. Reis's line that AI maps while humans model is the same split stated in the language of the modeling craft: the machine and the formal rewrite handle translation, and the judgment about what the data means stays in the model a human designed. The formal grounding earns its keep at the layer where reasoning is cheap and the answer has to be right, and it gets out of the way at the layer where the bytes are scanned.
Which returns the verdict to D3FEND. The standard is in exactly the right place, and the value is at mapping time today far more than at query time, because a class-level reciprocal crosswalk is a usable design-time reference and a roof-only grounding is not yet a runtime reasoner. So the near-term payoff is a richer, deeper, leaf-level answer-key that a mapping pipeline grades against rather than a graph you query over your telemetry, and the open question, the one I am taking to the people who build these standards, is whether closing that leaf-level gap measurably improves the hard tail of mapping and defensive inference, or whether the layers are better left decoupled and the pragmatic schema is enough. That is a question you settle by measuring it.
tl;dr
Security data does not need its events run through a triplestore, and it probably does benefit from a formal model, but at design time as a validation oracle rather than at runtime as a reasoner over the raw telemetry. D3FEND is the right place for that model to live, its crosswalk to OCSF is reciprocal at the class level, and its grounding is measurably roof-only today, so the near-term value is a deeper answer-key for mapping rather than a graph you query. Keep McComb's diagnosis of a single extensible model, keep Reis's line that AI maps while humans model, drop the prescription that the model has to be a materialized graph, and measure whether closing the leaf-level grounding gap actually pays.
¹ Joe Reis hosted Dave McComb on The Joe Reis Show ("The Unreasonable Power of Semantics and Knowledge Graphs," November 8, 2023) and on the Monday Morning Data Chat (November 20, 2023), engaging the data-centric revolution, Software Wasteland, and the single-extensible-model thesis directly; McComb's "don't put all your big data in the graph" caveat is from those episodes. Reis's own positions are from his serialized Practical Data Modeling Substack, 2024 to 2026, where he engages the pragmatic and library-science wing of the field, citing figures such as Juan Sequeda and Jessica Talisman rather than McComb's formal prescription. All quoted phrases are extracted from the episode auto-transcripts and the live posts and should be re-verified against the audio and source before any are presented as verbatim. Named practitioner, podcast and self-published (Tier B by authority, C by medium).
² First-party robustness analysis of the OCSF to D3FEND to CCO/BFO chain, computed from the shipped OWL artifacts (D3FEND with its published Common Core Ontologies alignment) rather than asserted from the documentation; the false-entailment result is a sound transitive closure over subsumption, which captures it exactly. Tier B, single analysis, versioned to the artifacts as of mid-2026; re-run against the current D3FEND release before leaning on the exact counts. Dave McComb's data-centric position is from The Data-Centric Revolution (Technics, 2019) and his writing at Semantic Arts; I keep his diagnosis and part company with the RDF/OWL runtime prescription on security-data-volume grounds.
³ Memorandum, "Baseline Standards for Formal Ontology within the Department of Defense and the Intelligence Community," signed by the DoD Chief Digital and AI Officer (Craig Martell, January 4, 2024) and the IC Chief Data Officer (Lori Wade, January 25, 2024), directing the use of a top-level ontology, the Basic Formal Ontology, and the Common Core Ontologies as baseline standards for formal ontology, scoped to data interoperability and integration and explicitly preserving each agency's freedom to build its own. BFO is ISO/IEC 21838-2:2021; CCO is a designated baseline still in IEEE balloting, not itself a ratified standard. Tier A on the primary memo. D3FEND's NSA funding and MITRE origin (Peter Kaloroumakis, lead) are confirmed against MITRE and NSA primary pages; D3FEND is a separate lineage and not BFO/CCO-based.