Tony Turner

Threat Modeling for Critical Infrastructure

Threat Modeling


Threat Modeling

The practice of threat modeling is an important component of a Secure by Design approach. It’s where we identify the product or system we are working on and analyze threats and weaknesses we want to mitigate to avoid undesirable consequences. We should be left with a set of achievable outcomes we can implement, monitor, and measure and work into future threat modeling cycles in a continuous fashion to reduce risk in our environment.

A discussion of the importance of critical function understanding to establish a consequences-centric security engineering approach

Article content

Threat modeling is important in a secure by design approach, but especially within critical infrastructure, we need to focus on the critical functions, and identify the dependencies that can compromise the mission. That is what our adversaries will target. Any dependency failure that can compromise our mission, must be mitigated and we need to plan for failure and establish a plan of action to reduce the impact.

Threat Modeling for Critical Infrastructure


Threat modeling is a critical component of a Secure by Design strategy. It’s where we identify the product or system we are working on and identify threats and weaknesses we want to mitigate to avoid undesirable consequences. We should be left with a set of achievable outcomes we can implement, monitor, and measure and work into future threat modeling cycles in a continuous fashion to reduce risk in our environment.


But let’s step back for a minute and consider why this is important. Why is that product or system important? Is it always important? In the same ways?


I’ve worked with some large electric power utilities that buy a large stock of certain IEDs (intelligent electronic device) that they keep in a warehouse. They don’t know where these assets are going to be deployed when they buy them, nor do they know what critical functions they will support, nor if they will be subject to NERC CIP or DCIP or other regulatory requirements. As an electric power asset owner, we can make some assumptions, but an installation in transmission may serve a different purpose than in generation or distribution. A site designated as a CDF (critical defense facility) may have a very different risk profile than a rural substation. If the utility does not know, I’m pretty sure the product OEM does not know either, so their threat models may be insufficient as well.


Critical Function Assurance


OK so it’s not the IED that’s important, it’s the mission it supports. The critical functions that align with that mission. And the dependencies for that critical function, or functions. This might include engineers to operate the site or program the IED, IT teams to manage networks that convey telemetry data, the networks themselves, power coming out of the wall, supply chain dependencies for service providers and firmware updates and so much more.


So, when we start to think about Threat Modeling, nay, Secure by Design, for critical infrastructure, it’s the critical function we need to focus on. So why have we focused so singularly on the technology?


If we look at the conventional wisdom from industry, it’s largely based around the topic of software security. After-all, this is how vulnerabilities are introduced, and how adversaries will likely compromise our mission. And this too is incredibly important, the explosion of ransomware plaguing industrial sectors has proven this. But when safety and resilience are at stake, natural disasters, mechanical failures, and even human error can have just as disastrous consequences.


Incident Examples


Look to the Oldsmar water incident for a prime example of this. What was originally believed to be a cyber hacking incident, was later revealed to be due to human error that could have poisoned thousands of residents with improper chemical mixtures. It has been reported that this issue was contained by following standard procedures, not through zero trust network architecture or any number of cybersecurity controls. If one were to design this critical function, part of the threat modeling should include the potential for operator error, but most cyber-oriented threat modeling typically focuses on adversarial conditions only.


Let’s consider another example from aerospace, the Boeing737 Max failures in the MCAS system that led to hundreds of deaths across two separate crashes. It was designed to manage the yoke as part of the navigation process to prevent a stall, pushing the nose of the plane down. It had separate flight computers and sensor arrays to manage the process, you might think providing some redundancy, but they were not designed to consider communication failures and how to manage safe operations, nor allow for pilot manual recovery. The system was never designed for safety, a critical function of any plane. Again, an overly complex computer system that did not align with the core mission. Had designers threat modeled the plane differently, this would have likely been caught in the design stage.


Approaches Aligned with the Critical Function


There are very few approaches in cybersecurity that align tothese concepts. Certainly, safety engineers are familiar with PHA (process hazard analysis) in its many forms, and we can certainly learn from these approaches. I’ve long advocated for the concept of a Cyber-FMEA (failure mode and effects analysis) to deconstruct cyber related processes into their requisite parts and plan for failure, or to support process analysis with cyber dependencies, but this too is not sufficient.


We’ve seen models emerge such as Cyber Informed Engineering (CIE) from the Department of Energy that go quite a bit farther than standard cybersecurity approaches, but it would be disingenuous to call CIE a cybersecurity model. It starts with consequence understanding which includes identification of critical functions, dependencies, and consequences, and moves through eleven other principles, not all of which are cybersecurity related, in its pursuit of securing the critical function. If you look at its close relative, Consequences-driven Cyber-informed Engineering (CCE) by IdahoNational Laboratory, it starts to look very much like a threat modeling approach, but for more than just cyber.


For example, if you were to use the OWASP definition of threat modeling, it looks something like:

  • Decompose the application (including dependencies)
  • Determine and rank threats
  • Determine consequences and mitigations

While the 4 step CCE model lays things out very similarly, but with a different scope:


  • Consequence prioritization (focusing on operations that must not fail and the systems that could bring them down)
  • System of systems analysis (including interdependency mapping)
  • Consequence based targeting (through the eyes of a threat actor taking the path of least resistance)
  • Mitigations and protections


Look similar?




Regardless of the approach you opt to use, consider stepping outside of your cybersecurity focused bubble and focus on the big picture. Whyis this system important? Do you know? Who does? Involve them in the threatmodeling process, along with any other stakeholders that can walk you through the why and the how, including all the dependencies you might not be aware ofand then threat model those things too.


To learn more about the approaches identified in this article, please see the below references.

 Originally posted November 17, 2023 at


Threat Modeling for Critical Infrastructure

Tony Turner

Founder, CEO

Experienced cybersecurity executive 30+ years, Author of SANS SEC547 Defending Product Supply Chains and Software Transparency.

Author's page