OWASP Threat Modeling Project

Overview

The term “Threat Modeling” has become quite popular. The “State Of Threat Modeling Report” points at a robust and improving practice across companies and enterprises of all sizes, embracing a growing number of tools and methodologies.

In 2020, a group of threat modeling practitioners, researchers and authors got together to write the Threat Modeling Manifesto in order to “…share a distilled version of our collective threat modeling knowledge in a way that should inform, educate, and inspire other practitioners to adopt threat modeling as well as improve security and privacy during development”. The Manifesto contains values and principles connected to the practice and adoption of Threat Modeling, as well as identified patterns and anti-patterns to facilitate it.

One of the outputs of the Manifesto was this consensus-driven definition:

“Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.”

A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.

Threat modeling is a process for capturing, organizing and analyzing all of this information. Threat modeling enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security threats identified, and possibly mitigations to the risk they create.

Why Threat Model?

Threat modeling embodies a family of activities for improving security by identifying threats, understanding their criticality, and then defining countermeasures to prevent, or mitigate the effects of these threats to the system, functionality and user. A threat is a potential or actual undesirable event that may be malicious (such as CSRF attack) or incidental (thunderstorm knocking the power down). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities. It can also encompass fields related to Security, like Safety and Privacy.

Threat Modeling Across the Lifecycle

Threat modeling is best applied continuously throughout a software development project - at whatever resolution may be practical for that specific project.

The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a high-level threat model should be defined in the ideation or design phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors may be created and exposed. The ongoing threat modeling process examines, diagnoses, and addresses these threats.

Note that it is a natural part of refining a system for new threats to be exposed. For example, when you select a particular technology – such as Java for example – you take on the responsibility to identify the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with.

Threat modeling can be divided into two closely related activities: system modeling and threat elicitation. It is very important that all participants in a threat model be able to recognize the system under analysis in whatever representation (diagram, textual, etc.) is chosen, as that recognition will be the basis of the threat elicitation phase.

Benefits

Done right, threat modeling provides visibility across a project that helps justify and support security efforts. The threat model allows security decisions to be made rationally, with all the information on the table. The alternative is to make ad-hoc security decisions with no support in real data, scenarios and outcomes. The threat modeling process naturally produces an assurance argument, or artifact, that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either sub-claims or evidence.

Where to go from here?

Check the Resources tab for more extensive documentation, books and tools to start you on your journey!

Application Threat Modeling

Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the Internet of things, business processes, etc. There are very few technical products which cannot be threat modeled; more or less rewarding, depending on how much it communicates, or interacts, with the world. Threat modeling can be done at any stage of development, preferably early - so that the findings can inform the design.

What

Most of the time, a threat model includes:

• A description / design / model of what you’re worried about
• A list of assumptions that can be checked or challenged in the future as the threat landscape changes
• A list of potential threats to the system
• A list of actions to be taken for each threat
• A way of validating the model and threats, and verification of success of actions taken

Our motto is: Threat modeling: the sooner the better, but never too late.

Why

The inclusion of threat modeling in the SDLC can help

• Build a secure design
• Efficient investment of resources; appropriately prioritize security, development, and other tasks
• Bring Security and Development together to collaborate on a shared understanding, informing development of the system
• Identify threats and compliance requirements, and evaluate their risk
• Define and build required controls.
• Balance risks, controls, and usability
• Identify where building a control is unnecessary, based on acceptable risk
• Document threats and mitigation
• Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
• Identification of security test cases / security test scenarios to test the security requirements

4 Questions

The Threat Modeling Manifesto has adopted the 4 Questions Framework as the seminal framework to direct threat modeling efforts. Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:

What are we building?

As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:

• Architecture diagrams
• Dataflow transitions
• Data classifications
• You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat modeling exercise.

What can go wrong?

This is a “research” activity in which you want to find the main threats that apply to your application. There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.

What are we going to do about that?

In this phase you turn your findings into specific actions.

Did we do a good enough job?

Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning. Review needed changes to your process, your methodology, and how you communicate results to your stakeholders.

Process

The effort, work, and timeframes spent on threat modeling relate to the process in which engineering is happening and products/services are delivered. The idea that threat modeling is waterfall or ‘heavyweight’ is based on threat modeling approaches from the early 2000s. Modern threat modeling building blocks fit well into agile and are in wide use.

When to Threat Model

When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious.

Threat modeling integrates into Agile by asking “what are we working on, now, in this sprint/spike/feature?”; trying to answer this can be an important aspect of managing security debt, but trying to address it per-sprint is overwhelming. When the answer is that the system’s architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being transmitted, then it is unlikely that the answers to ‘what can go wrong’ will change. When one or more of those changes, then it’s useful to examine what can go wrong as part of the current work package, and to understand designs trade-offs you can make, and to understand what you’re going to address in this sprint and in the next one. The question of did we do a good job is split: the “did we address these threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task.

After a security incident, going back and checking the threat models can be an important process.

Threat Modeling: Engagement Versus Review

Threat modeling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modeling, yet quite different.

The best resource to start learning about threat modeling or improving your existing process, is the Threat Modeling Manifesto. This Manifesto was created by a group of leading threat modeling professionals.

Threat Modeling OWASP Projects (Tools and Guidance)

• OWASP Threat Model Cookbook
• OWASP Threat Dragon
• OWASP PyTM
• OWASP Ontology Driven Threat Modeling
• OWASP Threat Model Library
• OWASP SAP Threat Modeling Builder
• OWASP Cumulus - gamified threat modeling for the cloud
• OWASP Cornucopia - gamified threat modeling
• OWASP Threat Modelling Guide
• OWASP Threat Modeling Playbook
• OWASP Dragon GPT

Additional OWASP References

• Threat Modeling in OWASP Security Culture
• Threat Modeling in OWASP Community Pages
• Threat Modeling Process in OWASP Community Pages
• Threat Modeling at the OWASP DevSecOps Guideline Project

Additional References

• Adam Shostack - “Threat Modeling: Designing for Security”
• Tony Uceda-Velez - “Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis”
• Brook Schoenfield - “Securing Systems: Applied Security Architecture and Threat Modeling”
• Microsoft’s Security Development Process
• Microsoft Threat Modeling & Tool
• SAFECode - “Tactical Threat Modeling”
• Matt Coles & Izar Tarandach - “Threat Modeling: A Practical Guide For Development Teams”