STIX

STIX (Structured Threat Information eXpression) is an open standard for describing and exchanging cyber threat intelligence (CTI). Put simply: it is a shared language and format that lets different security systems record and pass on what they know about threat actors, campaigns, malware, vulnerabilities and indicators of an attack. The same data is understood both by a human and by a machine. In the current STIX 2.1 version, data is written in JSON.

STIX began as a US-CERT initiative and was developed by the MITRE Corporation. Since version 2.0 the standard has been maintained by the OASIS Cyber Threat Intelligence Technical Committee (CTI TC). STIX 2.1 and its companion transport protocol TAXII 2.1 were approved as OASIS standards on 10 June 2021.

What is STIX?

STIX is not a product or a service. It is a specification describing how to represent threat data. The point is to remove ambiguity. Instead of loose PDF reports and random indicator lists, STIX imposes a shared vocabulary and structure. A single indicator (such as the IP address of a command-and-control server), the campaign it appeared in, and the threat actor behind it can all be linked into one unambiguous graph.

The earlier generation, STIX 1.x, used XML and a separate observable specification called CybOX. Version 2.x dropped XML in favor of JSON, absorbed CybOX as Cyber-observable Objects (SCOs), and greatly simplified the model. The two versions are not compatible with each other.

What objects make up STIX 2.1?

The STIX 2.1 model is built on typed objects, each with a globally unique identifier (the type--UUID format). There are four main categories:

• SDOs — STIX Domain Objects (18 types): domain objects, that is the concepts of threat intelligence. They include attack-pattern, campaign, course-of-action, grouping, identity, indicator, infrastructure, intrusion-set, location, malware, malware-analysis, note, observed-data, opinion, report, threat-actor, tool and vulnerability.
• SCOs — STIX Cyber-observable Objects: objects describing facts observed on a network or a host, e.g. ipv4-addr, domain-name, file (with hashes), url, network-traffic, email-message or process. These are the former CybOX objects.
• SROs — STIX Relationship Objects: objects that link the others. relationship connects two objects, describing the kind of link (e.g. indicator → indicates → malware), while sighting records that a given element was observed somewhere.
• SMOs — STIX Meta Objects: metadata objects, including labels for permissions and data sharing (marking-definition, e.g. TLP rules), extensions and language content.

Objects are wrapped in a bundle — a container that groups a set of objects for delivery. The bundle itself adds no meaning. Links between objects are expressed by relationship objects (SROs) or by embedded reference properties (such as created_by_ref or object_refs).

How does an indicator pattern work?

The most important object in practice is indicator. It carries a detection pattern written in the STIX Patterning language. The pattern describes which observables signal a threat, for example:

• [ipv4-addr:value = '198.51.100.7'] — traffic to a specific IP address,
• [file:hashes.'SHA-256' = '…'] — a file with a given hash,
• [domain-name:value = 'evil.example'] AND [url:value = 'http://evil.example/payload'] — a combination of observables.

Such patterns can be translated into the rules of specific detection tools (SIEM, EDR, IDS — e.g. Sigma, Suricata, KQL/SPL queries). That is what makes STIX more than a documentation format: it actually feeds detection.

How does STIX differ from TAXII?

STIX and TAXII are two separate OASIS standards that complement each other, and they should be clearly distinguished:

• STIX = the format (the what): a language describing the content of threat intelligence — the structure and meaning of the data.
• TAXII = the transport (the how): a protocol (built on HTTPS/REST) that defines how STIX documents are exchanged between systems.

TAXII organizes exchange around concepts such as the API Root, Collection (a set you can pull objects from and push objects to), and Channel. It supports several distribution models: hub-and-spoke (a central repository), source/subscriber, and peer-to-peer. Importantly, STIX can also be shared without TAXII (e.g. as a plain file or via another API), and TAXII could in principle carry other content — though in practice both standards were designed to work together.

Why does STIX matter for security and the SOC?

For a SOC team (security operations center), a threat intelligence platform (TIP) and network monitoring (NDR/NSM), STIX solves the problems of scale and interoperability between systems:

• Automated detection feeding: STIX indicators can be pulled automatically from feeds (ISACs, CERTs, commercial vendors) over TAXII and injected into SIEM/EDR/IDS without manual re-keying.
• Context, not bare indicators: instead of a plain list of IPs or hashes, STIX carries relationships — which indicator belongs to which campaign, actor and malware family. This reduces false positives and speeds up the initial review of events.
• Enrichment and correlation: sighting objects let teams report that an indicator was actually seen in their environment. This closes the loop between what the network sees and the intelligence.
• Mapping to attack techniques: attack-pattern objects can point to MITRE ATT&CK techniques, linking observations to an adversary’s tactics and techniques.
• Sharing hygiene: marking-definition labels (e.g. TLP) and provenance data control who a given piece of intelligence may be passed to.

The limitations matter too. The STIX model can be richer than needed, data quality depends on the source (junk indicators generate noise), and full use requires a platform able to parse, deduplicate and expire objects over time (data marking, valid_until).

Learn more

• MITTRE ATT&CK — STIX can encode threat intel that maps to MITRE ATT&CK tactics, techniques, and procedures.
• Software Bill of Materials (SBOM) — STIX may carry vulnerability and asset context related to software components listed in an SBOM.
• NIST Cybersecurity Framework — STIX supports threat intelligence sharing that can inform NIST CSF risk and response activities.
• IoC (Indicator of Compromise) — STIX is used to represent and exchange indicators of compromise in a standardized format.
• Incident Response Lifecycle — STIX data can support incident response by sharing indicators, sightings, and threat context.
• SaaS Security Posture Management (SSPM) — STIX can describe threats and indicators relevant to SaaS environments monitored by SSPM.
• TTPs — STIX can represent attacker TTPs as structured threat intelligence objects.