OWASP Threat Modeling Project

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.

The inclusion of threat modeling in the SDLC can help

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:

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.

In this phase you turn your findings into specific actions.

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 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.