Cyber Threat Intelligence (CTI), explained.

A blocklist of a thousand malicious IPs is not threat intelligence. Neither is a news article about a ransomware gang, or a spreadsheet of file hashes someone downloaded from a feed. Those are all inputs. Cyber threat intelligence (CTI) is what you get after someone has evaluated those inputs, worked out which ones are relevant to your organization, corroborated them against other sources, and turned the result into something a specific person can act on — a CISO deciding where to spend budget, an incident responder deciding whether an alert is the same campaign as last week, or a detection engineer deciding what rule to write next. This article covers what CTI actually is, the four tiers that structure it, how IOCs relate to the broader discipline, the intelligence cycle CTI teams run, how intelligence is shared between organizations, and how it ultimately turns into detections mapped to MITRE ATT&CK.

Intelligence vs information

The word "intelligence" is not decoration. Raw information — an IP address, a leaked forum post, a vendor's blog about a new malware family — becomes intelligence only once it goes through a process: collection from a known source, evaluation of that source's reliability, correlation against what you already know, and analysis that answers a question someone actually asked. A pile of unverified IOCs sitting in a spreadsheet is not intelligence; it is a stockpile of potential intelligence, waiting to be processed. This distinction matters because it is also the difference between an indicator and the discipline that produces, curates, and contextualizes indicators. If you want the deep dive on indicator types themselves — file hashes, IPs, domains, mutexes, JA3 fingerprints — and the Pyramid of Pain that ranks how expensive each is for an attacker to change, see our dedicated article on indicators of compromise. This article stays one level up: CTI as the program and process that gives those indicators meaning.

The four tiers of CTI

The most useful way to organize threat intelligence is by who consumes it and how fast it needs to move. The industry generally splits CTI into four tiers, each with a different audience, timeframe, and output format:

Strategic intelligence answers "should we be worried, and about what?" It rarely names a specific IP address; it describes trends — a ransomware-as-a-service group expanding into a new sector, a nation-state actor shifting toward supply-chain compromise — in language a board can use to justify budget or risk appetite decisions. Operational intelligence sits a level down: it tracks a specific campaign or actor closely enough to inform decisions during an active incident, like whether the intrusion you are handling this week matches the tooling and objectives of a group already profiled elsewhere. Tactical intelligence is where CTI starts to look like engineering input — it describes exactly how an adversary behaves, in terms detection teams can build against, typically referencing specific MITRE ATT&CK technique IDs. Technical intelligence is the fastest and most perishable tier: the atomic IOCs that get pushed to firewalls, EDR, and SIEMs the moment they are validated, and that decay the fastest as attackers rotate infrastructure.

A mature CTI function produces all four, because they serve completely different decisions. A CISO does not need a hash; a firewall does not care about sector-wide trends. The tiers are not a hierarchy of importance — they are a hierarchy of speed and audience, and confusing them is one of the most common ways CTI programs fail to land with the people who need them.

IOC vs TTP: two different currencies

Technical and tactical intelligence deal in two fundamentally different kinds of evidence. An IOC is a specific, disposable artifact from one instance of an attack — this exact hash, this exact IP, this exact domain. It is precise and unambiguous, but cheap for an attacker to invalidate: recompile the binary and the hash changes, rent a new VPS and the IP changes. A TTP (tactic, technique, and procedure) describes how an adversary operates — their method of gaining initial access, escalating privileges, or moving laterally — independent of which specific tools or infrastructure they happen to be using today. Changing a TTP means re-engineering an entire operation, which is why TTP-based detection is far more durable than IOC-based blocking.

This is the same logic behind David Bianco's Pyramid of Pain, which ranks indicator types by how much pain you cause an adversary when you deny them — hashes and IPs at the bottom, TTPs at the top. We cover that model, along with a full catalogue of IOC types and examples, in indicators of compromise explained. The short version for CTI purposes: technical intelligence (IOCs) gives you fast, precise matches against known threats; tactical intelligence (TTPs) gives you resilience against variants of the same threat you have not seen yet. A CTI program that only ever produces IOC feeds is stuck permanently one step behind; one that also produces TTP-level analysis gives detection engineering something durable to build on.

The intelligence cycle, applied to threats

CTI teams do not collect indiscriminately — they run a structured loop, adapted from classical intelligence tradecraft, that keeps the work tied to actual decisions instead of becoming an open-ended hoarding exercise:

1. Planning and direction. Define the intelligence requirement: what decision does someone need to make, and what would they need to know to make it? "Are we a plausible target for this new ransomware affiliate?" is answerable. "Tell us about ransomware" is not.
2. Collection. Gather raw material against that requirement — internal telemetry from the SOC, open-source reporting, paid feeds, ISAC (Information Sharing and Analysis Center) bulletins, dark-web monitoring, and structured feeds via STIX/TAXII.
3. Processing. Normalize formats, deduplicate, translate, and extract entities so raw collection becomes something analysts can actually work with rather than a pile of disconnected reports.
4. Analysis and production. Correlate sources, weigh reliability, separate confirmed fact from inference, and write the actual product — a strategic brief, an operational assessment, a tactical TTP writeup, or a technical IOC package.
5. Dissemination. Deliver each product to the tier that needs it, in the format that tier can use — a board deck is not a SIEM feed, and neither should try to be the other.
6. Feedback. Consumers tell the CTI team whether the product actually answered their question, which reshapes the next cycle's requirements. This loop-back step is what keeps a CTI program relevant instead of producing reports nobody reads.

Confidence and source reliability

Not every piece of collected information deserves equal trust, and good CTI products say so explicitly. Many programs borrow the NATO-derived Admiralty Code (also called the Admiralty System), which scores a report on two independent axes: source reliability (A, completely reliable, through F, reliability cannot be judged) and information credibility (1, confirmed by other sources, through 6, truth cannot be judged). A report might carry a rating like "B2" — a usually reliable source, probably true but not yet independently confirmed. Whether or not a team uses that exact notation, the underlying discipline is universal: state your confidence, show your sourcing, and never let a single unverified report drive a high-stakes decision. This is also why analysis explicitly separates what is known from what is assessed — a habit that keeps strategic and operational products honest under scrutiny.

Threat intel feeds and sharing standards

An indicator or a piece of tradecraft discovered by one organization is far more valuable once others can act on it too, which is why threat intelligence sharing is a whole ecosystem built on common standards rather than ad hoc email attachments.

STIX and TAXII. STIX (Structured Threat Information eXpression) is the standardized, JSON-based language for describing threat intelligence objects — indicators, threat actors, malware, campaigns, attack patterns, and the relationships between them — so that intelligence from one organization means exactly the same thing when a different organization's tooling reads it. TAXII (Trusted Automated eXchange of Intelligence Information) is the transport protocol that moves STIX content between servers and clients over HTTPS. The shorthand is that STIX is the what and TAXII is the how; both live under OASIS governance, which keeps the format vendor-neutral.

Traffic Light Protocol (TLP). Sharing sensitive intelligence also requires agreeing on who is allowed to see it and pass it on. TLP, maintained by FIRST, marks each shared item with a simple color: TLP:RED means for the named recipients only, TLP:AMBER (and the stricter TLP:AMBER+STRICT) means limited to the recipient's organization, TLP:GREEN means shareable within the wider community, and TLP:CLEAR means unrestricted. It is a lightweight label, not a technical control, but it lets analysts pass sensitive campaign details between organizations without ambiguity about redistribution.

Platforms. MISP (Malware Information Sharing Platform) is the widely used open-source hub for storing, correlating, and sharing intelligence across trusted communities, importing and exporting via STIX/TAXII. OpenCTI is a newer open-source platform built natively around the STIX data model, structuring intelligence as a connected graph of indicators, actors, campaigns, and techniques rather than a flat list.

ISACs and feeds. Many industries run an Information Sharing and Analysis Center (ISAC) — sector-specific communities (financial services, healthcare, energy, and others each have one) where members share intelligence relevant to their shared threat landscape under agreed trust rules. Below that, free technical feeds round out the picture: the abuse.ch project's URLhaus, ThreatFox, and MalwareBazaar, along with AlienVault OTX and VirusTotal, supply the technical tier with a steady stream of validated indicators.

From CTI to MITRE ATT&CK-mapped detection

MITRE ATT&CK is the common vocabulary that lets tactical CTI turn directly into engineering work. Instead of a narrative paragraph like "the actor used a scheduled task to maintain access," a tactical CTI product tags that behavior with a specific technique ID — in this example, T1053.005 (Scheduled Task). That ID means the same thing to every team that consumes ATT&CK, which is what makes it possible to hand a report straight to a detection engineer instead of a lengthy translation exercise.

The handoff generally runs like this:

1. CTI identifies the technique. A tactical report describes an adversary's behavior and maps it to one or more ATT&CK technique IDs.
2. Detection engineering asks "what evidence does this leave?" For a scheduled-task persistence technique, that might be Windows Event ID 4698, or a new entry under the Task Scheduler's registry keys.
3. The engineer writes the rule. A Sigma rule expresses that log pattern in a platform-agnostic format that converts to a specific SIEM's query language; a YARA rule can separately catch the dropped payload or a memory artifact tied to the same technique.
4. The rule is tested and tuned against real telemetry to control false positives, then deployed to production detection content.
5. Coverage is tracked against the ATT&CK matrix itself, so the team can see at a glance which techniques they can actually detect and which remain blind spots — a practice often called ATT&CK-based detection coverage mapping.

This is the entire point of separating tactical intelligence from technical intelligence: an IOC gives you a detection for one attack instance, but a technique mapped to ATT&CK and turned into a behavioral rule gives you a detection for every future variant of the same behavior, even after the attacker has burned every hash and IP you knew about. For the mechanics of writing and testing those rules once CTI has identified the technique, see our companion article on Sigma and YARA rules explained.

Building a CTI capability

A CTI function does not require a large team to add real value. Most programs start small and layer sources over time: internal telemetry (what is actually hitting your own SOC) is usually the highest-signal source you have, because it is guaranteed relevant to you; open-source reporting and vendor blogs add breadth; paid feeds and ISAC membership add depth and earlier warning; and a platform like MISP or OpenCTI gives the team a place to store, correlate, and disseminate all of it consistently instead of scattering findings across spreadsheets and chat threads. The discipline that matters more than any tool is the intelligence cycle itself — tying every collection effort back to a specific requirement, and closing the feedback loop so the program keeps producing what its consumers actually need.

The takeaway

CTI is not a feed you subscribe to — it is a process that turns collected information into decisions, at four distinct speeds for four distinct audiences. Strategic intelligence shapes budget and risk appetite; operational intelligence shapes incident response; tactical intelligence, mapped to MITRE ATT&CK, shapes what detection engineers build; and technical intelligence, the fast-moving world of IOCs, shapes what gets blocked today. STIX and TAXII make it possible to move that intelligence between organizations in a common language, and the entire discipline exists to answer one question well: given everything we now know about how adversaries operate, what should we actually do about it?

Frequently asked questions