Foundations
An attack model is a reasoning artifact. It expresses how an attacker can move through a system by satisfying prerequisites, taking actions, and producing effects. Unlike a generic risk list, an attack model is designed to be executed by humans or machines: you can enumerate paths, test controls, and update it when the environment changes.
Key Definitions
Threat modeling is a risk framing practice that asks what matters and what could go wrong. Attack modeling is a more concrete layer that describes the adversary route, step by step, including dependencies. In practice, a good program uses both: threat modeling to choose what to model, attack modeling to make the work precise and repeatable.
A Practical Taxonomy of Attack Models
Attack models are not one thing. The right choice depends on whether you care about alternatives, sequences, computed reachability, or operational mapping.
| Model family | Representation | Best for | Typical inputs | Typical outputs |
|---|---|---|---|---|
| Attack trees | Goal decomposition | Design time analysis and communication | Goals, sub goals, assumptions | Alternative strategies and choke points |
| Attack defense trees | Tree with explicit defenses | Control placement and what breaks a branch | Tree plus controls | Residual paths after mitigations |
| Attack graphs | States and edges | Multi stage path computation | Inventory, connectivity, vulnerabilities | Reachable states and attack paths |
| Probabilistic graphs | Bayesian or Markov variants | Uncertainty and likelihood reasoning | Graph plus probabilities | Path likelihoods and risk ranking |
| Intrusion lifecycles | Stages in time | Response playbooks and emulation | Observed behavior and intel | Structured narratives and playbooks |
| Technique knowledge bases | Techniques and relationships | Detection and control mapping | Telemetry, detections, tools | Coverage views and gap analysis |
| Attack patterns and weaknesses | Patterns and root causes | Secure design and secure coding | Designs, code, common flaws | Preventable classes of weakness |
The Building Blocks of a Strong Attack Model
Most modeling failures come from missing primitives. If you want a model that survives contact with reality, explicitly define:
- Objective: the attacker goal in measurable terms.
- Assets: what is valuable, what is safety critical, and what is mission critical.
- Trust boundaries: where assumptions about identity, integrity, and authority change.
- Attacker capability: access level, skills, time, and constraints.
- Prerequisites: conditions that must be true before a step can happen.
- Actions: what the attacker does, described at the right abstraction level.
- Postconditions: what becomes true after the step, including new privileges or new reachability.
- Controls: what prevents, detects, limits, or recovers, and what evidence shows it actually works.
Selecting the Right Model
Use this rule of thumb: if you want alternatives, start with a tree; if you want computed reachability, use a graph; if you want operational mapping, use technique and pattern knowledge bases; if you want uncertainty, use probabilistic variants.
Cyber-Physical Systems and OT
OT and CPS environments force a higher bar. Availability and safety often dominate confidentiality. Assets are physical processes, not just data. Patch cycles are slower, and constraints like deterministic timing, legacy protocols, and plant downtime shape what attacks are feasible and what defenses are realistic.
A useful OT attack model links cyber steps to process impact. It captures where an attacker can modify logic, manipulate setpoints, spoof sensor readings, or disrupt communications, and it documents the physical constraints that bound what can happen next.
Operationalization
A model becomes valuable when it drives action. Map paths to detections, hardening tasks, and incident response playbooks. When you can, represent behaviors in machine readable formats so your model can power automation and reporting.
Key References
Model Selection Checklist
- Define the objective and scope
- Pick a representation
- Define primitives and assumptions
- Add OT and CPS constraints
- Map to controls and evidence
- Use primary references
If your model cannot be tested, it is likely a narrative. If it can be tested, it can be improved.