By Simone Curzi
Threat Modeling is one of the best tools for Security and has been adopted successfully by various Companies around the globe, including Microsoft. Even if it has demonstrated to be a very effective approach, it has not shone for efficiency and has improved only so much compared to other development methodologies over the last years.
All those problems have been reason enough to limit its adoption. It is past due time for change. It is time to make Threat Modeling the flexible, integrated, automated and customizable process you need. Please meet Threat Modeling vNext!
This presentation is around the threat modeling, and more importantly, about how we can improve the process in a way that it makes this process much more useful for you. So first, let’s discuss, why should we care about threat modeling? This is a very important question that we need to ask ourselves. The simple answer is because we don’t want to have our job lost. We want to maintain the possibility to do what we love. So of course, security plays an important role, and something like threat modeling helps in maintaining the current status.
So security is important, and we are doing security already. There are various ways that we are applying to ensure that the solutions that we build are secure. Most of them, though, are based on a simple concept: walls. We are creating walls, like firewalls, like also checks that we introduce during the development, validations, activities that would very statistically try to understand if the solution can be attacked or not, and this is providing some perfections that is not going to save our day. If you have an adversary, she will continuously contact your systems, punch your systems up to a point where a breach will be found, a vulnerability or weakness will be found, and you’re done. So you the need really to change and to think about something else, something that will provide you the required assurance and the actual answers, they are great.
They provide a lot of value. They still must be embraced, like the adoption of tools to validate your code, best practices, and checklists derived from them, policies, and also validation activities like penetration tests. All those things play and still will play a very important role, but at a certain point, you may have needs that will require you to go over what is given by those systems, by those practices. In fact, those practices tend to provide you value that is related to a generic idea about security. You adopt a checklist that will define what, in general, is expected as a vulnerability from the solution. It’s not necessarily your solution. Use cases could still happen. So you need to care also for them, and threat modeling plays an important role. Shall you do what is provided as an extra mile each and every time? No, really not.
There are moments, reasons, situations in which that will be important. For example, when there is an extra exposure, like your solution is on internet, you have a business critical solution, there are important regulations that must be satisfied, like privacy, and also if you want to shift left in your security to save some bucks. This may play also an important role, threat modeling from that point of view. So what is threat modeling? Threat modeling is a way to understand the threats that identify what are the potential losses and to identify what you can do, and this has been over time true, and this is true for the threat model that everyone does, and another angle to that is that threat modeling plays an important role in a typical risk management process.
Typically, it covers the first phases, when you want to understand the risk for a solution and identify the required mitigations. This is where threat modeling plays a role. It is not finished though. From that point on, you needed to do other activities. You need to select the mitigations that make most sense for you, the right balance, provide the right balance of security and cost, and then you needed to implement those mitigations. Simply selecting them is not enough. You need to check that day are good, and you still will have some residual risks that you need to manage with exceptions and so on. So threat modeling plays a role. Threat modeling is important, but it is not widely adopted yet. In fact, statistics say that around 18% of the organizations worldwide are really investing in threat modeling. This is a very low number. So from my point of view, this is a huge opportunity to grow, but this means also that there are difficulties in implementing threat modeling.
What are those difficulties? Well, first typical problems, there is a partial overlap between compliancy and security and sometimes they are confusing. So making a good threat model may be difficult, because threat modelers will tend to focus on compliance, providing only limited value for the cost. So this will lower the value of threat model and the perception of the threat modeling process will be that it’s not that useful. Also, the problem is that sometimes you get results that are not so relevant, and also a lot of things that need to be done. This is typically true if there are automatic threat degeneration methodologies. They will tend essentially to repeat the checklist approach, but with a fancier interface. So this also is a common pattern that lowers the value of a threat model. To do threat model well, you need the required skills.
You need to have important skills, and those are rare. So it’s very difficult to implement a process like threat modeling in a very effective way, and this is, of course, another problem that makes threat modeling proceed as a not so effective approach, and another problem is that most of the times certain modeling is isolated. At the best cases, you get a document and you need from that point on to analyze that document, and it’s not integrated with DevOps. It’s hardly integrated with DevOps. So it may be difficult to do things after you receive a threat model. So the value that you get out of the threat model right now may be limited, depending on the tools and the processes that we are using. So shall we decide to drop the threat model a practice, or what shall we do?
Well, we need to really understand what we want out of threat model, where we want threat model to evolve. We want to have a process that provides guidance. Not everyone is an expert, and of course if you do not know very well security risks for a system, for a technology, you need to have stronger guidance helping you to improve the quality. You need also an approach that is able to adapt to your needs, to your specific processes. This is fundamental, and this is also related to customization, the possibility to integrate by adopting extensions, by adopting a process that can be part, really, of your organization, to work together with your systems, and clarity. You need to understand really well what is the system that you are managing? What are the risks? And what to do out of that.
So those are important characteristics, and then it is also important to understand that threat model cannot be the same tool, cannot provide the same experience to everyone. We have a lot of different needs. There are people that are not completely focused on security such as architects, or people that are just starting to become threat modelers. So they need to have a help and guidance, more than other roles. For example, you may have an expert that will do a threat model, and that’s what an expert will seek out of it. It will seek efficiency and effectiveness. It will seek the possibility to create report with the blink of an eye. So very fast and very good results. The possibility to integrate with other systems, which is also something that other roles will want. A project manager will want the threat model to create bugs, tasks in the project management tool that they are using, and in a way that makes those findings manageable and executable.
And other roles will need to have a comprehensive view, a synthetic view of the risks for the solution. So this is also a very important angle to that. Everyone has its needs and we need to provide different views over the reality that are presented by the threat model. So this is really what threat modeling vNext is. It’s about recognizing all those needs, and to understand that we need to provide a flexible set of functions, ideas, something that will be really adaptable to the experience and to the usage scenario. So flexibility. And what does it mean in practice? Guidance. There are a couple of concepts here. Yes, of course provide information that will lead, guide you how to do the threat model, the type of information about the risk, the systems, but also in an important concept.
Our projects nowadays are complex, are not represented by a single technology, by a single feature. They are represented by a blend of multiple solutions, technologies, products, sometimes even provided by different third parties. So we need to have knowledge bases that are able to create a blend together that will provide the value you seek, and they need to be manageable. They need to be extended over time as it is required, because this sort of knowledge is not fixed. It changes over time, very fast. We need to adapt the views to the different roles. We need to provide a view for the project manager, for the expert, for the novice. So this is very important. It is also about customization. Your organization has needs, has systems that need to be integrated, and we need to customize the experience to achieve this level of integration.
Extendability, it means that now we have a view about what threat model is. Tomorrow, this view could be extended, could include different needs, different roles that will have different needs around the threat model. We need to provide a system that would be able to cover, at least potentially, those needs, and also integration. The possibility to integrate with DevOps makes a threat model a first class citizen of those processes that we have nowadays, and this is crucial to make really threat modeling successful. Clarity, it’s about defining very clearly what we are talking about to the different elements of the threat model and provide solid information about the threat model itself, so that everyone agrees about the different concepts, which may sound as obvious, but considering that threat modeling use these different languages, essentially based on even the company that is doing it, it is absolutely a very important first step from which to start.
That said, everything we have discussed is not really tackling the fact that that threat modeling is perceived as being hard, a hard practice. So covering really the basics around how to do a threat model, what are the required skills, and provide the sort of skills, the sort of knowledge is fundamental. So it’s not about tooling, it’s even more about mindset, and in fact, to be a good threat modeler, you need, first of all, to have of course the knowledge about what may go wrong and about the potential attacks, but also you need to have a holistic approach. You need to understand that the system, that the reality is not only software, that it’s not only the application you are writing. There is also the infrastructure and vice versa out of there. There is not only the infrastructure, there are also applications.
If you focus only on one of them, then the other could be compromised, and if there’s a threat, everything is compromised. Our attackers are not limited. So adding a mentality that will limit ourselves will only provide additional weapons to them, and then a very important skill, perhaps the most important, is to be skeptic, to really never assume that something is secure, trying to understand what is said to you and trying to understand if perhaps there are problems in there. This is crucial, because otherwise you would tend to accept what is said to you without really trying to go in that and identify potential weaknesses. Okay. So that said, what can you do? What I think will be required is to get a comprehensive approach to introduce threat modeling in an organization, and this is achieved not only with formal training, which plays definitely a fundamental part, but because it provides awareness about the process.
So this is something that you want to do, but you want also to gain experience, to provide experience to your people that are going to do threat models, and the best way to do that is by training on the job, by doing the threat model with the experts that could guide you in doing the threat model. There is also another practice, something that we call tactical threat modeling, which would essentially provide additional reference by executing small threat models, with intent not only to assess additional systems, but also with intent of understanding, of providing reference threat models for those scenarios so that a want to be expert can use not only that experience gained with the previous steps or the previous activities, but also by reading these additional papers.
Then we have, if you will, activities to make the threat modeling activities more aligned with the business, with your organization, and this requires some form of process customization, and then to ensure that the first model evolves. This is not sticky. This is not fixed in time. This evolves, and you need to have the possibility to think, again, and to evolve how you perceive threat modeling over time. So at this point, I hope that you get interested in the concept of threat model vNext, and hopefully you start to thinking how you can get this feel in your organization. The threat modeling vNext is, as of today, a process, is an idea. It’s like threat modeling. Yes, there are tools out of there, but the most important part of it is the concept, is the idea about the threat model, and I really invite you to start thinking, how can you adopt this concept? How can you integrate threat modeling in your reality, in your organization?
Can you increase the value? And it is also a roadmap. It is something that we are starting to implement internally in Microsoft, and the value that we are seeing is something that we want to also to export and expose to everyone. threat modeling, really in a modern way is possible, and the recommendation is to stay tuned, to get in touch. There is the reference here about my blog where I have put some articles about those ideas and I continue to put new information. So that’s it from my side. I hope you enjoyed this presentation on threat modeling vNext.
There are different tools that are out of there, some commercial tools also that may be adopted in this way. I will say that no free tool right now, unfortunately, is filling this need, and when I talk about the commercial tool, I talk about non-Microsoft tools. So this is not, I will say, some of the advertising for us. There are hopefully news that will help to cover using free tools for this in the future, but it’s too early. So the only thing that I can tell you is to keep looking at my blog, where definitely news on these will be published.
By creating a basic set of high quality reference templates, a knowledge basis that will help it to identify the common risks in a way that will be easily adoptable, usable in the threat model. This could provide the first result. By the way, by doing this, you also are teaching to people about the potential risks. This is how I learned to do threat modeling. So this is definitely the first way to go. Another way to go is to perform reviews. Definitely, this is also something that we have seen done. Tools may help also in doing some validation about the complexity quality of the threat models that are done, but yeah, I think those approaches will be the best.
There are parts like the integration with Azure DevOps which are in the process of being realized, and also we are going in the direction of integrating very advanced topics, like risk management, exception management in particular as part of the risk management to extend the reach to people that are more business oriented, and also quantitative risk assessment is another very important concept that needs to be included in threat modeling, and this is something where we are working, but it’s already something that we internally are using for all of our engagements, and some product groups have adopted this approach.