IOC ≠ Intelligence: Turning Indicators into Decisions

A blocklist of forty thousand entries is not forty thousand pieces of intelligence. It may not be any. Whether it is depends on properties that the list itself, in almost every format in common use, does not carry.

This is about those properties: what has to travel with an indicator for it to support a decision, what breaks when it does not, and why the indicator layer — the cheapest and most automatable part of threat intelligence — reliably consumes the largest share of budget while producing the least durable value.

What an indicator is missing

Take a single line from a feed:

185.220.101.47

To decide anything, a defender needs to know at least the following, and the bare string carries none of it:

Question	Why the decision depends on it
Who observed it, and where?	A sinkhole, a customer network, and a researcher’s honeypot imply entirely different things
When was it first and last seen?	Adversary infrastructure has a lifespan; a stale address is a false-positive generator
What was it doing?	C2, scanning, phishing delivery and Tor egress warrant different responses
How reliable is the source?	Admiralty grading exists because sources are not interchangeable
How credible is this specific claim?	A reliable source can report something improbable
Is it dedicated or shared?	A CDN edge, a cloud NAT, or a Tor node blocks thousands of innocent sessions
When should it stop being enforced?	Without expiry, blocklists accumulate into permanent false-positive debt
What did it corroborate, and independently?	Five aggregators republishing one claim is one claim

Strip these and what remains is an observation someone once made, in circumstances now unknown, about a resource that may since have changed hands. Enforcing on it is not a decision; it is a reflex.

The technical failure is worth naming precisely, because it is invisible at every stage that follows: a record can pass through a pipeline intact and still arrive unusable, because the pipeline preserved the value and discarded the context that made the value assessable. Every downstream stage then runs normally and produces confident output that cannot be defended.

The cost of the cheap end

David Bianco’s Pyramid of Pain ranks indicator types by what it costs the adversary when you detect them. Hashes and IP addresses sit at the bottom: a recompile, a new server. TTPs sit at the top: retraining an operator and changing how they work.

Feeds deliver the bottom of the pyramid, because the bottom is what can be produced automatically and at volume. That produces a specific and very common organisational pattern:

1. Detection is judged inadequate.
2. More feeds are purchased, raising indicator volume substantially.
3. Detection does not improve, because the added indicators are of the type the adversary discards without noticing.
4. False positives increase, because volume rose and expiry did not.
5. Analyst trust in the feeds declines, so alerts from them are deprioritised.
6. Detection is judged inadequate.

Nobody in this loop does anything unreasonable. The loop is a property of buying the cheap tier at scale and expecting behavioural-tier results from it. Moving up the pyramid requires analysts rather than pipelines, which is exactly why the results are defensible and exactly why it is rarely funded.

Decay is the property that gets ignored

Indicators are not facts; they are observations about a state of the world that changes. Rough working lifespans:

• File hashes — dead the moment a single byte changes. Useful for retrospective hunting and for confirming a specific sample, nearly useless as a forward-looking block.
• Adversary-controlled IPs — days to weeks. Then the address is reassigned, often to someone entirely uninvolved.
• Domains — weeks to months, unless the registration was disposable, in which case days.
• Network and host artefacts — months, because changing them costs retooling.
• TTPs — years, because changing them costs retraining.

A blocklist without expiry does not merely go stale. It accumulates entries that were once correct and are now wrong, generating alerts that are indistinguishable in the console from real ones. The cost lands on the analyst queue, where it is experienced as noise rather than as the consequence of a retention policy nobody wrote.

The uncomfortable implication: an indicator with no expiry date is not intelligence with an omission. It is a liability with a delay fuse. Every indicator should arrive with a review-by date, and a pipeline should be able to answer, at any moment, the median age of the indicators currently enforcing in production. Very few can.

The decision is the unit, not the indicator

The reframe that changes practice: stop asking how many indicators do we have and start asking what decision does this support, for whom, and for how long.

Concretely, an indicator becomes intelligence when it can be expressed in this form:

Because <observation> from <source, graded> seen <when> doing <what>, we assess with <confidence> that <implication>. Recommend <action> until <review date>. This assessment would be overturned by <falsifier>.

Every clause is doing work, and the last one is the clause most often absent. An assessment that cannot name what would refute it has not been reasoned to — it has been arrived at. It is also the clause that makes the difference between an indicator you can revisit and one that becomes permanent by default.

Note what the form implies about volume. It is not possible to produce forty thousand of these. That is the point. The pipeline can process forty thousand observations; the intelligence function issues the small number of assessments those observations support. Conflating the two is how a team ends up measuring its output in records and its value at zero.

Where indicators genuinely earn their place

None of this is an argument against indicators. They do three jobs extremely well, and all three are automation-shaped:

Retrospective hunting. A hash or domain that is useless as a forward block is excellent for asking were we exposed to this in the last ninety days? Decay does not matter when the question is historical.

Enrichment rather than enforcement. An indicator attached to an existing alert as context — this address appeared in reporting on campaign X six weeks ago — costs nothing in false positives and materially improves triage. This is the highest-yield use and the most under-exploited.

Pivot points. One confirmed indicator leads to infrastructure, which leads to clustering, which leads up the pyramid. Here the indicator is not the product; it is the thread.

What indicators do badly is stand alone as an enforcement decision with no context, no confidence, and no expiry. Which is, in most organisations, the primary way they are used.

A short diagnostic

Six questions. A programme that cannot answer them is running an indicator pipeline rather than an intelligence function — and the distinction is not semantic, it is the difference between spending on volume and spending on decisions.

1. What is the median age of indicators currently enforcing in production?
2. What proportion of indicators in the pipeline carry a source grade and a first-seen timestamp that survived to the point of enforcement?
3. Which detections in production trace to a specific intelligence product?
4. How many enforced indicators have a review date, and what happens on that date?
5. When an indicator turns out to be a false positive, what changes upstream?
6. Of the corroborated findings, how many were corroborated from genuinely independent origins rather than from copies of one source?

Question six is the one that most often produces an uncomfortable silence, and it is mechanical to fix: record, for every claim, the earliest origin reachable, and give downstream copies zero additional weight. cti-confidence implements exactly that counting rule, and reports the inflation factor a naive count would have produced.

Status

A working framework rather than a finished publication. The pipeline this sits inside is described in From OSINT Collection to Actionable Cyber Threat Intelligence, and the measurement problems it depends on in Measuring Blind Spots in Intelligence Collection.