STIX/TAXII vs MISP Format: Choosing a Threat Intel Sharing Model

Teams that share threat intelligence often pick a format by habit and then discover, months later, that sharing limits, analyst context or detection flags quietly fell away when the data crossed into the other model. STIX 2.1 with TAXII 2.1 is an open OASIS standard pair: a JSON language for intelligence plus an HTTPS API to move it. The MISP format is the native data model of the MISP platform, used between MISP instances in a sync protocol that also enforces distribution and sharing groups. This guide compares the two as sharing models rather than products: data model and transport, community fit, what is lost in conversion, how sharing controls such as TLP and attribution survive, and the failure modes that follow. It is written for CTI leads, sharing community operators and SOC engineers who have to run both. For the basics of each, see the STIX and TAXII Guide and the MISP Threat Sharing Guide; this page does not repeat them.

Key takeaways

• Standard versus platform model. STIX 2.1 and TAXII 2.1 are vendor-neutral OASIS Standards (10 June 2021); the MISP core format is a single project's model, published as an individual Internet-Draft and carried by MISP's own sync.
• Access control lives in different places. MISP enforces distribution levels and sharing groups during sync; the TAXII 2.1 specification leaves access control to the community or product, and STIX markings only state handling intent.
• Conversion is lossy unless both ends speak MISP. The MISP-STIX converter round-trips MISP content through STIX 2.1 using four MISP extension definitions, but a third-party consumer may ignore extensions, and CIRCL warns that TAXII transfers should not be assumed to preserve every native MISP feature.
• TLP needs explicit mapping. MISP exports a TLP tag as a STIX marking definition and other tags as labels; TLP 2.0 in STIX is carried through an OASIS extension, so check which TLP version each side reads.
• Pick by community, then bridge deliberately. Use native MISP sync inside MISP communities, STIX/TAXII to reach government, vendor and platform feeds, and treat the bridge as a controlled pipeline with tests, size limits and credentials of its own.

The short answer

These are not rivals at the same layer. STIX is a content language and TAXII a transport; the MISP format is a content model whose usual transport is MISP-to-MISP synchronisation, with STIX export and TAXII push as bridges. The practical question is which model is authoritative for a given exchange, and where translation happens.

Data model and transport compared

The two models describe overlapping ideas with different building blocks. STIX is graph shaped: every object is a node with an id, and relationships are first-class objects. MISP is container shaped: an event holds attributes, objects and galaxy clusters, and distribution and tags set on the event apply to what it contains.

Architecture in words, STIX/TAXII: a producer writes STIX objects into a TAXII collection on an API root; consumers poll with added_after and match filters, page through results and keep their own state. The server decides which objects a client may read, but the specification says access control is not defined by it and is left to the community, vendor or product, and that a server may omit objects or properties a client is not authorised to receive.

Architecture in words, MISP: each organisation runs an instance; sync links push or pull events between instances, and each instance re-applies distribution rules on arrival. The CIRCL documentation describes the hop behaviour: on push, levels 0 and 1 are not pushed, level 2 arrives as level 1 and level 3 stays at 3; sharing group data follows explicit membership rather than a hop count. MISP also acts as a TAXII 2.1 client: the core code holds TAXII server connections that push filtered events, converted to STIX, into a chosen collection.

Threat model for each sharing path

Both paths share the same assets (the intelligence, the sharing promises made to its source, and the detection pipelines that consume it) but they fail differently.

Credentials are part of both threat models. TAXII clients usually authenticate with HTTP Basic (the specification suggests it and requires clients to support it), API keys or client certificates; MISP's own TAXII server connections store a Basic credential, and MISP sync uses per-server API keys. Treat each as a non-human identity with an owner, a vault entry, least privilege and rotation. See the API Key Management Guide and Securing the threat intelligence platform (TIP) itself.

What is lost in conversion, and what is not

The MISP-STIX converter (the misp-stix Python library, used by MISP core for STIX conversion) is the reference bridge. Its documentation describes exactly how the mapping works, which makes the losses predictable.

• Event becomes Report or Grouping: a published MISP event exports as a STIX 2.1 Report; an unpublished one exports as a Grouping. Consumers that only ingest Reports will miss unpublished work.
• to_ids becomes object choice: attributes with to_ids set produce both an Indicator (with a STIX pattern) and an Observed Data object linked by a Relationship; attributes without it become Observed Data. On import, Indicators become attributes with to_ids set and Observed Data become attributes without it. A consumer that treats every observable as an indicator undoes this distinction.
• Tags become markings or labels: the mapping documentation notes that STIX marking definitions only support the tlp and statement types, so a TLP tag becomes a marking definition and other tags become labels. STIX 2.1 Section 2.14 and 3.2 allow consumers to ignore labels, so taxonomy tags that drive MISP filtering and decay scores may carry no weight downstream.
• MISP-only content rides in extensions: content no standard STIX object holds travels in four MISP Extensions (misp-attribute, misp-object, misp-galaxy-cluster and a property extension). STIX 2.1 makes extension support optional, so a third-party platform may drop them.
• Internal versus external import: bundles carrying the MISP-STIX-Converter label are imported as a faithful round trip; third-party bundles are mapped with heuristics, and SDOs such as Attack Pattern, Malware and Threat Actor become new galaxy clusters.
• Distribution does not cross: MISP distribution levels and sharing groups are access rules enforced by MISP; on import the converter assigns a distribution you choose (default 0, your organisation only), so whoever imports decides the new audience.
• Native-only features: CIRCL's sharing documentation warns that TAXII transfers use STIX and should not be assumed to preserve every native MISP feature, giving value-level analyst data and collection references as examples.

Sharing controls: TLP, markings and attribution

TLP versions: FIRST's TLP 2.0 has been authoritative since August 2022, with TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN and TLP:CLEAR. FIRST states that TLP is not a formal classification scheme and that systems such as MISP may use it in automated exchange, leaving the mechanics to the system designers. The STIX 2.1 specification predates TLP 2.0, so the OASIS CTI common objects repository publishes a TLP 2.0 marking definition extension (a property extension carrying tlp_2_0). The misp-stix mapping examples still show a TLP:WHITE marking for a tlp:white tag. Before exchanging, agree which TLP version each side writes and reads, and map TLP:WHITE to TLP:CLEAR and AMBER+STRICT explicitly; a consumer that only knows the 1.0 markings will not recognise AMBER+STRICT.

Markings versus enforcement: in both models TLP states intent. In MISP a tlp:red tag does not change an event's distribution; CIRCL shows push and pull rules that block tlp:red as the control. In TAXII, enforcement is whatever the server operator built. So in every pipeline, back markings with an enforced control: a distribution level, a sharing group, a separate collection or an export filter.

Attribution: STIX producers often want anonymity for victims and sometimes for themselves. created_by_ref may be omitted, which the specification allows, leaving the source undefined; consumers then cannot weigh source reliability. In MISP the Orgc is always present, so communities that need anonymous submission usually route reports through a trusted hub organisation. Decide this per community and write it in the sharing agreement. See Writing Threat Intelligence Reports for sanitising practice.

Community fit

• MISP communities: many CERTs, CSIRTs and ISACs operate MISP hubs, and native sync gives them sharing groups, proposals and sightings that flow back to the creator. If the community is MISP based, joining through STIX loses the feedback loop. See the ISACs and Information Sharing Communities Guide.
• Standards-led exchanges: government programmes, commercial feeds and most threat intelligence platforms publish or consume STIX 2.1 over TAXII 2.1, and MITRE publishes ATT&CK as STIX. A consumer with a TAXII client and no MISP can join these directly.
• Small organisations: usually consume rather than produce. A hosted TIP or a single MISP instance that subscribes to a community, plus TAXII feeds it trusts, is enough; avoid running both stacks without an owner.
• Large organisations and hubs: typically run a platform of record and must serve both models. Put one team in charge of mapping rules, TLP translation and conversion tests.

Worked scenario: a sector hub serving two worlds

A sector ISAC runs a MISP hub. Twenty members sync natively; eight members use other TIPs that only accept STIX 2.1 over TAXII 2.1; a national CERT publishes advisories as STIX into a TAXII collection.

1. Set the authority: the MISP hub is the record for member-submitted events; the CERT's TAXII collection is the record for its own advisories, imported with its original bundle kept as an attachment.
2. Define audiences as collections: one TAXII 2.1 collection per trust tier (community TLP:GREEN, members-only TLP:AMBER), fed by MISP TAXII server push connections with tag filters, and never a TLP:RED collection.
3. Translate TLP explicitly: the hub writes TLP 2.0 markings for STIX members and keeps tlp: taxonomy tags in MISP; the mapping is tested quarterly with a known event.
4. Protect detection intent: only published events with to_ids attributes are pushed, so STIX members receive Indicators with patterns plus Observed Data for context.
5. Accept and document loss: sharing groups, proposals and analyst notes stay in MISP; STIX members are told this in the sharing agreement and send feedback as STIX Sightings, which the hub imports.
6. Control credentials: each push connection has its own read-write credential to one collection, each member a read-only TAXII credential, rotated when contacts change.

How to implement a dual-format sharing pipeline

1. Inventory exchanges: list every inbound and outbound feed with its format, version (STIX 1.x, 2.0, 2.1), transport, TLP practice and owner.
2. Choose the platform of record and write mapping rules: which TLP version, which tags must survive, how distribution maps to collections, and what happens to unpublished work.
3. Pilot with known data: export a reference event with every structure you use, import it on the receiving side and diff the result. Validate STIX output with the OASIS STIX validator; the MISP Extensions directory is laid out so the validator can find its schemas.
4. Set limits: keep the converter's input size cap (100 MB by default; conversion costs two to seven times the input in memory) and cap concurrent imports, as its documentation advises.
5. Go live by tier: start with TLP:CLEAR and GREEN collections, then AMBER once enforcement is proven.
6. Roll back cleanly: disable the push connection or revoke the collection credential; for bad content, publish revocations (STIX revoked or newer version) and delete or correct the MISP event so sync carries the fix. Remember that a rule change does not recall copies already delivered.

Decision checklist

• Who are the partners? Mostly MISP users: native sync. Mixed or platform-diverse: STIX 2.1 over TAXII 2.1.
• Must access control be enforced by the protocol? MISP sync enforces it; with TAXII you build it into collections and server policy.
• Do you need feedback to the producer? MISP sightings and proposals return to the creator; with STIX, agree a Sighting return path.
• Do consumers read extensions? If not, plan for MISP-only content to be dropped.
• Which TLP version does each side support? Test AMBER+STRICT and CLEAR end to end.
• Is attribution required, optional or forbidden? Set created_by_ref and Orgc policy accordingly.

Detection and measurement

• Round-trip fidelity: percentage of fields in a reference event that survive export and re-import (track per release of the converter or TIP).
• Marking survival rate: share of objects received downstream with a recognised TLP marking.
• Conversion errors and warnings per week, from converter logs.
• Feed latency: time from publication in the source to availability in the consumer's detection tools.
• Feedback volume: sightings and false positive reports returned per 100 indicators shared.

Log every TAXII request (client identity, collection, method, object counts) and every MISP sync and API key use; alert on writes from read-only partners and on unusual export volumes. See the Threat Intelligence Programme Metrics Guide.

Common failure patterns

• TLP tag mistaken for a control: a tlp:red event set to All communities syncs anyway, and a STIX consumer that ignores markings forwards it. Always pair TLP with distribution or collection boundaries.
• Every observable becomes a block: consumers flatten Observed Data into indicators, so context values such as shared hosting IPs reach firewalls. Keep the Indicator versus Observed Data split and apply warning lists before export. See the Indicators of Compromise vs Indicators of Attack Guide.
• Silent extension loss: a TIP drops misp-object content and nobody notices until analysts ask where the context went. Test with a reference event after every upgrade.
• Version drift: one side still produces STIX 1.x XML or 2.0 custom objects; the other expects 2.1 extensions. Agree versions in writing.
• Over-privileged connectors: a write-capable TAXII or MISP key held by a partner integration becomes a route to poison many blocklists. Scope keys to one collection or server and review them.
• Import resets the audience: STIX imported with a default distribution broader than the source intended. Set the import distribution per feed.

Framework mapping

Practitioner checklist

• Record, for every exchange, the authoritative model, format version, transport and owner.
• Write a TLP mapping covering TLP 1.0 and 2.0 labels and test AMBER+STRICT and CLEAR end to end.
• Back every marking with an enforced boundary: distribution, sharing group, collection or export filter.
• Export only published, to_ids data to detection consumers, with warning lists applied.
• Run a reference event through export and import after every converter or TIP upgrade and diff the result.
• Keep converter input limits and cap concurrent imports.
• Issue one scoped credential per TAXII collection and per sync link; vault and rotate them.
• Set import distribution per feed instead of relying on the default.
• Agree a feedback route (MISP sightings or STIX Sightings) with every partner.

Standards and references

• OASIS: STIX Version 2.1
• OASIS: TAXII Version 2.1
• OASIS CTI: TLP 2.0 marking definition extension
• FIRST: Traffic Light Protocol (TLP) 2.0
• MISP Project: MISP core format (Internet-Draft)
• MISP Project: MISP-STIX converter mapping documentation
• MISP Project: MISP Extensions for STIX 2.1
• CIRCL: MISP user guide, sharing and distribution

Related NHI Mgmt Group resources: STIX and TAXII Guide · MISP Threat Sharing Guide · Threat Intelligence Platform Buyer's Guide · Indicators of Compromise vs Indicators of Attack Guide · Threat Intelligence Guide