As security professionals working with software components it is not always easy to prioritise what security raising actions should be prioritised. According to most security standards (such as ISO27000) require a risk based security approach. Regardless if we are building our own applications, or we are installing third party software in our network we need to understand what threats there are to our environment. After understanding what threats there are, we prioritise them and thereby also prioritise what actions we should take to minimise the risk. Many organisations use threat modelling to understand what threats they have in their environment. However, I have lately come to understand that the definition of threat modelling varies widely between organisations. There are two main variants:

  1. The Pentest definition: According to the Penetration Testing Execution Standard (PTES) the goal of a threat modelling exercise is to understand what potential targets an attacker has on the network, and how an attacker might reach them. The process is a part of the testing phase to prioritise test cases and help assess the severity of findings.
  2. The Appsec definition: Open Worldwide Application Security Project (OWASP) on the other hand focuses on finding security hotspots as early on in the development phase as possible, preferably as early as the design phase. There are multiple structured ways of getting there, one of the most common is STRIDE.

Both of these have their value. The main point is to ensure that everyone is aware of what version of threat modelling that is discussed or performed. Regardless of model, it is helpful to not only think about the potential threats, but also what threat actors are relevant.

When I have read about identifying threat actors previously, I’ve dismissed it as overcomplicating. That might be true if you are looking at the differences between ransomware gangs, but just grouping the threat actors into categories. For example, noting that we trust our users in the air-gapped system to not be malicious and instead focussing on not getting malware installed through third parties as a way of performing industrial espionage. This is a quite extreme example, but it shows a valid point. By noting industrial espionage as a threat actor we need to discuss the security in another way than if we are looking at disgruntled employees.

By being aware of the threat actors against our organisation or application we can focus on the correct threats in the threat modelling sessions. This will certainly improve the accuracy of the identified threats, and the risk towards them. Furthermore, this will allow us to focus our efforts on the most important actions to improve the security posture.

In summary, as a part of our security practices we should identify both threat actors and potential threats. This is just as valid if it is software developed inhouse or if it is third party software.