STIX, TAXII and Sharing

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. Two organizations using different tools could not easily exchange intelligence in a way that both could immediately act on.

Structured threat intelligence solves the interoperability problem. 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. An analyst in one organization can share a structured incident report and a peer in a different organization using different tooling can immediately correlate it against their own data. The value of sharing multiplies when it removes the manual work of parsing and reformatting.

Consistency enables 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. 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. Objects 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.

The core SDOs that practitioners encounter most frequently are: Indicator, Malware, Threat Actor, Campaign, Attack Pattern, Tool, Vulnerability, Identity, and Report. Each has a defined schema with required and optional properties. An Indicator object represents a pattern that can be used to detect adversary behavior. It contains a pattern field expressed in STIX Pattern language and a valid_from field indicating when the pattern was first observed. A Malware object describes a specific malware sample or family, with fields for malware types, operating system requirements, and relationships to other objects.

The Threat Actor SDO represents an individual, group, or organization believed to be operating with malicious intent. Properties include name, aliases, goals, sophistication level, resource level, and primary motivation. The Campaign SDO represents a grouping of adversary behaviors believed to be orchestrated by the same actor toward a common objective over a defined time period. The Attack Pattern SDO maps to MITRE ATT&CK via an external_references property that links the technique ID.

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.

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 include: 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), and 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 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. 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).

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.

A TAXII client discovers available resources by querying the discovery endpoint, which returns a list of API Roots. From each API Root, the client can enumerate available collections and retrieve their contents. Collections can be filtered by added_after timestamp, object type, or object id to retrieve only new or relevant content rather than the full collection on every poll. This makes TAXII feeds practical to automate: a client polls hourly, retrieves only objects added since the last poll, and processes the delta.

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.

Sharing Platforms and Communities

MISP (Malware Information Sharing Platform) is the most widely deployed open-source threat intelligence sharing platform. It supports STIX 2.1 import and export, provides a web interface for analysts to create and enrich events, implements TAXII server functionality for automated sharing, and includes a flexible taxonomy and tagging system. MISP instances can federate with other MISP instances, creating a mesh of sharing communities. Many national CERTs and ISACs run MISP as their primary sharing infrastructure.

OpenCTI is an alternative open-source platform designed around the STIX 2.1 data model from the ground up. Its knowledge graph interface is particularly well-suited for actor profiling and campaign analysis. OpenCTI supports MISP import, TAXII 2.1, and a range of connector integrations with commercial feeds, sandbox platforms, and threat intelligence databases. It is increasingly adopted by organizations that need a richer analytical interface than MISP's event-focused model provides.

Commercial platforms including Anomali ThreatStream, Recorded Future, Mandiant Threat Intelligence, and EclecticIQ provide managed STIX/TAXII infrastructure alongside proprietary enrichment. These platforms aggregate feeds, apply confidence scoring and deduplication, provide threat actor profiles, and offer integration with SIEM and SOAR platforms. The value proposition is reduced curation burden in exchange for subscription cost.

ISACs (Information Sharing and Analysis Centers) are sector-specific sharing communities. Major ISACs include FS-ISAC (financial services), H-ISAC (health), E-ISAC (electricity), WaterISAC, and IT-ISAC. Each operates as a trust community for its sector, provides vetted analyst-produced intelligence, and runs secure sharing channels typically implemented on MISP or a commercial equivalent. ISAC membership usually requires organizational membership fees, basic vetting, and agreement to the community's sharing rules including TLP handling policies.

CISA (Cybersecurity and Infrastructure Security Agency) in the United States operates several free sharing programs for critical infrastructure sectors: the Automated Indicator Sharing (AIS) program provides a TAXII feed of indicators, the ISAC programs offer analyst-vetted advisories, and CISA's Known Exploited Vulnerabilities (KEV) catalog is openly accessible. Similar programs operate in the EU through ENISA and national CERTs across Europe.

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.

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 contributions. 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. Before contributing to a sharing community, review the intelligence for identifiable victim information and redact or generalize it. The goal is to share the threat intelligence (what the attacker did and how) without creating a secondary breach of victim privacy.

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.