# Diamond Model of Intrusion Analysis
The Diamond Model of Intrusion Analysis is a structured analytical framework developed by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz in 2013 to give security analysts a rigorous, repeatable method for decomposing and understanding intrusion events. The model exists because ad-hoc incident analysis produces inconsistent conclusions, loses institutional knowledge, and fails to connect individual events into coherent threat actor patterns. By anchoring every intrusion event to four core features (adversary, capability, infrastructure, and victim), the Diamond Model creates a consistent unit of analysis that teams can use to build intelligence, track campaigns, and predict future attacker behavior. It transforms reactive incident response into proactive threat intelligence production.
The Diamond Model defines a single intrusion event as a directed relationship between an adversary who deploys a capability over infrastructure against a victim. These four vertices form the diamond shape that gives the model its name. Each vertex carries specific meaning: the adversary is the actor or organization responsible for the intrusion; the capability is the tool, technique, or malware used; the infrastructure is the physical or logical resource used to deliver or control the capability; and the victim is the target asset, person, or organization.
The model is not a threat intelligence platform, a scoring rubric, or a maturity model. It is an analytical schema designed to structure observations about specific events and connect those events into campaigns. Organizations sometimes confuse the Diamond Model with the MITRE ATT&CK framework. ATT&CK is a knowledge base of observed adversary tactics and techniques. The Diamond Model provides the structural logic for connecting events involving those techniques to actors and victims. They are complementary: ATT&CK provides the vocabulary for describing capabilities; the Diamond Model provides the framework for connecting capabilities to campaigns.
Event Identification and Documentation
Every Diamond Model analysis begins with a discrete, observable intrusion event. An event is a time-bounded activity in which an adversary used a specific capability over specific infrastructure to affect a victim. The analyst's first task is to record what is known and explicitly note what is unknown. Unknown vertices are not left blank; they are marked as inferred or unknown, which forces the analyst to acknowledge gaps rather than skip them.
Consider this example: On March 15th, an attacker sends a spearphishing email containing an Excel spreadsheet with embedded macros (capability) from a domain registered three days earlier using a privacy service (infrastructure) to a financial analyst at a regional bank (victim). The adversary vertex may initially be unknown or tentatively attributed based on similar prior events. The analyst documents the confidence level for each vertex and any assumptions made during initial analysis.
Vertex Population and Evidence Mapping
Each vertex is populated with all available evidence, regardless of whether attribution is certain. The adversary vertex includes any attribution indicators, aliases, or associated groups, even if based on behavioral patterns rather than confirmed identity. The capability vertex captures the specific malware family, exploit, social engineering lure, or technique observed. This includes not just the primary payload but the delivery mechanism, persistence methods, and any observed post-exploitation tools.
The infrastructure vertex records IP addresses, domains, hosting providers, or physical assets used. Infrastructure analysis often provides the strongest pivoting opportunities because adversaries frequently reuse hosting providers, domain registration patterns, or command and control servers across campaigns. The victim vertex documents the targeted individual, system, department, or organization, including victim personas such as specific roles targeted (finance staff, IT administrators, executives with access to sensitive projects).
Confidence levels are critical. High-confidence entries are supported by direct technical evidence such as malware samples, network logs, or forensic artifacts. Medium-confidence entries are supported by behavioral correlation or indirect indicators. Low-confidence entries are analytical assessments based on limited information. Recording confidence levels prevents teams from treating tentative attribution as confirmed intelligence.
Meta-Feature Analysis
The Diamond Model includes two meta-features that extend beyond the core vertices. Socio-political context captures the relationship between adversary and victim, including motivation, geopolitical factors, and strategic objectives. This context helps explain why this particular adversary targeted this particular victim at this particular time. Technology context describes the technical ecosystem enabling the interaction, including operating systems, applications, protocols, and trust relationships exploited.
Meta-feature analysis transforms descriptive intelligence into predictive intelligence. If the socio-political context indicates espionage targeting intellectual property in a specific industry sector, analysts can predict which other organizations in that sector face similar risk. If the technology context reveals dependence on a particular software vulnerability or trust relationship, analysts can assess whether their own environment contains similar attack surfaces.
Pivoting and Campaign Reconstruction
The model's analytical power emerges when single events are connected to others through shared vertices. If the infrastructure vertex in Event A matches the infrastructure vertex in Event B, and Event B has a confirmed adversary attribution, the analyst can assess whether Event A shares that adversary with measurable confidence.
Here's a concrete pivoting scenario: An analyst at a healthcare organization observes a command and control beacon to an unfamiliar IP address. Building a diamond event, the infrastructure vertex contains that IP address. A threat intelligence database search reveals the same IP was used in a ransomware campaign targeting hospital networks six months prior. The analyst pivots to that prior diamond event, inherits the capability and adversary context, and immediately has a working hypothesis: this is consistent with a known ransomware group targeting healthcare.
This hypothesis generates immediate operational value. The team escalates the event, checks for lateral movement indicators consistent with that group's known playbook, and initiates containment procedures before encryption occurs. Without the structured pivoting enabled by the Diamond Model, the analyst might have treated the beacon as a generic malware infection requiring standard incident response rather than a targeted ransomware deployment requiring immediate containment.
Activity Threads and Campaign Construction
Multiple diamond events can be aggregated into higher-order constructs. An Activity Thread chains related events attributable to one adversary against one victim over time, revealing the complete attack progression from initial access through objective achievement. Activity Groups aggregate threads across multiple victims, enabling cross-organizational intelligence sharing. Campaigns represent broader collections of events sharing common adversary, capability, or infrastructure characteristics.
These constructs scale analysis from tactical incident response to strategic threat actor profiling. A single spearphishing event is a tactical concern for one organization. An Activity Thread showing that same adversary's complete kill chain against that organization is a strategic intelligence product. An Activity Group showing the same adversary's campaigns against multiple organizations in the same sector is sector-wide threat intelligence suitable for sharing with information sharing and analysis centers.
Implementation Requirements
The Diamond Model requires disciplined documentation practices. Teams must maintain structured event logs where each record maps to the four vertices with evidence citations and confidence ratings. Many threat intelligence platforms such as MISP, OpenCTI, or commercial equivalents can store Diamond Model-structured data natively or through customization.
The most important implementation decision is training analysts to default to Diamond Model schema during initial triage rather than writing unstructured incident notes. This cultural shift from narrative reporting to structured analysis requires management support and consistent practice. Organizations that implement the Diamond Model successfully embed it into their standard operating procedures for security event analysis, not just post-incident review processes.
Organizations that analyze intrusions without a consistent schema produce knowledge that does not accumulate. Each incident is handled in isolation, lessons are buried in narrative reports, and the next analyst to encounter the same adversary starts from zero. The Diamond Model solves this accumulation problem by creating structured, queryable records that build organizational intelligence over time.
Business Impact and Strategic Value
Security leaders who can present structured adversary profiles to executive stakeholders communicate threat context far more effectively than those who present raw incident counts. A Diamond Model-based threat briefing demonstrates which adversary groups are actively targeting the organization, what capabilities they have deployed, and what infrastructure patterns could enable early detection of their next campaign.
This analytical capability directly supports security investment decisions. If Diamond Model analysis reveals that adversary groups targeting this sector consistently exploit a particular vulnerability class or target specific victim personas (such as employees in mergers and acquisitions roles), the organization can prioritize controls and awareness training accordingly. Executive leadership can understand not just that threats exist, but which specific threats pose the highest risk to their specific business operations.
Diamond Model analysis also improves incident response efficiency. When analysts can quickly pivot from a single indicator to a comprehensive adversary profile, they can predict likely next steps in the attack progression and implement targeted countermeasures rather than generic incident response procedures. This reduces containment time and limits business impact.
Consequences of Unstructured Analysis
Without structured analysis frameworks, organizations frequently misattribute events, miss campaign patterns spanning multiple incidents, and fail to share actionable intelligence with sector partners. The SolarWinds supply chain compromise provides a clear example of these failure modes. Multiple organizations detected anomalous network behavior consistent with the SUNBURST backdoor for months before the campaign was understood as coordinated intrusion activity.
Structured Diamond Model event analysis, consistently applied and shared across affected organizations, would have connected infrastructure and capability patterns earlier in the campaign timeline. The individual suspicious events existed in organizational logs; the analytical framework to connect them into a coherent threat picture was absent or inconsistently applied. Each organization treated their observations as isolated incidents rather than components of a larger campaign.
Common Implementation Misconceptions
A frequent misconception is that the Diamond Model applies only to nation-state or advanced persistent threat analysis. In practice, the model is equally effective for analyzing commodity ransomware, business email compromise, and insider threat events. The framework requires observable events, not sophisticated adversaries. Any organization that can capture network logs, endpoint telemetry, or email headers has sufficient raw material to build diamond events.
Another misconception is that complete attribution is required before Diamond Model analysis can begin. The model explicitly accommodates unknown or uncertain attribution through confidence ratings and inference tracking. Partial information structured consistently is more valuable than complete information documented inconsistently.
CDA approaches the Diamond Model through the lens of the Planetary Defense Model (PDM), specifically within the Risk Governance and Assurance (RGA) domain. In RGA, the core challenge is establishing analytical infrastructure to recognize adversary behavior patterns consistently and produce assurance evidence that can be audited, shared, and acted upon.
CDA's methodology, Perpetual Compliance Assurance (PCA), operates on the principle that compliance is not an event; it is a state. This principle extends directly to threat analysis. A single diamond event documented after an incident is reactive and episodic. PCA-aligned threat analysis embeds Diamond Model schema into daily operations: every security event of interest is immediately structured as a diamond event, confidence levels are assigned, and the record enters a continuously maintained intelligence repository rather than a one-time incident report.
CDA operationalizes the Diamond Model at the process level rather than treating it as a training exercise or post-incident review tool. This means defining in policy exactly which event types trigger formal diamond event records, which analyst roles are responsible for vertex population, and what the review and confidence-updating cycle looks like. CDA integrates Diamond Model outputs directly into RGA domain governance artifacts: adversary capability profiles feed into risk assessments, infrastructure indicators feed into continuous monitoring rules, and victim persona analysis feeds into security awareness programs.
CDA practitioners map Diamond Model Activity Groups to specific threat scenarios in the organization's risk register. When an Activity Group profile is updated because new campaign intelligence becomes available, the corresponding risk scenario is reviewed and controls are assessed against the updated adversary profile. This closes the loop between threat intelligence production and compliance assurance, ensuring that documented risk posture reflects current adversary reality rather than static point-in-time assessments.
• Document every security event of interest as a formal diamond event immediately during triage, not after incident closure; structured records built during investigation retain far more detail and enable faster pivoting than narrative reports written retrospectively.
• Treat unknown vertices as mandatory fields, not optional ones; explicitly marking what you do not know about an adversary, capability, infrastructure, or victim is analytically more honest and more useful than leaving fields blank.
• Pivot on infrastructure and capability vertices first when attribution is uncertain; these vertices are often shared across events and campaigns even when adversary identity is unknown, and they produce actionable detection opportunities faster than attribution efforts.
• Connect your organization's Diamond Model event records to external threat intelligence sources (MISP communities, sector ISACs, MITRE ATT&CK group profiles) to inherit context from others' documented events rather than starting analysis from zero.
• Integrate Diamond Model outputs into your risk register and compliance documentation on a defined review cycle so that documented threat posture reflects current adversary behavior patterns rather than outdated risk assessment assumptions.