STIX and TAXII

Why it matters

Threat intelligence used to arrive as PDFs and spreadsheets, retyped by hand into each firewall and SIEM. STIX makes an indicator machine-readable and self-describing — the value, the pattern to match, when it is valid, who said so and how confident they are — and TAXII moves it automatically: your platform polls a partner's collection every hour and the blocklist updates itself. Every major threat-intelligence platform (MISP, OpenCTI, ThreatConnect, Anomali), the commercial feeds and the sector ISACs speak it; ATT&CK itself is published as a STIX bundle.

For a small team the payoff is simpler: an IOC list exported as STIX imports cleanly into whatever the next tool or the next partner uses, with stable identifiers so the same indicator is not duplicated on every exchange.

How it is structured

STIX 2.1 is JSON. Everything is an object with a type, a spec_version, an id of the form type--UUID, and created/modified timestamps. The main kinds:

• Domain objects (SDOs): indicator, malware, attack-pattern (ATT&CK techniques), threat-actor, intrusion-set, campaign, tool, vulnerability, report, note, identity.
• Relationship objects (SROs): relationship (indicator indicates malware, intrusion-set uses attack-pattern) and sighting.
• Cyber-observable objects (SCOs): the raw things — ipv4-addr, domain-name, url, file with hashes, email-addr.
• Marking definitions: TLP, attached via object_marking_refs.
• A bundle is just a container: {"type":"bundle","id":"bundle--…","objects":[…]}.

An indicator carries a pattern in the STIX pattern language — [domain-name:value = 'evil-cdn.example'], [file:hashes.'SHA-256' = '9f86…'], [ipv4-addr:value = '203.0.113.66'] — plus valid_from, optional valid_until, indicator_types (malicious-activity, anomalous-activity…) and confidence. Because ids are UUIDs, two parties emitting the same indicator with random ids create duplicates; the fix is deterministic UUIDv5 ids derived from the pattern, which is what the STIX-generating tools on this site do.

TAXII 2.1 is a small HTTPS API: a server exposes API roots, each with collections; clients GET …/collections/{id}/objects/?added_after=… to pull and POST to push, with content type application/taxii+json. Authentication is whatever the server chooses (usually HTTP basic or a token). It says nothing about the content beyond "STIX objects".

Common misreadings

• STIX 1 and STIX 2 are different formats. STIX 1.x was XML and is dead; "supports STIX" without a version usually means 2.0 or 2.1, and they are not identical (2.1 added malware-analysis, grouping, note, and made spec_version mandatory on every object).
• A bundle is not a report. It has no author, no title, no narrative; use a report object inside it for that.
• Custom properties are allowed but not free. x_myorg_… fields are legal; x-mytype objects that strict validators reject are not, and tools such as MISP will drop them.

Related terms

• IOC — An IOC is a piece of forensic evidence — a file hash, an IP address, a domain, a registry key, a mutex — whose presence on a system or in traffic indicates that a known intrusion has occurred.
• TTP — TTPs are the three levels at which attacker behaviour is described — the tactic is why (steal credentials), the technique is how (dump LSASS memory), the procedure is exactly how this actor does it (procdump renamed to dump64.exe, run via a scheduled task).
• MITRE ATT&CK — MITRE ATT&CK is a public, curated catalogue of the behaviours real attackers use, organised so defenders can say "we saw T1059.001" instead of "some PowerShell thing".
• Sigma — A Sigma rule is a detection written once, in a small YAML format, that describes what to look for in which kind of log — and is then converted into the query language of whatever SIEM you happen to run.