STRIDE was designed to find bugs in software. Critical national infrastructure does not have a bug problem. It has an adversary problem. The distinction matters enormously.
## The wrong tool for the wrong threat
In enterprise IT security, threat modelling has a well-worn rhythm. You take a system, you apply STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. You then produce a list of threats against each component, you rate them with DREAD or CVSS, and you feed the output into a backlog. It is a reasonable process for the context it was designed for where software systems where the primary concern is vulnerability exploitation by opportunistic attackers seeking data or access.
Critical national infrastructure is a different context in almost every meaningful dimension. The adversary profile is different. The consequence profile is different. The asset classes are different. The time horizons are different. And the thing you are ultimately trying to protect: the continued safe operation of a physical process, is not something that STRIDE was designed to reason about.
This is not a criticism of STRIDE. It is a precise tool for a specific problem. The issue arises when practitioners reach for it in environments where it does not fit, produce outputs that feel methodologically rigorous, and then build security programmes around conclusions that have systematically missed the most important threats.
In this post I want to set out what a threat modelling approach for critical national infrastructure, specifically in energy and utilities contexts, should look like: what frameworks apply, how they need to be adapted and combined, and what the outputs should actually drive. This is not a methodology review. It is a practitioner account of what works and what the gaps are in current practice.
## Part 1: Why the standard frameworks fall short in CNI contexts
To understand why standard threat modelling frameworks need augmentation in CNI environments, it helps to be specific about what they were built to analyse and what assumptions they embed.
STRIDE, developed at Microsoft in the late 1990s, is a threat classification scheme for software systems. Its categories map reasonably well to the trust boundaries in a software architecture diagram and help developers think systematically about how a component might be attacked. What it does not do is reason about physical consequences, adversary intent at the strategic level, or the specific capabilities and behaviours of sophisticated threat actors. A STRIDE analysis of an industrial control system architecture will correctly identify that a PLC’s firmware could be tampered with, but it will not tell you that the specific tamper technique documented in TRITON involved overwriting safety function memory in a way designed to survive a process restart and activate only under specific process conditions. That level of adversary sophistication is invisible to STRIDE.
DREAD, Damage, Reproducibility, Exploitability, Affected users, Discoverability, is a risk scoring approach often paired with STRIDE. It has been widely criticised in enterprise contexts for its subjectivity, and those criticisms apply with even more force in CNI contexts. “Affected users” is a category that makes sense for a consumer application. It does not map cleanly to the consequence of a substation protection system being disabled during a fault, where the “affected users” might be a transmission network and the “damage” might be a cascading outage across a region.
CVSS — Common Vulnerability Scoring System — scores individual vulnerabilities against a standardised set of base metrics: attack vector, attack complexity, privileges required, user interaction, scope, and three CIA impact metrics. CVSS is useful for prioritising patching in enterprise environments where you are managing a large vulnerability estate. It does not model adversary behaviour, it does not account for the operational context of the affected system, and its CIA impact metrics do not distinguish between the loss of availability of an email server and the loss of availability of a turbine protection system. Both might score identically on CVSS. The operational and safety consequences are orders of magnitude apart.
The deeper issue with all of these frameworks, applied to CNI contexts, is that they are inherently vulnerability-centric. They ask: what is wrong with this system that an attacker could exploit? That is a useful question, but it is not the primary question for a CNI security architect. The primary question is: what does an adversary want to achieve, what are they capable of, and what path through our environment would allow them to achieve it? The answer to that question cannot be derived from a list of vulnerabilities in a component inventory.
## Part 2: Adversary-centric thinking: why intent matters in CNI
In enterprise IT security, we often abstract the adversary to a generic “attacker” with the goal of access, data theft, or financial gain. This abstraction is sufficient for many purposes: the ransomware operator, the credential stuffer, the opportunistic intrusion set: these actors share enough common behaviour that a generic attacker model is a useful approximation.
In critical national infrastructure, this abstraction is dangerous. The adversary landscape for energy infrastructure includes actors whose objectives are not data theft or financial gain. They include nation-state actors, specifically, the offensive cyber programmes of states with strategic interests in disrupting energy supply to their adversaries — whose goals include pre-positioning for potential conflict, demonstrating capability, and in some cases causing physical damage or prolonged operational disruption. These actors are patient, technically sophisticated, well-resourced, and willing to invest years in a campaign that has no immediate visible payoff. Their tools and techniques are documented in government advisories and threat intelligence reporting, and they are qualitatively different from the commodity threat actor that most enterprise security programmes are calibrated against.
CISA, NCSC, and their international counterparts have published extensive attribution and technique documentation for state-sponsored actors targeting energy infrastructure. VOLTZITE, KAMACITE, ELECTRUM; the threat group nomenclature used by Dragos, and their equivalents in the MITRE ATT&CK for ICS threat actor catalogue represent specific adversary profiles with documented capabilities, preferred techniques, and known targeting patterns. A threat model for a major energy operator that does not account for these actors is not a threat model. It is a vulnerability list dressed up as one.
The implication for threat modelling methodology is that adversary intent must be the starting point, not a post-hoc consideration. Before you can model the threats to a system, you need to understand who wants to attack it, what they want to achieve, and what they are capable of. That understanding then drives your analysis of which attack paths are plausible, which controls are relevant, and which residual risks require the most urgent attention.
## Part 3: PASTA — a framework that starts with adversary objectives
Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat modelling methodology that was developed precisely because its creators recognised the limitations of vulnerability-centric approaches. Unlike STRIDE, which starts with system components, PASTA starts with business objectives and works through to attack simulation in a structured seven-stage process.
The seven stages are:
Stage 1 — Define business objectives. What does this system or process exist to do? What are the business consequences of its failure? In a CNI context, this means being explicit about the operational and safety consequences of different failure modes, not just the financial cost of downtime, but the process safety implications, the regulatory consequences, and the potential for harm to people and the environment. This stage forces engagement with operations and HSE functions at the outset, which is where those conversations belong.
Stage 2 — Define the technical scope. What systems, components, and data flows are in scope for this analysis? This is equivalent to the system decomposition step in STRIDE, but the scope in a CNI context must explicitly include the physical process and the interfaces between digital control systems and physical actuators. A threat model that stops at the network boundary and does not follow the consequence chain into the physical process is incomplete.
Stage 3 — Application decomposition. Decompose the system into its components, data flows, and trust boundaries. In OT terms, this means mapping the Purdue model hierarchy, documenting the conduits between zones, and identifying every interface between the digital system and the physical process. This stage produces the architecture artefacts that subsequent analysis will reference.
Stage 4 — Threat analysis. Identify threats relevant to the environment and the adversary profile. This is where PASTA diverges most sharply from STRIDE: rather than enumerating threats by category against each component, you are identifying specific threat actors, with their documented capabilities and objectives — and the threat scenarios they represent. This stage should draw directly on current threat intelligence, including sector-specific reporting from E-ISAC, Dragos, CISA ICS-CERT advisories, and NCSC.
Stage 5 — Vulnerability and weakness analysis. Identify vulnerabilities in the system that could be exploited by the threats identified in Stage 4. Note the sequencing: adversary and threat first, then vulnerability. This prevents the common failure mode where a long list of low-consequence vulnerabilities draws attention away from the small number of high-consequence paths that a sophisticated adversary would actually exploit.
Stage 6 — Attack modelling. Construct attack trees or attack graphs that represent the specific paths an adversary might take to achieve their objectives, given the vulnerabilities and architecture identified in the previous stages. This is where the analysis becomes most valuable for architectural decision-making: an attack tree is a concrete representation of the choices an adversary must make and the controls that would interrupt each branch. It makes the security architecture legible to a non-security audience in a way that a vulnerability list never can.
Stage 7 — Risk and impact analysis. Quantify the risk associated with each attack scenario and map it to the business objectives defined in Stage 1. In a CNI context, this means being explicit about the operational and safety consequences of each scenario, not just the financial exposure. A scenario that results in loss of process visibility for four hours has different consequences at a gas processing plant than at a corporate data centre.
PASTA’s strength in CNI contexts is its explicit linkage between adversary intent, attack paths, and business/operational consequences. Its weakness is that it was designed primarily for software and IT systems, and its decomposition vocabulary does not naturally accommodate the Purdue model hierarchy or the specific characteristics of industrial protocols and embedded OT devices. It requires adaptation for OT contexts, which I will address below.
## Part 4: MITRE ATT&CK for ICS: the adversary behaviour catalogue
If PASTA provides the process structure for CNI threat modelling, MITRE ATT&CK for ICS provides the adversary behaviour vocabulary. Released in 2020 and maintained by MITRE with input from the industrial security community, ATT&CK for ICS is a structured knowledge base of adversary tactics, techniques, and procedures (TTPs) specific to industrial control system environments.
The matrix is organised around eleven tactics — the adversary’s high-level objectives at each stage of an attack:
- Initial Access — how the adversary enters the target environment (spear-phishing, internet-exposed devices, supply chain compromise, external remote services)
- Execution — how the adversary runs code or commands
- Persistence — how the adversary maintains access across reboots and maintenance windows
- Privilege Escalation — how the adversary moves to higher-privilege accounts or contexts
- Evasion — how the adversary avoids detection
- Discovery — how the adversary understands the target environment (network scanning, device enumeration, I/O module discovery)
- Lateral Movement — how the adversary moves between systems and zones
- Collection — how the adversary gathers information about the process (I/O image read, point tag identification)
- Command and Control — how the adversary communicates with compromised systems
- Inhibit Response Function — how the adversary prevents the target from detecting or responding to an attack (alarm suppression, safety system bypass)
- Impair Process Control — how the adversary interferes with the physical process (rogue command, modify control logic, manipulate I/O)
The final two tactics: Inhibit Response Function and Impair Process Control, have no equivalent in the enterprise ATT&CK matrix, because they describe objectives that are specific to environments where digital systems interface with physical processes. TRITON’s targeting of the Triconex SIS is documented under Inhibit Response Function. The Industroyer malware’s use of IEC 104 to send native protocol commands to substation equipment is documented under Impair Process Control. These are not theoretical techniques. They are documented adversary behaviours against real infrastructure.
Using ATT&CK for ICS in threat modelling practice
The most effective use of ATT&CK for ICS in a threat modelling exercise is as a technique enumeration tool at Stage 4 of the PASTA process. Once you have identified the relevant threat actors for your environment, based on your sector, your geopolitical exposure, your known adversary interest, you can map those actors to their documented techniques in the ATT&CK for ICS matrix and ask, for each technique: does our architecture make this technique possible? What controls would detect or prevent it? What compensating controls exist if primary controls are unavailable?
This produces a materially different output from a STRIDE analysis. Rather than a list of component-level vulnerabilities, you get a structured assessment of your defence against specific, documented adversary behaviours. The gaps identified are specific and actionable: “We have no detection capability for T0845 (Program Upload/Download) on our Level 1 network” is a more useful finding than “PLC firmware tampering is a potential threat.”
ATT&CK for ICS also provides a common vocabulary for communicating threat findings to stakeholders who may be unfamiliar with industrial security specifics. A control system engineer may not know what a “living off the land” technique is, but they understand what it means for an adversary to use legitimate engineering software to reprogram a controller — which is exactly what T0873 (Project File Infection) describes.
## Part 5: Process Hazard Analysis as a threat modelling input
One of the most underutilised inputs to OT threat modelling is the process hazard analysis (PHA) or HAZOP (Hazard and Operability Study) documentation that responsible energy operators already maintain for process safety purposes.
PHA/HAZOP is a systematic methodology for identifying process hazards: conditions in which the physical process could deviate from its intended behaviour in ways that cause safety events. A HAZOP study of a gas compression facility will document, in exhaustive detail, every process deviation that could result from equipment failure, valve malfunction, measurement error, or operator error, and the safeguards that exist to prevent or mitigate each deviation.
This documentation is directly relevant to cybersecurity threat modelling, because the cybersecurity threat model for a CNI asset is, at its highest level, a question about how an adversary could cause the physical process to deviate from its intended behaviour. The adversary’s objective: whether it is loss of containment, equipment damage, or prolonged process shutdown, is typically one of the deviations already documented in the HAZOP study.
Integrating PHA/HAZOP into the threat modelling process has several benefits. First, it grounds the cybersecurity analysis in the actual consequence profile of the facility, rather than relying on generic consequence assessments. Second, it provides a structured set of target states: the adversary’s objectives from which you can work backwards to identify the attack paths that would achieve them. Third, it creates a natural bridge between the cybersecurity function and the process safety and HSE functions, which in most organisations operate in separate silos and need to be brought together for CNI security to be taken seriously.
The integration point is the attack tree: for each hazardous deviation identified in the HAZOP, construct an attack tree whose root node is the cybersecurity-induced version of that deviation. The tree then traces backwards through the control systems and network architecture to identify the specific sequences of adversary actions that could produce it. This produces a threat model that is explicitly grounded in process safety consequences, which is the only threat model that will be taken seriously by the operations and HSE leadership of an energy operator.
## Part 6: Consequence-driven prioritisation: the CNI essential
One of the most practically important outputs of a CNI threat modelling exercise is a prioritised list of scenarios — not prioritised by likelihood or CVSS score, but by consequence. This is where the CNI threat modelling approach diverges most sharply from enterprise practice.
In enterprise IT, risk is typically the product of likelihood and impact, with both dimensions assessed across a range of scenarios. In CNI contexts, consequence-driven prioritisation recognises that there is a subset of scenarios: those involving physical harm, environmental damage, or prolonged loss of critical service, where the consequence is so severe that the normal risk calculus breaks down. You do not accept residual risk of a catastrophic safety event because the likelihood is low. You architect to prevent it and put in place safety systems to mitigate it, regardless of your probability estimate.
This is the principle behind the safety integrity level (SIL) system in IEC 61511 and the security level (SL) system in ISA/IEC 62443: certain consequences are so severe that they demand a specified level of protection as a matter of design requirement, not risk prioritisation. The threat model should identify which scenarios fall into this category and ensure they receive the architectural attention they require, before other risk-based prioritisation is applied to the remainder.
In practical terms, this means separating your threat model outputs into at least two categories:
Must-prevent scenarios: those where the consequence of adversary success is physical harm, safety system failure, or loss of critical services at scale. These drive non-negotiable architectural requirements: safety system isolation, redundant protection logic, physical separation of safety networks. No business case justification is required for the controls that address these scenarios. Their implementation is a design constraint.
Risk-managed scenarios: those where the consequence is significant but recoverable: operational disruption, data loss, financial impact, reputational damage. These drive the normal risk-based prioritisation process where likelihood, impact, and control cost are all considered.
Most threat modelling exercises in CNI contexts fail to make this distinction explicit, which produces a prioritised backlog that allocates equal analytical attention to catastrophic and recoverable scenarios. The result is that controls for catastrophic scenarios sometimes lose out to controls for more probable but less severe scenarios in the implementation backlog. That outcome is architecturally indefensible.
## Part 7: Common failure modes in CNI threat modelling practice
Having described what a well-constructed CNI threat model looks like, it is worth being direct about the failure modes I encounter most frequently in practice.
Scope truncation at the IT/OT boundary. Threat models are scoped to the IT environment, with OT included only as an afterthought or an appendix. The consequence chain from digital system to physical process is not modelled. The result is a threat model that correctly identifies risks to corporate systems and completely misses the scenarios where the actual catastrophic consequences live.
Generic threat actor modelling. The threat actor profile is described as “external attacker” or “malicious insider” without reference to the specific adversary groups known to target energy infrastructure. The result is a threat model calibrated to opportunistic commodity attackers, which is irrelevant to the nation-state and sophisticated criminal actors that represent the primary risk to CNI assets.
STRIDE applied to OT architecture diagrams. STRIDE threat categories are applied to a diagram of the OT network, producing a list of spoofing, tampering, and denial-of-service threats against each component. The output looks thorough. It misses the adversary’s actual objective — physical process interference — because STRIDE’s categories do not include “cause a turbine to overspeed” or “disable the emergency shutdown system.”
No integration with process safety. The threat model is produced by the security team without engagement with process engineering or HSE. The consequence analysis relies on generic “operational disruption” assessments rather than the specific, quantified process hazard analysis that already exists for the facility. The result is a threat model that cannot be validated by the people who understand the physical consequences, and therefore cannot credibly inform investment decisions at the operations leadership level.
Point-in-time analysis with no refresh cadence. The threat model is produced once, perhaps during a security project or regulatory compliance exercise, and then filed. The adversary landscape for energy infrastructure evolves continuously — new techniques are documented, new threat actor activity is observed, new vulnerabilities are discovered in OT components. A threat model that is not refreshed against current intelligence becomes misleading within months.
## Part 8: Building a sustainable CNI threat modelling programme
A one-time threat model exercise produces a document. A threat modelling programme produces a living analytical capability that informs security architecture decisions continuously. For CNI operators, the latter is what is required.
The key components of a sustainable programme:
Threat intelligence integration. The threat modelling function must have access to relevant threat intelligence: sector-specific reporting from ISACs (E-ISAC for electricity, WaterISAC, Oil and Natural Gas ISAC), government advisories from CISA ICS-CERT and NCSC, and commercial threat intelligence focused on ICS adversary activity. This intelligence feeds Stage 4 of the PASTA process continuously, ensuring that new adversary techniques are assessed against the current architecture as they are documented.
Architecture change integration. Every significant change to the OT or IT/OT boundary architecture should trigger a threat model update. New remote access paths, new data integrations, new vendor connections, network topology changes: all of these alter the attack surface and may create new paths to high-consequence scenarios. Integrating threat modelling into the change management process is the mechanism for keeping the model current.
Red team and exercise validation. A threat model is a hypothesis about adversary behaviour and its consequences. It should be validated through red team exercises that test the attack paths identified in the model, and through tabletop exercises that test the operational and security response to the scenarios modelled. The findings from exercises should feed back into the threat model, correcting assumptions and identifying gaps.
Cross-functional ownership. The threat modelling programme cannot be owned by the security team alone. It requires substantive input from process engineering (for consequence analysis), operations (for understanding the operational constraints on controls), HSE (for integration with process safety analysis), and IT architecture (for the enterprise-side attack surface). Governance structures that bring these functions together, a security architecture board, a CNI risk committee, are the mechanism for sustaining this collaboration.
## Conclusion: The threat model is the architecture conversation
I want to close with an observation that applies as much to organisational practice as to methodology.
A threat model is not a compliance artefact. It is not a document produced to satisfy a regulatory requirement or a contract obligation. It is the mechanism through which an organisation develops and maintains a shared understanding of what it is defending against, what the consequences of failure are, and what architectural choices are required to manage that risk. In a CNI context, that shared understanding needs to extend across security, operations, engineering, and leadership because the decisions it informs are not purely security decisions. They are operational decisions, investment decisions, and ultimately decisions about the level of risk an organisation and its regulator are prepared to accept.
The frameworks I have described: PASTA for process structure, ATT&CK for ICS for adversary technique vocabulary, PHA/HAZOP integration for consequence grounding, consequence-driven prioritisation for architectural decision-making — are tools in service of that conversation. No framework, applied mechanically, produces a good threat model. What produces a good threat model is analysts with deep knowledge of both the adversary and the system under analysis, working within a structured methodology, with access to current intelligence and the authority to follow the analysis wherever it leads.
In critical national infrastructure, the stakes make that investment non-negotiable. The adversaries targeting energy infrastructure are not waiting for organisations to improve their threat modelling practice. They are already inside some of those organisations, conducting their own version of this analysis from the adversary’s perspective.
The question is whether the defender’s analysis is good enough to find them first.
## Key references and further reading
- MITRE ATT&CK for ICS — attack.mitre.org/matrices/ics/ — The authoritative adversary technique matrix for industrial control systems. Essential reference for Stage 4 of any CNI threat modelling exercise.
- PASTA Methodology — Tony UcedaVelez and Marco Morana, Risk Centric Threat Modeling (Wiley, 2015). The definitive reference for the PASTA framework.
- IEC 62443-3-2 — Security Risk Assessment for System Design. The standard’s own guidance on risk assessment for industrial automation and control systems.
- NIST SP 800-82 Rev. 3 — Appendix D provides a threat source catalogue relevant to OT environments.
- IEC 61511 — Functional Safety: Safety Instrumented Systems for the Process Industry. The process safety standard whose SIL framework provides the consequence-driven prioritisation model described above.
- Dragos ICS/OT Cybersecurity Year in Review — Annual threat actor activity reporting with specific coverage of threat groups targeting energy infrastructure.
- CISA ICS-CERT Advisories — us-cert.cisa.gov/ics — Current vulnerability and threat advisories for industrial control system components.
- NCSC — Bespoke Tooling Targeting Industrial Control Systems — UK government advisory on the TRITON malware and its implications for CNI operators.
- E-ISAC — eisac.com — The Electricity Information Sharing and Analysis Centre. Sector-specific threat intelligence sharing for electricity operators.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post examines SCADA modernisation architecture — specifically, how to replace legacy systems without compromising the operational safety properties that make them reliable.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.