What is STIX 2.1?
STIX 2.1 (https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html) — Structured Threat Information eXpression — is the OASIS standard for representing and sharing cyber threat intelligence. It defines a rich vocabulary of objects: Threat Actors, Attack Patterns, Malware, Campaigns,
Vulnerabilities, Indicators, Courses of Action, and more. Organizations across government, defense, and the commercial sector use STIX 2.1 to exchange threat intelligence in a consistent, structured format.
STIX 2.1 is excellent at what it does. But what it does is define a data exchange format — a JSON schema. Its semantics live in the specification prose, not in a machine-interpretable model. STONES was created to change that.
The Ontological Gap in STIX 2.1
The STIX 2.1 specification describes a rich conceptual model: object hierarchies, typed relationships, controlled vocabularies, and behavioral semantics. But when that model is serialized as JSON, several things are lost or left implicit:
– No formal class hierarchy. The specification describes that a ThreatActor is a StixDomainObject is a StixCoreObject is a StixObject — but the JSON schema does not enforce this. The hierarchy exists only in prose.
– Vocabulary values are string literals. “threat_actor_types”: [“nation-state”] is a plain string. Nothing prevents inconsistency, typos, or variant representations across systems. Machines cannot reason over string values.
– Relationships require identity chasing. In STIX JSON, a relationship between two objects is a separate document connected via UUID string references. Graph traversal requires resolving source_ref and target_ref strings manually — there is no predicate directly connecting the two objects.
– No participation in OWL reasoning or SPARQL. Without a formal ontological model, STIX data cannot participate in inference, federated querying, or integration with other knowledge graphs.
STONES resolves each of these gaps while remaining as faithful as possible to the STIX 2.1 specification.
The STONES Class Hierarchy
The STIX 2.1 specification implies a clear object hierarchy. STONES makes it axiomatic in OWL 2. Every class is formally declared as a subclass of its parent, and the full hierarchy is machine-enforceable
- stones.StixObject (abstract root – all STIX objects
- stones:StixBundle
- stones:StixMetaObject
- stones:LanguageContent
- stones:MarkingDefinition
- stones:ExtensionDefinition
- stones:StixMetaObject
- stones:StixSubType (embedded sub-types: KillChainPhase, ExternalReference, etc.)
- stones:StixCoreObject (carries created, modified, and a type-qualified identifier)
- stones:StixDomainObject (SDO)
- stones:AttackPattern
- stones:Campaign
- stones:CourseOfAction
- stones:Grouping
- stones:Identity
- stones:Incidentstones:Indicator
- stones:Infrastructure
- stones:IntrusionSet
- stones:Location
- stones:Malware
- stones:MalwareAnalysis
- stones:Note
- stones:ObservedData
- stones:Opinion
- stones:Report
- stones:ThreatActor
- stones:Tool
- stones:Vulnerability
- stones:StixCyberobservableObject (SCO)
- stones:ArtifactObject
- stones:AutonomousSystemObject
- stones:DirectoryObject
- stones:DomainNameObject
- stones:EmailAddressObject
- stones:EmailMessageObject
- stones:FileObject
- stones:IPv4AddressObject
- stones:IPv6AddressObject
- stones:MacAddressObject
- stones:MutexObject
- stones:NetworkTrafficObject
- stones:ProcessObject
- stones:SoftwareObject
- stones:UrlObject
- stones:UserAccountObject
- stones:WindowsRegistryKeyObject
- stones:X509CertificateObject
- stones:StixRelationshipObject (SRO)
- stones:Relationship
- stones:Sighting
- stones:StixDomainObject (SDO)
- stones:StixBundle
This hierarchy enables class-based reasoning across all STIX objects. A query for stones:StixDomainObject returns all 19 SDO types. A query for stones:StixCoreObject returns every SDO, SCO, and SRO. The hierarchy the specification describes is now one that a machine can reason over.
STIX Identifiers and Types as IRIs
Every STIX object has two required fields:
“id”: “intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28”
“type”: “intrusion-set”,
In STONES, these map to the semantic graph as follows:
The type value is preserved as a datatype property stones:stixType and is also the mechanism by which OWL class membership is asserted. Each STONES class is defined with an owl:equivalentClass restriction on stones:stixType:
stones:IntrusionSet owl:equivalentClass [
owl:intersectionOf (
stones:StixObject
[ owl:onProperty stones:stixType ;
owl:hasValue “intrusion-set”^^xsd:string ]
)
] .
This means an OWL reasoner will automatically classify any individual with stones:stixType “intrusion-set” as a stones:IntrusionSet — class membership is derived, not asserted manually. STIX data asserted into the graph is automatically placed in the correct class hierarchy.
The id value maps to a stable IRI in the data namespace. The UUID-based STIX identifier is preserved as the stones:stixId datatype property so that round-tripping back to JSON is lossless.
Vocabularies as Named Individuals
STIX 2.1 uses open and controlled vocabularies extensively. In JSON, these values are plain strings:
“threat_actor_types”: [“nation-state”],
“sophistication”: “advanced”
Plain strings have no formal identity. They can be misspelled. Two systems can use slightly different strings to mean the same thing and never know it. Machines can only string-match — they cannot reason over vocabulary membership or align values across datasets.
In STONES, every vocabulary value is a formal OWL NamedIndividual with a stable IRI:
stones:nation-state
a stones:ThreatActorTypeVocabulary ;
rdfs:label “nation-state” .
stones:advanced
a stones:SophisticationVocabulary ;
rdfs:label “advanced” .
Now vocabulary values have:
– Stable, dereferenceable identity — stones:nation-state is unambiguous across systems
– Formal class membership — vocabulary instances are typed, enabling class-level queries
– Reasoning support — OWL inferences can be drawn over vocabulary membership
– Alignment potential — owl:sameAs or skos:exactMatch can link STONES vocabulary values to equivalent concepts in other ontologies
SPARQL queries filter by IRI, not string matching. The vocabulary becomes a first-class part of the knowledge graph.
Relationships — Reification and Shortcut Predicates
STIX 2.1 represents relationships between objects as first-class Relationship objects (SROs):
{
“type”: “relationship”,
“id”: “relationship–a1b2c3…”,
“relationship_type”: “uses”,
“source_ref”: “intrusion-set–b695c322…”,
“target_ref”: “attack-pattern–d4e2f5…”
}
This is a reified relationship — the relationship itself is a named object with properties (type, timestamps, confidence, data markings). This design is intentional in STIX: relationships are first-class citizens with full provenance.
STONES preserves the full SRO as a named individual in the graph:
cti:relationship–a1b2c3
a stones:Relationship ;
stones:stixType “relationship” ;
stones:relationshipType “uses” ;
stones:sourceRef cti:intrusion-set–b695c322 ;
stones:targetRef cti:attack-pattern–d4e2f5 .
However, traversing the graph via an intermediate Relationship node for every query is verbose and unnatural for a semantic graph. STONES therefore also asserts a shortcut predicate — a direct OWL ObjectProperty between the source and target:
cti:intrusion-set–b695c322 stones:uses cti:attack-pattern–d4e2f5 .
The shortcut predicates — stones:uses, stones:targets, stones:mitigates, stones:attributed_to, stones:exploits, stones:indicates, and others — are formally declared as OWL ObjectProperty instances. They are not informal convenience shortcuts; they are proper semantic predicates with ontological standing.
This dual representation gives you the best of both worlds:
| Need | USE |
| Full provenance, timestamps, confidence, markings | The stones:Relationship named individual |
| Natural graph traversal in SPARQL | The shortcut predicate (stones:uses, etc.) |
| OWL reasoning over relationships | The shortcut predicate as a typed ObjectProperty |
A SPARQL query can ask “which intrusion sets use which attack patterns” with a single triple pattern:
PREFIX stones: <https://cyberterrain.org/ns/stones#>
SELECT ?group ?technique WHERE {
?group a stones:IntrusionSet ;
stones:uses ?technique .
?technique a stones:AttackPattern .
}
Without the shortcut predicates, the same query would require navigating through the Relationship node — three triple patterns instead of one, and no participation in property-based OWL inference.
A Concrete Example: From STIX JSON to STONES
The same intelligence — APT29 uses Spear Phishing — represented in STIX 2.1 JSON and as STONES Turtle:
STIX 2.1 JSON:
{
“type”: “bundle”,
“id”: “bundle–f3a41…”,
“objects”: [
{
“type”: “intrusion-set”,
“id”: “intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28”,
“spec_version”: “2.1”,
“name”: “APT29”
},
{
“type”: “attack-pattern”,
“id”: “attack-pattern–d4e2f5cb-3d3b-4b2a-9a1c-0e2c7b5a6f3d”,
“spec_version”: “2.1”,
“name”: “Spear Phishing”
},
{
“type”: “relationship”,
“id”: “relationship–a1b2c3d4-1234-5678-abcd-ef0123456789”,
“spec_version”: “2.1”,
“relationship_type”: “uses”,
“source_ref”: “intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28”,
“target_ref”: “attack-pattern–d4e2f5cb-3d3b-4b2a-9a1c-0e2c7b5a6f3d”
}
]
}
STONES Turtle:
@prefix stones: <https://cyberterrain.org/ns/stones#> .
@prefix cti: <https://cyberterrain.org/data/> .
# The Intrusion Set — classified automatically by the OWL reasoner
cti:intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28
a stones:IntrusionSet ;
stones:stixType “intrusion-set” ;
stones:stixId “intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28” ;
stones:name “APT29” .
# The Attack Pattern
cti:attack-pattern–d4e2f5cb-3d3b-4b2a-9a1c-0e2c7b5a6f3d
a stones:AttackPattern ;
stones:stixType “attack-pattern” ;
stones:stixId “attack-pattern–d4e2f5cb-3d3b-4b2a-9a1c-0e2c7b5a6f3d” ;
stones:name “Spear Phishing” .
# The Relationship — full SRO preserved with all provenance
cti:relationship–a1b2c3d4-1234-5678-abcd-ef0123456789
a stones:Relationship ;
stones:stixType “relationship” ;
stones:relationshipType “uses” ;
stones:sourceRef cti:intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28 ;
stones:targetRef cti:attack-pattern–d4e2f5cb-3d3b-4b2a-9a1c-0e2c7b5a6f3d .
# Shortcut predicate — direct, navigable semantic triple
cti:intrusion-set–b695c322-7e68-4e58-a4db-8cbf5d8b1e28
stones:uses cti:attack-pattern–d4e2f5cb-3d3b-4b2a-9a1c-0e2c7b5a6f3d .
The same intelligence is now queryable, reasoner-ready, and participates in the full STONES class hierarchy — with no loss of the original STIX provenance.
Faithfulness by Design
STONES is faithful to the STIX 2.1 specification by design. This means:
– No reinterpretation. STONES does not impose external semantics on STIX concepts. An AttackPattern in STONES means exactly what the STIX 2.1 specification says it means.
– No exclusions. Every STIX 2.1 Domain Object, Cyber Observable Object, Relationship Object, Meta Object, and structured sub-type is represented.
– Complete property coverage. Every standard STIX property — including optional and extension-point properties — has a corresponding datatype or object property in STONES.
– Independent work. STONES is not affiliated with OASIS or the OASIS Cyber Threat Intelligence Technical Committee (CTI-TC). It is a third-party ontological interpretation of the publicly available STIX 2.1 specification.
Where the STIX 2.1 specification is ambiguous or leaves modeling choices open, STONES selects the interpretation most consistent with OWL 2 best practices and the overall spirit of the specification.
Download and Resources
| Resource | |
| Ontology file | ontologies/stones-merged.ttl (single file, all modules included) |
| Ontology reference | cyberterrain.org/ns/stones/doc (/ns/stones/doc/) |
| STIX 2.1 Specification | docs.oasis-open.org/cti/stix/v2.1 (https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html) |
| GitHub | https://github.com/Cyber-Terrain-Ontology/stones |
| Extension ontology | STONEWORK (/stonework/) — extends STONES with ATT&CK, D3FEND, CWE, NIST SP 800-53, and CIS |
| License | MIT — free to use, extend, and integrate |