OCSF ontological grounding for federal-ready security data.

OCSF was launched in 2022 as a vendor-coalition project: AWS, Splunk, IBM, and a long tail of partners agreeing on a shared event schema so that security data could move between products without a custom transformer at every boundary. The 180-plus organization coalition mattered politically, but a vendor consortium is still a vendor consortium, and for federal and regulated buyers that sits in a different category from an international standard.

OCSF is now on a standards-body track: ITU-T Study Group 17 (the security study group of the International Telecommunication Union, the United Nations body whose Recommendations are used by national regulators worldwide) is standardizing it as Recommendation X.icd-schemas. Member states backed it for ratification in December 2025, with adoption as a published international standard targeted for mid-2026. Ratification would move OCSF from "Linux Foundation project coordinated by a vendor coalition" into the same category as ISO/IEC standards: a governance-neutral, vendor-neutral artifact with a formal change-control process and international recognition. The procurement implications take time to flow through specific RFPs and ATO packages, but the trajectory is the kind that compounds rather than reverses.

The D3FEND ontological grounding I describe below predates the ITU-T work (it shipped with OCSF v1.3.0 in August 2024) but the two reinforce each other, because the ITU-T standardization track speaks to "is this becoming a real standard?" while the D3FEND chain answers "does the schema have formal semantics behind it, or just field names?" Both are necessary for a federal-ready posture, and neither one on its own gets a buyer all the way there.

The grounding argument has four links. I'll walk each one because the chain is only as defensible as its weakest hop.

Link one: OCSF maps to D3FEND

D3FEND stands for Detection, Denial, and Disruption Framework Empowering Network Defense, a MITRE-maintained knowledge graph of defensive cybersecurity techniques. It's the defender-side counterpart to MITRE ATT&CK, which catalogs adversary tactics. Where ATT&CK says "adversaries do this," D3FEND says "defenders may detect, deny, or disrupt that with these techniques." MITRE released D3FEND 1.0 in January 2025, and that release was the first time the framework was formally grounded in upstream ontologies rather than presented as a standalone knowledge graph.

OCSF v1.3.0, released August 2024, added a d3fend attribute to every event class. The attribute contains a D3FEND technique identifier, the digital artifact being analyzed (network traffic, process, file, user credential), and the defensive tactic (Detect, Deny, or Disrupt). For a Network Activity event, that may look like:

{
  "class_uid": 4001,
  "time": "2026-01-10T14:32:00Z",
  "src_endpoint": { "ip": "192.168.1.100", "port": 54321 },
  "dst_endpoint": { "ip": "10.0.0.5", "port": 443 },
  "d3fend": {
    "technique_id": "D3-NTA",
    "artifact": "NetworkTraffic",
    "tactic": "Detect"
  }
}

The practical effect: an OCSF event carries its own mapping to a MITRE-maintained defensive technique. A query like "show me every event that supports Network Traffic Analysis (D3-NTA)" can be expressed as WHERE d3fend.technique_id = 'D3-NTA' across every OCSF source. Without the d3fend attribute, that mapping has to be reconstructed manually for each proprietary schema, a consulting project that defense-contractor sources I've spoken with quote in the $150K-$400K range for full coverage of 500 to 2,000 detection rules. I treat that cost range as Tier B evidence (practitioner interviews, three firms specializing in DoD cybersecurity compliance), not a published number.

Link two: D3FEND grounds in Common Core Ontologies

Common Core Ontologies (CCO) are a set of mid-level ontologies (Agent, Artifact, Event, Information, Organization, Facility) that the Department of Defense and Intelligence Community designated as their baseline ontology framework. Reporting by DefenseOne and the DoD Data Strategy place that designation in January 2024. I treat the designation date as Tier B evidence (journalism plus official strategy document) rather than Tier A. I have not personally read the underlying memorandum, and federal designation language is often more conditional than the press coverage implies.

What CCO provides for D3FEND: a formal home for concepts like CyberEvent, SecuritySensor, and DigitalArtifact. Rather than D3FEND defining "Network Traffic Analysis" in isolation, the D3FEND 1.0 release expresses it as a specialization of a CCO Event category, with formal has-input, produces-output, mitigates, and detects relationships. That allows automated reasoning over D3FEND. A SPARQL query (a standard query language for ontologies) can ask "what defensive techniques mitigate ATT&CK T1071 Application Layer Protocol?" and get a derived answer rather than a manually maintained lookup.

Link three: CCO grounds in Basic Formal Ontology

Basic Formal Ontology (BFO) is a top-level ontology, the most general categorization layer, dealing in things like Continuant (something that persists through time), Occurrent (something that happens over time), Object, Process, Role, and Function. BFO has been peer-reviewed and developed by the International Association for Ontology and its Applications for two decades. CCO is constructed as a BFO-conformant set of mid-level categories, so every CCO concept inherits a formal place in the BFO hierarchy.

The practical effect of that hop is that when CCO says "CyberEvent is a kind of Event," there's a formal definition behind both Event and the is-a relationship, so the claim is derivable from the underlying ontology rather than resting on the CCO working group deciding that CyberEvent feels like an Event.

Link four: BFO is ISO/IEC 21838-2

The final link is the one that gives the chain international standing: BFO was published as ISO/IEC 21838-2:2021, "Information technology, Top-level ontologies (TLO), Part 2: Basic Formal Ontology." That's a Tier A primary source, published by the International Organization for Standardization, governed by international committee, with a formal change-control process.

The composition reads as one continuous chain: an OCSF Network Activity event maps to D3FEND Network Traffic Analysis, which is a CCO CyberEvent, which is a BFO Occurrent, which is an ISO/IEC 21838-2-standardized category, and each hop is independently defined and validated. That chain is what the major proprietary schemas don't currently provide, because Splunk CIM, Microsoft Sentinel UDM, Google Chronicle UDM, and AWS ASFF all stop at the field-definition layer with no upstream ontological anchor.

The four proprietary schemas a federal or regulated buyer is most likely to encounter all stop at the same layer: defined field names, vendor-controlled semantics, no formal ontology, no native D3FEND mapping. None of these are bad schemas in their own context. Splunk CIM is a mature normalization layer for Splunk Enterprise Security, Sentinel UDM (Unified Data Model) is the Microsoft equivalent inside Azure, Chronicle UDM is Google's, and AWS Security Finding Format (ASFF) is what Security Hub uses internally. They work well within their vendor's product ecosystem.

The gap shows up when the buyer is federal, defense-adjacent, or cross-vendor by necessity:

• D3FEND mapping. Proprietary schemas require manual mapping, a consulting project that runs $150K-$400K for full coverage, per the defense-contractor practitioner sources I cited earlier. OCSF v1.3.0 includes the d3fend attribute at the schema level. The mapping ships with the data.
• CCO alignment. Proprietary schemas have no upstream ontology. A defense contractor responding to an RFP that asks for CCO-aligned semantic metadata has to either construct that alignment manually or argue it isn't required. OCSF inherits CCO alignment by transitivity through D3FEND.
• Governance neutrality. Splunk CIM evolves at Splunk's discretion. Sentinel UDM evolves at Microsoft's. Chronicle UDM evolves at Google's. ASFF evolves at AWS's. OCSF evolves under Linux Foundation governance with a 180+ org coalition and an active ITU-T standardization track. That distinction may matter to a buyer who needs schema stability across an ATO cycle that outlasts a vendor relationship.
• International recognition. A US vendor's proprietary schema is a US vendor's proprietary schema in any cross-border context. An ITU-T Recommendation would give OCSF a different kind of standing for NATO-aligned, Five Eyes, and EU-US data-sharing contexts. Whether that translates to specific cross-border programs depends on the program; Tier D for the specific procurement claims.

None of this means an organization currently running Splunk CIM should rip-and-replace, but it does mean that for new architectural decisions, especially in federal or federal-adjacent contexts, the schema-choice calculus has changed in OCSF's favor in a way that wasn't true two years ago.

Defense and intelligence

This is the clearest case, because defense contractors building security data systems for DoD components, IC agencies sharing threat intelligence across agency boundaries, and prime integrators bidding on security analytics RFPs all face procurement language that increasingly references D3FEND mapping and semantic interoperability, and OCSF responses to those requirements are derivable where proprietary responses require an additional consulting deliverable.

The framework-level hedge applies in full force here: a specific contract still requires a specific ATO, a specific control mapping against a specific baseline (NIST 800-53 moderate or high, depending on the program), and a specific demonstration of operational security against that baseline, so OCSF makes the schema-and-mapping pages of that package easier to write without writing the rest of the package for you.

Critical infrastructure and regulated industries

Energy, water, financial services, and healthcare all have sector-specific regulators with their own framework references. CISA has been steadily building OCSF-based mappings for cross-sector threat intelligence sharing. The Zeek-to-OCSF mappings CISA validated at petabyte scale are an example of the federal government voting with its engineering hours. Sector-specific frameworks (NERC CIP, FFIEC, HIPAA) don't typically require OCSF, but they do require defensible mapping between detection capabilities and threat models. The D3FEND-grounded chain may shorten that mapping work.

For financial-services buyers specifically, the FFIEC's references to threat-informed defense and the SEC's 8-K disclosure rules both reward a security program that can articulate detection coverage against an external framework, and D3FEND is the obvious external framework while OCSF carries the mapping at the event level. The argument here isn't that OCSF means SEC compliance, but that OCSF makes the part of an SEC disclosure that describes detection coverage cheaper to evidence.

Academic and research

Cybersecurity research grants (NSF Secure and Trustworthy Cyberspace, DARPA programs, NIH for health-sector cybersecurity) increasingly reference formal semantic frameworks in their solicitations. BFO and CCO peer-reviewed standing make OCSF data citable in ways proprietary schemas aren't. A research group studying detection effectiveness across organizations needs a shared semantic frame to compare results; OCSF plus D3FEND provides one. I'd treat the "increasingly" claim as Tier B: observed in solicitations I've read, not a quantitative trend I've measured.

Commercial sector

For commercial-only organizations with no federal exposure, the ontological grounding argument is weaker. A 500-person SaaS company with no defense customers may run perfectly well on Microsoft Sentinel UDM and never need to think about CCO. The relevant lens for those organizations is optionality. Today's commercial-only company is sometimes tomorrow's federal-RFP respondent, and sometimes tomorrow's EU-data-sharing entity, and sometimes tomorrow's acquired-by-a-prime-contractor entity. OCSF preserves the schema-level option to engage with those futures, whereas proprietary schemas require migration work to engage with them, and since the cost of preserving the option today is roughly zero while the cost of migrating later is high, that asymmetry is what makes the case for OCSF in commercial contexts even where the federal argument doesn't bite directly.

Returning to the ITU-T track I mentioned at the top, the ITU is a UN agency whose Recommendations are referenced by national regulators worldwide, and ratifying OCSF as Recommendation X.icd-schemas would move it into the same category of artifact as the ISO/IEC standards that already underpin BFO: a governance-neutral published standard with formal change control and international standing.

For NATO-aligned threat intelligence sharing, the practical effect may be that allied national-CERT-style organizations can reference a single schema in their cross-border data-sharing agreements. The CCDCOE (the NATO Cooperative Cyber Defence Centre of Excellence) has historically advocated for ontology-grounded approaches, and OCSF now sits inside both the ontology chain (via D3FEND-CCO-BFO) and the ITU-T standards chain, which gives those organizations two reinforcing arguments rather than one.

For Five Eyes collaboration (US, UK, Canada, Australia, New Zealand) the picture is similar. Each of those countries has its own cybersecurity agency (CISA, NCSC, CCCS, ACSC, NCSC-NZ), and each has invested in OCSF mapping at varying levels of public commitment. An ITU-T Recommendation would give those agencies a less politically loaded standards reference than "the schema the US vendor coalition agreed on."

The hedge is two-fold. First, ratification is still pending: member states backed X.icd-schemas in December 2025 and the target is mid-2026, so it is on track but not yet a published Recommendation. Second, ITU-T Recommendations are voluntary, so national regulators choose which to adopt and how to reference them, and the trajectory I'm describing is the kind that takes years to translate into specific cross-border agreements, where the specifics may surprise me. I treat the "ITU-T standardization will lead to broad cross-border OCSF references" claim as Tier D: informed expectation, not documented outcome. The narrower claim, that OCSF is the basis of an active draft ITU-T Recommendation (X.icd-schemas) that proprietary schemas have no equivalent to, is Tier A based on the SG17 documents themselves.

Four moves I'd recommend to a security architect evaluating schema choice today, ordered by how cheap they are to execute:

• Track OCSF v1.3.0+ adoption in the products you already run. AWS Security Lake emits OCSF natively. Snowflake's security data offerings emit OCSF. Splunk and Microsoft both ship OCSF mappings as optional outputs. If you're already in one of these ecosystems, OCSF is often available without changing platforms.
• For new architectural decisions, treat OCSF as the default schema. The compatibility cost is low, the future-optionality value is high, and the federal-ready posture is materially stronger than any proprietary alternative.
• Push vendors for D3FEND attribute support during contract renewals. If a vendor claims OCSF support, ask whether they emit the d3fend attribute. The gap between "OCSF-shaped fields" and "full v1.3.0 including D3FEND mapping" is the gap between marketing claims and federal-ready posture.
• Don't conflate schema choice with ATO work. If you're responding to a federal RFP, OCSF helps the schema and detection-mapping pages of the package. It does not replace the ATO process, the control mapping work, or the operational-security demonstration. Budget for the rest of the work accordingly.

OCSF is not the most exciting standard in the lakehouse stack, and Iceberg's V3 features and Arrow's ADBC story attract more attention, but OCSF may be the standard that does the most distinctive work for federal-exposed buyers, because it's the only layer where the formal-semantics argument and the procurement-language argument both attach. The D3FEND-CCO-BFO chain is the academic credibility layer that makes the schema defensible, while the ITU-T standardization track is the international standards-body layer that makes it governance-neutral, and both have advanced in the last 18 months, so both compound, though neither one on its own amounts to an Authority to Operate.