The thought of tackling a threat model (TM) might not be the most appetizing to some people.   Doing a quick Internet search, someone could get stuck under a mountain of acronyms and terms.  I mean, what is a CVSS anyway?  And then there are the diagrams, attack trees and feedback loops that could drive even the sanest person mad.  Oh, and then you encounter the Threat Model Manifesto which sounds like something that’s straight out of an occult.  What does this all mean and where in the world does someone begin??  Take a deep breath and relax.  

Let’s see if this can all be simplified to a few simple tenets. 

The first logical step is to identify what threat modeling actually is.  The National Institute of Standards and Technology (NIST), defines TM as “a form of risk assessment that models aspects of the attack and defense sides of a logical entity, such as a piece of data, an application, a host, a system, or an environment (NIST.gov, n.d).”  That clears it up perfectly.  Enough said.  Not exactly.  Let’s break this apart.

First, the logical entity NIST references could be anything that is being consumed or produced from the system in question.  Let’s examine a power grid for example.  What is being consumed or produced by this power grid?  First and foremost, electricity and power.  That’s the easy answer and obviously, there’s more.  What other resources are being consumed to produce that power?  There is human resource consumption through those operating the control systems as well as the data being generated between the components that dictates how other components might respond.  There is much more that is entailed but for the sake of brevity, we’ll stick with these components. 

Next, is the attack and defense aspects of the definition.  

We’re going to temporarily put the defense aspect on the backburner.  Before we can defend something, it might be helpful to see how we can attack it.  This is where we can switch hats from the defender and play the bad guy just like you see on CSI or Criminal Minds.  How can we effect enough change to the identified resources being generated and consumed (in this case, power, human and data resources) to disrupt the operation of the system?  This might be where some people get anxious and think this is where the technical aspect comes in.  While technical expertise is certainly valuable at this step, there are many less technical attacks that are often overlooked and easier to carry out.  For example, what if an attacker strategically caused accidents in and around the power station that would delay or prevent the human resources from even reaching the plant?  That might not be that big of an impact since there is a crew on at night and they would need to stay over until relief comes in.  True.  But what if the attacker uses this chance to pose as law enforcement and gain access to the plant to install malware for use later; malware that can be used to disable or alter the operation of a programmable logic controller (PLC), thereby shutting down a portion of the station?  Granted, this kind of sophistication would come from a high-end, nation state, kind of hacker, but it’s something worth considering depending on the importance of the system being defended, or, in technical terms, the Target of Evaluation (TOE).  

It is important to clarify something at this point.  

Based on the explanation above, threat modeling seems very similar to risk analysis.  Threat modeling can be performed at both the end user/asset owner and the component/system levels.  Typically, in the Industrial Automation Control System industry, threat modeling pertains to the component/system level.  When it is done at the asset owner level, it is considered risk analysis.  For the purpose of this discussion, the term threat modeling will be the term used to address the analyses at both the end user/asset owner and component/system level. This is a rabbit hole of “what ifs” that is never-ending and could go on forever.  However, this is the mindset we must be in to identify some of the attack vectors worth considering.  It’s a daunting task and something that can become overwhelming quickly.  But it’s something that is doable with a little discipline.  

Below are a few guidelines you might consider when attempting to tackle TM (See Figure 1 for reference). 

1. Take a deep breath.  This is your chance to play hacker.  Have fun with it.
2. Identify all the resources being generated or consumed by the system.  In security terms, these are termed assets of the system.  Don’t leave anything out, no matter how small.  Write every possibility down. 
3. Now ask the question, “Which resources would have the biggest impact on the system and how would I effect change on them?”  Start with the resources identified in step 2.  Can anything be done to interrupt the production or consumption of these resources (i.e., prevent staff from getting into work, or cause a diversion to facilitate a later attack)?  If so, write it down no matter how silly or crazy you might think it is.  Now which of these resources is the easiest to alter that would provide the biggest impact?
4. Next, we need to identify the likelihood of the threats we generated in Step 3.  I mean could a meteor come flying to earth and strike the power station? Sure.  But the likelihood of this happening is exceptionally low.  Therefore, we shouldn’t spend a lot of time planning and preparing for it.  Is it more likely that someone might try and gain access to unauthorized areas?  Of course.  On a side note, there are tools available, and highly recommended, such as CVSS (Common Vulnerability Scoring System) that should be used to help rank and prioritize these vulnerabilities.  The CVSS is relatively straight forward and can be found at NVD - CVSS v3 Calculator (nist.gov).
5. For steps 3 and 4, brainstorming sessions can help identify the resources, threats and vulnerabilities of the target of evaluation.  Being able to collaborate within a group helps promote ideas from different perspectives in a shorter period of time.  It also provides a learning experience for everyone involved.  Make it fun.  Maybe whoever identifies the most threats gets lunch and bragging rights.
6. Once complete, think about the easiest, most cost-effective ways to fix these vulnerabilities.  Keep it simple.  A procedural change or a cybersecurity training awareness program can help shore up a lot of these vulnerabilities.  Requiring identification checkpoints prior to entry and having visitors be escorted the entire duration of their stay could be something that could drastically reduce unauthorized access and not incur much cost.   Looking at it from a more technical standpoint, as if we were creating a threat model for a product, what are some of the steps that can be taken to make that product more secure.  For example, is it possible to reduce the number of interfaces or severely limit the interfaces?  Write down all the ideas that come up.  Sometimes the simplest suggestions can have the biggest impact.
7. Have more than one person, or even team, review the documents being generated.  Getting a different perspective can truly be the difference between identifying an overlooked vulnerability that is easily fixed, and one that is exploited down the line.  Use caution, however.  You don’t want to publicize this document as it does contain sensitive information.
8. Finally, understand this is a living document that requires regular maintenance and review.  It is something that can help decision makers direct their resources, optimize the outcome, and avoid potential downfall as new threats arise. 
9. Once this high-level approach is complete, the system can be broken down into logical components and the process should be started again.  Continue breaking down each component until you feel you have reached a level where the vulnerability scoring is low enough and is within acceptable limits.  In many cases, breaking down a threat model into smaller, bite-size components can significantly simplify the process.  Additionally, smaller TMs promotes reusability and provides a level of agility that can be incorporated into future, larger models.

This is a very high level, simplistic approach to threat modeling, but it captures the main components and, hopefully, takes the fear and angst out of starting the process. Understanding there are a plethora of different models and approaches to tackling this somewhat overwhelming task, the most important part of it is starting. Being able to get thoughts on paper (or tablet for the tech savvy population) is the crucial first step. Sharing it with others is also important. Obviously, keeping this as confidential as possible in a controlled review environment is of utmost importance. Threat models can quickly become a roadmap on how to hack your system. But being able to discuss it with those having the technical expertise and can step back and ask the “what ifs” can prove invaluable.

NIST.gov. (n.d.). Threat Modeling. Retrieved on December 22, 2021, from threat modeling - Glossary | CSRC (nist.gov)

NIST Calculator. (n.d.). Common Vulnerability Scoring System Calculator. Retrieved on December 22, 2021, from NVD - CVSS v3 Calculator (nist.gov).