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

  1. Schneier: Attack Trees (1999)
  2. Caltagirone et al.: Diamond Model (2013)
  3. Hutchins et al.: Intrusion Kill Chain (2011)
  4. MITRE ATT&CK Data and Tools
  5. MITRE CAPEC
  6. MITRE CWE
  7. NIST SP 800-154: Guide to Data-Centric System Threat Modeling
  8. NIST SP 800-82 Rev. 2: Guide to Industrial Control Systems Security

Model Selection Checklist

If your model cannot be tested, it is likely a narrative. If it can be tested, it can be improved.

Related Domains

Contact