An incident is unfolding. You see a suspicious process on PROD-DC01 — powershell.exe spawning net.exe, querying domain admins. You file the ticket. Two weeks later, a different SOC at a different company sees the same pattern. They have no way to know you’ve seen it. Their analyst writes a different ticket, using different terminology. The same adversary technique gets documented twice, in two places, incompatibly.
That’s the problem security frameworks solve: a shared vocabulary for adversary behavior, so that what one team discovers, every team can act on.
There are three frameworks you’ll encounter repeatedly as a detection engineer. Understanding why each was built — and what it’s bad at — tells you exactly when to use which.
The Lockheed Martin Kill Chain
The Kill Chain describes an intrusion as seven sequential stages:
| Stage | What the adversary does |
|---|---|
| 1. Reconnaissance | Research the target — LinkedIn, job postings, public DNS |
| 2. Weaponization | Build or acquire a payload (malicious doc, exploit) |
| 3. Delivery | Send the phishing email, exploit the public-facing service |
| 4. Exploitation | Execute code on the target machine |
| 5. Installation | Drop a persistent mechanism (RAT, scheduled task) |
| 6. Command & Control | Establish a channel back to attacker infrastructure |
| 7. Actions on Objectives | Exfil data, move laterally, deploy ransomware |
What it’s good for: Reasoning about where in an intrusion you can intervene. If you detect Delivery, you stopped it earlier than if you only detect Actions on Objectives. Early detection = smaller blast radius.
What it’s bad for: Specificity. “Execution” is not a telemetry source. The Kill Chain doesn’t tell you which Windows Event IDs to collect, which process relationships are suspicious, or how to write a query.
It also assumes linearity. Modern adversaries don’t always follow stages in order. An insider threat may skip Reconnaissance through Actions on Objectives in a single session.
The Diamond Model
The Diamond Model represents every intrusion event as a relationship between four vertices:
Adversary
/ \
Infrastructure Capability
\ /
Victim- Adversary — the threat actor
- Capability — the tools, malware, or techniques used
- Infrastructure — servers, domains, IPs used by the adversary
- Victim — the target organization or individual
The model’s power is in pivoting: you know an IP address (infrastructure), so you pivot to find other victims it hit, then to the malware families hosted there, then to the adversary cluster.
What it’s good for: Threat intelligence correlation. Linking campaigns. Attribution analysis.
What it’s bad for: Writing detections. The Diamond Model doesn’t tell you which process events to alert on or which log sources to collect.
MITRE ATT&CK — Why It Won
ATT&CK solves the problems both prior frameworks leave unsolved:
-
Specific behaviors, not stages. Instead of “Execution,” ATT&CK gives you
T1059.001 — PowerShell. That’s a specific thing you can write a Sigma rule for. -
Mapped to real data sources. Every technique page lists which data sources (Process Creation, Windows Registry, Network Traffic) can detect it. That maps directly to your telemetry.
-
Real adversary procedures. Each technique includes “Procedure Examples” — documented use by real threat groups. APT29 used T1059.001 for X. Lazarus Group used T1566.002 for Y.
-
Community-maintained. Over 500 contributors. Updated as adversaries evolve.
The comparison in one sentence: Kill Chain tells you where you are in an intrusion. Diamond Model tells you who is attacking you. ATT&CK tells you what specific thing they’re doing and how to detect it.
Intelligence-Driven Computer Network Defense— Lockheed Martin (2011) The Diamond Model of Intrusion Analysis— Caltagirone, Pendergast, Betz (2013) ATT&CK Design and Philosophy— MITRE (2020)