Threat Intelligence Fundamentals

The intelligence cycle is the repeating workflow through which raw information is converted into finished intelligence and then consumed by decision-makers whose feedback refines the next cycle. The model originates in national intelligence practice and has been adopted, with minor variations in terminology, by virtually every major threat intelligence framework. The six standard phases are direction, collection, processing, analysis, dissemination, and feedback.

Direction defines the intelligence requirements: what questions does the organisation need answered, what decisions will the intelligence inform, and what is the time horizon? Without clear direction, collection teams gather data indiscriminately, producing large volumes that cannot be prioritised. An incident response team needs answers within hours. A security strategy team may need trend analysis over quarters. The direction phase establishes which of these drives the current cycle.

Collection gathers the raw material needed to answer the requirements. Sources divide broadly into open-source intelligence (OSINT) from public sources such as threat feeds, security blogs, and domain registration records; closed-source or commercial intelligence from vendors; sharing communities such as ISACs (Information Sharing and Analysis Centers); and internal telemetry from the organisation's own logs and sensors. No single source is sufficient. Collection from multiple independent sources allows cross-validation and reduces the risk that a single source's errors propagate through to finished intelligence.

Processing converts collected data into a form that can be analysed: normalising formats, removing duplicates, deduplicating IoCs, translating foreign-language sources, and enriching raw indicators with context such as geolocation or autonomous system data. Analysis applies expert judgment to the processed data to identify patterns, attribute behaviour, assess adversary intent, and project likely future activity. Dissemination delivers the finished product to the intended audience in the right format, at the right level of detail, and in time to support the decision it was commissioned to inform. Feedback from consumers closes the loop: if the intelligence did not answer the question or arrived too late, the cycle is adjusted.

Threat intelligence is not one product. It is a family of products differentiated by the audience they serve, the questions they answer, and the time horizon they address. The four-level model is the standard way to describe these distinctions.

Strategic intelligence describes the threat environment at the highest level of abstraction. A strategic report might assess the likelihood that a nation-state will conduct destructive attacks against critical infrastructure in a given region over the next twelve months. The audience is executives and risk committees who allocate security budgets and accept or transfer organisational risk. The report contains no IP addresses. It contains geopolitical context, sector targeting patterns, and risk likelihood assessments.

Operational intelligence addresses a specific adversary campaign: who is behind it, what is their stated or inferred objective, what sectors or organisations are being targeted, and what is their current phase of activity. A financial institution that learns a known fraud group has acquired credential databases from their sector and is preparing a large-scale account-takeover campaign has operational intelligence. That knowledge drives preparation: monitoring specific account types, increasing authentication friction, and coordinating with peer institutions.

Tactical intelligence translates campaign knowledge into detection and response guidance. It identifies which techniques, as described in MITRE ATT&CK, the adversary is known to use, which defensive controls are most effective against those techniques, and what process or artefact evidence defenders should look for. Technical intelligence is the most granular level and the most perishable. Specific IoCs such as IP addresses and domains can change within hours as attackers rotate infrastructure. File hashes change with each recompile of a malware binary. Technical intelligence is useful but must be consumed quickly and refreshed continuously.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a structured knowledge base of observed adversary behaviour maintained by the MITRE Corporation, a US non-profit that operates federally funded research centres. The framework is based on documented real-world incidents and is updated continuously as new threat intelligence is contributed. It is freely available and has become the de facto common vocabulary for threat intelligence globally, used by security vendors, government agencies, and research organisations across the US, EU, UK, and internationally.

ATT&CK organises adversary activity into a matrix with tactics as columns and techniques as rows. Tactics are the high-level goals an adversary pursues during an intrusion: initial access, execution, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact. Each tactic contains multiple techniques, each with a unique alphanumeric identifier. For example, T1566 is Phishing, a technique under the Initial Access tactic. Techniques are further divided into sub-techniques: T1566.001 is Spearphishing Attachment; T1566.002 is Spearphishing Link.

For an investigator, ATT&CK serves several functions. When examining an incident, mapping observed artefacts and behaviours to ATT&CK technique IDs allows the analyst to communicate findings in a language that other teams, other organisations, and intelligence sharing platforms understand without translation. The mapping also drives detection gap analysis: if an adversary known to use T1003 (OS Credential Dumping) is targeting the organisation and the SOC has no detection rule for that technique, that gap is visible and actionable. ATT&CK Navigator, a free web tool, allows analysts to overlay threat actor profiles and current detection coverage on the same matrix to identify priorities.

The Diamond Model, introduced by Caltagirone, Pendergast, and Betz in a 2013 paper, provides an analytic framework for understanding and documenting a single intrusion event. It arranges four elements at the vertices of a diamond: adversary, capability, infrastructure, and victim. Every cyber intrusion event has all four elements. The model makes their relationships explicit and structures the analyst's pivot from one element to another.

The adversary is the actor conducting the intrusion. The capability is the tool or technique used, whether malware, an exploit, or a social engineering method. The infrastructure is the systems the adversary uses to deliver and control the capability, including command-and-control servers, phishing domains, and compromised relay hosts. The victim is the targeted organisation or system. The model adds two meta-features: the socio-political context describing the adversary's motivation and target relationship, and the technology context describing the platforms involved.

During an investigation, the Diamond Model drives pivot analysis. If you know the infrastructure (a command-and-control domain), you can pivot to find other victims connecting to the same infrastructure. If you know the capability (a specific malware family), you can pivot to find other campaigns using the same tool, which may reveal the adversary. If you know the adversary, you can anticipate their likely infrastructure choices and capabilities. The model does not dictate where to start; it clarifies which relationships are available and what evidence each pivot requires.

The model also supports campaign analysis across multiple events. Intrusion events that share an adversary or a capability or overlap on infrastructure can be grouped into an activity cluster. Establishing those clusters is the foundation of threat actor attribution and long-term tracking of adversary groups over time.

Sharing threat intelligence between organisations multiplies its value. An IoC seen at one financial institution and shared to peers before the attacker pivots can prevent several subsequent intrusions. But informal sharing through emails or PDF reports does not scale and cannot be ingested automatically by security platforms. STIX and TAXII together provide the language and the transport needed for automated, machine-readable sharing.

STIX (Structured Threat Information eXpression), currently at version 2.1, defines a set of domain objects that represent intelligence concepts: indicators, malware, threat actors, campaigns, attack patterns, tools, vulnerabilities, and others. Each object has a standard set of properties, including a unique identifier, a creation timestamp, and a confidence value. Objects are related to each other through relationship objects. A STIX bundle containing an indicator object, a malware object, and a relationship object linking them represents a coherent intelligence package that a receiving platform can parse, ingest, and act on without human reformatting.

TAXII (Trusted Automated eXchange of Intelligence Information), currently at version 2.1, defines the API through which STIX content is published and consumed. A TAXII server exposes collections of STIX objects. Clients can discover available collections, pull new objects since a given timestamp, or subscribe to push notifications. This enables near-real-time distribution of new indicators from a threat intelligence platform to every subscribing organisation, at machine speed, without manual intervention.

ISACs (Information Sharing and Analysis Centers) are sector-specific organisations that facilitate intelligence sharing among member organisations. They exist for financial services (FS-ISAC), healthcare (H-ISAC), energy (E-ISAC), and many other sectors, operating in the US, EU, UK, and other jurisdictions. Many ISACs use STIX/TAXII for automated distribution of member-contributed intelligence. In India, the Indian Computer Emergency Response Team (CERT-In) provides advisories and coordinates sector-level sharing. The EU's ENISA (European Union Agency for Cybersecurity) performs a comparable coordination role across member states.

In a cyber investigation, threat intelligence serves a different function from what it serves in a defensive operations context. The investigator is not using intelligence to prevent an attack; they are using it to understand an attack that has already occurred, attribute it to an actor, and build an evidence package that can withstand legal scrutiny. These demands impose additional constraints on how intelligence is gathered and used.

Attribution is the most contested application of threat intelligence in investigations. Attributing an attack to a specific actor requires correlating technical evidence, such as malware shared with a known group, with operational intelligence about that group's targeting patterns and objectives. Attribution claims that are used in court proceedings must be supported by admissible evidence rather than intelligence assessments, which may rely on classified sources or analytical judgments that cannot be disclosed. In India, the Bharatiya Sakshya Adhiniyam 2023 governs the admissibility of electronic evidence; in the UK, the Computer Misuse Act 1990 and the Police and Criminal Evidence Act 1984 apply; in the US, federal rules of evidence govern digital evidence standards. Investigators must understand which intelligence findings can be presented as evidence and which remain background context.

Data protection law imposes constraints on what threat intelligence can contain and how it can be shared. If an IoC includes personal data, such as a victim's email address used in a phishing campaign, sharing it may engage GDPR obligations in the EU and UK, or the Digital Personal Data Protection Act 2023 in India. Many ISAC sharing agreements include provisions that strip or pseudonymise personal data before distribution. Investigators collecting intelligence from commercial or open-source feeds should understand the legal basis for data processing in each jurisdiction relevant to their case.

For investigators working on indicators of compromise recovered from a victim's systems, threat intelligence adds context that raw artefacts cannot provide alone. A file hash that appears in a known malware family's signature database, confirmed through a threat intelligence platform, tells the investigator what capability was used and potentially who uses it. That context shapes the investigation's scope and priorities.