Most teams that say they “do threat intelligence” are really just subscribing to feeds. They pipe a few thousand malicious IPs and domains into a firewall, watch the block count tick up, and call it a program. Six months later nobody can answer a simple question: did any of this actually stop an attack that mattered to us? That gap — between having data and having intelligence — is exactly what a threat intelligence framework exists to close.
A framework is not a product you buy. It is the set of processes, models, and plumbing that takes raw observations about adversaries and turns them into something a defender can act on with confidence. Feeds are ingredients. A framework is the kitchen.
Why Bother Building One
The core problem is signal-to-noise. Open and commercial sources will happily drown you in indicators — hashes, URLs, IPs, CVEs — most of which have nothing to do with your environment. Without structure, analysts spend their days copy-pasting IOCs between spreadsheets and consoles, decisions get made on gut feeling, and the same investigation gets redone from scratch every time because nobody wrote down what was learned last time.
A framework fixes this by imposing three things: a consistent way to describe threats, a repeatable process for producing intelligence, and defined paths for that intelligence to reach the tools and people who use it. The payoff is concrete. Detection rules get tied to specific adversary behaviors instead of brittle one-off indicators. An alert that says “possible Cobalt Strike beacon, associated with a group known to target our sector” is worth ten alerts that just say “traffic to a bad IP.”
Start With What You Actually Need to Know
Before touching a single tool, a good framework forces you to define your intelligence requirements — the specific questions the program must answer. These flow from the business, not from whatever the feeds happen to contain. A hospital, a bank, and a game studio face different adversaries and care about different things.
Requirements usually break down by audience:
- Strategic — for leadership. Who is likely to target us and why? How is the threat landscape for our industry shifting? This drives budget and risk decisions.
- Operational — for defenders and incident responders. What campaigns are active right now? What techniques are they using?
- Tactical — for the tools and the SOC. Concrete indicators and detection logic that plug directly into sensors.
Writing these down first is what keeps a program from becoming a firehose with no nozzle. Everything downstream — which sources to collect, which alerts to prioritize — traces back to a requirement someone actually asked for.
What Lives Inside the Framework
A working framework has a few recognizable parts.
A common language. You need standard models so that a threat means the same thing to everyone. The industry leans on a handful:
- MITRE ATT&CK — a catalog of adversary tactics and techniques, letting you describe how an attacker behaves rather than just what file they dropped.
- The Cyber Kill Chain — a stage model of an intrusion from reconnaissance to exfiltration.
- The Diamond Model — links adversary, capability, infrastructure, and victim into a single analytic unit.
- STIX/TAXII — STIX is a structured format for expressing intelligence; TAXII is the protocol for sharing it between systems.
A collection layer. This pulls from OSINT, commercial feeds, ISACs and sharing communities, and — crucially — your own internal telemetry. Your past incidents are often your most relevant intelligence source.
A processing and enrichment layer. Raw indicators get normalized, deduplicated, and enriched with context: who’s behind it, what campaign it belongs to, how confident we are, and when it stops being relevant. A platform like MISP (open source) is commonly the home for this.
An analysis and production layer. This is where humans add judgment — correlating events, attributing activity, and writing intelligence products against those requirements from earlier.
A dissemination layer. Finished intelligence gets pushed to the tools and people who consume it, in a format each can use.
Wiring It Into the Tools You Already Run
A framework earns its keep only when it connects to your existing stack — the SIEM, EDR, firewalls, and SOAR. The glue is almost always structured formats and APIs rather than manual exports.
Most modern platforms speak STIX over TAXII. Pulling a feed from a MISP instance to inspect what you’d actually be ingesting looks like this:
# Fetch recent events from a MISP server via its REST API
curl -s -H "Authorization: $MISP_API_KEY" \
-H "Accept: application/json" \
"https://misp.internal/events/index" | jq '.[].Event.info'That jq filter just prints event titles so you can sanity-check relevance before wiring the feed into a sensor.
Enrichment is the other half. When an alert fires, you want context attached automatically. A SOAR playbook might reputation-check an indicator against a service like VirusTotal:
# Look up a file hash's detection ratio during triage
curl -s --request GET \
--url "https://www.virustotal.com/api/v3/files/$SHA256" \
--header "x-apikey: $VT_API_KEY" \
| jq '.data.attributes.last_analysis_stats'The output — counts of engines flagging the hash as malicious, suspicious, or clean — lets a playbook auto-escalate or auto-close without an analyst reading raw JSON.
For turning intelligence into detections, ATT&CK-mapped rules travel well. Sigma is a vendor-neutral rule format that converts to whatever your SIEM speaks:
title: Suspicious PowerShell Encoded Command
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains: '-EncodedCommand'
condition: selection
tags:
- attack.execution
- attack.t1059.001The tags line ties the rule straight back to an ATT&CK technique, so coverage can be measured against the framework rather than counted as a pile of disconnected rules.
Standing One Up Without Boiling the Ocean
The failure mode is trying to build everything at once. A saner path is incremental:
- Write your requirements. Pick a handful of questions leadership and the SOC genuinely need answered. Ruthlessly ignore everything else for now.
- Pick your models. Adopt ATT&CK as the common vocabulary and STIX/TAXII for exchange. Don’t invent your own.
- Start with one good source and one platform. Stand up MISP or an equivalent, ingest a single high-quality feed plus your own incident history, and get the enrichment loop working.
- Integrate one consumer. Wire the platform to your SIEM or EDR so indicators flow automatically and matches generate alerts with context.
- Close the feedback loop. Track which intelligence produced useful detections and which was noise, then feed that back into collection. This step is what separates a living program from a dead pipeline.
- Expand. Add sources, consumers, and analysts once the core loop demonstrably works.
Measure the program by outcomes, not volume. “We ingest two million indicators” is a vanity metric. “Our mean time to triage dropped because alerts arrive pre-enriched, and we detected an intrusion by its ATT&CK technique before the payload was known” is the real thing.
The Takeaway
A threat intelligence framework is less about exotic tooling and more about discipline: knowing what you need to learn, describing threats in a shared language, and building the plumbing so that knowledge reaches your defenses automatically and improves over time. Done well, it converts a chaotic flood of indicators into a small stream of decisions you can trust. The tools — MISP, ATT&CK, STIX, Sigma — are the easy part and largely free. The hard, valuable part is the process around them, and that is the part no vendor can hand you.