Identifying the main characteristics that make a Threat Model good is tricky and definitely something requiring to take a lot of factors in account.
We have started considering aspects like the need to provide value that would be hardly achievable otherwise. We have touched important concepts, like the Residual Risk, and discussed the importance of measuring it.
The last article introduced a way that may be used to simplify the evaluation of the risk. While not particularly rigorous, the suggested method has the benefit of being simple and easily applicable, providing a qualitative evaluation of the risk. Quantitative risk management approaches like FAIR would represent a better option from the point of view of the outcome that can be achieved, but they are hardly applicable for Threat Models, due to the high number of threats and scenarios that could be identified as requiring an evaluation.
In any case, thank to the proposed methods discussed last time, we now are able to say that a certain potential attack may represent an high risk for the organization. This is an important achievement, but we are hardly finished. In fact, now the most important questions of them all must be asked:
- Is that risk acceptable for the Organization?
- What can we do to decrease the Risk?
- What mitigations identified in the previous step would make the risk acceptable?
Some of those questions have already been considered in one of the previous articles (see for example “The Residual Risk“). In particular, you’ll recall that the article demonstrated how it would not be the best course to try and minimize the residual risk, while it would be more sensible to optimize a function based on the sum of the estimated costs due to the potential losses, which could be estimated as a range, to the cost of implementing the mitigations. We have seen how there is a sweet spot that needs to be identified, which constitutes what we may call an optimized set of mitigations, because it represents the best value for the money. Starting from this information, the solution’s stakeholders may decide to implement only some of the mitigations from the optimized set, which would still be a subset of those which have been identified during the Threat Model, because they would be enough to achieve a level of acceptable risk.
Let me anticipate you that we are not there yet. To make this vision real, we need first to be able to calculate the risk represented by each scenario, then to calculate the impact of each mitigation on the risk and finally to identify the acceptable risk for an organization. Well, all of this is actually possible nowadays already, thank to methodologies like FAIR, and books like “How to measure”. The problem is again how to efficiently apply all those concepts. We do not have a good answer yet, but we will, so stay tuned.
Of course, this need must be addressed somehow right now, and this means that we have to identify yet another sub-optimal approach, which would still allow to determine what mitigations need to be implemented out of a list.
First of all, we have to determine if the list of mitigations we have for a Threat Model is good enough. Let’s start easy: the first rule is that each and every potential attack must have at least a mitigation identified. That mitigation may be too expensive and thus you already know that the stakeholders will never allow it to be implemented; that would be ok: your role as a Threat Modeler is to include every possible mitigation you consider effective for addressing the specific threat, not to decide what will be implemented. This consideration is related to our second rule: identify more than one mitigation every time you can, to provide alternatives to allow stakeholders to choose. Sometimes you need to include complementary mitigations, because one of them would not be effective enough. An example of this is would be represented by the risk of data stored on a DB to be disclosed due to lack of encryption. To mitigate it, you may require to propose Client-Side encryption, which would definitely improve things a lot; but this would not be enough, because the encryption keys may be stolen if they are not protected adequately. This brings us to the second mitigation required: a Key Vault. Again, this would not be enough if the credentials used to access the Key Vault are not protected: at this point, you need some mechanism to protect those credentials and make them less accessible, like Azure’s Managed Identities.
We have again covered a lot of ground. Next week we will see another reason to have multiple mitigations.