What is threat modeling?
Threat modeling is a structured method for establishing, during the design of a system, what needs protecting, how an attacker could compromise it and which measures counter those threats. In OT environments the concern is not only data but the physical process: a manipulated PLC can run a pump dry or upset a chemical dosing unit. Threat modeling makes the team answer Adam Shostack’s four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job?
🎯 Why does threat modeling matter so much in OT?
Industrial installations stay in service for twenty to thirty years. A design flaw in the network architecture or a controller is expensive and sometimes almost impossible to fix after handover, because downtime costs money and every change has to be revalidated. Threat modeling therefore belongs in the design phase, which is the idea behind security by design and Cyber-Informed Engineering.
Two parts of IEC 62443 make it explicit:
- IEC 62443-4-1 (product suppliers) — practice 2, Specification of security requirements, contains requirement SR-2 Threat model: every product must have a threat model for its current deployment scope, and the security requirements are checked against it. The model therefore has to stay current as the design evolves.
- IEC 62443-3-2 (asset owners and integrators) — the 2020 standard defines seven steps (ZCR 1 to 7) for risk assessment and system design. In the detailed assessment of ZCR 5, the first step is identify threats: threats are named per zone and conduit.
A supplier seeking certification of its development process, for example under ISASecure SDLA, must therefore be able to show a documented threat model for each product.
🔧 Which threat modeling methods exist?
| Method | Origin | Approach | Fit for OT |
|---|---|---|---|
| STRIDE | Microsoft, Kohnfelder and Garg (1999) | Six threat categories per element of a data flow diagram | Good for products and network design |
| PASTA | UcedaVelez and Morana (2015) | Seven stages, from business objectives to attack simulation and risk analysis | Good when business impact leads |
| Attack trees | Bruce Schneier (1999) | Attacker goal as the root, broken down into sub-paths | Very good for a single critical scenario |
| LINDDUN | KU Leuven | Privacy threats | Limited; mainly where personal data is involved |
| MITRE ATT&CK for ICS | MITRE (2020) | Knowledge base of real attack techniques across twelve tactics | Excellent for grounding threats in reality |
| Crown Jewel Analysis | MITRE | Decomposing the mission down to its critical assets | Prioritising what matters most |
| CCE | Idaho National Laboratory | Four phases, starting from the worst physical consequences | Critical infrastructure |
STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. In OT, tampering (altered setpoints or PLC logic) and denial of service (loss of view and control) usually weigh heaviest. ATT&CK for ICS complements this with tactics that have no IT equivalent, such as Inhibit Response Function and Impair Process Control. Consequence-driven Cyber-Informed Engineering (CCE) reverses the order: it assumes a skilled adversary will get in and works backwards from the high-consequence events.
🏭 How do you build a threat model for a water treatment plant?
Take a drinking water treatment plant with a chemical dosing installation. The model follows the four questions.
- Define the scope — the system covers intake, filtration, chemical dosing and the clean water reservoir. Record what is out of scope, such as office IT.
- Draw assets and data flows — map the components per level of the Purdue Model: sensors and dosing pumps (0), PLCs (1), SCADA server and HMI (2), the historian in the DMZ (3.5) and a supplier who logs in via remote access. Draw the data flows between them.
- Identify trust boundaries — every transition between zones is a trust boundary. In 62443 terms these are the conduits of the zones and conduits model: supplier to DMZ, DMZ to SCADA, SCADA to PLC.
- Name the threats — walk through every element and boundary with STRIDE and map techniques from ATT&CK for ICS to them. Example: an attacker with stolen supplier credentials changes the sodium hydroxide dosing setpoint through the HMI (tampering, Modify Parameter).
- Determine consequences — what is the physical effect? Overdosing could produce harmful drinking water; that is a high-consequence event.
- Choose mitigations — multi-factor authentication and time-limited access for the supplier, setpoint limits enforced in the PLC itself, an independent pH measurement with a hardwired trip, and monitoring for unusual write commands.
- Validate and maintain — check that every threat has a mitigation or an accepted residual risk, and revisit the model with every change.
The PLC limit and the hardwired trip are typical Cyber-Informed Engineering measures: they keep working even when the digital defences fail.
🔄 How does threat modeling differ from risk assessment and HAZOP?
| Characteristic | Threat modeling | Risk assessment | HAZOP |
|---|---|---|---|
| Core question | How could an attacker compromise this system? | How big is the risk and is it acceptable? | What happens if a process parameter deviates? |
| Perspective | Deliberate attack | Likelihood times consequence | Failure, human error, process deviation |
| When | Design and every change | Periodically and on change | Process design and major modifications |
| Output | Threats, attack paths, mitigations | Risk score, security level, residual risk | Deviations, consequences, safeguards |
| Typical participants | Architects, security, engineers | Risk owner, security, management | Process engineers, operators, safety specialists |
The three complement each other. Threat modeling supplies the threats that the risk assessment quantifies, and HAZOP supplies the process consequences that determine which cyberattacks are genuinely dangerous. More and more organisations link the HAZOP to a cyber analysis, often called a cyber PHA, so that safety and security are assessed together.
🧠 Which tools and principles support threat modeling?
- Microsoft Threat Modeling Tool — a free Windows application in which you draw a data flow diagram; it generates STRIDE threats per element.
- OWASP Threat Dragon — free and open source, available as a desktop or web application; supports STRIDE, LINDDUN and the CIA triad among others.
- ATT&CK Navigator and ATT&CK for ICS — for selecting relevant techniques and observed groups such as Sandworm.
- Whiteboard and sticky notes — for a first model, a session with engineers who know the installation is often enough.
The Threat Modeling Manifesto of 2020, written by a working group including Adam Shostack and Kim Wuyts, captures the essence in five values. Among other things it favours finding and fixing design issues over checkbox compliance, people and collaboration over methods and tools, and continuous refinement over a single delivery. For OT this means involving operators and process engineers, not just the security team.
❓ Frequently asked questions
When should you carry out threat modeling?
Threat modeling is best carried out in the design phase, before the network and controllers are built. You then revisit the threat model with every significant change, such as a new remote connection or cloud integration. For existing installations a first threat model is still worthwhile as a baseline for improvements.
Is threat modeling mandatory under IEC 62443?
For product suppliers it is: IEC 62443-4-1 requires in SR-2 that every product has a threat model. For asset owners and integrators, IEC 62443-3-2 requires threats to be identified per zone and conduit during the detailed risk assessment, which in practice amounts to threat modeling.
Which threat modeling method suits OT best?
In OT a combination works best: STRIDE on a data flow diagram to find threats systematically, and MITRE ATT&CK for ICS to ground them in real attack techniques. For the most critical scenarios, attack trees or CCE add depth to the threat modeling.
How long does a threat modeling session take?
A first threat modeling session for one process area typically takes a few half-days with a small team of architect, engineer and security specialist. For a complete installation, or a product heading for certification, it becomes a project of several weeks. Maintaining the model afterwards takes far less time.
What is the difference between threat modeling and a pentest?
Threat modeling is a paper analysis of what could go wrong, carried out before and during design. A pentest tests an existing system hands-on for vulnerabilities. A good threat model tells the pentester which attack paths matter most.
Who should take part in threat modeling for OT?
Threat modeling for OT should ideally involve process engineers, operators, an OT architect and a security specialist. Process people know which deviations are dangerous; security people know how attackers operate. Without both perspectives the model misses consequences or attack paths.
📌 In summary
Threat modeling answers, before an installation is built, how an attacker could compromise the physical process and which measures prevent that. In OT you combine STRIDE, MITRE ATT&CK for ICS and a consequence-driven view, anchored in IEC 62443-4-1 and IEC 62443-3-2, and you keep the model up to date for as long as the installation is in service.