When making a Threat Model, we draw up a comprehensive list of threats which our system faces. STRIDE is our guide here, helping us find the possible threats but also giving us a handy categorisation for each once we’re done.
The next (and most important) step is to deduce risk. In other words, the individual risk severity that each of these threats poses to your business.
When we talk about a “severity”, there is usually a scale of risk we adopt. Your organisation may already have one, but if you don’t, I suggest starting with four severity levels: Low, Medium, High and Critical. Some teams prefer to work with a more elaborate scale with 6 or 7 severities. Whatever your choice, ensure you have a fixed and full definition of the impact that each severity implies. Impacts usually come under a variety of areas (e.g. financial, technological, customer, reputational, legal/regulatory, etc). For a risk to be serious enough to be at that impact, it needs to meet the criteria for any one of those areas.
For example, a Critical Technological impact could be systems critical to earning revenue being down for 24 hours, and the severity decreases with the duration of the outage.
Once you understand the level of risk posed by each threat in your threat model, you know which threats are more important, and thus which controls to implement.
Controls are the “levers” we use to reduce the risks you just identified. By “reduce the risks”, I mean that the likelihood of each risk is lowered, because the attack is harder to execute, or the impact is lowered if an attacker succeeds, or both.
We categorise controls based on how they reduce the risk:
- Preventative
Almost completely removes the risk (e.g. a hacker can access our system through an open port, so a preventative control would be to close the port using a firewall). - Mitigating
Not quite preventative, but mitigates the threat to some degree (e.g. a hacker may brute-force a user’s password, so a mitigating control is to require a stronger password, which doesn’t prevent brute-forcing but does make it harder). - Detective/Monitoring
Detective controls don’t affect the attacker in carrying out their attacks, but let you know that an attack might be taking place, so that you can respond accordingly. Though this doesn’t affect the attacker, it can reduce the downstream likelihood or impact caused by a threat. For example, if a detective control detects a particular attack, you may reduce access to the system to prevent the attacker conducting a further attack while still having some access to continue business operations in a reduced way, until the attack stops.
When we suggest controls for each threat in our threat model, aiming to have 3-6 controls per threat is a good aim, though not always achievable. Some threats may also have more controls in place.
Remember, not every control is required - it’s more like a shopping list. Once we have a list of controls we can choose which controls are best to lower the risk. The controls we don’t implement can remain on the list, but kept in reserve in case we need to implement extra controls in future.
As you implement controls you bring the risk of each threat down. Generally you’ll have a sense of “tolerance”: there will be a level of risk at which you’re happy to simply tolerate the potential impacts. When each of your threats is at or below that tolerable level, you’ve finished the work of securing your system, and can move onto the next one.
All this makes threat modelling a great tool not just for security people, but product owners and project managers too, as they can easily see a roadmap of controls work, which of those really matter, and they have the ability to influence which controls are best implemented given their other constraints.
