Cyber Threat Intelligence: The Definitive Guide — From Fundamentals to Advanced Operations

Cyber Threat Intelligence (CTI) is the discipline of collecting, processing, and analyzing information about threats — and turning that analysis into actionable intelligence that defenders can use. But real CTI is far more than an IoC feed. It is the difference between reacting to alerts and anticipating attacks.

I’m Reza Rafati, and I’ve spent over a decade doing this work — from malware reverse engineering in the lab to domain takedowns in the field, from building threat feeds to briefing boards. At Threat Intelligence Lab, our mission is to make CTI accessible, actionable, and operationally relevant. This guide is the resource I wish I had when I started. It is written for practitioners, by a practitioner.

Whether you’re a SOC analyst trying to understand what makes intelligence different from data, a security manager building your organization’s first CTI program, or an executive who needs to know what threat intelligence can actually deliver — you’ll find your answers here. Take your time. This is a long read, and that’s by design. Threat intelligence is a deep discipline, and surface-level understanding leads to surface-level defenses.


What Is Cyber Threat Intelligence — Really?

Let’s start with a clear definition. Cyber Threat Intelligence is evidence-based knowledge about existing or emerging threats to assets. The key word is evidence-based. CTI is not speculation, not headlines, not fear. It is the product of a rigorous process that transforms raw data into understanding — and understanding into action.

There’s an important distinction that many people miss: data is not intelligence. A list of malicious IP addresses is data. Knowing who is using those IPs, what their objectives are, how they operate, and — crucially — what you should do about it: that’s intelligence.

“The goal of threat intelligence is to provide decision-makers with the context, timing, and confidence they need to act — before the adversary succeeds.”

— Reza Rafati, Threat Intelligence Lab

In practice, CTI answers questions like:

  • Who is targeting our industry, our geography, our organization?
  • What tactics, techniques, and procedures (TTPs) do they use?
  • When are they most active, and what triggers their campaigns?
  • Where are our vulnerabilities that they’re most likely to exploit?
  • Why are they attacking us — financial gain, espionage, disruption?
  • How can we detect, prevent, and respond effectively?

Notice that these questions move from the tactical to the strategic. Good CTI does the same — it serves every level of your organization, from the SOC analyst who needs a detection rule right now to the board member planning next year’s security budget.

The Intelligence Cycle: How Threat Intelligence Is Produced

Intelligence is not magic. It’s a repeatable process. The intelligence cycle — adapted from military and government intelligence methodology — gives us a structured way to produce reliable, actionable intelligence consistently. Here’s how it works in the cyber domain:

The Cyber Threat Intelligence Lifecycle diagram showing six phases
Figure 1: The six-phase Cyber Threat Intelligence Lifecycle — a continuous, iterative process.

Phase 1: Direction — Defining What You Need to Know

Every intelligence effort begins with a question. Without clear requirements, you’ll drown in data. The Direction phase is about defining your intelligence requirements (IRs) — the specific questions that intelligence must answer.

I typically break requirements into three categories:

  • Priority Intelligence Requirements (PIRs): The big strategic questions. “Which threat actors are most likely to target our intellectual property in the next 12 months?”
  • Essential Elements of Information (EEIs): Specific data points needed to answer PIRs. “What malware families has APT29 deployed against our sector?”
  • Requests for Information (RFIs): Tactical, time-bound questions from operational teams. “Is this suspicious domain associated with the phishing campaign we saw yesterday?”

Practitioner tip: The most common mistake I see is skipping this phase entirely — teams start collecting everything they can find without knowing what they’re looking for. That’s not intelligence. That’s hoarding. Start every CTI effort by writing down what you need to know and why.

Phase 2: Collection — Gathering Raw Data from Every Available Source

Collection is where you gather the raw material. I categorize sources into five broad buckets:

Source TypeExamplesTypical Value
Internal TelemetryFirewall logs, EDR alerts, proxy logs, DNS queries, email gatewaysHighest — shows what’s actually hitting your environment
Open Source (OSINT)Security blogs, research papers, social media, paste sites, public sandboxesHigh — free, abundant, but requires heavy curation
Commercial FeedsVendor threat feeds, paid intelligence platforms, API integrationsMedium-High — curated but can be noisy or generic
Closed SourcesISAC/ISAO sharing groups, industry partnerships, private forumsHigh — trusted peers sharing vetted intelligence
Human Intelligence (HUMINT)Conference conversations, dark web monitoring, law enforcement liaisonVariable — hard to obtain but often uniquely valuable
Table 1: The five primary CTI collection source categories.

My golden rule of collection: Never rely on a single source for critical judgments. I always seek at least two corroborating sources before considering intelligence “confirmed.” The most dangerous intelligence failure is acting on single-source information that turns out to be wrong.

Phase 3: Processing — Turning Raw Data into Structured Information

Raw data is messy. Logs come in different formats. Feeds use different taxonomies. Reports are unstructured text. Processing is where you normalize, structure, enrich, and deduplicate everything so it becomes usable.

This phase typically involves:

  • Normalization: Converting disparate formats into a common schema (e.g., STIX 2.1)
  • Enrichment: Adding context — WHOIS lookups, passive DNS, VirusTotal lookups, geolocation
  • Deduplication: Removing duplicate indicators that come from multiple sources
  • Scoring/Confidence: Assigning preliminary confidence levels to indicators based on source reliability
  • Tagging: Applying structured labels (threat actor, campaign, malware family, sector, etc.)

Automation is essential here. Manual processing doesn’t scale. A well-tuned Threat Intelligence Platform (TIP) can handle the heavy lifting, freeing analysts for the high-value work that comes next.

Phase 4: Analysis — The Heart of Intelligence

This is where the magic happens — and where human judgment is irreplaceable. Analysis is the process of evaluating processed information, identifying patterns, testing hypotheses, and forming assessments with confidence levels.

I use structured analytic techniques that I learned from both the intelligence community and years of practical incident response. Here are the core methods I rely on:

  • Structured Analysis of Competing Hypotheses (ACH): List all possible explanations for observed activity and systematically evaluate evidence for and against each. The hypothesis with the most consistent evidence and fewest contradictions wins — not the one that “feels right.”
  • Diamond Model of Intrusion Analysis: Map every incident across four nodes — Adversary, Capability, Infrastructure, Victim. This reveals gaps in your understanding and shows you what intelligence you’re missing.
  • Kill Chain Analysis: Map adversary activity to stages of the attack lifecycle (reconnaissance, weaponization, delivery, exploitation, installation, C2, actions on objectives). Identify where in the chain you can detect or disrupt them.
  • Pivot Analysis: Start with one known indicator and explore connections — what other domains resolve to this IP? What other samples use this code signing certificate? Pivoting reveals the adversary’s broader infrastructure.

Critical mindset: Every analyst brings bias. Confirmation bias — favoring evidence that supports your existing beliefs — is the enemy of good intelligence. I actively seek out evidence that disconfirms my hypotheses. If you can’t find any, your analysis isn’t rigorous enough.

Phase 5: Dissemination — Getting Intelligence to the Right People, in the Right Format

Intelligence that sits in a report that nobody reads is wasted effort. Dissemination is about delivering the right intelligence, to the right audience, at the right time, in the right format.

Different consumers need different products:

  • Board/Executives: One-page strategic briefs. Business risk, financial impact, high-level trends. No technical jargon. Clear recommendations they can act on.
  • Security Managers: Operational reports. Campaign timelines, threat actor profiles, control effectiveness assessments. Context to prioritize resources.
  • SOC Analysts: Tactical alerts, detection rules, SIEM signatures. Fast, machine-readable, directly actionable. Context on why this alert matters.
  • Automated Systems: Structured feeds (STIX/TAXII, JSON, CSV). Blocklists, detection logic. No prose — just structured data for automated ingestion.

Key principle: I follow a “three-click rule” — any intelligence product should require no more than three clicks from delivery to the consumer understanding what action they need to take. If they need to dig through four appendices to find the actionable item, you’ve failed at dissemination.

Phase 6: Feedback — Closing the Loop for Continuous Improvement

The cycle doesn’t end with dissemination — it loops back. Feedback from consumers tells you whether your intelligence was accurate, timely, relevant, and actionable. Without feedback, you’re flying blind.

I recommend structured feedback collection:

  • Did the intelligence lead to a defensive action? (Yes/No — binary and trackable)
  • Was the intelligence timely? (Did it arrive before or after the threat materialized?)
  • What was the operational outcome? (Blocked attack, patched vulnerability, changed policy)
  • What would have made the intelligence more useful? (Different format, different depth, different focus)

Track these metrics over time. A CTI program that doesn’t measure its own effectiveness is a CTI program that can’t justify its budget.


The Four Levels of Threat Intelligence: Who Needs What

Not all threat intelligence serves the same purpose. The classic framework — adapted from military doctrine — divides CTI into four levels based on who consumes it and how it’s used. Understanding these distinctions is essential to building intelligence that actually gets used.

Pyramid diagram showing the four levels of threat intelligence
Figure 2: The four levels of threat intelligence — as you move up the pyramid, the pain to produce increases but so does the value to the organization.

Strategic Threat Intelligence: The Board-Level View

Audience: CISOs, CIOs, boards of directors, risk committees
Purpose: Inform long-term security strategy, budget allocation, and business risk decisions
Format: High-level reports, briefings, risk assessments

Strategic CTI examines the big picture: Which threat actors are targeting our industry? What geopolitical developments create new cyber risks? How are attack trends shifting over quarters and years? What is the likely financial impact of these threats on our organization?

Strategic intelligence is the hardest to produce well because it requires deep understanding of both the threat landscape and the organization’s business context. I’ve seen too many strategic briefs that are essentially technical reports with the jargon stripped out. That’s not strategic intelligence — that’s watered-down tactical intelligence. True strategic intelligence connects threats to business impact in terms the board understands: revenue at risk, regulatory exposure, competitive disadvantage, brand damage.

Operational Threat Intelligence: The Campaign-Level View

Audience: SOC managers, threat hunting leads, incident response managers, security architects
Purpose: Understand ongoing campaigns, adversary behavior patterns, and imminent threats
Format: Threat actor profiles, campaign reports, intrusion analysis summaries

Operational CTI answers the question: “What is likely to attack us, and how?” It profiles specific threat actors — their motivations, capabilities, infrastructure, and TTPs — and tracks active campaigns. This level of intelligence is what enables threat hunting teams to develop hypotheses about adversary behavior and what allows SOC managers to prioritize detection engineering efforts.

When I produce operational intelligence, I’m thinking about the attack lifecycle: How does this actor gain initial access? What malware do they deploy? How do they move laterally? What are their exfiltration methods? Operational intelligence maps the adversary’s playbook so defenders can anticipate the next move.

Tactical Threat Intelligence: The Indicator-Level View

Audience: SOC analysts, detection engineers, incident responders
Purpose: Detect and block known threats in near-real-time
Format: IoCs, detection rules, SIEM queries, YARA/Sigma signatures

Tactical CTI is what most people think of when they hear “threat intelligence” — IP addresses, domain names, file hashes, and other Indicators of Compromise (IoCs). It’s the most commonly consumed form of CTI and, frankly, the most commonly misused.

The hard truth: IoCs have a very short shelf life. A malicious IP address may be active for hours or days before the adversary moves to new infrastructure. If your only CTI strategy is consuming IoC feeds and blocking them at the firewall, you’re playing whack-a-mole with adversaries who are far more agile than your feed updates. Tactical intelligence is essential — but it is not sufficient.

Effective tactical CTI also includes detection logic: Sigma rules for SIEMs, YARA rules for malware identification, Suricata/Snort signatures for network detection. These artifacts outlast raw IoCs because they describe adversary behavior rather than ephemeral infrastructure.

Technical Threat Intelligence: The Raw Data Layer

Audience: Security automation systems, TIPs, SIEM/SOAR platforms
Purpose: Feed automated defenses with structured threat data
Format: Machine-readable feeds (STIX/TAXII, JSON, CSV, API)

Technical CTI is the rawest form — threat feeds, telemetry streams, and automated data exchanges. It’s designed for machines, not humans. The goal is to get threat data into your defensive systems as quickly as possible, with as little human latency as possible.

But here’s the catch — and it’s a big one: raw technical feeds without curation are more noise than signal. I’ve seen organizations ingest millions of IoCs daily, only to find that 90%+ are irrelevant to their environment, false positives, or already expired. The value of technical intelligence is directly proportional to the quality of your processing and curation pipeline.


Key Frameworks and Standards Every CTI Practitioner Must Know

Threat intelligence doesn’t happen in a vacuum. A robust ecosystem of frameworks, standards, and models has evolved to help practitioners work effectively — and, critically, to share intelligence across organizational boundaries. If you’re serious about CTI, you need to know these.

MITRE ATT&CK: The Universal Language of Adversary Behavior

MITRE ATT&CK is the single most important framework in CTI today. It’s a knowledge base of adversary tactics, techniques, and procedures (TTPs) organized into a matrix that maps every stage of the attack lifecycle. When I describe an adversary’s behavior in ATT&CK terms — “they use T1059.001 (PowerShell) for execution, T1003.001 (LSASS memory) for credential dumping, and T1071.001 (HTTP) for C2” — every CTI practitioner in the world understands exactly what I mean.

ATT&CK is not just a reference — it’s a measurement tool. You can map your detection coverage against ATT&CK techniques to find gaps. You can map threat actor group profiles to see which techniques you’re most likely to face. You can use ATT&CK Navigator to visualize your defensive posture. If you only learn one framework, learn ATT&CK.

STIX and TAXII: The Standard for Sharing

Structured Threat Information Expression (STIX) is the standard language for describing cyber threat information. Trusted Automated Exchange of Intelligence Information (TAXII) is the transport protocol for sharing STIX data. Together, they enable organizations to share threat intelligence in a structured, machine-readable format.

STIX 2.1 defines objects for indicators, threat actors, campaigns, malware, attack patterns, relationships, and more. When your TIP exports intelligence in STIX format, any other STIX-compatible system can consume it. This interoperability is crucial — without it, every intelligence-sharing relationship requires custom integrations that don’t scale.

The Diamond Model: Four-Corner Analysis

The Diamond Model of Intrusion Analysis is deceptively simple and incredibly powerful. Every intrusion event, it argues, has four core features: Adversary, Capability, Infrastructure, and Victim. By mapping these four nodes and their relationships, you identify what you know, what you don’t know, and where to pivot next.

When I’m deep in an intrusion analysis and feel stuck, I draw a Diamond Model diagram. It almost always reveals the missing piece: I know the infrastructure and the capability, but who’s the adversary? I know the victim and the infrastructure, but what capability was used? Each unknown is a collection requirement — something you now know you need to find.

The Cyber Kill Chain: Staging Your Defense

Originally developed by Lockheed Martin, the Cyber Kill Chain models an intrusion as a sequence of seven stages: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command & Control (C2), and Actions on Objectives. The key insight is that you can break the chain at any stage — and the earlier you break it, the less damage the adversary can do.

The Kill Chain is sometimes criticized as being too linear for modern attacks, and that’s a fair critique. But as a thinking tool for structuring defensive analysis, it remains invaluable. I use it to ask: At which stage did we first detect this intrusion? At which stage could we have detected it? What controls would have broken the chain earlier?

The CTI Capability Maturity Model (CTI-CMM)

How mature is your CTI program? The CTI Capability Maturity Model (CTI-CMM) — which we developed here at Threat Intelligence Lab — provides a structured framework for assessing and improving your CTI capabilities across dimensions including collection, analysis, dissemination, tooling, and governance. It’s a roadmap, not a scorecard. Use it to identify where you are today and where you need to go next.


Building a CTI Program: From Zero to Operational

So you need to build a threat intelligence capability. Where do you start? I’ve helped organizations of all sizes answer this question, and while the specifics vary, the fundamental approach is consistent.

Step 1: Define Your Intelligence Requirements (IRs)

Before you buy a single tool or hire a single analyst, you need to know what questions you need intelligence to answer. Sit down with your stakeholders — SOC, incident response, vulnerability management, risk management, the CISO — and ask: What decisions do you make that threat intelligence could inform?

Document your IRs. Keep the list focused — 5 to 10 well-defined requirements is far better than 50 vague ones. Review them quarterly. Requirements change as your organization changes and as the threat landscape evolves.

Step 2: Start with What You Already Have

Most organizations sit on a mountain of unused threat data. Your firewalls, proxies, EDR, email gateways, and DNS servers generate enormous amounts of telemetry that can be mined for intelligence. Before you buy external feeds, learn to extract value from what you already own.

I always start new CTI programs with an internal data audit: What logs do we have? How long do we retain them? Who has access? What’s the quality? You’ll be surprised — and often horrified — by what you find. Fix your internal data foundation before you go shopping for external intelligence.

Step 3: Invest in People Before Tools

A common mistake: buying an expensive Threat Intelligence Platform and then realizing you don’t have anyone who knows how to use it effectively. People are your most important CTI investment. Hire analysts with curiosity, critical thinking skills, and a passion for understanding adversaries. Tools amplify capability — they don’t create it.

What makes a good CTI analyst? I look for:

  • Insatiable curiosity: The drive to ask “why?” and keep digging
  • Analytical rigor: Comfort with structured methods and the discipline to avoid jumping to conclusions
  • Technical foundation: Understanding of networks, operating systems, malware, and attack techniques
  • Communication skills: Ability to write clearly and present to both technical and non-technical audiences
  • Humility: Willingness to say “I don’t know — but I’ll find out”

Step 4: Select Tools That Fit Your Maturity

Your tooling should match your maturity level. If you’re just starting out, a spreadsheet and some OSINT feeds may be sufficient. As you grow, consider:

  • Threat Intelligence Platform (TIP): Centralizes collection, processing, and dissemination. Examples: MISP (open source), ThreatConnect, Anomali, EclecticIQ.
  • Malware Analysis Sandbox: Automates dynamic analysis of suspicious files. Examples: Joe Sandbox, Any.Run, Cuckoo Sandbox, VMRay.
  • SIEM/SOAR Integration: Connects intelligence to detection and response workflows. Enables automated enrichment and blocking.
  • Visualization and Analysis Tools: Maltego for link analysis, ATT&CK Navigator for technique mapping, Gephi for network graph analysis.

One warning: Don’t let your tool budget outpace your people budget. A TIP without analysts is an expensive data graveyard.

Step 5: Build Intelligence Products, Not Just Feeds

Your CTI program’s output should be finished intelligence products tailored to specific consumers. Start small. One well-written threat actor profile that your SOC actually uses is worth more than a thousand IoCs dumped into a SIEM that nobody looks at. Build relationships with your consumers. Learn what they find valuable. Iterate.

My recommended starter set of intelligence products:

  • Weekly Threat Brief: 1-page summary of relevant threats, distributed to SOC and management
  • Monthly Threat Landscape Report: Trends, statistics, and notable incidents for your sector
  • Quarterly Strategic Assessment: Forward-looking analysis for leadership and the board
  • Ad-Hoc Flash Reports: Time-critical alerts about imminent or active threats

CTI in Action: How Intelligence Drives Real Security Outcomes

Theory is important, but what does CTI actually do in the real world? Here are concrete ways threat intelligence drives security outcomes — drawn from my own experience in the field.

Intelligence-Led Threat Hunting

Instead of hunting blind, intelligence-led hunting starts with a hypothesis based on CTI. “APT29 has been observed using technique X against our sector. What would that look like in our environment?” The hunter develops a detection hypothesis, queries logs and endpoints for evidence, and either finds the adversary or confirms the absence of that specific threat — both valuable outcomes. This is exponentially more efficient than “let’s look for anything suspicious.”

Intelligence-Informed Incident Response

During an active incident, CTI provides context that accelerates response. Who is the likely adversary? What are their known TTPs? What’s their typical dwell time? What data do they typically target? This context allows responders to prioritize: instead of investigating every anomaly, they focus on the behaviors and artifacts most associated with the likely threat actor. Intelligence also informs scoping — if you know how this actor typically moves laterally, you can look for those specific patterns across your environment.

Vulnerability Prioritization

The old model: patch everything with a CVSS score above 7. The problem? You can’t patch everything, and CVSS scores don’t tell you what’s being actively exploited in the wild. CTI-driven vulnerability management asks a different question: “Which of these vulnerabilities are being weaponized by threat actors who target organizations like ours?” Prioritize those. This is the difference between patching 5,000 vulnerabilities and patching the 50 that matter most.

Phishing and Infrastructure Takedowns

One of the most operationally satisfying applications of CTI is proactive takedowns — identifying and dismantling adversary infrastructure before it’s used against you. By monitoring domain registrations, SSL certificate transparency logs, and phishing kit deployments, CTI teams can spot malicious infrastructure as it’s being set up. Combined with relationships at registrars, hosting providers, and law enforcement, this intelligence enables rapid disruption. I’ve personally overseen takedowns of hundreds of phishing domains, botnet C2 servers, and fraudulent websites — each one representing attacks that never reached their intended victims.


The Analyst’s Mindset: How to Think About Threats

Tools and frameworks are necessary but not sufficient. The best CTI practitioners I know share a particular way of thinking — a mindset that can be learned and cultivated.

Embrace Uncertainty

Intelligence is rarely certain. Adversaries actively deceive. Data is incomplete. Your job is not to be right all the time — it’s to calibrate your confidence honestly and communicate it clearly. I use a confidence scale with every assessment: High Confidence (corroborated by multiple reliable sources), Moderate Confidence (plausible and partially corroborated), Low Confidence (possible but unconfirmed). Stakeholders need to know how much weight to give your judgments. Never overstate your certainty.

Think Like the Adversary

The best CTI analysts I know can mentally model the adversary: If I were a financially motivated cybercrime group targeting this organization, what would I do? How would I research them? What would I find? Where would I attack? This adversarial mindset — sometimes called “red team thinking” — helps you anticipate attacks rather than merely react to them.

Follow the Evidence, Not the Narrative

The cybersecurity industry loves narratives: “Nation-state actors are targeting the energy sector!” Maybe they are, maybe they aren’t. What’s the evidence? How reliable are the sources? Are there alternative explanations? Good analysts are skeptics — not cynics, but people who demand evidence before they believe. And when the evidence contradicts the popular narrative, they have the courage to say so.

Share Freely, But Responsibly

Threat intelligence is a team sport. Adversaries share techniques and infrastructure freely — if defenders hoard intelligence, the adversary has an asymmetric advantage. Participate in ISACs, threat sharing groups, and open-source intelligence communities. But share responsibly: protect victim confidentiality, respect traffic light protocol (TLP) markings, and never expose your own organization’s vulnerabilities through careless sharing.


Common CTI Pitfalls — and How to Avoid Them

I’ve watched organizations make the same mistakes repeatedly. Learn from them:

  • “Feed Flooding”: Ingesting every free threat feed without curation. Result: analysts spend all their time triaging false positives instead of doing actual intelligence work. Fix: Curate feeds ruthlessly. If a feed doesn’t provide intelligence relevant to your IRs, drop it.
  • “Tool-Only CTI”: Buying a TIP and assuming you now have a CTI program. A TIP is infrastructure — it’s what you put into it and do with it that matters. Fix: Invest in people and processes first, tools second.
  • “Intelligence for Intelligence’s Sake”: Producing beautiful reports that nobody reads. Intelligence that doesn’t drive a decision or action is wasted effort. Fix: Start every product by asking: Who will use this, and what will they do differently after reading it?
  • “The Strategic-Tactical Gap”: Producing only tactical IoCs while the board asks about risk, or producing only high-level briefs while the SOC begs for detection rules. Fix: Serve all four intelligence levels. Map every product to a specific consumer.
  • “One-Way Intelligence”: Pushing intelligence out but never collecting feedback. Fix: Build feedback loops into every product. Track consumption and outcomes.

The Future of CTI: Where We’re Heading

Threat intelligence is evolving rapidly. Here are the trends I’m watching closely — and what they mean for practitioners:

AI-Augmented Analysis

Large language models and machine learning are transforming CTI. AI can already summarize threat reports, extract IoCs from unstructured text, translate between languages, and even suggest pivots. But — and this is critical — AI is an augmentation tool, not a replacement for human judgment. AI lacks context about your organization. It doesn’t understand business risk. It can’t make the nuanced assessments that experienced analysts produce. Use AI to accelerate the mechanical parts of CTI; keep humans in the loop for analysis and decision-making.

Adversary Use of AI

At the same time, adversaries are adopting AI for reconnaissance, social engineering, and exploit development. AI-generated phishing emails are harder to detect. AI-assisted vulnerability discovery is accelerating exploit timelines. CTI must evolve to detect and characterize AI-enabled attacks — a topic we cover in depth on this site.

Intelligence Automation and Orchestration

The future of CTI is tighter integration with automated response. Intelligence that flows directly from source to detection rule to automated block — with human oversight at key decision points. SOAR platforms are making this possible today. The analyst of the future will spend less time on manual triage and more time on the high-value analysis that machines can’t do.

Supply Chain Intelligence

As supply chain attacks grow in frequency and impact, CTI programs must expand their scope to include third-party and fourth-party risk. Understanding the threat landscape isn’t enough if you don’t understand the threats flowing through your vendors, your SaaS providers, and your open-source dependencies. Supply chain threat intelligence is becoming its own sub-discipline — and it’s one we’re actively researching and writing about.


Continue Your CTI Journey

This guide is your foundation — but it’s only the beginning. Threat Intelligence Lab publishes in-depth articles, practical guides, and threat briefs to help you go deeper into every topic covered here. Here’s where to go next:

Threat intelligence is a journey, not a destination. The threat landscape evolves every day — and so must we. I’m committed to sharing what I learn, and I hope this guide helps you build intelligence that truly protects your organization. If you have questions, feedback, or topics you’d like us to cover, reach out. I read every message.

— Reza Rafati
Founder, Threat Intelligence Lab
Rotterdam, The Netherlands


Published July 2026. This guide is continuously maintained as the CTI field evolves. All content is practitioner-written and evidence-based.