Cyber threat intelligence: a practical CTI lifecycle

Cyber threat intelligence (CTI) is threat knowledge prepared for a specific decision. A list of IP addresses is not intelligence. Value appears when a team knows who the information concerns, why it matters and what action should follow.

NIST SP 800-150 describes cyber-threat information sharing. Operationally, run CTI as a repeatable lifecycle: requirements, collection, processing, analysis, dissemination and feedback.

Begin with requirements

Priority Intelligence Requirements should follow the organisation’s profile. A payment provider may focus on groups targeting APIs and identity, a manufacturer on espionage and supply chains, and a hospital on ransomware and disruption.

A good requirement is bounded, has an audience and a time horizon. “What are hackers doing?” fails those tests. “Which initial-access techniques are groups targeting European logistics companies using this quarter?” is actionable.

Collection and processing

Combine internal EDR, email, IAM, DNS, vulnerability and incident data with material from CERTs, CISA, vendors and trusted communities. Rate source reliability separately from information probability.

Normalise timestamps, domains, addresses and identifiers. Deduplicate and record when an indicator was observed. An old IOC without context creates cost, while blocking an address used by shared cloud infrastructure can disrupt legitimate traffic.

Analysis: beyond indicators

IOCs decay quickly. Techniques and procedures described in MITRE ATT&CK often retain value longer. Map hypotheses to telemetry: which event would support the technique, where should it be logged and what visibility is missing?

An assessment should state confidence, evidence, alternative explanations and limitations. Keep observed fact separate from analytical judgement.

Tailor dissemination

The SOC needs detection logic and priorities. Vulnerability Management needs affected technologies and evidence of exploitation. Executives need business scenarios, trends and investment decisions. One report cannot serve every audience.

CTI should feed purple-team tests and architecture reviews. Detection results should flow back to analysts.

Outcome-based metrics

Measure time from intelligence receipt to detection deployment, reports that lead to a decision, telemetry coverage of priority techniques and alert precision. The number of feeds ingested is a cost, not an outcome.

Ask recipients whether the material changed a priority, control or response. Retire or revise requirements that support no decision.

A minimal CTI cycle

1. Define audiences and requirements.
2. Select sources relevant to those questions.
3. Normalise, deduplicate and assess the data.
4. Analyse behaviour, context and alternatives.
5. Deliver in a format the recipient can use.
6. Collect feedback and measure decisions.
7. Update requirements as threats change.

Effective CTI does not attempt to know everything. It shortens the path from a credible signal to a better defensive decision.

---

From information to a decision

A useful CTI product answers an agreed question. For the SOC that may be behaviours to detect; for vulnerability management, technologies being exploited in its sector; for leadership, changed risk to a named service. An IOC feed loses value quickly without time, source, confidence and behavioural context.

Label confidence and separate observed facts from analytic judgement. Measure feedback through action: a new detection, changed patch priority, exercise or architecture decision. ATT&CK helps describe behaviour, but mapping a technique does not establish attribution.

Assess a source by access to data, accuracy history, motivation and independence. Two outlets repeating one notice are not independent confirmation. Preserve observation and publication dates because an indicator may be historically correct yet useless for blocking today.

Sources: NIST SP 800-150, MITRE ATT&CK, CISA — Information Sharing.