Threat modelling was the subject of the latest Virtualization Security Podcast (which I am still trying to upload, so time for a new service). Threat modelling is what every security person does, but not necessarily formally. Threat modelling in many ways takes an architecture and looks for well-known threats. One such threat that could come to mind is crossing a trust zone boundary without going through a control point. Yet, there are many more.

Threat modelling goes a long way to discover just what those are. However, it is not the end—just the starting point. A well-drawn-out threat model is a logical representation of your application. Therefore, all the threats are derived from well-defined, logical rules. Good tools allow you to add your own rules. For a cloud environment, we could insist that access to the management plane be through some control point such as a CASB or firewall construct. However, there could be other logical issues with such a design. The diagrams of a threat model are designed to help you think logically about security.
They also act as a communication tool: a tool that helps to organize your thoughts when you talk to others. You can also share the raw diagrams and threats. However, once you have the threats, the next step is to decide what really applies to your organization. Is there some defense in depth you do not know about? In our example, a defense-in-depth measure could be using SSO already to only allow authentication through authorized users. If that is not in the model, then it should be added and the model adjusted.
After the model review and the potential threats review, it is time to use that data and business logic to determine the value of each threat. In other words, how serious is the threat? Not every threat is as serious as the others. This is where business impacts security. A good threat model will help to organize your thoughts and even provide places to augment your defense in depth to cover the greatest number of issues at once. Would adding a CASB on top of what you already have solve more issues, such as tracking use actions within the cloud?
The goal is to have the most secure environment, but there are costs. Those costs are defined by the business. There are just not unlimited funds, so the threat model is the platform to help decide the best and most cost-effective approaches. You can put the changes into your model, rerun the threat generation, and see if your bases are covered.
So, basically, we have a tool that will allow us to play “what if” questions. As long as the model is kept up to date, then those “what if” questions can provide answers upon which we can build our solutions. We can answer the questions and provide something we don’t know now as a potential solution.
Threat modelling does not need to be black magic. It is logic, with rules and tools. Those tools include Microsoft Threat Modeling Tool, OWASP Threat Dragon, and several others. These tools are your starting point: they will help you to begin, organize your thoughts, and provide diagrams as talking points when you go to the business. However, while the tools know about specific threats, you will need to add your own.
Who should threat model? Only security professionals? No, everyone can. It is a tool that can help organize thoughts and provide a method to communicate between teams. Developers can threat model and then allow security professionals to answer the questions brought up. It is a tool for every day. It all starts with an architectural diagram. That is the key.
A threat model should be kept up to date as architecture and implementations change. We can now bridge architecture, implementation, security, and operations with one tool. It all starts with the thought on how data moves.
Shouldn’t all developers, architects, implementers, and operations folks know how data moves around an environment? Do you threat model?