Attack Models

Home / Foundations

Foundations

Try it in practice: Use the Attack Model Composer to generate an exportable model from context selections, then use the concepts on this page to strengthen assumptions, primitives, and evidence. When you are ready to operationalize, turn that model into an Evidence Pack to map telemetry, baselines, and validation tasks to each step.

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.

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

FAQ

Is an attack model the same as a threat model?

No. A threat model frames risk and priorities. An attack model specifies the adversary route with prerequisites, actions, and postconditions so you can enumerate paths, test controls, and measure coverage.

What makes a model defensible?

Clear scope, explicit assumptions, and primitives that can be validated. If a step cannot be falsified with evidence, rewrite it until you can test prerequisites, observe indicators, and confirm postconditions.

When should I use a tree versus a graph?

Use a tree to communicate alternatives and strategy. Use a graph when reachability and privileges change over time and you want computed paths, chokepoints, and what becomes possible after each transition.

How do OT and cyber-physical constraints change modeling?

OT models must link cyber progression to process impact. Add safety and availability requirements, deterministic timing realities, protocol semantics, and physics-informed bounds such as ramps, limits, interlocks, and conservation constraints.

How do I validate assumptions without disrupting operations?

Prefer non-invasive evidence: network inventories, configuration baselines, identity paths, historian trends, and read-only queries where permitted. Turn each assumption into a safe validation task and record the evidence source and timestamp.

How do I keep a model current?

Separate stable structure from site-specific facts. Keep the structure versioned, and refresh facts on a cadence aligned with change management so paths update when zoning, access, firmware, or procedures change.

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
• FAQ

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

Companion hubs

• Attack Modeling
• AttackGraphs
• ATT&CK for ICS

Contact

• Email: [email protected]