Threat Intelligence API: Cyber Security Data for Applications

TLDR: Threat intelligence APIs deliver structured cybersecurity data in standardized formats that security tools can ingest and act on programmatically. This article covers IOC types, the STIX 2.1 data model and TAXII 2.1 transport protocol, concrete SIEM and SOAR integration patterns, how to evaluate feed quality, and how to complement structured feeds with open-web monitoring for early signals. The goal is a working integration model, not a vendor survey.

What Structured Threat Intelligence Delivers

Threat intelligence APIs differ from general-purpose search or data APIs in one critical way: they return data in formats specifically designed for automated security tool consumption. A domain name returned by a search API is a text string. The same domain returned by a threat intelligence API arrives with a type annotation, a confidence score, a first-seen timestamp, a valid-until date, and potentially a set of relationships linking it to a known malware family or threat actor group. That structure is what allows downstream tools to act without human review of every record.

The two standards that define this structure are STIX 2.1 (Structured Threat Information Expression) for the data model and TAXII 2.1 (Trusted Automated Exchange of Intelligence Information) for the transport layer. Both are OASIS standards. STIX 2.1 was published as an OASIS Standard on 10 June 2021. TAXII 2.1 was published on the same date. (STIX 2.1 spec, TAXII 2.1 spec)

The STIX 2.1 Data Model

STIX is a graph-based language. The graph has two node types and one edge type.

STIX Domain Objects (SDOs) represent threat intelligence concepts. The full set defined in STIX 2.1 includes: Attack Pattern, Campaign, Course of Action, Grouping, Identity, Indicator, Infrastructure, Intrusion Set, Location, Malware, Malware Analysis, Note, Observed Data, Opinion, Report, Threat Actor, Tool, and Vulnerability. Each SDO has a defined schema with required and optional properties.

STIX Cyber-observable Objects (SCOs) represent host-based and network-based observables: file objects, process objects, network traffic objects, domain name objects, IPv4 and IPv6 address objects, URL objects, email message objects, and others. SCOs document facts about what was observed, without asserting the "who" or "why."

Relationship Objects (SROs) link SDOs and SCOs to each other. A relationship might express that a Threat Actor "uses" a Tool, that a Malware "targets" an Identity, or that an Indicator "indicates" an Infrastructure object. The graph structure allows downstream tools to traverse relationships to build context around a single indicator.

The mandatory serialization format for STIX 2.1 is JSON. Objects are transported in a STIX Bundle container. The STIX Patterning language, used by Indicator SDOs, allows matching patterns against timestamped observable data collected by a threat intelligence platform. A patterning example for a file hash indicator:

[file:hashes.'SHA-256' = 'aabbcc...']

STIX 2.1 is transport-agnostic. The spec explicitly states that "structures and serializations do not rely on any specific transport mechanism" and that TAXII is the companion spec designed specifically for STIX transport. Non-TAXII transport (HTTP REST endpoints, message queues, bulk file exports) is also valid and commonly used.

TAXII 2.1 Transport

TAXII 2.1 is an application-layer protocol over HTTPS. It defines two primary sharing models:

• Collections: A TAXII server hosts a set of CTI objects that consumers request on demand. This is a pull model: clients query the server for objects added after a given timestamp using the added_after parameter.
• Channels: A publish-subscribe model. TAXII 2.1 reserves the keywords for Channels but notes in the specification that "Channel services will be defined in a subsequent version of this specification." Most current implementations use Collections.

The standard entry point for TAXII server discovery is the /taxii2/ path. A GET to that endpoint returns available API Roots. Each API Root organizes one or more Collections. Collections are queried at {api-root}/collections/{collection-id}/objects/. Pagination uses the TAXII next cursor.

MITRE ATT&CK publishes its knowledge base over a TAXII 2.1 server in STIX 2.1 format. The ATT&CK STIX data is available in both STIX 2.0 and STIX 2.1 representations, as confirmed on the ATT&CK Data and Tools page. This means any TAXII 2.1-capable client can ingest the full ATT&CK technique taxonomy programmatically, enabling automated technique mapping without maintaining a local copy of the dataset.

IOC Types and Their Integration Use Cases

Indicators of compromise are the atomic unit of most operational threat intelligence. The types most commonly delivered via API are:

IOC Type	STIX SCO / Indicator Pattern	Primary Use
IPv4/IPv6 address	ipv4-addr, ipv6-addr	Firewall block, SIEM alert on outbound connection
Domain name	domain-name	DNS sink-holing, proxy block, phishing detection
URL	url	Web gateway block, phishing link detection
File hash (MD5, SHA-1, SHA-256)	file:hashes.MD5, file:hashes.'SHA-256'	EDR block, antivirus signature, artifact matching
Email address	email-addr	Phishing sender blocking, BEC detection
Autonomous system number	autonomous-system	Network-level blocking of known bad ASNs

ECS threat.indicator.confidence in Elasticsearch maps STIX confidence as a keyword field (Not Specified, None, Low, Medium, or High per the STIX 2.1 Appendix A scale), not the raw 0-100 integer from the STIX object. (Elastic Common Schema threat fields, 2026-09-04) The valid_until property on Indicator SDOs drives IOC expiration, which is critical for managing false positive rates: an IP address that hosted malicious infrastructure two years ago is far more likely to be a false positive today if it has been reassigned.

SIEM Integration Patterns

SIEM platforms integrate threat intelligence feeds through two distinct patterns: indicator-match rules and enrichment at query time.

Indicator-Match Detection Rules

In this pattern, the SIEM maintains a local index of threat indicators ingested from TAXII feeds. Detection rules match incoming log events against this index. When a firewall log shows an outbound connection to an IP address present in the indicator index, an alert fires.

The Elastic Custom Threat Intelligence (ti_custom) integration, documented at elastic.co, implements this pattern. It acts as a TAXII client, polls configured Collections on a schedule, maps STIX fields to Elastic Common Schema (ECS) fields, and writes records to an indicator index. An Elastic Transform deduplicates the stream, writing active indicators to destination indices aliased at logs-ti_custom_latest.indicator and keeping only the most recent state per STIX object ID. (Elastic ti_custom docs, 2026-09-04) Detection rules then reference this deduplicated index. The integration supports ISAC feeds (MS-ISAC, FS-ISAC, H-ISAC) out of the box, provided the consuming organization holds ISAC membership.

Sumo Logic implements the same pattern through its STIX/TAXII 2 Client Source, which supports TAXII versions 2.0 and 2.1. It polls for new indicators hourly by default (configurable from 5 minutes to 48 hours) and supports CISA AIS, Dragos, Recorded Future, and SOCRadar feeds natively. (Sumo Logic STIX/TAXII docs)

Enrichment at Query Time

In the enrichment pattern, the SIEM calls out to a threat intelligence API during alert investigation rather than maintaining a local indicator index. When an analyst opens an alert containing a suspicious IP, the SIEM's enrichment playbook queries the TI API and appends the returned context to the alert record. This pattern trades latency for freshness: enrichment queries always hit the current state of the feed rather than a cached snapshot.

The tradeoff is query volume. A high-alert-volume SOC generating thousands of alerts per hour will generate a proportionate number of enrichment API calls. Most commercial TI APIs price on query volume, so the operational cost model requires careful planning. Many organizations use the indicator-match pattern for high-frequency block decisions and the enrichment pattern for analyst-facing investigation workflows.

SOAR Integration Patterns

SOAR platforms orchestrate multi-step security workflows. The TAXII 2 Feed integration in Cortex XSOAR (available from version 5.5.0, also supported in XSIAM) ingests STIX indicators from TAXII 2.0 and 2.1 servers and surfaces them to playbooks. Playbooks can then perform indicator enrichment, trigger blocking actions, and create investigation tickets automatically. (XSOAR TAXII 2 Feed docs)

A standard threat intelligence enrichment playbook in a SOAR platform follows this sequence:

1. Receive alert with one or more indicators (IP, domain, hash)
2. Query configured TI APIs for each indicator
3. Map returned confidence scores and feed names to an internal severity rating
4. If confidence is above threshold: auto-block at configured enforcement points and create a high-priority ticket
5. If confidence is below threshold: append context to alert and route to analyst queue
6. Set expiration reminder based on valid_until field to trigger re-evaluation

The Traffic Light Protocol (TLP) labels on STIX objects govern redistribution. TLP:RED indicators must not leave the receiving organization. Automated systems that redistribute indicators to partners or shared platforms must enforce TLP labels, which requires the STIX object's object_marking_refs to be parsed and respected at the delivery stage.

Evaluating Feed Quality

The most common failure mode in threat intelligence operations is high false positive rates from stale or low-quality feeds. Evaluation criteria that matter in practice:

Timeliness

The gap between when a threat is observed in the wild and when it appears in an API feed is the timeliness metric that matters most. For fast-moving threats (phishing campaigns, ransomware C2 infrastructure), a feed with a 48-hour delay delivers indicators after the attack has already completed its initial phase. Ask vendors for their median time from observation to API availability, broken down by IOC type. File hashes typically lag more than network indicators because they require malware analysis steps.

False Positive Rate

A feed with high recall but poor precision will generate alert fatigue that burns analyst capacity and trains teams to ignore alerts. Measure false positive rates by importing a sample of feed indicators and matching them against your internal traffic logs during a baseline period. Any match to infrastructure you have confirmed as legitimate is a false positive. Compare rates across candidate feeds before making a procurement decision.

IOC Expiration Discipline

Feeds that do not expire indicators degrade quality over time. An IP address that was active C2 infrastructure three years ago may today host a legitimate business. STIX 2.1 provides the valid_until field for this purpose. Vendors that populate this field correctly and that actively revoke indicators that are no longer reliable are meaningfully differentiated from those that treat IOCs as permanent.

Coverage Breadth vs. Depth

No single feed covers all threat actor groups, all malware families, and all geographic regions with equal depth. Evaluate candidate feeds against the specific threat categories your organization faces. A financial services organization has different coverage requirements from a defense contractor. Feed providers typically publish coverage matrices or can provide sample data for evaluation against your specific threat model.

Feed Source Transparency

NIST SP 800-150 emphasizes that cyber threat information sharing works best when the provenance of each data element is clear, because source reliability varies and recipients need to weight information accordingly. A feed that aggregates from multiple upstream sources without carrying source attribution in the returned objects makes this impossible. Prefer feeds that populate the created_by_ref and object_marking_refs fields in returned STIX objects.

Combining Structured Feeds with Open-Web Monitoring

Structured threat intelligence feeds have a latency floor. Intelligence goes through collection, analysis, validation, and publication before it reaches a TAXII endpoint. For early signals, before a new campaign has been formally reported and published, open-web monitoring is faster.

The operational pattern is to run open-web queries on suspicious infrastructure encountered during incident response, in parallel with TI feed lookups. If a new domain appears in an alert and returns no hits in the structured feed, a web search for that domain often surfaces researcher posts, VirusTotal community notes, or threat actor forum activity that provides attribution context within seconds.

You.com's web search API supports this pattern directly. A real-time query for a suspicious domain or actor alias returns current web and news results that structured feeds have not yet published. The Research API goes further: it runs multi-step reasoning across search results and returns a cited synthesis, reducing analyst reading time when a result set is large. API documentation is at you.com/docs. New accounts receive $100 in complimentary credits at you.com/platform.

The combination of structured feeds (TAXII-delivered STIX objects for known threats) and open-web monitoring (search APIs for early signals and novel infrastructure) is more complete than either alone. Structured feeds drive automated blocking at scale; open-web search supports analyst investigation and early warning before formal reporting catches up.

For dark web coverage, which neither structured feeds nor open-web APIs reach, see dark web monitoring APIs, and for the broader OSINT collection layer that feeds into this pipeline, see OSINT API integrations.