Threat Intelligence Training

There is a critical distinction that most security practitioners never learn: the difference between information and intelligence. Information is raw data — a list of IP addresses, a domain name, a hash, a log entry. Intelligence is information that has been collected, processed, analysed, and put into context for a specific decision-maker to act on. Sharing a list of 10,000 IP addresses with a SOC analyst is not intelligence. Telling the SOC team "these 14 IP addresses are active Cobalt Strike C2 servers targeting Indian BFSI organisations, here is the detection query, and here is the TTP pattern so you can hunt for activity before this week's patch window" — that is intelligence.

The intelligence cycle is a six-phase process that transforms raw data into finished intelligence products. Understanding this cycle is not academic — it is the operational framework you will use every single day as an analyst.

Analytic models give structure to your thinking. Without a model, threat analysis becomes a free-form description of events with no systematic relationship between them. With a model, you can identify gaps in your knowledge, predict attacker behaviour, and communicate findings consistently. Three models are used by professional CTI analysts globally.

The Diamond Model of Intrusion Analysis (Caltagirone, Pendergast, Betz, 2013) is the most useful for threat intelligence. It states that every intrusion event has four features arranged in a diamond: Adversary (who), Infrastructure (where), Capability (how), and Victim (who was targeted). The diamond is connected by edges representing relationships — and the model's power is that discovering any feature gives you intelligence clues about all the others.

Intelligence analysis fails not because of missing data but because of cognitive biases — systematic errors in human thinking that cause analysts to draw wrong conclusions from correct data. Confirmation bias (seeking information that confirms existing beliefs), anchoring (over-weighting the first piece of information received), and groupthink (adopting the consensus view without critical examination) have all contributed to major intelligence failures.

Structured Analytic Techniques (SATs) are documented methods for applying disciplined, structured thinking to analytic problems. They force you to consider alternative explanations, challenge your assumptions, and separate what you know from what you infer. They were developed by intelligence professionals and adopted in cybersecurity CTI because the same cognitive failures occur in both domains.

Open-source intelligence is intelligence derived from publicly available sources. "Publicly available" does not mean "easy to find" — OSINT includes academic papers, court documents, company filings, technical forums, social media, satellite imagery, and dark web markets. The skill is knowing where to look, how to collect systematically without alerting your target, and how to assess source reliability.

The most important OSINT discipline for CTI is infrastructure analysis — mapping the technical infrastructure an attacker uses. When you find one C2 server, infrastructure analysis finds the other twelve. Attackers reuse: registrar accounts (same registrant email across many domains), hosting providers (same ASN), SSL certificates (same certificate subject across multiple domains), and coding patterns (same HTML templates across phishing sites).

No CTI programme relies solely on manual OSINT. Technical intelligence feeds provide thousands of IOCs per day from automated collection systems — honeypots, sinkholes, malware analysis sandboxes, and passive DNS systems. Your job is not to collect these manually but to select the right feeds, assess their quality, and integrate them into your platform so they are automatically enriching your team's work.

Feed quality varies enormously. A feed with high false positive rates (legitimate IPs flagged as malicious) is worse than no feed — it generates alert fatigue and destroys analyst trust in the tooling. Evaluate every feed before consuming it: what is its source, how is it verified, what is the age of indicators (stale IOCs are nearly worthless), and what is its false positive rate in your specific environment?

An IOC is only valuable within its valid time window. An IP address associated with C2 activity two years ago is almost certainly being used for legitimate purposes now — the malicious infrastructure has moved on. Blocking it wastes nothing but adds noise. More importantly, blocking it without understanding that it is stale could create a false sense of security (the attacker is detected) when the attacker has completely changed their infrastructure.

The Pyramid of Pain (David Bianco, 2013) is the most important framework for IOC prioritisation. It visualises how painful it is for an attacker to change each type of indicator when you detect and block it. At the bottom: hash values (trivial to change — recompile the malware). At the top: TTPs (attacker behaviour — extremely difficult to change without retooling entirely). The higher you hunt and detect, the more you hurt the attacker.

CTI analysts are not malware reverse engineers — but they need to extract intelligence from malware analysis reports and sandbox outputs. The intelligence questions malware analysis answers are: What actor developed this? What victims was it targeting? How does it communicate with C2? What does its network traffic look like (for detection)? Does it share code with known malware families (attribution)?

Code similarity analysis is the most powerful malware-based attribution technique. Attackers reuse code — either their own code from previous campaigns, or shared code from underground marketplaces. When malware shares code segments, compile-time artifacts, or unique strings with previously attributed samples, it links the campaigns. This is how Lazarus Group's attribution was solidified — unique code artifacts appeared across WannaCry, SWIFT attacks, and their custom banking malware.

You do not need to know every threat actor. You need to deeply know the actors who are relevant to your threat model — the sectors they target, the regions they operate in, and the geopolitical motivations that drive their activity. This section profiles the major global threat actor categories with enough depth to inform your collection and detection priorities.

Intelligence sharing without proper classification causes real harm. If you share sensitive information about an ongoing law enforcement investigation, you alert the criminal. If you share specific victim information with the wrong audience, you harm the victim. The Traffic Light Protocol (TLP) is the universal standard for managing intelligence sharing — used by CERTs, ISACs, government agencies, and private organisations globally.

Intelligence writing is a specific skill distinct from general technical writing. Intelligence products are not descriptions of what happened — they are assessments of what it means, with explicit confidence levels and clear recommendations. The format must match the consumer: a CISO reads a one-page executive summary in a meeting. A SOC team reads a technical report during an investigation. A threat hunter reads a MITRE ATT&CK-mapped TTP analysis before starting a hunt.

The most common failure in intelligence writing is conflating data with analysis. "The actor sent a spear-phishing email with a malicious attachment on January 14" is a data statement. "The actor's use of a military housing allowance theme targeting Indian Army personnel indicates deliberate social engineering of the government sector rather than opportunistic targeting" is an intelligence statement. Always answer: "So what? What does this mean?"