The previous post has introduced the question of the quality of Threat Models and has discussed the importance of achieving with it value that could not be found otherwise. We have discussed how the automated generation of threats is not really going to provide much value compared with checklists and best practices, and how it instead may cause bad mistakes adversely impacting quality.
The apparent lack of clearly good examples doesn’t help getting an idea of how an ideal Threat Model looks like. This is not only related to the presence of mistakes like those discussed within the previous article, but also because most of them are provided as examples referring to an ideal system and as such cannot go beyond what is normally included in checklists and best practices. Still, there are some very good examples out of there. Personally I have found some of the best collected in the wonderful book “Securing Systems” by Brook S.E. Schoenfield.
Given that we cannot easily understand what is a good Threat Model by looking at examples, we need to identify alternative ways to determine what makes a Threat Model Good. My personal point of view is that the most important characteristic for a quality Threat Model is being useful. But what does it really mean? To me, a lot of things: first of all, a Threat Model must represent a view of the design of the solution at hand, highlighting common and uncommon but still credible potential attacks; it must provide balanced evaluations of the severity of the potential attack; and finally, it must identify multiple mitigations for each potential attack.
Identifying credible attacks is very important. In fact, your stakeholders need to trust you to provide fair evaluations of the severity of the attacks, because they have limited resources to spare for security and need to spend them where it matters the most. There are a couple of ways to ensure the attacks you identify are considered credible by the stakeholder: the first one is to include recent examples of compromises where similar issues have been exploited. One thing is to tell your stakeholders that an attacker may compromise their storage due to access rights misconfiguration; another is to tell them that that sort of weakness has been recently identified even for resources published by Microsoft. Oops.
Another way to make the attacks you identify more credible, is to describe the flow that the attacker may follow to compromise your system through that issue: there are various ways to do that, one of them would be to describe it through an Attack Tree, but sometimes even some story-telling may be effective enough.
Another important factor to gain the trust of the team owning the solution you are Threat Modeling is related to how fairly you are assigning severity levels to your findings: as a Security-focused expert, you may be tempted to tell them that most of your findings are Critical or High Severity, because you know that anything else may be simply dismissed as non important. But it would be a mistake: as a Threat Modeler you do not have the responsibility to ensure that the solution you analyze is secure, but only to get a good picture of it and to provide the information the stakeholders require to decide what to do. Of course, bias is only natural, but you should strive to be as fair as possible.
There are various approaches to improve on that account: the first one would be to adopt what in Microsoft is called a Bug Bar.
|Critical||Critical Severity. It is related to the most important issues, which could cause a catastrophic failure of the solution and critical damage to the involved counterparts.|
|High||High Severity. It is related to important issues that may cause major disruption and thus should be seriously considered.|
|Medium||Medium Severity. It is related to issues that should represent some concern and thus should not be overlooked.|
|Low||Low Severity. It is related to minor issues.|
|Info||Informational only. It is related to mitigated issues or to topics that are included for completeness.|
Normally, Bug Bars are defined as Security Quality Gates, that is means to decide if a solution is good enough to pass some quality assurance control; for Threat Modeling, Bug Bars are simply a strict definition of each Severity level. For example, if you define Critical every potential attack which would compromise a major feature of the solution, for which there is no workaround and that is so severe that data integrity would be in discussion, and you still define most findings for a Threat Model as Critical, the stakeholders of the related solution may be tempted to block it from going in Production, but most of them would simply dismiss all your assertions as biased, because obviously at least some are and therefore there is a legitimate doubt about your whole work. In any case, your assessment would hardly be considered useful, would it?
A more modern approach to evaluate severities would be represented by Quantitative Risk Analysis, the most famous of which when we are talking about Security is certainly FAIR. Please bear in mind that while this approach is designed to take most of the bias out of the equation and to provide credible estimations of the security risks in monetary terms, it may still be quite hard to apply this approach to a big amount of scenarios. As a result, it is still unclear how we could use those concepts for Threat Models, particularly with automatically generated findings.
Some of my readers may have heard about Microsoft’s DREAD methodology: it is an old methodology that is not used in Microsoft anymore since long, because not effective nor efficient. So, forget about it.
A key characteristic of high quality Threat Models is to provide more Mitigations for each finding. This is for various reasons, including to provide choice: in fact, if you have two alternative mitigations, the first one more effective but also more expensive, and the second one cheap but less effective, what would be the right choice? I know a lot of Security Experts who would say without a second thought that the first one is best, but if the residual risk you have after applying the second mitigation can still be considered acceptable, why bother with the first? As a Threat Modelers, your time would not be to decide which way to go, therefore it’s better to simply inform about both of them.
That said, the most important reason why you would need to identify multiple mitigations is because adopting multiple Control Types is better to stick with one. It’s a sad fact that most Threat Models contain mitigations falling exclusively under the Preventive Controls umbrella, which means that they are designed to make the execution of the attack more difficult. This may be enough to block some categories of attackers, like the so-called Script Kiddies, which are enthusiast but inexperienced attackers who have no skill but the ability to search for ready-made scripts; nevertheless, it may be totally ineffective against more knowledgeable and determined attackers, which the Preventive Controls would only delay and force to leave traces of their attempts. For this reason, Preventive Controls have limited effectiveness if taken alone, and typically require other mitigations like the Detective Controls, which are needed to detect attacks while they occur. Again, awareness is not useful if you do not have planned already what to do when an attack is occurring, which is the role of the Corrective Controls. I may continue this list, for example by citing Recovery Controls (needed to restore the system to its normal operation after a successful attack) or Deterrent Controls (which are designed to convince the potential attacker to desist from even trying), but I hope you got the point.
Ultimately, if we think hard enough we can identify characteristics that make a Threat Model good or even great. The article has shown some of them, and to summarize what we have learned, we could say that a good Threat Model can be recognized by how much it helps stakeholders to understand the current risks and what to do to make them acceptable.
So, the key concept for good Threat Models is represented by the Residual Risk and how to make it acceptable, which is obviously a function of the initial risk for our solution and of the impact represented by the selected Mitigations. But how can we measure those? This is what we will try to understand starting from the next article.