Today’s cloud security requires a new way of looking at threat models. Making a threat model can support your security teams before problems start. It helps them develop a strategy for handling existing risks, instead of detecting incidents at a later stage. Let’s walk through how to create a threat model that works for your cloud landscape.
The Open Web Application Security Project (OWASP) defines threat modeling as “a process for capturing, organizing and analyzing all of the information [that affects the security of an application].”
By the end of making one, you should have a list of “security improvements to the concept, requirements, design or implementation.”
Why Does Threat Modeling Matter?
A threat model shows parameters that explain a threat. For example, it might cover the built-in risk factors, threat agents, potential attack road maps, business impact assessments and remedies. In the field of software security, threat models help spot threats to systems and data — from tech-driven threats such as web exploits to wider risks such as unwanted system access or insecure data storage.
There are many threat assessment methodologies, like Microsoft’s STRIDE. STRIDE — which stands for Spoofing, Tempering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege — helps security experts and developers find threat vectors in these categories.
Creating a threat model at the design stage helps throughout the system development life cycle. Teams can learn the controls and automate cloud security infrastructure from beginning to end. Therefore, threat modeling should occur at an early stage of your system development.
Let’s get started. Here are the best steps to building a threat model.
1. Choose the Right Team for Your Cloud Security
A threat modeling process should include people from teams across different disciplines. A security team member will serve as the risk
owner of the process. The security team, web developers, software engineers, operations team and business segment owners might all be important members.
Working with the expertise of multiple, mixed groups involved in app development, testing scenarios and business delivery will provide a more holistic vision of what you are designing. That includes what could go wrong in the process and how to rectify or mitigate risk over the long term.
2. Understand the Boundaries of the System
Once your team is ready, it’s time to analyze what the trust zones and scope of the system are. Just be cautious not to make the system boundary too large — as you increase the scope of the boundary, it gets more difficult to model. Map out all the application architecture to understand the data flows and actors involved. A data flow diagram is the usual way of doing this.
OWASP has some guidelines, which look at the following factors:
- The trust boundaries modeled within the system.
- The threat actors or agents that interact within and outside of the trust boundaries of the system.
- Information flows in various directions within and to/from the trust boundaries.
- Information persistence within and outside of trust boundaries for data modeling.
- The potential threats and existing risks to these trust boundaries.
- Threat actors or agents that exploit known openings.
- The impact and likelihood a threat agent could exploit an opening.
3. Consider Risk Factors to Cloud Security
When you have a list of threats to your applications and system, you need to determine what type of controls you will put in place to reduce them. If you don’t configure the various things required to implement the system boundaries properly, they could impact your threat model in a big way.
For example, take a look at your cloud security infrastructure design and the control plane services to start with.
