CTI Foundations

What Is Threat Intelligence?

Threat intelligence is analyzed information about adversaries and their capabilities that enables better security decisions. That definition has three load-bearing words. Analyzed means raw data has been processed and interpreted, not just collected. Adversaries means the focus is on human actors with intent, not generic vulnerability data. Decisions means intelligence exists to reduce uncertainty at a specific choice point, whether blocking an IP, escalating an alert, or briefing an executive on sector risk.

The intelligence community distinguishes between data, information, and intelligence. Data is unprocessed observations: log lines, packet captures, domain registration records. Information is data that has been parsed and structured into something meaningful: a domain registered to a known hosting provider in a country associated with threat activity. Intelligence is information that has been analyzed, contextualized, and assessed against a specific question: "Is this domain part of the actor campaign our IR team is working? What is the confidence level? What should we do?"

Most of what gets called threat intelligence in vendor feeds is actually data or information. A file hash list is data. An IP reputation score is information. A finished analysis explaining which APT group is using a specific toolset, what their targeting patterns look like in your sector, and which TTPs to prioritize for detection is intelligence. The difference is not pedantic. Analysts who treat raw feeds as finished intelligence make worse decisions and waste triage time on low-confidence, decontextualized indicators.

The Intelligence Cycle

The intelligence cycle is the repeating process through which raw collection becomes finished intelligence and eventually feeds back into new requirements. Most frameworks break it into five or six phases. The specifics vary by organization, but the core sequence is consistent: requirements drive collection, collection feeds processing, processing enables analysis, analysis produces dissemination, and dissemination generates feedback that refines requirements.

Direction is where the cycle begins. Someone with a decision to make articulates what they need to know. These are formalized as Priority Intelligence Requirements (PIRs) or Standing Intelligence Requirements (SIRs). A SOC team might define: "What are the current active C2 infrastructure ranges for ransomware groups targeting healthcare?" A CISO preparing for a board meeting might need: "What is the current threat landscape for financial institutions in APAC?" The specificity of the requirement determines how useful the eventual intelligence will be.

Collection is the systematic acquisition of raw data that could answer the requirement. Sources include open-source intelligence (OSINT) such as public threat reports, vendor advisories, and social media; commercial intelligence feeds from providers like Recorded Future, Mandiant, or CrowdStrike; technical sources such as malware sandbox analysis, network traffic, and honeypot data; and human sources including ISAC sharing communities and vendor briefings.

Processing converts raw collection into something analyzable. This includes parsing structured data, translating foreign-language reports, normalizing IOC formats, and deduplicating entries across feeds. A significant portion of CTI team time goes into processing work that never appears in finished products but determines whether analysis is possible at all.

Analysis is where collected information becomes intelligence. An analyst applies context, draws connections, assesses confidence, identifies gaps, and produces an assessment. This is the cognitive core of CTI work. Good analysis requires knowing what you do not know as clearly as what you do, and communicating both.

Dissemination delivers the finished intelligence to the consumer in a format they can act on. Timing matters. A report about an active campaign delivered three days after the actor moved off that infrastructure is useless. Format matters. An executive brief with 40 IOC appendices will not be read. Feedback from consumers closes the loop: did the intelligence support the decision? What was missing? What should be prioritized next cycle?

Types of Intelligence

Intelligence is commonly divided into four types based on the time horizon and consumer it serves. Each type requires different sources, different analytical techniques, and different output formats. Conflating them is one of the most common failures in CTI programs: a team producing only tactical IOC feeds for a CISO is not serving that audience, and a team producing only strategic assessments for a SOC is leaving analysts without actionable data.

Strategic intelligence serves senior decision-makers: CISOs, boards, and executive teams. It operates on long time horizons, covering trends across months or years. It answers questions like: "Is our sector being targeted more frequently than last year? Are nation-state actors shifting their focus toward our supply chain?" Strategic intel rarely contains IOCs. It contains assessments, trend lines, and recommendations. The consumer uses it to allocate budget, adjust security programs, and communicate risk to stakeholders.

Operational intelligence serves security managers, incident response leads, and threat hunt teams. It covers active campaigns and ongoing adversary operations on a time horizon of weeks to months. It answers: "There is an active ransomware campaign targeting mid-size logistics companies using a specific initial access vector. Here is what we know about the actor, the delivery mechanism, and the affected regions." Operational intel helps teams prioritize hunts, plan IR exercises, and scope defenses against current campaigns.

Tactical intelligence is where most SOC analysts work. It covers specific adversary TTPs: the techniques, tools, and procedures an actor uses. Time horizon is days to weeks. It answers: "This actor uses T1059.001 (PowerShell) with a specific base64 encoding pattern and drops a RAT to C:\Users\Public\svchost.exe before making a beacon to a DGA domain." Tactical intel feeds directly into detection rule development, hunt hypotheses, and IR playbook updates.

Technical intelligence is the most granular tier: individual IOCs such as IP addresses, file hashes, domains, and URLs. Time horizon is hours to days. A malicious IP that was active yesterday may be abandoned or repurposed today. Technical intel is high-volume, fast-decaying, and requires automated processing to be useful. It feeds SIEM blocklists, firewall rules, and EDR deny lists. It is the tier most commonly mislabeled as "threat intelligence" when it is really just data.

The TLP Framework

Traffic Light Protocol (TLP) is the sharing classification system used across the security community to control how intelligence can be distributed. It was developed by FIRST (Forum of Incident Response and Security Teams) and has become the de facto standard. Every piece of shared intelligence should carry a TLP marking. Understanding TLP is required before engaging in any sharing community, ISAC, or intel exchange.

TLP:CLEAR means information can be distributed without restriction. The source has assessed that public release creates no harm. Public threat reports, blog posts, and vendor whitepapers typically carry TLP:CLEAR or no marking at all. When you receive TLP:CLEAR material you may share it, publish it, and reference it openly.

TLP:GREEN means information is appropriate for the community but not for public release. ISACs and sector sharing groups typically operate at TLP:GREEN. You can share it with peers in your sector and your organization, but not with media, public forums, or parties outside the relevant community. When in doubt about who counts as "community," ask the source before sharing.

TLP:AMBER means sharing is limited to the recipient organization and its clients. This marking appears on vendor briefings, incident-specific reporting, and intelligence about active campaigns that could harm third parties if widely disclosed. You may share within your organization on a need-to-know basis but should not distribute externally without explicit permission from the originating source.

TLP:AMBER+STRICT narrows distribution further to the immediate recipient only. It does not extend to clients or subsidiaries. This is used when the source has a specific reason to limit distribution even within the recipient organization.

TLP:RED means not for disclosure outside the specific individuals or group it was shared with. This classification typically covers highly sensitive information about active nation-state operations, unpatched zero-days, or ongoing law enforcement actions. Mishandling TLP:RED material can compromise ongoing investigations or harm victims.

Intelligence Requirements

Intelligence requirements are formal statements of what a consumer needs to know to make a decision. They are the mechanism that prevents CTI programs from producing interesting-but-useless research. Every CTI product should trace back to a documented requirement. If it does not, the team is doing analysis for its own sake rather than serving the organization.

Priority Intelligence Requirements (PIRs) are the highest-priority questions an organization needs answered. A PIR might be: "What threat groups are currently targeting critical infrastructure in our region, and what initial access vectors are they using?" PIRs are set by organizational leadership in consultation with the security team and are revisited regularly, usually quarterly. They define what the CTI team collects against and what gets resourced.

Specific Intelligence Requirements (SIRs) are sub-requirements that must be answered to satisfy a PIR. If the PIR asks about initial access vectors for regional threat groups, SIRs would include: "What phishing lure types does this actor group use?", "What exploit does the group use for internet-facing appliances?", and "What are the known C2 protocol signatures for the group's toolset?" SIRs guide specific collection tasks and analysis efforts.

Requests for Information (RFIs) are ad-hoc requirements from consumers outside the normal PIR process. An incident responder on an active case might RFI: "Do you have any intel on infrastructure tied to this IP range or this file hash pattern?" RFIs are time-sensitive and should be triaged quickly: can this be answered from existing collection, or does it require new tasking? RFIs that recur frequently are candidates for elevation into standing SIRs.

The discipline of requirements management prevents a common CTI anti-pattern: the team that tracks everything interesting but produces nothing actionable. Every hour spent collecting and analyzing something should be justified by a requirement. When it is not, the team is building reports no one will read and missing the questions that actually matter to the organization.

What This Module Covers

Eight chapters build a complete CTI practitioner skill set from vocabulary through production-grade output. Chapter 1 (this chapter) establishes the foundational concepts: intelligence vs data, the intelligence cycle, the four types, TLP, and requirements. These are the concepts everything else builds on.

Chapter 2 covers IOC types and confidence scoring. Not all indicators are equal, and treating a file hash the same as a TTP is one of the most common analytical errors. Chapter 3 covers threat actor profiling using the Diamond Model, ATT&CK Groups, and naming conventions across vendors. Chapter 4 covers structured sharing: STIX 2.1, TAXII, MISP, and how to participate in a trust community without creating liability for yourself or your organization.

Chapter 5 bridges CTI and threat hunting directly: how to take a finished intelligence report and produce hunt hypotheses, pivot chains, and search queries from it. Chapter 6 covers malware and campaign intelligence: reading sandbox reports, clustering samples to campaigns, and writing basic YARA rules from behavioral analysis. Chapter 7 covers CTI report writing: how to produce finished intelligence products that executives will read and analysts can act on. Chapter 8 closes the loop by covering how to convert intelligence directly into detection rules, ATT&CK coverage mappings, and tuned Sigma/KQL queries.