STIX and TAXII Guide: Standard Formats and Transport for Threat Intelligence

Threat intelligence that arrives as PDFs, spreadsheets and vendor-specific feeds cannot be correlated, deduplicated or acted on by machines at the speed attackers move. STIX (Structured Threat Information Expression) is the OASIS standard language for describing cyber threat intelligence as JSON objects, and TAXII (Trusted Automated Exchange of Intelligence Information) is the OASIS standard HTTPS protocol for exchanging it. This guide explains both in plain terms first, then goes into the object model, the TAXII 2.1 API, versioning, markings and the credentials that TAXII clients depend on. It is written for threat intelligence analysts, SOC engineers and architects who consume or publish feeds, connect a threat intelligence platform, or work with MITRE ATT&CK data, which MITRE publishes as STIX.

Key takeaways

• STIX is the content, TAXII is the transport. STIX defines what a threat actor, indicator or relationship looks like in JSON; TAXII defines how clients discover servers and read or write those objects over HTTPS.
• Version 2.1 of both is current. STIX 2.1 and TAXII 2.1 were approved as OASIS Standards on 10 June 2021, and the OASIS CTI documentation site still points to 2.1 as the latest specifications.
• Relationships carry the intelligence. STIX 2.1 has 18 domain objects, 18 cyber-observable objects and two relationship objects; the value comes from linking them, such as an intrusion set that uses malware that is indicated by an indicator.
• Versioning and markings are rules, not hints. An object version is identified by its id plus modified timestamp, only the creator may update or revoke it, and handling restrictions travel with the object as marking definitions.
• TAXII credentials are non-human identities. Feed clients authenticate with HTTP Basic credentials, API keys or client certificates that usually sit in a platform connector; they need an owner, a vault and rotation like any other machine credential.

What it is

STIX is, in the words of the OASIS Cyber Threat Intelligence (CTI) Technical Committee, a language and serialisation format used to exchange cyber threat intelligence. TAXII is an application layer protocol for communicating cyber threat information over HTTPS, designed specifically to carry STIX but able to carry other content. Both are maintained by the OASIS CTI Technical Committee. The 1.x generations of both standards used XML; the 2.x generations use JSON, which is the reason most modern tooling only supports 2.0 or 2.1.

Put simply, STIX lets a producer say "this IP address is command and control for this intrusion set, 80 per cent confidence, share within your community only", and TAXII lets a subscriber ask "give me everything added to this collection since yesterday".

How it works

The STIX object model

• STIX Domain Objects (SDOs): 18 higher-level concepts: 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.
• STIX Cyber-observable Objects (SCOs): 18 objects for facts seen on systems and networks, including File, IPv4 Address, IPv6 Address, Domain Name, URL, Email Message, Network Traffic, Process, User Account, Windows Registry Key and X.509 Certificate. In STIX 2.1 SCOs are top-level objects that relationships can point to directly.
• STIX Relationship Objects (SROs): Relationship, which links two objects with a relationship_type such as uses or indicates, and Sighting, which records the belief that something (an indicator, malware, a threat actor) was seen.
• Meta objects: Marking Definition (statement and TLP markings), Language Content (translations) and Extension Definition (the 2.1 mechanism for adding custom properties or object types in a declared way).
• Bundle: a wrapper for moving arbitrary STIX content in bulk, for example as a file.

Common properties every producer must get right

Versioning: only the creator of an object may publish a new version or revoke it. Another producer that wants to change an object must create a new object with its own id and should link it to the original with a derived-from relationship.

Indicators and patterning

An Indicator contains a pattern that can be used to detect suspicious or malicious activity, a pattern_type and a valid_from time. The OASIS documentation example for a malicious URL uses the native STIX patterning language with pattern_type stix and a pattern of the form [url:value = '...']: an object path (SCO type and property), a comparison operator and a value, inside square brackets, with observation expressions combinable using AND, OR and qualifiers. The pattern type vocabulary also allows other detection languages, such as Sigma, Snort, Suricata and YARA, so a STIX Indicator can carry an existing detection rule with its context. The grammar is published by OASIS as a non-normative ANTLR grammar.

The TAXII 2.1 API

1. Discovery: a client sends GET /taxii2/ and receives server information, an optional default API root and a list of api_roots. Servers can also be advertised with a DNS SRV record for the service name taxii2.
2. API roots: each API root is a separate instance of the API with its own base URL, often one per trust group. GET {api-root}/ returns the title, supported versions and max_content_length.
3. Collections: GET {api-root}/collections/ lists collections; each shows can_read and can_write for the calling client. Objects are read with GET .../collections/{id}/objects/, added with POST to the same path, listed cheaply with .../manifest/, and individual versions with .../objects/{object-id}/versions/.
4. Filtering and paging: added_after, limit, next and match[id], match[type], match[version] (first, last, all or a timestamp) and match[spec_version]. Comma-separated values in one filter are ORed and different filters are ANDed. Responses come in an envelope with more and next; without next, clients page using added_after and the X-TAXII-Date-Added-Last header.
5. Status: a POST returns a status resource at {api-root}/status/{status-id}/ that reports pending or complete; servers should keep it for at least 24 hours.

Channels: the publish-subscribe model is reserved in TAXII 2.1 but not defined; the specification defers channel services to a future version.

TAXII supports hub-and-spoke, source-subscriber and peer-to-peer sharing models. Errors use standard HTTP codes, notably 401 (authentication needed), 403 (denied) and 404 (missing or not visible to the client).

Where identity fits: TAXII client credentials

TAXII uses standard HTTP authentication as defined in RFC 7235. The specification suggests HTTP Basic: servers should implement it and clients must implement it. Feeds also use API keys, bearer tokens or mutual TLS. CISA's Automated Indicator Sharing, for example, requires a PKI certificate from a Federal Bridge Certificate Authority and registration of the connecting IP address. These credentials sit in platform connectors, run unattended for years and a write-capable one lets an attacker publish poisoned indicators into a community's blocking pipelines. Treat each one as a non-human identity: one credential per feed and per environment, read-only unless publishing is required, stored in a vault, owned by a named team and rotated on staff or vendor change. See the API Key Management Guide.

Why it matters

• Automation at community scale: CISA's Automated Indicator Sharing (AIS) is a free service for exchanging machine-readable indicators and defensive measures between government and the private sector. It uses TAXII 2.1, and participants sign the AIS Terms of Use (or, for federal agencies, a Multilateral Information Sharing Agreement) and an Interconnection Agreement. CISA states that sharing through AIS in line with the Cybersecurity Information Sharing Act of 2015 brings liability and privacy protections. ISACs and ISAOs commonly offer TAXII feeds to members in the same way.
• Framework data you already use: MITRE publishes ATT&CK as STIX 2.1 collections in the attack-stix-data repository, one folder per domain (Enterprise, Mobile, ICS) with versioned and latest files and an index.json. The Enterprise v20.0 file is one bundle of 26,690 STIX 2.1 objects, including 867 attack-pattern objects (techniques), 193 intrusion sets (groups), 268 courses of action (mitigations) and 21,819 relationships such as uses, mitigates and subtechnique-of. Tactics, matrices, data sources, data components, analytics and detection strategies use custom x-mitre-* object types. MITRE CAPEC is also distributed as a STIX bundle. See the MITRE ATT&CK Guide for Defenders.
• Handling rules that survive the journey: markings travel with the object. FIRST's Traffic Light Protocol 2.0, authoritative since August 2022, defines TLP:RED, TLP:AMBER+STRICT, TLP:AMBER, TLP:GREEN and TLP:CLEAR. The marking definitions built into STIX 2.1 predate TLP 2.0 (they use the older labels), so check how your platform represents AMBER+STRICT and CLEAR before you exchange data with a partner.
• Vendor independence: STIX-native pipelines survive a change of platform or feed provider. See the Threat Intelligence Platform Buyer's Guide.

Choosing how far to adopt

A phased adoption path

1. Inventory feeds: list each source, its format, API root, collections and credential.
2. Pilot read-only: connect one TAXII 2.1 collection to a test platform instance with a read-only credential; confirm paging with added_after and that revoked objects and new versions replace old ones.
3. Set quality gates: minimum confidence, valid_until handling, allow-lists for your own ranges and domains, and mapping of markings to your internal handling rules.
4. Feed controls in audit mode: send indicators to detection rules that alert but do not block; measure false positives for two to four weeks before enabling blocking.
5. Publish back: once processes are stable, share Sightings or new indicators with an approval step and the correct TLP marking.
6. Roll back: keep the collection subscription and the blocking integration separately switchable, so a bad feed can be disabled without losing history; revoke or rotate the feed credential if the source is compromised.

What to measure

• Feed freshness: median time from an object's created time to its arrival in your platform.
• Actionable rate: share of received indicators that pass quality gates and reach a control.
• False positive rate: alerts closed as benign per thousand indicators deployed, per feed.
• Sighting yield: number of Sightings your environment produces per feed per month, a direct measure of relevance.
• Stale indicator share: deployed indicators past valid_until or revoked but still active in controls.

Log TAXII client activity on both sides: 401 and 403 responses, unexpected POST requests to collections, and requests from unregistered addresses can indicate a stolen feed credential.

Common misconceptions

• "STIX is a feed." STIX is a format. The quality of a feed depends entirely on the producer's curation, confidence scoring and expiry, and a well-formed STIX object can still be wrong or stale.
• "A bundle is a report." A bundle explicitly conveys no context. Producers who ship unrelated objects in one bundle, and consumers who treat co-location as a relationship, create false links. Use Report or Grouping objects for context.
• "TAXII 2.1 streams in real time." Channels are reserved but undefined in 2.1. Clients poll collections, so freshness depends on polling interval and server-side processing; check the status resource after writes rather than assuming success.
• "STIX 2.0 and 2.1 are interchangeable." 2.1 changed how cyber observables work (top-level SCOs instead of embedded observed data), added objects such as Grouping, Infrastructure, Location, Malware Analysis, Note and Opinion, and introduced Extension Definitions. Check spec_version and convert deliberately.

Related concepts

See the Threat Intelligence Guide.

Practitioner checklist

• Record every intelligence source with its STIX version, TAXII API root, collection ids and credential owner.
• Require spec_version 2.1 from new suppliers, and plan conversion for any STIX 2.0 or 1.x sources.
• Honour revoked, valid_until and new versions automatically, and remove stale indicators from blocking controls.
• Map STIX marking definitions, including TLP 2.0 labels, to your internal handling rules before data reaches analysts.
• Put every feed's indicators through an audit-mode period before enabling blocking, with your own assets allow-listed.
• Issue one read-only TAXII credential per feed and environment, store it in a vault and rotate it at least yearly and on staff or vendor change.
• Load ATT&CK from the official STIX 2.1 collections by version, and skip revoked and deprecated objects.
• Validate outbound STIX before publishing, with a named approver for anything marked above TLP:CLEAR.

Standards and references

• OASIS: STIX Version 2.1, OASIS Standard
• OASIS: TAXII Version 2.1, OASIS Standard
• OASIS CTI Technical Committee: STIX and TAXII documentation
• CISA: Automated Indicator Sharing (AIS)
• MITRE: ATT&CK STIX 2.1 data (attack-stix-data)
• FIRST: Traffic Light Protocol (TLP) 2.0
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Threat Intelligence Guide · MISP Threat Sharing Guide · OpenCTI Guide · MITRE ATT&CK Guide for Defenders · API Key Management Guide