The Diamond Model

The Diamond Model of Intrusion Analysis is the canonical analytical framework for cyber threat intelligence. The model represents any malicious activity as a relationship between four nodes — adversary, capability, infrastructure, and victim — connected by edges that describe the relationships between them. The four nodes form a diamond, with the analytical work consisting of populating what is known about each node, pivoting from known elements to discover unknown ones, and aggregating individual events into broader patterns of adversary behavior over time.

The framework was published in 2013 by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz, then at the U.S. Department of Defense’s Center for Cyber Intelligence Analysis and Threat Research. The paper “The Diamond Model of Intrusion Analysis” introduced a structured framework for CTI analytical work at a time when the discipline was still consolidating, and the model has held up well enough over a decade to remain the standard intelligence-analysis framework in mature CTI programs as of 2026.

This page is the deep-dive companion to the Threat Modeling Frameworks umbrella. The scope here is what the Diamond Model is, how it structures CTI analytical work, where it earns operational value, and how it pairs with the other major frameworks (particularly ATT&CK and the Cyber Kill Chain).

What the Diamond Model actually is

The Diamond Model is a scientific framework for intrusion analysis — explicitly framed as such in the original paper, with the discipline of intelligence analysis grounded in formal logic and hypothesis-driven reasoning. The framework provides:

• A structured representation of intrusions that captures the entities involved and the relationships between them.
• An analytical workflow based on populating, pivoting, and aggregating.
• An integration pattern that connects to other CTI frameworks (kill chain phases, attribution methodologies, threat intelligence sharing standards).

The framework was developed within the U.S. intelligence community context but was published openly and has been adopted broadly across commercial CTI vendors, threat intelligence sharing organizations, and enterprise CTI programs. The CCIATR was a Department of Defense organization that has since been absorbed into other DoD structures; the authors moved on to commercial CTI roles (Caltagirone notably to Dragos, focused on industrial control systems CTI).

The Diamond Model is deliberately abstract. The four-node structure is meant to apply to any malicious activity — not just network intrusions narrowly, but any adversary action that has an adversary, a capability employed, infrastructure used, and a victim affected. The abstraction is part of why the model has held up across changing technology — the four nodes are stable even as specific adversary tools and victim systems change.

The model is also not a methodology in the way STRIDE or PASTA are. The Diamond Model provides the analytical structure and vocabulary; it does not prescribe specific workflow steps the way design-time threat modeling frameworks do. The analyst’s expertise and the broader CTI program’s processes provide the methodology that the Diamond Model structure supports.

The four nodes

The four nodes of the diamond are the entities that participate in any malicious activity:

Adversary

The adversary is the actor responsible for the malicious activity. The adversary node captures everything analysts know about who is conducting the activity — the threat group designation, the operator (if individual), the broader organization or program, and the actor’s motivation. The adversary node is the hardest to populate accurately because adversaries actively work to hide their identity, and the available evidence usually allows inferences about adversary capability and infrastructure long before it supports confident attribution to specific actors.

Standard adversary node fields:

• Adversary operator — the specific actor or persona conducting the operation, if identifiable.
• Adversary customer — for criminal-ecosystem operations, the entity sponsoring or directing the activity. For state-sponsored operations, the agency or program.
• Threat group designation — the standardized name (often differing by vendor: APT28 / Fancy Bear / Sofacy refer to the same group).

The adversary node is often the slot that remains ‘unknown’ even when the other three nodes are well-populated. Mature CTI analysis explicitly tracks confidence levels on adversary attribution, distinguishing between activity clustered under a temporary designation and activity attributed to a specific named group with high confidence.

Capability

The capability is what the adversary uses against the victim. The capability node covers the technical means employed — malware, exploit tools, custom scripts, abuse of legitimate software, and the broader set of techniques. The capability node is where ATT&CK tagging lives in a Diamond Model representation; the capability is described both as specific tools (Cobalt Strike, Mimikatz, named malware families) and as ATT&CK techniques (specific TTPs).

Standard capability node fields:

• Capability — the specific tool, technique, or method used.
• Capability variant — for malware, the specific variant or version observed.
• Vulnerability — the specific vulnerability exploited, if any.

The capability node is typically well-populated for technical intrusions because forensic analysis produces direct evidence of what was used. The capability evidence usually drives the rest of the diamond population — knowing the malware family observed allows the analyst to identify the threat groups that have used that family historically, which informs adversary hypotheses, and to identify the typical infrastructure patterns of those groups.

Infrastructure

The infrastructure is the technical resources the adversary uses to conduct the operation. The infrastructure node covers command-and-control servers, exfiltration endpoints, staging servers, registered domains, IP addresses, cloud accounts, email addresses used in delivery, and any other technical resource the adversary controls or uses.

Standard infrastructure node fields:

• Infrastructure type — C2 server, exfiltration endpoint, malware distribution server, etc.
• Specific identifiers — IP addresses, domain names, certificates, hashes.
• Hosting provider — the entity providing the infrastructure (which may or may not know).
• Ownership and registration details — domain registration data, hosting account information.

Infrastructure is often the richest pivot source in CTI analysis because adversary infrastructure tends to be reused across operations and shares technical signatures (TLS certificate reuse, hosting provider preferences, registration patterns) that allow analysts to discover related activity. The “pivoting” workflow that is operationally central to the Diamond Model frequently starts from a piece of infrastructure and discovers additional victims, additional capabilities, or additional adversary attribution evidence through systematic enrichment.

Victim

The victim is the target of the malicious activity. The victim node captures who or what was affected — the organization, the specific systems, the specific people if individually targeted, the assets compromised.

Standard victim node fields:

• Victim persona — the organization or individual targeted.
• Specific assets — the systems, accounts, or data affected.
• Victim sector or vertical — the industry, government function, or other categorization.
• Victim geography — the location of the affected entity.

The victim node provides the strategic context for the analysis. Adversary targeting patterns — which sectors, which geographies, which functional areas — often inform attribution hypotheses (state-sponsored actors target specific sector mixes; criminal actors target high-payout sectors) and prediction of future activity (an actor that has targeted X sector recently is more likely to target similar entities next).

The relationships and edges

The four nodes are connected by edges that capture the relationships between them. Each edge represents an analytical relationship rather than just a connection:

Adversary ↔ Capability — the adversary’s known capabilities, the capabilities historically attributed to the adversary. Used to associate observed activity with known threat groups based on capability matching.

Adversary ↔ Infrastructure — the infrastructure the adversary is known to control or use. Used for attribution and for predicting where related activity might appear.

Capability ↔ Infrastructure — the infrastructure a specific capability requires or uses. C2 protocols paired with specific malware families; exploit payloads paired with delivery infrastructure.

Capability ↔ Victim — the capabilities used against this victim, the capabilities effective against this victim’s defenses.

Infrastructure ↔ Victim — the infrastructure the adversary used to engage this victim. The connection most directly visible in network telemetry.

Adversary ↔ Victim — the targeting relationship. Adversaries select victims based on adversary objectives; victims have characteristics that attract specific adversary types.

The edges are the analytical core of the framework. Populating the four nodes is data collection; reasoning about the edges is analysis. The edges are where the pivoting workflow operates — given known elements, what can be inferred about the related elements through the edge relationships?

Meta-features

The Diamond Model extends the four-node core with meta-features that provide additional analytical structure:

• Timestamp — when the activity occurred. Enables timeline analysis and correlation across events.
• Phase — where the activity sits in the broader attack lifecycle (typically mapped to Kill Chain stages or ATT&CK tactics).
• Result — what the adversary achieved (success, partial success, failure).
• Direction — whether the activity flow was adversary-to-victim or victim-to-adversary (relevant for analyzing C2 traffic, exfiltration, etc.).
• Methodology — the adversary’s broader operational approach.
• Resources — what resources the activity required (technical infrastructure, human time, custom development).
• Social-political — the broader context of the activity (geopolitical events, criminal ecosystem dynamics, business sector context).
• Technology — the technology context of the victim (platforms used, defenses deployed, technology stack).

The meta-features are what distinguish Diamond Model analysis from purely technical IOC tracking. A piece of CTI that captures only “we saw this IP communicating with this victim” omits the meta-features that provide analytical context. A Diamond Model-structured analysis explicitly tracks the broader context that makes the activity meaningful.

The pivoting workflow

Pivoting is the operational heart of the Diamond Model. The technique is straightforward in description and substantial in practice:

1. Start from known elements in the diamond — typically a single piece of infrastructure, a malware sample, a specific incident.
2. Use edge relationships to identify candidate related elements — what other infrastructure does this hosting provider have? What other malware uses this C2 protocol? What other victims have been targeted by this adversary?
3. Investigate the candidates through targeted research and additional evidence collection.
4. Validate or refute each candidate based on the evidence.
5. Add the validated candidates to the diamond as additional known elements.
6. Repeat with the expanded set of known elements.

The pivoting workflow produces a rapidly expanding picture of adversary activity from a relatively small starting point. A single observed C2 IP, through systematic pivoting, often discovers dozens of additional infrastructure elements, multiple capability families, multiple victims, and progressively higher-confidence attribution to specific adversary groups.

The pivoting workflow is the CTI equivalent of detective work. The Diamond Model provides the structural framework — the four nodes and their edges — within which the analytical work happens. The expertise of the analyst, the available tooling, and the access to relevant data sources determine how effectively the pivoting works.

Common pivot sources in practice:

Infrastructure pivots are the most common starting point. A C2 IP address pivots through:
– Passive DNS data → what domains have resolved to this IP?
– Certificate transparency → what certificates have been issued for those domains?
– Other domains using related certificates or registration patterns → expanded infrastructure picture.
– WHOIS data → registrant information that might appear across infrastructure.
– Hosting provider information → other infrastructure from the same provider with related patterns.

Capability pivots start from a malware sample or technique:
– Code similarity → other samples that share code with this one.
– Behavior similarity → samples that behave similarly even if code differs.
– C2 protocol → other samples using the same C2 protocol.
– ATT&CK techniques → adversary groups known to use these techniques.

Victim pivots start from a known target:
– Sector targeting patterns → other victims in the same sector recently affected.
– Geographic targeting patterns → other victims in the same geography.
– Adversary historical targeting → other organizations the same adversary has targeted.

Adversary pivots start from an attribution hypothesis:
– Group’s historical capabilities → check whether observed activity matches known capabilities.
– Group’s historical infrastructure → check whether observed infrastructure matches known patterns.
– Group’s historical targeting → check whether the victim matches known targeting preferences.

The pivoting workflow is structurally simple and operationally demanding. The framework provides the structure; the actual work requires substantial CTI expertise, access to relevant data sources (passive DNS, certificate transparency, malware sandboxes, commercial threat intelligence feeds), and the analytical discipline to validate candidates rather than accepting them on weak evidence.

Aggregation from events to activity threads to campaigns

The Diamond Model provides a structured way to aggregate individual events into larger units of analysis:

Events are individual instances of malicious activity. A single phishing email delivered to a single victim is an event. The four-node structure captures the event’s adversary, capability, infrastructure, and victim, with the meta-features adding context.

Activity threads are sequences of related events tied together by common elements. Multiple phishing emails to multiple victims that share the same C2 infrastructure form an activity thread connected through the infrastructure node. The same capability used against multiple victims forms an activity thread connected through the capability node.

Activity groups are clusters of activity threads that share enough elements to suggest common operational origin. The Diamond Model formalizes this as activity groups defined by shared elements across the four nodes — events that share adversary attribution, that use related capabilities, that operate from related infrastructure, that target similar victims.

Campaigns are activity groups with explicit operational intent and timeframe. A campaign has a beginning, an end, an operational objective, and a coherent narrative that explains the activity. Mature CTI work produces campaign-level analysis that explains the broader operational context of the technical evidence.

The aggregation hierarchy is the structural bridge between technical CTI and strategic intelligence. Individual events are tactical observations; activity threads suggest operational patterns; activity groups identify operator-level coherence; campaigns provide strategic-level narrative. The Diamond Model structure supports all four levels with consistent vocabulary.

Operational use in CTI

The Diamond Model appears in CTI work in several specific contexts:

Incident analysis structuring. When a CTI team receives raw incident data, the Diamond Model provides the structure for organizing it. The incident becomes one or more events with populated diamonds, with the meta-features providing context. The structured representation supports later analysis better than free-text incident reports.

Threat intelligence reporting. Published CTI reports increasingly use Diamond Model structure for their evidence presentation. The “indicators of compromise” section captures the infrastructure and capability evidence; the “victimology” section captures the victim node; the “attribution” section captures adversary node evidence. Reports structured this way are more easily ingested by automated CTI platforms.

Adversary tracking and group profiles. CTI teams maintain Diamond Model representations of named threat groups, with the adversary node populated and the capability, infrastructure, and victim nodes documenting what the group has used and targeted historically. New observed activity can be matched against these group profiles to identify continuing operations.

Hunt and detection planning. Diamond Model representations of recent adversary activity inform hunt operations. The capability node identifies what to look for technically; the infrastructure node provides IOCs for searching; the victim node identifies the systems likely to be affected.

Strategic intelligence synthesis. Aggregating campaigns across multiple Diamond Model analyses produces strategic-level intelligence about adversary patterns, targeting trends, capability evolution, and operational tempo. The Diamond Model structure provides consistency across the underlying tactical observations that the strategic analysis aggregates.

Intelligence sharing. Standardized intelligence sharing formats (STIX 2.1, MISP) align well with Diamond Model structure. The four-node representation maps cleanly to STIX objects (Threat Actor, Malware, Infrastructure, Identity), and the meta-features map to STIX properties. Sharing Diamond Model-structured intelligence is straightforward.

The relationship to ATT&CK and Kill Chain

The Diamond Model operates at a different level of abstraction than ATT&CK and the Cyber Kill Chain, and the three frameworks combine in a specific way for mature CTI work:

Diamond Model provides the structural framework for capturing what is known about a piece of malicious activity. The four nodes and their edges are the organizational structure.

Kill Chain provides the lifecycle phase context. The Diamond Model’s “phase” meta-feature is typically populated with Kill Chain stages (or ATT&CK tactics). The lifecycle dimension adds temporal-strategic structure to the four-node snapshot.

ATT&CK provides the technique vocabulary for the capability node. Where the Diamond Model has a “capability” slot, mature CTI work fills it with both specific tools (named malware, specific binaries) and ATT&CK technique tags (T-numbers). The technique-level granularity makes the capability evidence operationally actionable.

The combination produces CTI analysis that is structured (Diamond Model), lifecycle-aware (Kill Chain), and technique-tagged (ATT&CK). All three frameworks address different aspects of the same activity, and using all three together is the standard pattern in CTI programs that have matured beyond ad hoc analysis.

A specific example: an analyst working a phishing-derived incident would use the Diamond Model to organize the evidence (adversary likely APT28 based on infrastructure and capability matching; capability includes specific malware and specific ATT&CK techniques; infrastructure includes the C2 servers and the phishing infrastructure; victim is the organization’s executive team); the Kill Chain to characterize phase (delivery and exploitation observed, persistence achieved); and ATT&CK to tag specific techniques (T1566.001 spearphishing attachment, T1059.001 PowerShell, etc.). The combined analysis is more useful than any single framework would produce.

Where the Diamond Model excels

The framework earns operational value in several specific contexts:

Cyber threat intelligence analytical work. The Diamond Model is the standard structure for CTI analysts at every maturity level. The framework gives analytical work consistent structure, supports knowledge transfer between analysts, and produces output that other analysts can build on.

Attribution work. The Diamond Model’s explicit handling of the adversary node, with the discipline of tracking confidence levels and connecting attribution evidence across all four nodes, supports attribution work better than less-structured approaches. The framework doesn’t make attribution easier, but it makes attribution analysis more defensible.

Tracking adversary campaigns across multiple incidents. The aggregation from events to activity threads to activity groups to campaigns provides a way to connect observations across time, organizations, and incidents. The Diamond Model structure makes the connections explicit and analyzable.

Intelligence pivoting and enrichment. The pivoting workflow is the operational core of CTI work, and the Diamond Model provides the structural framework that makes pivoting systematic rather than ad hoc.

Knowledge transfer between analysts. Diamond Model-structured intelligence is interpretable by other analysts in a way that free-text reporting is not. New analysts joining a CTI team can read Diamond Model-structured intelligence to understand the team’s accumulated knowledge.

Where the Diamond Model has limits

Several structural limits are worth being honest about:

The framework requires CTI expertise to use effectively. The Diamond Model is a structure for analytical work; the actual analysis still requires substantial skill. Organizations that adopt the framework without the analytical expertise to fill it in well produce Diamond Model-shaped documentation that doesn’t deliver the analytical insight the framework is designed to support.

Attribution is hard and the framework doesn’t make it easier. The Diamond Model’s explicit adversary node is sometimes interpreted as implying that attribution should always be populated. In practice, attribution often remains uncertain, and the Diamond Model’s discipline is to track that uncertainty honestly rather than to force attribution conclusions the evidence doesn’t support.

The framework is descriptive of past activity, not predictive of future activity. Diamond Model analysis describes what has happened. Predicting what the adversary will do next requires additional intelligence and judgment that the framework does not directly support.

The four-node structure can feel reductive for complex activity. Some malicious activity involves multiple adversaries (criminal ecosystem operations where developer, operator, affiliate, and broker are different actors), shared infrastructure (multiple groups using common bulletproof hosting providers), or shared capabilities (commodity malware used by many actors). The four-node abstraction captures these cases but sometimes awkwardly.

The framework was developed for traditional intrusions. Some attack patterns — supply chain compromise, broad credential theft operations, ransomware-as-a-service ecosystem dynamics — stretch the four-node model. The framework can be adapted but the fit is less natural than for traditional intrusion analysis.

Tooling support is narrower than for ATT&CK. While CTI platforms generally support Diamond Model-structured intelligence, the visualization, integration, and tooling ecosystem is less developed than for ATT&CK. Most Diamond Model work happens in CTI platforms (ThreatConnect, EclecticIQ, OpenCTI) where the framework is one element among many rather than the central organizing structure.

Persistent pitfalls

Recurring failure patterns in Diamond Model adoption:

Populating nodes without analytical reasoning. Adding facts to the four nodes without analyzing the relationships between them produces structured documentation rather than intelligence analysis. The edges and meta-features are where the analytical work happens; ignoring them defeats the framework’s purpose.

Forcing attribution. The Diamond Model’s explicit adversary node tempts analysts to populate it even when the evidence is insufficient. Confident attribution from weak evidence is one of the most damaging failure modes in CTI work, and the framework’s structure can encourage it without explicit discipline against it.

Treating the Diamond as static. Diamond Model representations should update as new evidence arrives. A diamond that was correct at the initial analysis but hasn’t been updated since misrepresents what is currently known.

Skipping the meta-features. The four nodes capture the technical entities; the meta-features capture the analytical context. Analyses that populate only the four nodes produce technical IOC tracking rather than intelligence analysis.

Confusing aggregation levels. Mixing events, activity threads, and campaigns without distinguishing between them produces confused analysis. The aggregation hierarchy is part of the framework’s structure and is worth maintaining explicitly.

Adopting the framework without the broader CTI program. The Diamond Model supports CTI work; it does not create CTI capability where none exists. Organizations that adopt the framework without the analytical staff, the data access, and the operational integration to use it well produce structured documentation that satisfies the framework but doesn’t deliver intelligence value.

Standards and references

• The Diamond Model of Intrusion Analysis by Caltagirone, Pendergast, and Betz (2013) — the canonical paper introducing the framework.
• STIX 2.1 — the intelligence sharing standard that maps cleanly to Diamond Model structure.
• MISP (Malware Information Sharing Platform) — the open-source intelligence sharing platform that supports Diamond Model-structured intelligence.
• Center for Cyber Intelligence Analysis and Threat Research (CCIATR) — the original organizational context for the framework’s development.
• F3EAD (Find, Fix, Finish, Exploit, Analyze, Disseminate) — the military intelligence cycle that pairs with Diamond Model in some intelligence-driven operations frameworks.

How to actually use the Diamond Model in 2026

For organizations adopting the Diamond Model in their CTI work, a practical sequence:

1. Train CTI analysts in the framework structure. The four nodes, the edges, the meta-features, the pivoting workflow, the aggregation hierarchy. A half-day training is sufficient for analysts who already have CTI background; analysts new to CTI need substantially more.

2. Adopt the framework in incident analysis and CTI reporting. New incidents and new intelligence reports get Diamond Model-structured representations. The structure becomes the standard analytical output format.

3. Build pivoting capability through data access and tooling. The pivoting workflow depends on access to passive DNS, certificate transparency, malware sandboxes, and commercial threat intelligence feeds. Without this data access, pivoting is severely limited and Diamond Model work becomes shallow.

4. Integrate with ATT&CK and Kill Chain frameworks. The capability node gets ATT&CK technique tags; the phase meta-feature gets Kill Chain stage assignments. The integration makes the Diamond Model analysis operationally useful for detection engineering and response work.

5. Maintain group profiles using Diamond Model structure. For threat groups the organization tracks, maintain ongoing Diamond Model representations that get updated as new evidence arrives. The accumulated knowledge becomes the basis for matching new activity against known patterns.

6. Aggregate intentionally. Move analysis through the aggregation hierarchy explicitly — events to activity threads to activity groups to campaigns — rather than treating all observations as undifferentiated. The hierarchy is part of the framework’s value.

7. Maintain analytical humility about attribution. Track confidence levels explicitly on adversary node populations. Honest uncertainty is more valuable than false confidence.

8. Use intelligence sharing formats that align with Diamond Model. STIX 2.1 and MISP are the standard formats. Diamond Model-structured intelligence is easier to share, easier to ingest, and easier to act on than free-text reporting.

The Diamond Model has earned its position as the standard CTI analytical framework. The framework is structurally simple, conceptually elegant, and operationally demanding — the simplicity of the four-node structure is part of why it has held up, and the demanding nature of the analytical work is what determines whether the framework produces value in practice. Used well, it transforms CTI work from ad hoc observation tracking into structured intelligence analysis. Used poorly, it produces Diamond Model-shaped documentation that satisfies the framework’s form without delivering its analytical value. The difference is CTI expertise and operational discipline.

Where to go next on this site

Adjacent material on this site:

• Threat Modeling Frameworks — the umbrella overview.
• MITRE ATT&CK — the technique-level framework that provides vocabulary for the Diamond Model’s capability node.
• MITRE D3FEND — the defensive countermeasure catalog.
• The Cyber Kill Chain — the lifecycle model that provides phase context for Diamond Model analysis.
• STRIDE — the design-time threat categorization framework that operates at a different abstraction level.
• LINDDUN — the privacy-focused parallel framework.
• PASTA — the heavyweight risk-centric methodology.
• OCTAVE — the asset-driven enterprise risk methodology.

The Diamond Model completes the offensive-operational toolkit alongside ATT&CK and the Kill Chain. The three frameworks together cover the macro lifecycle structure (Kill Chain), the technique-level granularity (ATT&CK), and the analytical organization of evidence (Diamond Model). Mature CTI programs use all three; less mature programs that use any single one of them often find themselves missing the complementary structure the other two provide.