STIX, TAXII and Sharing
Intelligence that stays inside one organization is worth less than intelligence shared across a trust community. The security industry built two standards to make that sharing automated, consistent, and machine-readable: STIX for structuring the intelligence itself, and TAXII for transporting it. This chapter covers how both work, what platforms implement them, and how to participate in a sharing community without creating problems for yourself or others.
Why Structured Sharing Matters
Before structured formats existed, threat intelligence sharing happened through email attachments, PDF reports, and informal phone calls. A security team that received a PDF report about a new malware campaign had to manually extract IOCs, paste them into their SIEM, and repeat the process the next time a report arrived. This was slow, error-prone, and did not scale.
What Structured Sharing Solves
- Interoperability: when intelligence is expressed in a standard format, a machine can read it. A SIEM can ingest it automatically, a firewall can pull updates from a shared feed without human intervention, and an analyst in one organization can share a structured incident report that a peer using different tooling can immediately correlate against their own data.
- Analytics at scale: when the same types of intelligence objects are described the same way across reports and organizations, you can query across them. How many organizations in my sector observed this IP? What other malware families are associated with the campaign that used this domain? Which ATT&CK techniques appear most frequently in reports about this actor? These questions are answerable with structured data and not answerable with a collection of PDF reports.
The Two Dominant Standards
STIX and TAXII were originally developed by MITRE and are now maintained by OASIS. STIX 2.1 is the current version of the data model and TAXII 2.1 is the current version of the transport protocol. They are separate specifications: STIX describes what intelligence looks like, TAXII describes how it moves. They are designed to work together but can be used independently.
STIX 2.1 Core Objects
STIX (Structured Threat Information eXpression) defines a data model for threat intelligence. Everything in STIX is an object: objects have types, unique identifiers, and properties, and are expressed in JSON. Two categories of objects exist: STIX Domain Objects (SDOs), which represent concepts, and STIX Relationship Objects (SROs), which express connections between SDOs.
Core SDOs
The core SDOs that practitioners encounter most frequently, each with a defined schema of required and optional properties:
| SDO | Represents | Key Properties |
|---|---|---|
| Indicator | A pattern that can be used to detect adversary behavior | pattern (in STIX Pattern language), valid_from |
| Malware | A specific malware sample or family | Malware types, operating system requirements, relationships to other objects |
| Threat Actor | An individual, group, or organization believed to be operating with malicious intent | Name, aliases, goals, sophistication level, resource level, primary motivation |
| Campaign | A grouping of adversary behaviors orchestrated by the same actor toward a common objective over a defined time period | Name, objective, time bounds |
| Attack Pattern | Maps to MITRE ATT&CK via an external_references property linking the technique ID | Name, external references |
| Tool, Vulnerability, Identity, Report | Additional common object types practitioners encounter regularly | Vary by object type |
Identity and Versioning
Every STIX object has a type field, an id field (formatted as type--UUID), a created field, and a modified field. The id is globally unique and persistent: the same intelligence object will have the same id across every system that shares it, which enables deduplication and provenance tracking across organizations. Modifying an object produces a new modified timestamp but preserves the original id, so consumers can track object version history.
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
"created": "2026-06-01T10:00:00.000Z",
"modified": "2026-06-01T10:00:00.000Z",
"name": "Malicious PowerShell download cradle",
"pattern": "[process:command_line MATCHES 'powershell.*-enc.*']",
"pattern_type": "stix",
"valid_from": "2026-06-01T10:00:00Z",
"indicator_types": ["malicious-activity"],
"confidence": 75
}STIX Relationships
STIX Relationship Objects (SROs) are what make STIX more than a database of facts. They express connections between objects, turning a collection of individual indicators and actor profiles into a graph of interconnected intelligence. A Relationship object has a source_ref (the object the relationship originates from), a target_ref (the object it points to), and a relationship_type that describes the nature of the connection.
Common Relationship Types
- uses: a threat actor or campaign uses a specific tool or attack pattern.
- indicates: an indicator indicates malware or attack pattern presence.
- attributed-to: a campaign is attributed to a threat actor.
- targets: a threat actor targets an identity or sector.
- mitigates: a course of action mitigates an attack pattern or vulnerability.
- delivers: malware delivers another malware family as a secondary payload.
These relationships allow analysts to traverse the graph and answer questions like: "What attack patterns does this threat actor use, and what indicators have been associated with those patterns?"
STIX Bundles
STIX bundles package multiple objects for transport. A bundle contains a type of "bundle", a unique id, and an objects array containing any combination of SDOs and SROs. When a CTI provider shares a threat report as STIX, they typically package it as a bundle containing the relevant SDOs (indicators, malware, threat actor, campaign) and the SROs that link them together. The consumer imports the bundle, and their platform reconstructs the graph from the contained objects and relationships.
TAXII Protocol
TAXII (Trusted Automated eXchange of Intelligence Information) is the transport protocol for STIX. It defines how to serve and retrieve STIX content over HTTPS.
What a TAXII Server Exposes
A TAXII server exposes an API with two primary resources: API Roots (top-level endpoints that group related collections) and Collections (named groupings of STIX objects that can be read from or written to).
Poll vs. Push
TAXII operates in two modes: a server can make collections available for polling (clients fetch on a schedule) or push new intelligence to subscribed clients when it arrives. The poll model is simpler to implement and more common in commercial platforms. The push model provides faster distribution for time-critical intelligence but requires server-side subscription management.
Client Discovery Workflow
This filtering is what makes TAXII feeds practical to automate at scale rather than re-downloading the full collection on every poll.
Authentication
Authentication in TAXII is standard HTTP: basic auth, API key via header, or OAuth. The TAXII specification does not mandate a specific authentication mechanism, so implementations vary. Most commercial and community TAXII servers issue API keys to registered participants. Access control to specific collections within a server can be implemented per-collection, allowing a single server to serve public feeds and restricted sharing group content to different audiences.
| TAXII Endpoint | Method | Purpose |
|---|---|---|
| /taxii2/ | GET | Discovery, list available API Roots |
| /{api-root}/ | GET | API Root info, list available collections |
| /{api-root}/collections/ | GET | List all collections in this API Root |
| /{api-root}/collections/{id}/objects/ | GET | Retrieve objects from a collection |
| /{api-root}/collections/{id}/objects/ | POST | Add objects to a collection (write access) |
Sharing Platforms and Communities
Understanding what each platform provides and how to consume it effectively is part of operating an intel-driven CTI function.
Open-Source, Commercial, and Sector Programs
| Platform / Program | Type | Notable Features |
|---|---|---|
| MISP | Open-source, most widely deployed | STIX 2.1 import/export, web interface for creating and enriching events, TAXII server functionality, flexible taxonomy/tagging, and instance federation. Many national CERTs and ISACs run MISP as their primary sharing infrastructure. |
| OpenCTI | Open-source, built around STIX 2.1 | Knowledge graph interface well-suited for actor profiling and campaign analysis. Supports MISP import, TAXII 2.1, and connectors to commercial feeds, sandboxes, and TI databases. Adopted by organizations that need a richer analytical interface than MISP's event-focused model. |
| Commercial platforms | Anomali ThreatStream, Recorded Future, Mandiant Threat Intelligence, EclecticIQ | Managed STIX/TAXII infrastructure with proprietary enrichment: feed aggregation, confidence scoring, deduplication, actor profiles, and SIEM/SOAR integration in exchange for subscription cost. |
| ISACs | Sector-specific trust communities | FS-ISAC (financial services), H-ISAC (health), E-ISAC (electricity), WaterISAC, IT-ISAC. Vetted analyst-produced intelligence over secure channels, typically MISP or a commercial equivalent. Membership requires fees, vetting, and agreement to sharing rules including TLP handling. |
| CISA (US) | Free government sharing programs | Automated Indicator Sharing (AIS) provides a TAXII feed, ISAC programs offer analyst-vetted advisories, and the Known Exploited Vulnerabilities (KEV) catalog is openly accessible. Similar programs operate in the EU through ENISA and national CERTs. |
Sharing Etiquette and Legal Considerations
Intelligence sharing communities function on trust. Trust is built slowly through consistent, high-quality contributions and destroyed quickly through a single mishandled disclosure. Before joining any sharing community, understand both the technical participation requirements and the behavioral norms that govern how members are expected to conduct themselves.
Four Norms That Govern Participation
- Contribute before you consume. Communities that have only consumers and no contributors collapse. The expectation in most ISACs and sharing groups is that members contribute intelligence from their own environments, not just receive intelligence from others. Even organizations without a dedicated CTI team can contribute: IOCs extracted during incident response, phishing samples received by users, and anomalous network connection data are all valuable. The quality threshold for community contribution is lower than the threshold for finished intelligence products.
- Honor TLP markings unconditionally. As covered in Chapter 1, TLP defines sharing scope. Violating TLP markings breaks the trust model that makes sharing possible. If you receive TLP:AMBER intelligence and want to share it beyond your organization, contact the originating source first. If you are unsure whether a piece of intelligence can be shared, assume it cannot until confirmed.
- Sanitize sensitive victim data before sharing. Intelligence derived from incident response in your environment may contain information that identifies your organization, your customers, or third-party systems involved in the incident. Review the intelligence for identifiable victim information and redact or generalize it before contributing. The goal is to share the threat intelligence (what the attacker did and how) without creating a secondary breach of victim privacy.
- Understand legal obligations. Legal considerations vary by jurisdiction. In some countries, sharing threat intelligence that includes personal data may require compliance with data protection regulations (GDPR in Europe, various state laws in the US). Before establishing automated sharing pipelines that include any personal information, consult with legal counsel about what can be shared and under what conditions. Many ISACs provide their member organizations with legal guidance and template sharing agreements specifically for this purpose.
Key Takeaways
- STIX 2.1 is the data model for structured threat intelligence. Objects are expressed in JSON with unique persistent IDs. SDOs represent concepts; SROs represent relationships between them.
- Core STIX object types include Indicator, Malware, Threat Actor, Campaign, Attack Pattern, Tool, and Report. Relationships connect these objects into an intelligence graph.
- TAXII 2.1 is the transport protocol. Clients poll collections on a schedule using an added_after filter to retrieve only new objects. Authentication is standard HTTP (API key or OAuth).
- MISP and OpenCTI are the primary open-source platforms. Commercial platforms (Anomali, Recorded Future, EclecticIQ) provide managed infrastructure with enrichment.
- ISACs are sector-specific trust communities. FS-ISAC, H-ISAC, IT-ISAC, and others provide vetted intelligence for members in exchange for organizational membership and contribution obligations.
- Sharing etiquette: contribute before you consume, honor TLP markings unconditionally, sanitize victim data before sharing, and review legal obligations for data containing personal information.
Knowledge Check
Click an answer to reveal the explanation.
What is the primary difference between STIX and TAXII?
You want to retrieve only the STIX objects added to a TAXII collection in the last 24 hours. What parameter do you use?
During an incident, you extract IOCs that include an email address belonging to a victim employee used in a phishing campaign. Before sharing this with your ISAC, you should: