The clock reads 03:47. A security analyst in Helsinki stares at a flood of alerts from three different platforms, each describing what looks like the same phishing campaign. One tool labels the indicator as a malicious URL, another marks it as a suspicious domain, and the third simply notes an “unusual outbound connection.” None of them speak the same language. So she starts copying and pasting data into a spreadsheet, knowing that somewhere in the noise, an active intrusion is unfolding. This scene plays out in security operations centres every night, and it explains exactly why threat intelligence needs open standards with a clarity that can no longer be ignored.
The Babel Problem in Threat Data
Threat intelligence has a language problem. Every vendor, every internal tool, every research group describes threats in its own proprietary format. One team might call a threat actor “APT29,” another uses “Cozy Bear,” and a third just tags it with an internal reference number that means nothing outside their building. When an organisation tries to combine feeds from commercial providers, open-source projects, industry ISACs, and government alerts, they don’t get a unified picture—they get a mess of overlapping, conflicting, and often redundant data points.
This fragmentation does real damage. A 2022 Ponemon Institute study found that security teams waste an average of 25 percent of their time normalising and deduplicating threat data before they can even begin analysis. That’s one full day a week lost to translation work that shouldn’t be necessary. During active incidents, the delay directly translates into longer dwell times for attackers. Every minute spent reformatting an indicator is another minute the adversary uses to move laterally, escalate privileges, or exfiltrate data.
The root cause isn’t technical complexity—it’s a lack of agreed-upon formats and vocabularies. When intelligence producers and consumers can’t agree on how to describe a simple IP address, let alone a complex attack pattern, the whole discipline of threat intelligence runs at a fraction of its potential speed and accuracy.
STIX, TAXII, and the Structured Approach
Two open standards have emerged to tackle this fragmentation head-on: Structured Threat Information Expression (STIX) and Trusted Automated Exchange of Intelligence Information (TAXII). Developed under the OASIS open standards consortium and now widely adopted across government and industry, these specifications give threat data a common grammar and a way to move it around.
STIX defines a consistent way to describe threat actors, campaigns, indicators, observed data, vulnerabilities, and the relationships between them. Instead of free-text descriptions that need a human to interpret, STIX uses JSON-based objects with clearly defined properties. An indicator of compromise isn’t just a string; it’s a structured object that includes the pattern, confidence level, source, and the context in which it was observed. That structure lets machines process, correlate, and prioritise threat data without waiting for an analyst to read every entry.
TAXII handles the movement. It defines a set of services and message exchanges that let organisations share STIX-formatted intelligence over HTTPS. A TAXII server can act as a hub, allowing multiple consumers to pull relevant feeds or receive push notifications when new intelligence gets published. This replaces the patchwork of email attachments, CSV files, and custom APIs that currently dominate threat sharing.
What Adoption Looks Like in Practice
Organisations that adopt STIX and TAXII report measurable improvements. The financial services sector, an early and aggressive adopter through the FS-ISAC community, has cut the time from intelligence receipt to actionable alert by roughly 40 percent, according to internal benchmarks shared at the 2023 FS-ISAC Summit. That speed comes from eliminating manual reformatting and enabling automated ingestion directly into SIEM and SOAR platforms.
The real power shows up when multiple organisations share a common intelligence picture. During the widespread exploitation of the ProxyLogon vulnerabilities in early 2021, organisations using STIX-based sharing received and deployed indicators within 15 minutes of initial publication. Organisations that relied on emailed PDF reports took over six hours to reach the same state of readiness. In a vulnerability exploitation scenario, six hours is an eternity.
Beyond Format: Vocabularies and Taxonomies
Standardising the envelope is necessary but not enough. Even when two organisations use STIX, they may still describe the same threat using different terminology. One team might classify a malware family as a “banking trojan” while another calls it a “credential stealer,” even though both are describing the same code. That’s where standardised vocabularies come into play.
The VERIS framework (Vocabulary for Event Recording and Incident Sharing) gives a common language for describing security incidents, covering threat actors, actions, assets, and impact. When an organisation reports a breach using VERIS, the data becomes comparable across industries and time periods. The annual Verizon Data Breach Investigations Report relies on VERIS precisely because it enables aggregation and analysis that free-text reports can’t support.
Similarly, MITRE ATT&CK has become a de facto standard for describing adversary behaviours. By mapping observed techniques to ATT&CK IDs (such as T1566 for phishing or T1059 for command and scripting interpreters), organisations can communicate with precision and connect their detections to a globally understood reference model. When a threat intelligence report says a campaign uses T1059.001 for PowerShell execution, every defender who knows ATT&CK immediately understands what to look for in their logs.
The OpenC2 Connection
A less widely known but equally important standard is OpenC2, which tackles the action side of threat intelligence. While STIX describes threats and TAXII moves data, OpenC2 defines a language for issuing commands to security devices. When a threat intelligence platform spots a malicious IP, it can use OpenC2 to tell a firewall to block that IP, a proxy to terminate connections, or an endpoint agent to quarantine a device—all using a standardised syntax that works across vendor boundaries.
This closes the loop between detection and response. Without OpenC2, automated blocking needs custom integrations for every combination of intelligence source and enforcement point. With it, the number of integrations drops from a multiplicative problem to an additive one. A single OpenC2 orchestrator can command any device that speaks the protocol, no matter who manufactured it.
The Hidden Cost of Proprietary Lock-In
Vendors have strong incentives to resist open standards. A threat intelligence platform that uses proprietary formats creates switching costs. If an organisation builds its workflows around a vendor’s unique data model and API, moving to a competitor means rebuilding those integrations from scratch. That lock-in lets vendors raise prices and slow innovation, knowing their customers face serious pain if they leave.
The security community has seen this pattern before. Before SNMP became the standard for network monitoring, every management tool used its own protocol, and network teams were forced to choose between vendor lock-in and blind spots. Before SCAP standardised vulnerability reporting, organisations ran multiple scanners and manually correlated results. In each case, open standards eventually broke the logjam, but only after years of wasted effort and inflated costs.
Threat intelligence is currently in the pre-standardisation phase that network management and vulnerability assessment left behind years ago. Organisations that insist on open standards in their procurement requirements can speed up this transition. When RFPs demand STIX/TAXII compatibility, VERIS-aligned reporting, and ATT&CK mapping, vendors respond. The market shifts because buyers force it to shift.
Interoperability Is a Force Multiplier
The strongest argument for open standards isn’t philosophical—it’s operational. Threat intelligence becomes exponentially more valuable when you can combine it. An indicator from a commercial feed that matches a finding from a government alert and aligns with an ATT&CK technique observed in internal telemetry produces a composite signal far stronger than any single source could provide. But that correlation is only possible when the data is structured, tagged, and transported in compatible formats.
Picture a real-world scenario. A manufacturing company subscribes to a commercial threat feed, participates in an industry ISAC, and receives alerts from its national CERT. The commercial feed reports a suspicious domain using STIX. The ISAC shares a VERIS-coded incident report describing a ransomware attack against a peer. The CERT alert maps the attacker’s techniques to ATT&CK. Because all three sources use open standards, the company’s SIEM ingests them automatically, correlates the domain with the attack pattern, and escalates an alert with a confidence score that reflects the multi-source corroboration.
Without open standards, that same company would receive a PDF from the CERT, a CSV from the ISAC, and a JSON blob from the commercial feed in a proprietary schema. A human analyst would need to read all three, recognise the connection, and manually create a detection rule. By the time that rule goes live, the attacker may have already succeeded.
Practical Steps for Immediate Adoption
Moving to open standards doesn’t require a multi-year transformation programme. You can take concrete steps that produce value within weeks.
1. Audit Current Intelligence Formats
Start by cataloguing every threat intelligence source you currently use. For each source, document the format (STIX, CSV, JSON, PDF, email), the delivery mechanism (TAXII, API, email, portal download), and the time required to ingest the data into operational tools. This audit will reveal the biggest pain points and the sources most in need of standardisation.
2. Require STIX/TAXII in New Procurements
When evaluating new threat intelligence platforms or feeds, make STIX and TAXII support a mandatory requirement, not a nice-to-have. Vendors that can’t or won’t support these standards should be disqualified. This single procurement rule, applied consistently, will reshape the threat intelligence market within your supply chain.
3. Map Existing Intelligence to ATT&CK
Even if full STIX adoption takes time, you can start mapping threat data to MITRE ATT&CK techniques immediately. Assign a small team to review recent intelligence reports and tag each described behaviour with the appropriate ATT&CK ID. This creates a bridge between unstructured reports and structured detection engineering.
4. Join a Sharing Community That Uses Open Standards
Many ISACs and threat sharing groups have already adopted STIX and TAXII. Joining one of these communities provides immediate access to standardised intelligence and creates peer pressure to maintain compatible internal systems. The Cyber Threat Alliance and various national CERT communities operate TAXII servers that any vetted organisation can access.
The Urgency We Cannot Afford to Ignore
Threat actors don’t suffer from fragmentation problems. They share tools, techniques, and infrastructure with remarkable efficiency, often using the same dark web forums and encrypted channels no matter their location or target industry. The asymmetry between attacker collaboration and defender isolation is widening, and open standards represent the most direct way to close that gap.
Every day organisations keep describing threats in incompatible formats, attackers gain an advantage measured in hours and days of delayed response. The standards already exist. They are mature, well-documented, and backed by active communities of practice. What’s missing isn’t technical capability—it’s organisational will.
The analyst in Helsinki shouldn’t be copying and pasting at 3:47 in the morning. The machines should be talking to each other in a language they both understand, correlating signals, and presenting a clear, prioritised picture of the threat. That’s what open standards make possible. That’s what the defenders deserve. And that’s what we must demand, starting now.
Frequently Asked Questions
What is the difference between STIX and TAXII?
STIX is the language used to describe threat intelligence. It defines objects and properties for indicators, threat actors, campaigns, vulnerabilities, and relationships. TAXII is the transport mechanism that moves STIX data between organisations. Think of STIX as the letter and TAXII as the postal service. You need both to share structured threat intelligence effectively.
Do open standards create security risks by sharing too much information?
Open standards don’t dictate what you share, only how you format and transport it. Organisations retain full control over which indicators, reports, and context they distribute. TAXII includes authentication and authorisation controls, so sharing can be restricted to trusted partners. The format is open; the sharing relationships are entirely under your control.
How long does it take to implement STIX/TAXII in an existing security stack?
Many SIEM, SOAR, and threat intelligence platforms already include native STIX/TAXII support. If your tools are reasonably current, enabling these capabilities can take days to weeks, not months. The larger effort is usually retraining analysts and reconfiguring playbooks to take advantage of automated ingestion, but this work pays for itself rapidly through reduced manual processing.
Is MITRE ATT&CK a standard or just a framework?
MITRE ATT&CK is a knowledge base that has become a de facto standard through widespread community adoption. It isn’t a formal standard in the way STIX is, but its ubiquity makes it effectively mandatory for threat intelligence work. Most STIX implementations now include ATT&CK technique IDs as part of their threat actor and campaign descriptions.