There is nothing more instructive than learning from someone’s misadventures. When your own mistakes cause those misadventures, then you have an even better story to tell, because it represents an opportunity for yourself and your readers.
So, I am happy to share my latest.
The other day, I was talking with Tom and Heinrich, two good friends of mine I am collaborating with nowadays on various initiatives around Threat Modeling. Tom shared some feedback he keeps receiving: apparently, there are a lot of people who think that Threat Modeling would not be required, nowadays, because there are many tools and approaches which can validate the security of a solution more efficiently. Typical examples would be Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA) tools, intelligent dashboards to provide insights about the security of your infrastructure, like Azure Security Center, and even PenTesting.
All those approaches are fundamentally different from Threat Modeling, because they operate when you have code you can test and a deployed solution you can scan. In contrast, Threat Modeling can be applied very early, since the initial design phases. Moreover, Threat Modeling and those practices focus on different types of weaknesses, thus the overlap is only apparent. Therefore all of them should be considered as equally important and necessary.
You know, this conversation looked a lot like a comparison between meat and apples: of course, they are all edible, but they have different purposes. So different that even thinking to avoid one for the other seems odd. Sorry, Dr. Dukan.
And here is my mistake and the lesson for you: when you think that something is shortsighted or even wrong, do not start saying something in the line of “wow, that’s stupid!”. This reaction may be perceived as disrespectful toward those who have expressed the idea or who are communicating it. And as a result, your real message will be lost. It does not matter what you had to say: your initial reaction has irredeemably tainted your message. Lesson learned, my friends.
Apologies given, let me explain why I know Threat Modeling is so important.
While I am fully convinced of the importance of Threat Modeling, I also need to give a complete representation of my position by telling you that yes, I recognize that those doubts around the relevance of Threat Modeling as a modern security practice have a lot of merits. Indeed, those considerations are not new, as my answers to them: they have been covered in the past, as you’ll see if you continue reading through this article.
All Security Experts I know agree that Threat Modeling provides a differentiating value from SAST, DAST, SCA, and the like. This message has been around for more than a decade. Still, someone keeps doubting the necessity of Threat Modeling. Why?
I think that the reason is related to the difficulty of perceiving the value we keep publicizing. There are various causes for this.
First of all, some of the processes I have seen implemented are too complex or produce too much collateral work. As a result, Threat Modelers tend to fill their dues and stop, because they have already exhausted all the intellectual energy they had to spare. For example, I have worked in the recent past for a Company that has implemented its Threat Modeling program. They have templates with a lot of macros, to guide you through various steps and generate Threats automatically based on some initial assessment. Some of the values you fill in produce counterintuitive results, and then you have to cope with that continuously, to get what you expect. For example, if you say that a specific attack could only be executed by a Nation-State actor, you would expect the probability of the event to be lower, but you get an increase of the impact. Of course, Nation-States can do more damage, but there are only a limited number of them, and if they are the only subjects who can perform that attack, it means that other attackers would not be able to. On the other hand, an attack that could be executed by a Script Kiddie could also be performed by any other actor, which increases the probability. As a result of those and similar complications, at the end of a day using that process, you are more tired and less satisfied than you should reasonably be. Some of the most experienced Threat Modelers are able to cope with that and still provide reasonable results. Still, the vast majority will get poor value for a significant effort.
And here comes the second issue: Threat Modeling is not a process that you can do entirely automatically. If you follow this blog, you may recall that we have already discussed the importance of Quality for Threat Models and how you should gain specific skills to provide better value. On that account, we have introduced the importance of technical knowledge related to the various security risks and mitigations, the importance of gaining competencies about the holistic approach and, last but not least, how a critical mindset would provide you a much needed framework to analyze and understand the systems you are Threat Modeling. You can achieve a high level of proficiency, but unfortunately, too few in the world are currently able to create significant value through Threat Modeling.
If you knew nothing about Threat Modeling and you started reading my blog only from the last couple of paragraphs, I guess your thoughts would be in the line of: “wow, this Threat Model really sucks”. And a lot of managers would agree with you: as a result, it’s not uncommon to see the newest hires to be used to perform Threat Models. Given that Threat Models are a necessary evil, why should we care to devote our best resources to them?
And guess what? This approach only makes things worse.
Does it mean that we should forget about Threat Modeling, because typically the cost is too high and the value too low? Absolutely not! In Italy, we have a saying: it would be like throwing out the water with the baby. The point is not about ditching Threat Modeling or not, is to adopt a better process and use it when required. Under this urgency, I have defined with my colleagues what has been presented in those posts as Threat Modeling vNext.
In a recent webcast I have done for Xellentro, I have discussed how Threat Modeling should be considered as the tool to get the extra assurance required by some scenarios. For all the others, you may simply need to cover the basics, and SAST, DAST, SCA, PenTesting, and similar approaches may provide precisely that level of assurance. If you manage sensitive data, like PII or PHI, perhaps relying on some Cloud platforms like Azure or AWS, or if you have a strategic solution with significant business or national strategical value, then you may want to do more. In this case, Threat Modeling done properly would provide the additional assurance you need, or at least part of the answer.
So, dear Tom, Heinrich, and you, this is my answer to the question which started this post: we do not need Threat Modeling as it is done nowadays by too many, we need Threat Modeling for what it can and must be, and we need to use it when it makes sense.
That’s all for now. Stay safe, and keep Threat Modeling!
Simone On Security 