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, 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 devices) 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, 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, 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 Boeing 737 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 to these 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 further than standard cybersecurity approaches, but it would be disingenuous to call CIE a cybersecurity model. It starts with consequence understanding which includes the 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 Idaho National 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 countermeasures 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?

Conclusion

Regardless of the approach you opt to use, consider stepping outside of your cybersecurity-focused bubble and focusing on the big picture. Why is this system important? Do you know? Who does? Involve them in the threat modeling 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 of, and then threat model those things too.

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

https:/www.inl.gov/cie/
https://www.inl.gov/cce/
https://www.owasp.org/www-community/Threat_Modeling_Process

Tony Turner

Tony serves as the Founder and CEO of Opswright, a software company focused on Secure by Design for critical infrastructure and Cyber Informed Engineering. He is the co-author of Software Transparency, authored SANS SEC547 Defending Product Supply Chains and is the chief editor for https://ciewiki.io focused on Cyber Informed Engineering.