Most threat intelligence programmes produce one measurable output: PDF reports that nobody reads. A glossy weekly brief lands in an inbox, gets skimmed, and changes nothing about how the organisation detects or responds to attacks. That is not intelligence, it is journalism. Real cyber threat intelligence (CTI) ends in a changed control: a new detection rule, a tuned alert, a blocked indicator, a hunt hypothesis. This article lays out how to build a CTI programme whose success metric is detections shipped, not reports published.
The intelligence lifecycle, used honestly
The classic intelligence lifecycle is direction, collection, processing, analysis, dissemination, and feedback. The step that gets skipped is the first one and the last one. Teams jump straight to collection (buy feeds, ingest everything) and never close the feedback loop to see whether anything they produced was used.
Direction means defining what decisions the intelligence must support before you collect a single indicator. Feedback means measuring whether the consumers (the SOC, detection engineers, incident responders, leadership) actually acted on what you delivered. If you cannot point to detections that exist because of CTI, the lifecycle has a broken loop, and the fix is almost always at the direction and feedback ends, not in buying another feed.
Prioritised intelligence requirements come first
Prioritised Intelligence Requirements (PIRs) are the questions your programme exists to answer. Without them, CTI defaults to reporting on whatever is loudest in the news, which is rarely what threatens you. Good PIRs are specific to your sector, geography, technology stack, and crown-jewel assets.
- Which ransomware affiliates are actively targeting our industry and region, and what initial access vectors do they use?
- What techniques are adversaries using against the specific identity provider and cloud platform we run?
- Which of our internet-facing technologies have exploited-in-the-wild vulnerabilities right now?
- Are our brand, executives, or credentials being discussed or sold on criminal forums?
PIRs turn an infinite intake problem into a finite one. They tell collection what to gather and analysis what to prioritise, and they give you a yardstick to kill feeds and sources that answer none of them.
Map adversary behaviour to MITRE ATT&CK
Indicators of compromise (IP addresses, domains, file hashes) are the lowest, most perishable form of intelligence. An adversary rotates infrastructure in hours. What persists is behaviour: how they gain access, escalate, move laterally, and exfiltrate. MITRE ATT&CK is the common language for that behaviour, and it is what makes intelligence durable enough to drive detections.
When you read a threat report, do not stop at the IOC table. Extract the tactics, techniques, and procedures (TTPs) and map them to ATT&CK technique IDs. A report describing an actor using valid accounts (T1078), then abusing a remote service (T1021), then exfiltrating over a web service (T1567) tells you exactly which behaviours to detect, regardless of which IP they use next week. Maintaining an ATT&CK heat map of techniques relevant to your PIRs also exposes your detection gaps at a glance: techniques adversaries use that you have no coverage for.
The CTI-to-detection pipeline
This is where most programmes break and where the value lives. A pipeline that turns intelligence into detections has a few clear stages.
Triage and enrichment
Incoming intelligence is filtered against PIRs, deduplicated, and enriched with context: confidence level, source reliability, relevance to your environment, and ATT&CK mapping. Low-confidence, irrelevant noise is dropped here, not pushed downstream to drown the SOC in false positives.
Decision: block, detect, or hunt
For each piece of actionable intelligence, decide its destiny. High-confidence atomic indicators with low false-positive risk can be pushed to blocklists in firewalls, DNS filtering, or endpoint controls automatically. Behavioural intelligence becomes a detection rule. Lower-confidence or novel behaviour becomes a hunt hypothesis rather than an always-on alert.
Detection engineering
This is the craft of converting a TTP into a reliable rule for your SIEM or XDR. A good detection has a clear hypothesis, is tested against both true and false positives, includes the ATT&CK mapping in its metadata, and ships with response guidance so the analyst who receives the alert knows what to do. Detections should be version-controlled and tested as code, the same way software is, so coverage is auditable and regressions are caught.
Threat hunting on the gaps
Where you cannot write a deterministic rule, intelligence feeds proactive hunts. The hunter takes a behavioural hypothesis (this actor uses scheduled tasks for persistence) and searches historical telemetry for evidence. Successful hunts frequently graduate into new detection rules, closing the loop.
This pipeline is exactly the engine behind a mature managed detection and response service, where intelligence is continuously converted into tuned detections rather than delivered as a monthly slide deck.
Measuring a programme that works
Stop counting reports published and feeds ingested. Measure outcomes that show intelligence is changing the environment.
- Number of new detections shipped from intelligence per quarter, and their true-positive rate.
- ATT&CK technique coverage against your prioritised techniques, trending up over time.
- Time from a relevant threat report to a deployed detection or block.
- Hunts run from intelligence and findings that graduated into permanent detections.
- Consumer feedback: did the SOC and IR teams act on what was delivered?
Takeaways
- CTI that ends in a PDF has failed. The output of intelligence is a changed control.
- Define prioritised intelligence requirements before buying feeds, so collection is finite and relevant.
- Map adversary behaviour to MITRE ATT&CK, because TTPs outlast indicators.
- Build an explicit pipeline that routes intelligence to block, detect, or hunt, with detection engineering at its core.
- Measure detections shipped and ATT&CK coverage, not reports published.
If your threat intelligence is generating reports but not detections, talk to Basalt Cyber about wiring CTI into your detection and hunting workflow.