Building an IOC Pipeline with MISP and STIX: The Complete Guide

A SOC team gets access to three threat intelligence feeds, two CSV lists shared by a partner, and a JSON export from an EDR vendor. Each source has its own format, its own duplicates, and indicators two years old that are still marked active. The question is no longer "where do I find IOCs" (they are everywhere), it is "how do I fit them into a pipeline that feeds detection without drowning it". MISP and STIX 2.1 are the reference building blocks for that question. This guide covers the pipeline end to end, from raw source to the rule that actually fires.

The overall architecture: sources into MISP, MISP into detection

A solid IOC pipeline breaks down into three stages.

Sources into MISP. Inbound feeds (commercial feeds, national CERTs, sector ISAC sharing, internal incident findings) land in MISP through feed connectors, the REST API, or manual import. MISP acts as the normalization layer: each indicator becomes a typed attribute (ip-dst, domain, sha256, url, and so on), attached to an event, tagged against a shared taxonomy.

Normalization and deduplication. This is MISP's central job: two sources reporting the same hash in different formats must converge on a single attribute, with automatic correlation between events that share indicators.

STIX 2.1 export into detection engines. Once attributes are qualified, MISP exports them as STIX 2.1 (bundles of indicator, malware, attack-pattern objects linked by relationship), consumable by a SIEM, a NIDS such as Suricata, or an EDR that can ingest structured threat intel.

# STIX 2.1 export of a MISP event via the REST API
curl -s -H "Authorization: <API_KEY>" \
  -H "Accept: application/json" \
  "https://misp.example.org/events/stix/download/1234/2.1" \
  -o event-1234-stix21.json

This three-stage split has one simple benefit: each link can change without breaking the others. Switching feed vendors does not touch the Suricata export, as long as MISP normalization stays stable.

Ingesting a feed: attributes, tags, taxonomies, correlation

Raw ingestion is where most pipelines derail. A mistyped attribute (an IP tagged as a hash) breaks correlation downstream. Three disciplines matter here.

Type every attribute correctly. MISP distinguishes, for instance, ip-src (source of an observed connection) from ip-dst (destination), and that distinction changes the detection decision you draw from it: blocking a source IP you saw attacking is not the same call as blocking a destination IP an internal host merely connected to.

Tag against a stable taxonomy. MISP ships standard taxonomies (tlp, admiralty-scale, estimative-language) that carry source reliability and permitted sharing scope. An attribute without a TLP tag should never leave the platform toward a third party.

Turn on correlation. MISP automatically correlates identical attributes across events, surfacing indicators seen by multiple independent sources, a far stronger confidence signal than a single isolated mention.

The real noise filter, however, is warninglists. These are lists of values that should never become blocking IOCs, even when a source reported them by mistake or by over-broad extraction:

• RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), addresses no legitimate external feed should ever mark as malicious;
• the top one million most-visited domains worldwide, whose presence in an IOC almost always signals an over-broad automated extraction rather than a real compromise;
• IP ranges of major cloud providers and CDNs, routinely shared by thousands of legitimate services.

# Example warninglist configuration enabled in MISP
warninglists:
  - name: "List of RFC 1918 private IP addresses"
    enabled: true
  - name: "Top 1000000 domains"
    enabled: true
  - name: "Cloud service providers IP ranges"
    enabled: true

Without these guardrails, a pipeline eventually proposes blocking an internal IP or a public CDN. That is the incident that breaks the network team's trust in every IOC that follows.

IOC lifecycle: scoring, expiration, avoiding overreach

An IOC is not a permanent truth. A malicious IP today can be reassigned to a legitimate hosting customer six months from now. A command-and-control domain seized by law enforcement becomes available for anyone to buy again.

Scoring should combine several signals: the number of independent sources corroborating the indicator, how recently it was first observed, the attribute type (a malware hash ages far better than an IP), and the context of the associated campaign. MISP lets you expose this as a Threat Level attribute or through custom Galaxy fields.

Expiration (decay) needs to differ by indicator type: a SHA-256 malware hash stays valid for years, an attack infrastructure IP has a useful lifespan of weeks to a few months, a throwaway domain even less. A pipeline that applies the same retention window to every IOC type mechanically accumulates stale noise.

A concrete before/after example:

Before (unmanaged raw feed): an IP reported eight months ago by a feed, never reviewed since, still sitting in the firewall's active block list. The hosting provider has since reassigned that IP to a legitimate customer, who ends up blocked with no explanation, generating a support ticket and eroding trust in the whole control.

After (pipeline with lifecycle management): the same IP is automatically downgraded to "expired" status after 90 days without new corroboration, removed from the active block list, but kept in the database for historical correlation during future investigations. Active blocking stays reserved for recent, corroborated indicators.

Delivering into detection: export and the sightings loop

STIX export does not end at a JSON file dropped somewhere. Every target engine has its own consumption format.

For Suricata, network IOCs (IP, domains, URLs) turn into rules or block lists (iprep, dataset) loaded at startup.

# Example Suricata rule generated from an IOC indicator (C2 IP)
alert ip $HOME_NET any -> 198.51.100.23 any (msg:"IOC MATCH C2 infrastructure"; \
  reference:url,misp.example.org/events/view/1234; \
  classtype:trojan-activity; sid:9000123; rev:1;)

For Sigma, host-based IOCs (hashes, file paths, registry keys) feed endpoint detection rules rather than network signatures.

For an EDR, file hashes and indicators typically integrate through a custom indicators API, distinct from the EDR engine's own native signatures.

The loop that closes the pipeline, and that many teams forget, is sightings: every time an indicator actually fires an alert in the field, that sighting should be reported back to MISP. This feedback strengthens the indicator's confidence score (one seen multiple times under real conditions deserves more weight than one never revisited since import), and in turn feeds the expiration decision.

Measuring the value of an IOC pipeline

A pipeline that runs without measurement proves nothing. Three metrics are enough to steer quality over time:

• Match rate: share of IOCs that trigger at least one sighting over a given window. A rate that stays near zero for long signals a feed that adds nothing to your threat context.
• False positive rate: share of blocking IOCs that had to be pulled after investigation because they did not correspond to real malicious activity. This is the number that should stay low if warninglists and lifecycle management are doing their job.
• Average freshness: median age of active indicators in the database. A database that ages without renewal loses value silently, even when total volume stays stable.

A curated feed instead of a raw stream to sort

Everything above, normalization, warninglists, scoring, lifecycle, the sightings loop, is recurring engineering work, not a project you finish once. Every new source adds its own set of exceptions to handle and false positives to filter out.

That is exactly what the ThreatClaw IOC feed delivers: indicators already normalized and corroborated across multiple independent sources, with "never block" hygiene built in upstream (RFC1918, top one million domains, legitimate cloud infrastructure) and quality floors that filter out indicators too old or too weakly corroborated. You wire the feed into your detection; the sorting work is already done.