How to Build a Threat Intelligence Program: From Isolated IOCs to Campaign-Level Defense

Security organizations often track last quarter's threat intelligence outputs: feeds ingested and reports published. Those outputs matter only when they change decisions.

The gap is measurable: 91% of CISOs call threat intelligence valuable, while 26% say it drives their decisions (opens in new tab). That gap is a design problem, and it starts with the unit of analysis. Programs built around isolated indicators of compromise (IOCs) organize around artifacts an attacker replaces in minutes, while the operation behind them keeps running across domains, social platforms, paid ads, messaging apps, and voice.

This article covers what a threat intelligence program is, how the unit of analysis moved from the indicator to the campaign, five steps to build a program around that shift, and four measures that show whether it works.

Key takeaways

• A threat intelligence program works when written intelligence requirements map to decisions a named stakeholder owns.
• Campaign-level correlation gives defenders the unit that survives infrastructure churn. Indicators keep their narrower job of blocking known bad.
• Measurement should track decisions influenced, requirement coverage, stakeholder adoption, and requirement turnover.

A threat intelligence program turns threat data into decisions someone owns

A threat intelligence program is the standing capability that converts external threat data (opens in new tab) into decisions specific people act on. The feeds, platforms, and analyst tooling underneath it are inputs the program governs, which is why a program can fail with excellent inputs and succeed with modest ones.

Some programs also cover vulnerability and geopolitical intelligence. The examples here stay on the social engineering surface, and feed mechanics live in our guide to threat intelligence feeds (opens in new tab).

A program has six parts, and feedback closes the loop

Six parts make a program: stakeholders and the decisions they make, intelligence requirements, collection scoped to those requirements, analysis, dissemination in the format each audience acts on, and feedback that adjusts all of it. These run as a repeating loop that mirrors the classic intelligence cycle.

Programs often stop after dissemination. Collection then keeps answering last year's questions, reports grow longer while readership shrinks, and leadership funds a function whose output nobody can trace to a decision.

Intelligence requirements are the questions the program exists to answer

An intelligence requirement is a question a named stakeholder needs answered before a decision they own. "Which impersonation campaigns (opens in new tab) are targeting our payment flows this quarter, and do they justify new customer-facing controls?" qualifies. It has an owner and a time-bound decision. "Track emerging threats" fails that test.

Security teams borrow the priority intelligence requirement from military intelligence doctrine (opens in new tab), which ties each requirement to a decision the commander must make and keeps the list short because collection assets are finite.

Each written requirement obligates collection.

The unit of analysis moved from the indicator to the campaign

The standards the discipline runs on adopted the campaign as their unit before most programs did. The atomic indicator earned its place when infrastructure was expensive to replace. Cheap hosting, fast phishing churn, and bulk domain registration ended that condition.

Most programs still match known bad against internal telemetry

In the indicator-matching model, teams ingest artifacts such as domains, IP addresses, hashes, and URLs, cross-check them against internal logs, and alert or block on a match. The model is coherent, and it still catches known infrastructure.

A blocked domain once bought real protection, and the SOC could measure defense in matches. That assumption broke. Most indicators no longer stay useful long enough to organize a program around.

Attackers made indicators disposable

Defenders usually match on the cheapest thing on an attacker's list to change. Denying an adversary an IP address causes almost no pain, because replacing one is trivial. Defenders have long described that cost imbalance through the 2013 Pyramid of Pain (opens in new tab).

The economics have since collapsed further. Phishing sites (opens in new tab) now have a median lifespan (opens in new tab) of roughly five hours after detection, and many phishing domains arrive through bulk registration (opens in new tab) that stands up lookalike domains (opens in new tab) in volume.

By the time an indicator reaches a feed, the attacker has often already abandoned it.

The campaign is the unit a defender can impose cost on

Campaign-level tracking gives defenders the unit that survives infrastructure turnover. MITRE ATT&CK (opens in new tab) campaign objects and the STIX 2.1 (opens in new tab) campaign definition already reflect this shift. STIX defines a campaign as adversarial behavior aimed at a specific set of targets with a defined objective, distinct from the intrusion set that runs many campaigns over time.

Take down one domain and the operator replaces it before the ticket closes. Take apart the connected domains, profiles, ad accounts, and phone numbers together, and the operator's standing infrastructure loses its value in one action.

Skip any one of those channels and the operation survives in whatever channel the enforcement missed, usually voice or messaging.

Five steps to a campaign-level threat intelligence program

Inside an indicator-era operating model, good teams can still produce intelligence their organization cannot act on. Four breaks keep intelligence from becoming action:

• Collection runs against no defined question, so every added source produces triage instead of clarity.
• Teams report success in indicators ingested and reports published, which tells a leader nothing about what changed.
• Output reaches the SOC and stops there, while fraud, legal, communications, and the executive team carry exposure they rarely receive intelligence on.
• The work ends at publication, and a published finding leaves the operation running.

Five steps close those gaps: write requirements with the stakeholders who carry the risk, map each requirement to the channels that can answer it, correlate signals into campaigns before an analyst sees them, match each output to the decision it supports, and close the loop into enforcement.

Step 1: write intelligence requirements with the stakeholders who carry the risk

Get security, fraud, legal, communications, and an executive sponsor in one room and write the requirements together. Expect the fraud team and the security team to disagree about what matters most, and treat that as the point: it surfaces the decisions each function is currently making without intelligence.

Write a few specific questions tied to decisions those people actually make, and retire a requirement when it stops earning its collection.

Programs mature in stages, and a two-person function running three well-scoped requirements outperforms a large team collecting everything. Teams that want a formal assessment can baseline against a public maturity model (opens in new tab).

Step 2: map every requirement to the channels that can answer it

Walk each requirement to the channels that carry its evidence, and name the gaps. A requirement about executive impersonation (opens in new tab) needs coverage on the social platforms and paid ad networks (opens in new tab) where it runs, because email telemetry alone cannot answer it.

The social engineering attack chain (opens in new tab) belongs in the channel map because attackers build and arm campaigns in the Setup and Launch stages, well before the Contact stage reaches your people. Collection that starts at Contact starts late.

Our guide to threat intelligence sources (opens in new tab) has the source-by-source detail on which channels answer which questions.

Step 3: correlate signals into campaigns before an analyst sees them

Correlation has to happen upstream of the queue, because at high alert volume (opens in new tab) analysts cannot reliably spot infrastructure reuse (opens in new tab) across channels without it. A domain registration, a fake profile (opens in new tab), and an ad account only reveal themselves as one operation when something links them before triage.

Platform selection belongs here, after the requirements and the channel map exist. Tooling chosen earlier ends up defining the program's questions for it.

Step 4: match each output to the decision it supports

Each intelligence output has to match the decision workflow of the team using it. The SOC needs indicators and playbooks it can load into existing tooling. The fraud team (opens in new tab) needs victim-flow detail showing how a scam moves a customer from lure to loss. Legal needs an evidence package that supports enforcement.

The executive team needs a campaign narrative that connects to business impact (opens in new tab). One report format serving all four serves none of them.

Step 5: close the loop from intelligence to enforcement and back

Route confirmed campaigns to coordinated enforcement (opens in new tab) across every channel they run on, then feed each outcome back into collection and correlation so the next campaign surfaces earlier. Enforcement generates intelligence a feed vendor cannot supply: how fast an operator rebuilds, and which registrar or page template they reuse.

This is the step that separates a program that reports from a program that costs the attacker something.

How to measure a threat intelligence program

A program earns renewal on evidence that it changed something, and most programs cannot produce that evidence: 57% track no maturity over time and 49% gather no structured feedback (opens in new tab) on their own effectiveness. Operational speed measures matter too, and our threat intelligence source (opens in new tab) guides cover that set.

Four measures evaluate the program itself.

• Decisions influenced. Which specific decisions changed because of an intelligence product, tracked against the requirement that prompted it.
• Requirement coverage. What share of your written intelligence requirements the program can currently answer, and which ones it cannot.
• Stakeholder adoption. Whether each audience you write for uses its output, established by asking them rather than counting deliveries.
• Requirement turnover. How often the program retires and rewrites requirements, which shows whether it is tracking the threat or its own plan.

The first two prove the program is answering the right questions. The second two prove the organization is using the answers. A program that cannot report all four is measuring its own activity.

Make the program something attackers feel

Security leaders should stop scoring the threat intelligence program on what it publishes and start scoring it on what it takes off the board. A program that ends in enforcement changes what it costs an attacker to target your organization, and every campaign it dismantles raises that cost again.

Request a Demo (opens in new tab) to see campaign-level defense run against live attacker infrastructure.