Threat intelligence that changes what you do

Why this matters

Threat intelligence has a bad reputation in some teams, and usually for a good reason: an expensive feed arrives, gets connected to the SIEM, produces alerts nobody can action, and becomes noise with an invoice attached.

The distinction this lesson draws is the one CS0-004 tests: intelligence is information that changes a decision you would otherwise make differently. Everything else is reading. The exam will give you scenarios where the right answer depends on knowing which kind you have, and how much confidence it deserves.

The lesson

Strategic, operational and tactical intelligence

Three levels, distinguished by who consumes them and over what timescale.

Strategic — for executives and risk owners, over months and years. Which threat actors target this sector, how ransomware economics are shifting, what regulatory change is coming. It informs budget and architecture, not alerts. Typically prose, not data.

Operational — for SOC leads and detection engineers, over weeks and months. A specific actor's tradecraft: how they gain access, which tools they favour, what they do after the foothold. This is the level that changes what you build: new detections, hunting hypotheses, hardening priorities.

Tactical — for analysts and machines, over hours and days. Concrete artefacts: addresses, domains, hashes, URLs, mail subjects. Immediately usable and shortest-lived.

The common mistake is buying tactical and expecting strategic outcomes. A feed of ten million indicators tells you nothing about whether your architecture is appropriate for the threats you face. The exam rewards matching the level to the question being asked.

Indicators, TTPs and the pyramid of pain

An indicator of compromise is an observable artefact. Tactics, techniques and procedures describe behaviour — how the actor operates.

The pyramid of pain ranks these by how much it costs an attacker when you detect at that level. From cheapest to most painful:

Two consequences follow, and they are the practical heart of this lesson.

Hash and address blocking is cheap to implement and cheap to defeat. It is still worth doing — it stops commodity attacks at no cost — but it is not a detection strategy.

Behavioural detection is expensive to build and expensive to evade. A detection for "web server process spawns a shell" survives every change of domain, address and binary, because the behaviour is what the attacker actually needs. That is why lessons 6 to 9 emphasised shape over artefact, and it is why the same emphasis appears in the hunting lesson next.

Applied to intelligence consumption: when a report arrives, the indicator appendix is the least valuable part and the behavioural description is the most valuable. Most teams use the appendix and skim the description, which is backwards.

Feeds, sharing communities and trust levels

Where intelligence comes from:

• Open source, freely published. Broad, variable quality, sometimes stale.
• Commercial, paid, usually with analyst-written reporting and better curation.
• Government and sector bodies, frequently sector-specific and often the most relevant to a regulated organisation.
• ISACs and sharing communities, where peers share what they are seeing. The most valuable intelligence available, because it comes from organisations that look like yours and is current.
• Internal. Your own past incidents are intelligence about who targets you specifically, and this is the most under-used source in most organisations.

Standards worth recognising by name: STIX for structured representation, TAXII for transport, MISP as a widely used sharing platform, and the Traffic Light Protocol for handling restrictions — TLP:RED through TLP:CLEAR governing who you may pass something to. Sharing something marked TLP:RED into a wider channel is a real breach of trust and an exam-worthy distinction.

On trust: intelligence should carry a source, a date and a confidence, and those should survive into your tooling. An indicator with no provenance cannot be triaged when it fires, because the analyst has no way to weigh it.

Confidence, ageing and why an old IOC misleads

Indicators decay, and decay is the most under-managed property in threat intelligence.

Why they go stale:

• Infrastructure is recycled. An address used for command and control last year is a legitimate hosting customer today. Cloud addresses rotate in hours.
• Domains expire and are re-registered, sometimes by an ordinary business.
• Shared infrastructure. A CDN address or a popular hosting provider serves thousands of benign sites alongside anything malicious.
• Hashes change on every rebuild.

The costs of not managing this are both false positives — analysts burning time on a match against a recycled address — and, worse, credibility damage, the same effect a bad correlation rule has in lesson 10. After enough noisy intelligence matches, analysts stop reading them.

What good practice looks like:

• Every indicator has an expiry, explicit or derived from its type. Hashes can persist; addresses should be measured in weeks at most.
• Confidence is recorded and used, so a high-confidence match escalates and a low-confidence one enriches quietly.
• Context travels with the indicator. "Address associated with actor X command and control, observed 2026-08-14, confidence medium" lets an analyst triage in seconds. A bare address does not.
• Enrich rather than alert for large feeds. Tag matching events so they surface during investigation, rather than generating an alert per match.
• Retrospective search when new intelligence arrives. Ask whether this indicator appeared in the last 90 days of your data. That question routinely finds intrusions nobody knew about, and it is the single most valuable automated use of a feed.

Turning intelligence into a detection

The step that separates intelligence programmes that matter from ones that produce reading material.

A workable process for a new report:

1. Ask whether it is relevant. Does this actor target your sector, region or technology? Many reports are genuinely interesting and not about you.
2. Extract the behaviours, not just the artefacts. How did they gain access, persist, move, exfiltrate?
3. Check coverage. For each behaviour, do you have the telemetry to see it, and a detection that would fire? This is the gap analysis covered in the frameworks lesson.
4. Look backwards first. Run the indicators and behaviours against historical data before building anything. Discovering you were already affected changes the priority entirely.
5. Build the detection at the highest level of the pyramid you can afford. Prefer the behaviour; use the artefacts as enrichment.
6. Test it in the lab, and record what the false-positive rate looks like before it reaches the live queue.
7. Write down what you decided not to do, and why. A report where the answer was "not relevant to us" is a decision worth being able to defend later.

That last step matters more than it looks. When a breach makes the news and someone asks whether you knew about this actor, the useful answer is a dated record showing you assessed it and why you concluded what you did — which is exactly the kind of reporting the final lessons of this course are about.

Topics this lesson owns

• [x] Strategic, operational and tactical intelligence
• [x] Indicators, TTPs and the pyramid of pain
• [x] Feeds, sharing communities and trust levels
• [x] Confidence, ageing and why an old IOC misleads
• [x] Turning intelligence into a detection