Mitigation identification is probably the most important step in Threat Modeling. With the previous article in the Threat Modeling vNext series (“Mitigations, oh my!“), we have started to see some rules to work with Mitigations. We have finished our discussion with the consideration that it is best to identify more than one mitigation for each threat, because this would give multiple choices to choose from, and also because sometimes you need to consider multiple complementary mitigations to provide a complete answer. But how to identify those complementary mitigations?
Sometimes you may simply know that you need them, because of experience: last time we have seen an example related to the risk of information disclosure for a database. In that case, we saw that client-side encryption would not be enough, because the encryption key may be stolen, and thus you would need to store the key in a Key Vault and protect the credentials used to access that Key Vault with something like Azure Managed Identities. While this could be satisfactory in many cases, we need something better.
One way to identify complementary mitigations is related to their classification based on when they are applied (see https://en.wikipedia.org/wiki/Security_controls). The idea is that every mitigation you may identify will eventually fail, therefore the best approach is to include a series of mitigations, which would be applied in an integrated and coordinated way to increase the effectiveness. If you think about that, this is another example of application of the Defense in Depth principle.
So, what are those Security Controls?
| Name | Description |
|---|---|
| Preventive or Preventative | Preventive Controls reduce the probability or impact of the threat event, effectively gaining time to the defenders and forcing the attacker to make attempts that could be detected . |
| Detective | Detective Controls allow detecting an attack while it is in progress. |
| Corrective or Responsive | Corrective Controls allow responding to attacks while they are in progress, for example to stop them. |
| Recovery | Recovery Controls are designed to recover from the damages occurred from an attack. |
| Deterrent | Deterrent Controls are mostly there to convince the potential attackers that the cost for them may be higher than the potential gain. |
It is very important to understand which Security Control a mitigation belongs to, because it is typically necessary to have more than a type represented, if you want to achieve a good protection. In fact, Preventive Controls tend to make life harder for attackers: this means that unskilled attackers may forfeit the attacks, while more capable and persistent attackers would still be able to compromise the solution, but to do that they would need to execute various attempts. So, you need to expect attackers to eventually succeed, but those attempts represent an opportunity for you, as a defender. To exploit this opportunity, you need Detective Controls in place, so that you may be alerted that something does not adds up. Again, knowing that you are under attack is not going to help, if you do not do anything with this information. But what to do? If you have to decide on the spot, chances are that you are going to do the wrong thing, therefore it is of uttermost importance to plan ahead. This represents yet another type of Security Controls, usually called Corrective or Responsive.
There are a lot of other possible Security Controls, including Recovery and Deterrent (see the table above), and you should be familiar with all of them to be an effective Threat Modeler.
What does it practically mean, to adopt Security Controls? Let’s answer this question using the example from which we have started: the information disclosure for the database. All the proposed mitigations are preventive in nature: in fact, using client-side encryption, storing the encryption key is some key vault and adopting Azure Managed Identities to protect the credentials for accessing that key vault, are all mitigations having the goal of preventing the attack. As said, we may need to consider additional control types, but what? Let’s start from the Detective Controls: their intent is to detect attacks in effect; this means raising events, for example to identify attempts to access the key vault and the encryption key, independently from the outcome. Then we need to consider Corrective Controls, like rejecting automatically all the requests coming from the offending IP addresses. Recovery controls are typically represented by a sound Backup and Restore infrastructure. I may continue, but I hope you already got the point.
So, returning to the initial question of this series of articles, that is what are the quality factors that would make a Threat Model good, definitely having multiple Security Controls for most Threat Models is one of them.
Next time, we will continue with our Threat Modeling vNext series, discussing a little more about the differences between the traditional Threat Modeling process and the new approach.
Simone On Security 