Executing Diamond Model Analysis

When to Use

Use this skill when:

Analyzing a confirmed intrusion to understand the complete adversary-capability-infrastructure-victim relationship
Attempting to link two or more incidents to a common threat actor using shared infrastructure or capability indicators
Structuring a finished intelligence product that explains adversary behavior in a formal analytic framework

Do not use this skill during active incident containment — Diamond Model analysis is a post-event or concurrent intelligence activity, not a response procedure.

Prerequisites

Completed incident investigation data: logs, forensic artifacts, malware samples, network captures
Access to MITRE ATT&CK, VirusTotal, Shodan, and passive DNS databases for vertex enrichment
Link analysis platform (Maltego, Analyst's Notebook, or graph database like Neo4j) for multi-event correlation
Familiarity with the original Diamond Model paper: Caltagirone, Pendergast, Betz (2013)

Workflow

Step 1: Populate the Four Core Vertices

Adversary Vertex: Who conducted the activity?

Operator (direct keyboard access) vs. Customer (who commissioned the attack) distinction
Attribution confidence level (Low/Medium/High) with supporting evidence
Known aliases, ATT&CK Group ID, sector targeting history

Capability Vertex: What tools and techniques were used?

Malware families: names, YARA signatures, behavioral characteristics
Exploits: CVEs exploited, exploit kit identifiers
ATT&CK techniques employed (T-numbers)
Capability sophistication: commodity (off-shelf) vs. custom-developed

Infrastructure Vertex: What systems were used to conduct the attack?

C2 servers: IPs, domains, hosting providers, certificate fingerprints
Delivery infrastructure: phishing domains, watering holes, compromised servers
Operational relay boxes (ORBs): intermediate proxies obscuring true origin

Victim Vertex: Who/what was targeted?

Organization profile: sector, size, geography, technology stack
Personae: specific individuals targeted (CISO, finance team, executives)
Assets targeted: intellectual property, financial systems, OT/ICS

Step 2: Identify Vertex Relationships (Edges)

Document relationships between vertices:

Adversary → uses → Capability (malware development/deployment relationship)
Adversary → uses → Infrastructure (operational relationship)
Infrastructure → delivers → Capability (technical delivery mechanism)
Capability → targets → Victim (attack surface relationship)
Infrastructure → attacks → Victim (direct connection)

Each edge should be supported by at least two independent data points (evidence-backed, not inferred).

Step 3: Apply Meta-Features for Enrichment

Meta-features provide additional context beyond the four vertices:

Timestamp: When did each phase of the intrusion occur? Map to cyber kill chain phases.

Phase: Which kill chain phase does this activity represent?

Reconnaissance → Weaponization → Delivery → Exploitation → Installation → C2 → Actions on Objectives

Direction: Attack direction (external-to-internal, internal-to-external for exfiltration)

Result: Outcome of each adversary action (success/failure/partial)

Resources: Adversary resources invested (time, money, infrastructure cost, zero-day usage)

Step 4: Cluster Events Using Vertex Pivoting

Apply Diamond Model pivoting logic to cluster related incidents:

Infrastructure pivot: Same C2 IP across multiple incidents → same or related adversary
Capability pivot: Same malware hash or YARA signature → same tool developer
Adversary pivot: Same victimology pattern (sector + geography + asset type) → same targeting criteria
Victim pivot: Same victim across multiple incidents → sustained campaign against organization

Incident A: IP 185.220.101.x, domain evil-redir[.]com, SUNBURST malware variant
Incident B: IP 185.220.101.y (same /24), domain redir-evil[.]com, modified SUNBURST
→ Infrastructure cluster (same /24 block) + Capability cluster (same malware family) = High confidence same actor

Step 5: Produce Structured Analytic Output

Document analysis in structured format:

Diamond event diagram for each discrete intrusion event
Activity thread connecting multiple events across time
Activity group (cluster) with confidence assessment
Competing hypotheses analysis: alternative attribution explanations with evidence weighting (ACH methodology)

Key Concepts

Term	Definition
Diamond Model	Intrusion analysis framework with four vertices (adversary, capability, infrastructure, victim) connected by edges representing relationships
Activity Thread	A time-ordered sequence of Diamond events representing a single adversary operation
Activity Group	A cluster of Diamond events linked by shared vertex properties, suggesting a common adversary
Adversary Operator vs. Customer	Diamond Model distinction: operator has keyboard access; customer directs/funds the operation
Pivoting	Using a known vertex value to discover additional related events or infrastructure (e.g., one IP revealing 20 more C2 domains)
ACH	Analysis of Competing Hypotheses — structured analytic technique for evaluating evidence against multiple attribution hypotheses

Tools & Systems

Maltego: Graph-based link analysis ideal for visualizing Diamond vertex relationships and infrastructure pivots
Neo4j: Graph database for storing and querying complex Diamond event clusters at scale; supports Cypher query language
MISP: Diamond Model meta-feature tagging supported via MISP galaxies and correlation engine
Analyst's Notebook (IBM i2): Law enforcement/intelligence-grade link analysis for adversary relationship mapping

Common Pitfalls

Conflating operator and customer: Not distinguishing between who conducted the attack and who directed it leads to incorrect attribution targeting.
Infrastructure re-use assumption: Bulletproof hosting providers sell the same IP blocks to multiple criminal groups. Shared IP ≠ same actor without additional corroboration.
Analysis without confidence levels: Diamond Model conclusions presented without confidence qualifiers appear more certain than the evidence supports.
Ignoring the victim vertex: Analysis often over-focuses on adversary/capability and neglects victim characterization, which provides crucial context for predicting future targeting.
Static diagrams: Diamond events should be time-stamped and evolve as new evidence emerges. Static diagrams without version history mask analytic evolution.

Verification Criteria

Confirm successful execution by validating:

[ ] All prerequisite tools and access requirements are satisfied
[ ] Each workflow step completed without errors
[ ] Output matches expected format and contains expected data
[ ] No security warnings or misconfigurations detected
[ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

SOC 2: CC7.1 (Monitoring), CC7.2 (Anomaly Detection)
ISO 27001: A.6.1 (Threat Intelligence), A.16.1 (Security Incident Management)
NIST 800-53: PM-16 (Threat Awareness), RA-3 (Risk Assessment), SI-5 (Security Alerts)
NIST CSF: ID.RA (Risk Assessment), DE.AE (Anomalies & Events)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

# Install via CLI
npx claw-grc skills add executing-diamond-model-analysis

# Or load dynamically via MCP
grc.load_skill("executing-diamond-model-analysis")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

SHA-256 chain hashing ensures no step can be modified after execution
Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.

Executing Diamond Model Analysis

When to Use

Use this skill when:

Analyzing a confirmed intrusion to understand the complete adversary-capability-infrastructure-victim relationship
Attempting to link two or more incidents to a common threat actor using shared infrastructure or capability indicators
Structuring a finished intelligence product that explains adversary behavior in a formal analytic framework

Do not use this skill during active incident containment — Diamond Model analysis is a post-event or concurrent intelligence activity, not a response procedure.

Prerequisites

Completed incident investigation data: logs, forensic artifacts, malware samples, network captures
Access to MITRE ATT&CK, VirusTotal, Shodan, and passive DNS databases for vertex enrichment
Link analysis platform (Maltego, Analyst's Notebook, or graph database like Neo4j) for multi-event correlation
Familiarity with the original Diamond Model paper: Caltagirone, Pendergast, Betz (2013)

Workflow

Step 1: Populate the Four Core Vertices

Adversary Vertex: Who conducted the activity?

Operator (direct keyboard access) vs. Customer (who commissioned the attack) distinction
Attribution confidence level (Low/Medium/High) with supporting evidence
Known aliases, ATT&CK Group ID, sector targeting history

Capability Vertex: What tools and techniques were used?

Malware families: names, YARA signatures, behavioral characteristics
Exploits: CVEs exploited, exploit kit identifiers
ATT&CK techniques employed (T-numbers)
Capability sophistication: commodity (off-shelf) vs. custom-developed

Infrastructure Vertex: What systems were used to conduct the attack?

C2 servers: IPs, domains, hosting providers, certificate fingerprints
Delivery infrastructure: phishing domains, watering holes, compromised servers
Operational relay boxes (ORBs): intermediate proxies obscuring true origin

Victim Vertex: Who/what was targeted?

Organization profile: sector, size, geography, technology stack
Personae: specific individuals targeted (CISO, finance team, executives)
Assets targeted: intellectual property, financial systems, OT/ICS

Step 2: Identify Vertex Relationships (Edges)

Document relationships between vertices:

Adversary → uses → Capability (malware development/deployment relationship)
Adversary → uses → Infrastructure (operational relationship)
Infrastructure → delivers → Capability (technical delivery mechanism)
Capability → targets → Victim (attack surface relationship)
Infrastructure → attacks → Victim (direct connection)

Each edge should be supported by at least two independent data points (evidence-backed, not inferred).

Step 3: Apply Meta-Features for Enrichment

Meta-features provide additional context beyond the four vertices:

Timestamp: When did each phase of the intrusion occur? Map to cyber kill chain phases.

Phase: Which kill chain phase does this activity represent?

Reconnaissance → Weaponization → Delivery → Exploitation → Installation → C2 → Actions on Objectives

Direction: Attack direction (external-to-internal, internal-to-external for exfiltration)

Result: Outcome of each adversary action (success/failure/partial)

Resources: Adversary resources invested (time, money, infrastructure cost, zero-day usage)

Step 4: Cluster Events Using Vertex Pivoting

Apply Diamond Model pivoting logic to cluster related incidents:

Infrastructure pivot: Same C2 IP across multiple incidents → same or related adversary
Capability pivot: Same malware hash or YARA signature → same tool developer
Adversary pivot: Same victimology pattern (sector + geography + asset type) → same targeting criteria
Victim pivot: Same victim across multiple incidents → sustained campaign against organization

Incident A: IP 185.220.101.x, domain evil-redir[.]com, SUNBURST malware variant
Incident B: IP 185.220.101.y (same /24), domain redir-evil[.]com, modified SUNBURST
→ Infrastructure cluster (same /24 block) + Capability cluster (same malware family) = High confidence same actor

Step 5: Produce Structured Analytic Output

Document analysis in structured format:

Diamond event diagram for each discrete intrusion event
Activity thread connecting multiple events across time
Activity group (cluster) with confidence assessment
Competing hypotheses analysis: alternative attribution explanations with evidence weighting (ACH methodology)

Key Concepts

Term	Definition
Diamond Model	Intrusion analysis framework with four vertices (adversary, capability, infrastructure, victim) connected by edges representing relationships
Activity Thread	A time-ordered sequence of Diamond events representing a single adversary operation
Activity Group	A cluster of Diamond events linked by shared vertex properties, suggesting a common adversary
Adversary Operator vs. Customer	Diamond Model distinction: operator has keyboard access; customer directs/funds the operation
Pivoting	Using a known vertex value to discover additional related events or infrastructure (e.g., one IP revealing 20 more C2 domains)
ACH	Analysis of Competing Hypotheses — structured analytic technique for evaluating evidence against multiple attribution hypotheses

Tools & Systems

Maltego: Graph-based link analysis ideal for visualizing Diamond vertex relationships and infrastructure pivots
Neo4j: Graph database for storing and querying complex Diamond event clusters at scale; supports Cypher query language
MISP: Diamond Model meta-feature tagging supported via MISP galaxies and correlation engine
Analyst's Notebook (IBM i2): Law enforcement/intelligence-grade link analysis for adversary relationship mapping

Common Pitfalls

Conflating operator and customer: Not distinguishing between who conducted the attack and who directed it leads to incorrect attribution targeting.
Infrastructure re-use assumption: Bulletproof hosting providers sell the same IP blocks to multiple criminal groups. Shared IP ≠ same actor without additional corroboration.
Analysis without confidence levels: Diamond Model conclusions presented without confidence qualifiers appear more certain than the evidence supports.
Ignoring the victim vertex: Analysis often over-focuses on adversary/capability and neglects victim characterization, which provides crucial context for predicting future targeting.
Static diagrams: Diamond events should be time-stamped and evolve as new evidence emerges. Static diagrams without version history mask analytic evolution.

Verification Criteria

Confirm successful execution by validating:

[ ] All prerequisite tools and access requirements are satisfied
[ ] Each workflow step completed without errors
[ ] Output matches expected format and contains expected data
[ ] No security warnings or misconfigurations detected
[ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

SOC 2: CC7.1 (Monitoring), CC7.2 (Anomaly Detection)
ISO 27001: A.6.1 (Threat Intelligence), A.16.1 (Security Incident Management)
NIST 800-53: PM-16 (Threat Awareness), RA-3 (Risk Assessment), SI-5 (Security Alerts)
NIST CSF: ID.RA (Risk Assessment), DE.AE (Anomalies & Events)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

# Install via CLI
npx claw-grc skills add executing-diamond-model-analysis

# Or load dynamically via MCP
grc.load_skill("executing-diamond-model-analysis")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

SHA-256 chain hashing ensures no step can be modified after execution
Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.

Prerequisites

Executing Diamond Model Analysis

When to Use

Prerequisites

Workflow

Step 1: Populate the Four Core Vertices

Step 2: Identify Vertex Relationships (Edges)

Step 3: Apply Meta-Features for Enrichment

Step 4: Cluster Events Using Vertex Pivoting

Step 5: Produce Structured Analytic Output

Key Concepts

Tools & Systems

Common Pitfalls

Verification Criteria

Compliance Framework Mapping

Deploying This Skill with Claw GRC

Agent Execution

Audit Trail Integration

Continuous Compliance

Use with Claw GRC Agents

Tags

Related Skills

Analyzing Cyber Kill Chain

Analyzing Threat Intelligence Feeds

Profiling Threat Actor Groups

Analyzing Campaign Attribution Evidence

Automating IOC Enrichment

Building Threat Actor Profile from OSINT

Prerequisites

Executing Diamond Model Analysis

When to Use

Prerequisites

Workflow

Step 1: Populate the Four Core Vertices

Step 2: Identify Vertex Relationships (Edges)

Step 3: Apply Meta-Features for Enrichment

Step 4: Cluster Events Using Vertex Pivoting

Step 5: Produce Structured Analytic Output

Key Concepts

Tools & Systems

Common Pitfalls

Verification Criteria

Compliance Framework Mapping

Deploying This Skill with Claw GRC

Agent Execution

Audit Trail Integration

Continuous Compliance

Use with Claw GRC Agents

Tags

Related Skills

Analyzing Cyber Kill Chain

Analyzing Threat Intelligence Feeds

Profiling Threat Actor Groups

Analyzing Campaign Attribution Evidence

Automating IOC Enrichment

Building Threat Actor Profile from OSINT