Quality for Threat Models

Nothing is less clear than what is Quality for Threat Models. There are various reasons why this is true.

First of all, there are not many Threat Models published, and even those are superficial or hard to understand. Many of the available Threat Models analyze the system in scope from the lenses of best practices only, without trying to really understand the solution at hand. And it would be hard to have anything different, because examples are typically based on ideal, simplified scenarios, but still this is not what you would need to understand what Threat Modeling is all about.

Do not get me wrong: I am a strong supporter of checklists and best practices, because they help to lay good foundations, but a Threat Model is a different beast. It is about really understanding the solution and identifying weaknesses that are its own specific, which means that as a Threat Modeler you have to include the potential attacks and mitigations that are both well known and as such typically included in best practices and checklists, but also potential attacks that may cause harm to the solution and that may not be so common. And example of this is represented by a solution I have analyzed some time ago: a Web Application hosted in the Cloud to provide crypto-money exchange services to some Bank’s customers; this solution had most of the basic best practices for Web Applications got right, but they didn’t consider the need to implement the transactions to be fail-safe, so that a crash caused by a malicious user would not cause virtual money to magically appear in their account, without a real possibility to compensate due to the impossibility to rollback transactions on systems based on blockchains. This sort of findings are exactly where Threat Modeling shines and where it provides the most value.

From this point of view, I would say that Threat Modeling must provide an experience that gives you more or at least a different value than what is provided by other approaches. This means that the pure adoption of a tool which is based on the automatic generation of threats, without providing a good experience to the Threat Modeler which has additional findings to include, represents a very limited value for the cost compared with a pure checklist-based approach. In fact, it may be best to define good checklists for most project to follow, dedicating the more thorough Threat Modeling approach to the most critical projects, under the guidance of expert Security Advisors.

As a matter of fact, the attempt some organizations are doing to require Architects and other non-specifically trained people to compile Threat Models for their projects is bound to give a very limited return for the investment, because those roles will not be able to identify important weaknesses nor the most proper mitigations. On the contrary, it is even too common for non-experts to be overwhelmed by the sheer amount of threats generated by automatic threat generation rules and rely on indiscriminate copy & paste for fending off the complexity and get the much coveted “Mission Accomplished” badge. As a result, too many Threat Models have bad mistakes like listing authorization controls as mitigations for reply attacks; of course, this would not work because the fact that the request would have been accepted implies that most probably the replies would be accepted as well, and strong authorization would not make any difference. Instead, they should have included some reliable messaging mechanism like a sequence ID and integrity checking controls, like an HMAC, plus the related enforcement logic.

If you are a faithful reader of those columns, you may recall my Threats Manager tool. In fact, I have recognized the unwanted effects associated with the automatic threat generation since long, and this has pushed me to try and identify ways to lift some of the burden from the Threat Modeler’s shoulders (being myself one of them), particularly during the prioritization and mitigation activities. Unfortunately, the approach I have implemented with Threats Manager has pretty soon demonstrated all of its limits, being so dependent on the adopted Template. For this reason, I stopped using it pretty soon and the Threats Manager has never evolved as I would have liked it to do.

The problem with the Automated Threat Generation approach is that it should not be at the center of the Threat Modeling experience, but merely a tool to simplify the life of the Threat Modeler. What is really required is something that would allow very specific threats and mitigations, not necessarily something included in some knowledge base. Of course, the ability to peek from the knowledge collected in sources like Mitre’s CAPEC or CWE is also something that would provide a lot of value for the skilled Threat Modeler, but it should not be the only way to go. We still need to give proper relevance to the ingenuity of the Threat Modeling expert.

We have touched so far a lot of aspects around quality of Threat Models, but we are far from exhausting the topic. Stay tuned to get a new installment of the Threat Modeling vNext series next week!