The Diamond Model of Intrusion Analysis — CTI Academy

The Diamond Model of Intrusion Analysis is one of the foundational frameworks in cyber threat intelligence. Introduced in 2013 by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz, the model provides a structured approach to describing and analyzing intrusion events. Unlike linear models such as the Kill Chain, the Diamond Model focuses on the relationships between four core features of every intrusion event, enabling analysts to pivot between data points and build comprehensive threat intelligence.

Learning Objectives

Understand the four core features of the Diamond Model and how they relate to each other
Apply meta-features to enrich intrusion analysis beyond the basic diamond
Use activity threading and activity grouping to connect individual events into campaigns
Construct a diamond from raw intrusion data
Recognize how the Diamond Model complements the Kill Chain and ATT&CK frameworks

Origin and Purpose

The Diamond Model was formally published in a 2013 paper titled The Diamond Model of Intrusion Analysis by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz. The paper was released through the Center for Cyber Intelligence Analysis and Threat Research. The authors developed the model to address a gap in how the intelligence community analyzed and communicated intrusion events. Prior models focused on the attacker's process (like the Kill Chain) but lacked a structured way to describe the relationships between the entities involved in an intrusion.

The core insight of the Diamond Model is that every intrusion event can be described as a relationship between four features arranged in a diamond shape. By analyzing these relationships, analysts can pivot from known information to discover unknowns — a process fundamental to intelligence analysis.

The Four Core Features

Every intrusion event in the Diamond Model consists of four core features connected in a diamond shape:

        Adversary
       /         \
      /           \
Infrastructure --- Capability
      \           /
       \         /
        Victim

Adversary

The adversary is the actor (person, group, or organization) responsible for the intrusion event. The model distinguishes between:

Adversary Operator: The individual or team conducting the intrusion (the "hands on keyboard" actor)
Adversary Customer: The entity that benefits from the intrusion (may be the same as or different from the operator)

This distinction matters because nation-state operations often involve operators (contractors, military units) working on behalf of customers (government agencies, military commands). Not every intrusion will have a known adversary — attribution is often the hardest feature to establish.

Capability

Capability refers to the tools, techniques, and procedures used in the intrusion event. This includes:

Malware families and variants
Exploit code targeting specific vulnerabilities
Attack techniques (phishing, credential stuffing, lateral movement methods)
Custom or commercial tools (Cobalt Strike, Metasploit, custom RATs)

The model distinguishes between capability (the broad class of tools/techniques) and capability capacity (the specific instance or variant used in an event).

Infrastructure

Infrastructure is the physical or logical communication structures the adversary uses to deliver capabilities or maintain command and control. Examples include:

Command and control (C2) servers
Domain names used for phishing or C2
Email accounts used for spear-phishing
Compromised websites used for watering hole attacks
VPN services or proxy chains

Infrastructure is divided into Type 1 (owned or directly controlled by the adversary) and Type 2 (infrastructure owned by others but used by the adversary, such as compromised servers or legitimate cloud services).

Victim

The victim is the target of the intrusion event. Like adversary, the model makes a distinction:

Victim Persona: The organization, person, or entity targeted (the "who")
Victim Asset: The specific system, network, or data resource attacked (the "what")

Understanding both aspects helps analysts determine whether an adversary targets specific organizations (persona) or simply targets vulnerable systems regardless of owner (asset).

Meta-Features

Beyond the four core features, the Diamond Model defines meta-features that provide context and enrich the analysis:

Meta-Feature	Description
Timestamp	When the event occurred (start and end times)
Phase	Where the event falls in an attack lifecycle (maps to Kill Chain phases)
Result	The outcome of the event (success, failure, unknown)
Direction	The flow of the event (adversary-to-victim, victim-to-infrastructure, bidirectional)
Methodology	The general class of activity (spear-phishing, watering hole, brute force)
Resources	What the adversary needed to execute the event (software, hardware, funds, access, knowledge)

Meta-features transform a simple four-node graph into a richly described intelligence object. An event with a timestamp, phase, and result tells a much more complete story than one with only the four core features.

The Seven Axioms

The Diamond Model is built on seven axioms — foundational assumptions that define how the model works:

Axiom 1: For every intrusion event, there exists an adversary taking a step toward an intended goal by using a capability over infrastructure against a victim to produce a result.
Axiom 2: There exists a set of adversaries which, in the aggregate, are responsible for all intrusion events. Each adversary has at least one common attribute with other adversaries.
Axiom 3: There exists a set of capabilities which, in the aggregate, were used to execute all intrusion events.
Axiom 4: There exists a set of infrastructure elements which, in the aggregate, were used to execute all intrusion events. Every piece of infrastructure has at least one common attribute with other infrastructure.
Axiom 5: There exists a set of victims which, in the aggregate, were targeted in all intrusion events. Every victim has at least one common attribute with other victims.
Axiom 6: There exists a socio-political relationship between adversary and victim which motivates the intrusion event.
Axiom 7: There exists a technology relationship between capability and infrastructure that enables the intrusion event.

Axioms 6 and 7 are particularly important because they define the two axes of the diamond: the socio-political axis (adversary-victim relationship driven by motivation, targeting, and geopolitics) and the technology axis (capability-infrastructure relationship driven by technical requirements and constraints).

Activity Threads and Activity Groups

Individual diamond events rarely occur in isolation. The model provides two constructs for connecting events:

Activity Threads

An activity thread is a sequence of diamond events connected by a shared feature. For example, if the same C2 server (infrastructure) is used across multiple events, those events form an activity thread. Activity threads allow analysts to trace an adversary's operations over time by following any of the four features.

Common pivoting patterns:

Infrastructure pivoting: Find one C2 domain, discover others through shared registration details, hosting, or SSL certificates
Capability pivoting: Identify a malware family, find other events using the same malware
Victim pivoting: Identify a targeted organization, look for other events targeting the same entity
Adversary pivoting: Attribute events to a group, look for all their known operations

Activity Groups

An activity group is a cluster of diamond events that share common features and are assessed to be related. Activity groups are the analytical basis for what the industry calls "threat groups" or "threat actors" (APT28, Lazarus Group, etc.). Grouping is performed by identifying events that share multiple features — for example, the same malware family delivered through similar infrastructure against the same industry vertical.

Key Definition: An activity group is an analyst-defined clustering of diamond events based on shared features. It represents a hypothesis about related adversary activity, not a proven attribution.

Building a Diamond from Raw Data

When an analyst receives an alert or report, they can construct a diamond by filling in what is known:

Start with what you have. An alert might give you a victim (your organization) and infrastructure (a suspicious IP address). Plot those two features.
Pivot to discover more. Query threat intelligence platforms for the IP address to identify associated malware (capability). Check if the IP has been attributed to a known group (adversary).
Add meta-features. Record the timestamp, determine the phase (was this delivery? C2 communication?), and note the result (was the attack blocked?).
Connect to other diamonds. Has this infrastructure appeared in previous events? Does this capability match known campaigns? Link this diamond to existing activity threads.

Relationship to Other Frameworks

The Diamond Model is not a replacement for the Kill Chain or MITRE ATT&CK — it is complementary:

Kill Chain describes the phases of an attack (the "when" in a sequence)
ATT&CK catalogs adversary techniques in detail (the "how")
Diamond Model describes the relationships between entities in each event (the "who, what, where, and with what")

Many mature CTI programs use all three together. An analyst might describe an intrusion as a sequence of Kill Chain phases, detail each phase using ATT&CK techniques, and structure the event data using Diamond Model features to enable pivoting and clustering.

Practical Applications

The Diamond Model is used daily by CTI analysts in several ways:

Pivoting during investigations: When you discover one feature (e.g., a malicious domain), use it to find related events sharing that feature
Threat actor tracking: Activity groups built from diamond events form the basis of threat actor profiles
Intelligence gap identification: Empty features in a diamond highlight what you do not know and where to focus collection
Communication: The diamond provides a clear, visual way to brief stakeholders on intrusion events
Tool integration: Many TIP (Threat Intelligence Platform) tools structure data around diamond-like relationships

Key Takeaways

The Diamond Model describes every intrusion event as a relationship between Adversary, Capability, Infrastructure, and Victim
Meta-features (timestamp, phase, result, direction, methodology, resources) add essential context
The socio-political axis (adversary-victim) and technology axis (capability-infrastructure) define the two fundamental relationships in every intrusion
Activity threads connect events through shared features; activity groups cluster related events into what the industry calls threat groups
The Diamond Model excels at pivoting — using one known feature to discover unknowns
It complements (not replaces) the Kill Chain and ATT&CK frameworks

Practical Exercise

Take a published threat intelligence report (Mandiant, CrowdStrike, or Recorded Future reports work well) and extract the Diamond Model features:

Identify the adversary (if attributed) — note whether the report identifies operators, customers, or both
List all capabilities mentioned — malware families, tools, exploits
Catalog the infrastructure — C2 domains, IPs, email addresses, hosting providers
Describe the victim — targeted organizations, industries, geographies, specific assets
Fill in meta-features: timestamps, phases, results, methodology
Draw the diamond on paper or a whiteboard and label the relationships
Identify which features have gaps — where would you focus additional collection?