STIX to STONES

Faithfully Changing Strings to Things

STIX 2.1 is the industry’s shared language for describing threats — intrusion sets, attack patterns, indicators, and the relationships between them, exchanged as JSON. It’s widely adopted, and for good reason: it gives disparate tools and teams a common wire format.

But JSON is a serialization, not a model. Types are strings. Relationships are their own free-floating objects, connected by string-valued reference fields. Open vocabularies — things like an identity’s identity_class — are just… strings, with no formal meaning beyond what a human reader brings to them. None of that is a criticism of STIX; it’s simply what a JSON exchange format is for. But it means that everything a human reader infers when looking at a STIX bundle — that a source_ref and a target_ref point to real, typed things, that "organization" means the same thing everywhere it appears — has to be inferred again, by hand, every time.

Bind STIX 2.1 to a real OWL ontology, faithfully, and a reasoner and a graph database carry that meaning instead of a human inferring it by hand, every time.

That ontology is STONES, and below is a live example of what it produces.

Five real objects, transformed live

We took five connected objects straight out of MITRE’s own ATT&CK STIX 2.1 export — no synthetic data, no cherry-picked toy example — and ran them through our STIX-to-STONES transform:

• The MITRE Corporation (identity)
• FIN7 (intrusion-set)
• Code Signing / T1553.002 (attack-pattern)
• The relationship object connecting FIN7 to Code Signing via "uses"
• A copyright marking-definition

Here’s what came out the other side:

A few things worth noticing:

Everything is dual-typed, and nothing is lost. FIN7 comes out as both stones:IntrusionSet — the faithful STIX type — and stonework:ThreatActorGroup, its ground-truth ontological class. Code Signing is both stones:AttackPattern and stonework:AttackTechnique. The original stixId is preserved on every object, so the graph round-trips back to the STIX world it came from.

The relationship object survives intact. STIX relationships aren’t simple edges — they’re first-class objects with their own IDs, timestamps, and (often) their own citations. Our transform keeps that object exactly as STIX defines it: stones:sourceRef and stones:targetRef still point at the real objects, and its external references — the actual research citations behind the claim that FIN7 uses code signing — are preserved as structured resources, not flattened into a description string.

A direct shortcut sits alongside it, additively. We also assert FIN7 stones:uses Code Signing directly, one hop. Nothing about the reified relationship is removed or replaced to make room for it — a query that wants full STIX provenance can still walk the relationship object, and a query that just wants the fact can take the shortcut. Both are true in the same graph at the same time.

Open vocabulary strings become real individuals. MITRE Corporation’s identity_class is the string "organization" in the source JSON. In STONES, it becomes stonex:_organization — a stable, dereferenceable OWL individual, not a string a downstream tool has to pattern-match. That sounds small until you’ve written the fifth parser that has to special-case "organization" vs "Organization" vs "org".

Here’s the same five objects and their relationships, rendered directly from a plain SPARQL query against the loaded graph. The nodes, edges, and labels below are exactly what that query returned — nothing added, nothing hand-drawn — we only dragged the boxes into a tidier layout:

That’s the whole pipeline: real STIX 2.1 JSON in, a generic SPARQL-based transform, a standards-compliant OWL graph out, queryable with nothing but SPARQL.

Scope, not deficiency

It would be easy to read STIX’s verbosity — the reified relationships, the open vocabularies, the string-typed everything — as a design flaw an ontology “fixes.” That’s not the right way to think about it, and it’s not what STONES does.

STIX 2.1 is doing exactly what a threat intelligence exchange format needs to do: stay flexible, stay extensible, and preserve provenance so that a receiving system can trust and cite what it’s ingesting. STONES’s job isn’t to reform that design — it’s to represent it faithfully, with the same completeness, as an ontology. Every property STIX defines, STONES has a place for. That fidelity is the whole point: a binding you can trust to mean what the standard means, nothing added, nothing quietly dropped.

But fidelity to STIX’s own data model is a different, narrower job than building a unified conceptual model across the frameworks a real threat intelligence practice actually uses — STIX bundles alongside ATT&CK techniques, CWE weaknesses, CAPEC attack patterns, NIST SP 800-53 controls, CIS controls, and CVEs, all of which use their own identifiers, their own structures, their own vocabularies. Being faithful to one standard doesn’t, by itself, tell you how that standard’s objects relate to another standard’s objects. That’s a genuinely separate problem, and it needs its own ontology to solve it.

That ontology is STONEWORK — the ground-truth ontology in the CyberTerrain ecosystem. STONES is one of several faithful peer reference vocabularies STONEWORK aligns — alongside similarly faithful bindings for ATT&CK, CWE, CAPEC, NIST SP 800-53, and CIS Controls — each one a trustworthy rendering of its own source standard, cross-linked by STONEWORK’s shortcut predicates. The stones:uses edge in the diagram above is one instance of a pattern that repeats across the whole ecosystem: stonework:exploitsWeakness linking an attack pattern to a CWE, stonework:mitigatesAttackPattern linking a NIST or CIS control back to an ATT&CK technique. Same idea, same additive relationship to the faithful data underneath it, applied consistently across every framework a real investigation touches.

This isn’t a paper exercise

The graph above is running on live infrastructure today — the same STIX-to-STONES/STONEWORK transform behind our CTI Encyclopedia, and the same cross-framework linking pattern we used to trace Log4Shell from an ATT&CK technique through to the NIST and CIS controls that mitigate it. Ontological fidelity and practical, queryable cross-framework reasoning aren’t in tension — they’re the same pipeline.

Five objects is small on purpose — small enough to fit in a diagram. The same transform, unmodified, runs across MITRE’s entire ATT&CK STIX 2.1 export and everything else feeding the CTI Encyclopedia: tens of thousands of objects, cross-linked to CWE, CAPEC, NIST SP 800-53, and CIS Controls through STONEWORK’s shortcut predicates, kept current automatically rather than by hand. Moai, the reasoning interface we’re building on top of it, is what lets an analyst ask a question across all of that — plus their own organization’s local graph — without writing a line of SPARQL.

Both the hosted CTI Encyclopedia and Moai are coming soon — sign up to hear when they are.

STONES and STONEWORK are both open source. If you work with STIX 2.1 and want to see what a faithful, complete OWL binding looks like — or you’re thinking about how STIX fits into a broader threat intelligence ontology — read the full technical comparison between STONES and STIX 2.1 or see STONEWORK’s interactive class diagram.