The Attributer has become aware that threat modelling is enjoying some popularity at the moment. However, most of what is written and said about it makes little sense. It’s not the role of this column to ‘name and shame’, but if you doubt what is said here, just type the words ‘threat modelling’ into your favourite search engine and read what it brings up.
There is the widespread confusion between ‘threat’ and ‘vulnerability’. A threat is a potential action against you, carried out by someone or something called a ‘threat actor’. The action may be malicious or accidental, intentional or unintentional. The actor may be an individual human, or a group of humans acting together in joint enterprise, or it may even be a natural event with no human action involved (such as a flood or an earthquake).
Vulnerability is a weakness in your system. The weakness may be concerned with poor design and construction of your technology, or with inadequate processes, or with the incompetence of people doing their jobs, or some combination of these three factors. Threats can exploit vulnerabilities to cause negative impacts on your business objectives. Threats and vulnerabilities are related, but they are not the same thing. A threat is only dangerous if there is a vulnerability that it can exploit. A vulnerability is only a problem if there is a material threat that can exploit it. Got it?
Consider a simple SABSA domain model in which there are two domains. ‘Your Systems’ is a sub-domain of ‘Environment’ in which those systems exist (the super-domain). For those readers not familiar with SABSA domains, they are sets and sub-sets and the graphic is a Venn diagram. That means that everything in the sub-set (sub-domain) is also part of the super-set (super-domain).
Threats are found in the super-domain. They emanate from the systems environment. However, there is something known as the ‘insider threat’ which originates in the sub-domain – which is also part of the super-domain. Insider threats are usually subversive members of staff acting against the organisation. Vulnerabilities are never found in the environment outside the Your Systems sub-domain – they are properties if the systems themselves, not properties of the environment.
This clarity of detail is essential in any threat-modelling framework. A methodology that begins by advising you to look at Your Systems (applications, infrastructure, databases, etc.) is beginning in the wrong place, heading in the wrong direction and will finish up with the wrong model.
To analyse the threat in more detail you need to look at the threat actor with three questions: what are their capabilities to act? What is their motivation for acting? And what opportunities do they have to act against you? There may also be inhibitors (making action less likely), catalysts (triggering action) and amplifiers (making action more likely) that influence the actor’s motivation. Nowhere in this threat model is there mention of vulnerability. Modelling vulnerabilities is an entirely different type of activity.
Using SABSA thinking for threat modelling has several advantages: it begins by looking at your business and understanding why an adversary might want to attack you – what’s in for them – their motivation, together with their ability to mount an attack. It then adopts a sound conceptual model of the anatomy of a threat as opposed to vulnerability. Finally it allows you to predict the most likely types of threat and the target assets because you understand what the adversary is trying to achieve. This allows you to focus your defences more effectively and efficiently than if you attempt to cover all possibilities all of the time. Looking at your defences is where vulnerability becomes relevant.