Threat Intelligence Analysis: Turning Raw Data Into Decisions

Ask ten security teams what “threat intelligence” means and you will get ten different answers, and most of them will be wrong in the same way. They will point at a feed of IP addresses and domain names streaming into their firewall and call it intelligence. It isn’t. That feed is data. A list of a hundred thousand malicious IPs with no context, no confidence rating, and no relevance to your environment is closer to noise than to knowledge. Threat intelligence analysis is the discipline that sits between raw data and a defensible decision, and skipping it is why so many organizations own expensive feeds they never actually use.

Data, Information, Intelligence

The distinction matters because it drives everything else. Raw data is an isolated observation: a hash, a URL, a login timestamp. Information is data with some structure and correlation, for example “this hash was seen in three sandbox detonations this week.” Intelligence is information that has been analyzed and shaped to answer a specific question that a decision-maker actually has, such as “an actor targeting our sector is deploying this loader, and our EDR does not currently detect it.”

Analysts usually sort intelligence into three altitudes, and confusing them is a common failure:

• Strategic intelligence informs executives and shapes long-term risk posture. It is prose, not indicators: which actors care about your industry, how ransomware economics are shifting, what a geopolitical event means for your attack surface.
• Operational intelligence describes campaigns and adversary behavior — the tactics, techniques, and procedures (TTPs) behind an intrusion set. It guides how you hunt and where you invest detection effort.
• Tactical intelligence is the machine-consumable layer: indicators of compromise (IOCs) like hashes, domains, and IPs that feed detection tooling. It is the most abundant and the shortest-lived.

The mistake most teams make is buying tactical feeds and expecting strategic outcomes.

Why It Is Worth the Effort

Good analysis pays off in a few concrete ways. It lets you prioritize — instead of patching alphabetically, you patch what actors relevant to you are actively exploiting. It improves detection engineering, because understanding an adversary’s TTPs lets you write behavioral rules that survive infrastructure changes, rather than chasing IPs that rotate every day. It shortens incident response, since an analyst who recognizes the tooling in an intrusion can predict the next step. And it feeds risk decisions with evidence rather than vendor fear.

The unifying theme is relevance. Intelligence you cannot act on, or that does not map to your environment, has no value no matter how “true” it is.

Where the Analysis Actually Happens

Most organizations at some scale run a Threat Intelligence Platform (TIP) as the workbench. A TIP ingests feeds, deduplicates and normalizes indicators, enriches them, scores confidence, and pushes vetted output to the SIEM, firewall, or EDR. The best-known open-source example is MISP (Malware Information Sharing Platform), which is built around structured “events” and community sharing.

Because MISP exposes a full API, analysts rarely click through the UI for bulk work. A typical enrichment or export uses the PyMISP client:

from pymisp import PyMISP

misp = PyMISP('https://misp.local', '<API_KEY>', ssl=False)

# Pull every network indicator tagged as ransomware, seen in the last 7 days
results = misp.search(
    controller='attributes',
    type_attribute=['ip-dst', 'domain', 'url'],
    tags=['ransomware'],
    date_from='7d',
    to_ids=True   # only indicators vetted for detection use
)

for attr in results['Attribute']:
    print(attr['type'], attr['value'], attr['Event']['info'])

The to_ids flag is the point worth noticing: it separates indicators an analyst has judged reliable enough to block automatically from raw context that should never touch a firewall. That human judgment call is the analysis.

Indicators travel between organizations in standard formats so they don’t have to be retyped. STIX (Structured Threat Information eXpression) is the JSON schema for describing indicators, actors, and relationships; TAXII is the protocol for exchanging STIX over HTTP. A minimal STIX indicator looks like this:

{
  "type": "indicator",
  "spec_version": "2.1",
  "pattern": "[file:hashes.'SHA-256' = 'aec070645f...']",
  "pattern_type": "stix",
  "valid_from": "2026-07-01T00:00:00Z",
  "labels": ["malicious-activity"]
}

Frameworks Give the Analysis a Backbone

Raw indicators tell you what touched your network; frameworks tell you what it means and what comes next. Three are worth knowing well.

MITRE ATT&CK is a catalog of adversary behaviors organized by tactic (the goal) and technique (the method). Its power is that it turns a fuzzy narrative into a shared vocabulary. Instead of “the attacker moved around the network,” you write “T1021.002 — SMB/Windows Admin Shares.” Mapping an intrusion to ATT&CK immediately surfaces detection gaps: if an actor uses ten techniques and you can detect only four, you know exactly where to invest. The freely available ATT&CK Navigator lets you build heatmaps of an actor’s technique coverage against your own.

The Diamond Model forces an analyst to reason about four linked vertices of any event — adversary, capability, infrastructure, and victim. Pivoting from one vertex often reveals the others: a shared TLS certificate on the infrastructure vertex can tie two campaigns to the same adversary.

The Cyber Kill Chain describes intrusion as sequential stages from reconnaissance to actions on objectives. It is coarse compared to ATT&CK but useful for communicating to non-specialists where in the sequence a detection fired, and therefore how much damage was likely averted.

In practice these compose. You use the Kill Chain to frame the phase, ATT&CK to name the specific techniques, and the Diamond Model to pivot toward attribution and hunt for related infrastructure.

Operationalizing: Closing the Loop

Analysis that ends in a report nobody reads is wasted. Operationalizing means wiring conclusions back into defenses and measuring whether they helped. This tends to follow a cycle that professionals borrow from military doctrine:

1. Direction — define the intelligence requirements. What decisions need supporting? “Which initial-access techniques should detection engineering prioritize this quarter?” is a requirement; “give me more IOCs” is not.
2. Collection — gather from feeds, OSINT, internal telemetry, and sharing communities (ISACs).
3. Processing — normalize, deduplicate, and enrich, usually inside the TIP.
4. Analysis — correlate, apply frameworks, assess confidence, and produce something a human or machine can act on.
5. Dissemination — push tactical indicators to tooling automatically, and deliver operational and strategic findings to the humans who own those decisions.
6. Feedback — measure what fired, what was a false positive, and refine the requirements.

The automated end of that loop is straightforward to demonstrate. A hunt query against a SIEM turns operational intelligence — an actor’s known use of a technique — into a concrete search rather than a static blocklist:

-- Splunk: hunt for suspicious child processes of Office apps (T1566/T1204)
index=endpoint (process_parent_name IN ("winword.exe","excel.exe"))
  process_name IN ("powershell.exe","cmd.exe","wscript.exe","mshta.exe")
| stats count values(process_command_line) as cmdlines by host, user
| where count > 0

Notice this rule keys on behavior, not on an IP that will rotate tomorrow. That is the durable payoff of analysis over feed subscription: behaviorally grounded detections cost more to build but survive the adversary changing their infrastructure, which they do constantly and cheaply.

The Takeaway

Threat intelligence analysis is not a product you buy; it is a judgment you apply. The feeds, the TIPs, and the frameworks are all instruments in service of a single question: given everything I can observe about adversaries, what should my organization do differently? A team that answers that question — even with modest tooling and free frameworks like ATT&CK and MISP — will out-defend a team that spends heavily on feeds and never analyzes them. Start with the decisions you need to make, work backward to the intelligence that would inform them, and treat every indicator with the skepticism it deserves until analysis has earned it a place in your defenses.