This section discusses Threat Modeling, an activity described in the OWASP Software Assurance Maturity Model (SAMM). Threat modeling is part of the Threat Assessment security practice in the Design business function.
Much of the material in this section is drawn from the OWASP Threat Model project, and the philosophy of this section tries to follow the Threat Modeling Manifesto.
Threat modeling activities try to discover what can go wrong with a system and determine what to do about it. The deliverables from threat modeling take various forms including system models and diagrams, lists of threats, mitigations or assumptions, meeting notes, and more. This may be assembled into a single threat model document; 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 and enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of potential security vulnerabilities in the concept, requirements, design, or implementation. Any potential vulnerabilities that have been identified from the model should then be remediated using one of the common strategies: mitigate, eliminate, transfer or accept the threat of being exploited.
There are many reasons for doing threat modeling but the most important one is that this activity is useful , it is probably the only stage in a development lifecycle where a team sits back and asks: ‘What can go wrong?’.
There are other reasons for threat modeling, for example standards compliance or analysis for disaster recovery, but the main aim of threat modeling is to remedy (possible) vulnerabilities before the malicious actors can exploit them.
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.
A threat model document is a record of the threat modeling process, and often includes:
The threat model should be in a form that can be easily revised and modified during subsequent threat modeling discussions.
Like all engineering activities, effort spent on threat modeling has to be justifiable. Rarely any project or development has engineering effort that is going ‘spare’, and the benefits of threat modeling have to outweigh the engineering cost of this activity. Usually this is difficult to quantify; an easier way to approach it may be to ask what are the costs of not doing threat modeling? These costs may consist of a lack of compliance, an increased risk of being exploited, harm to reputation and so on.
The inclusion of threat modeling in the secure development activities can help:
Threat modeling also provides a clear ‘line of sight’ across a project that can be used to justify other security efforts. The threat model allows security decisions to be made rationally, with all the information available, so that security decisions can be properly supported. The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims and then justifies them with either sub-claims or evidence.
There is no wrong time to do threat modeling; the earlier it is done in the development lifecycle the more beneficial it is, but it threat modeling is also useful at any time during application development.
Threat modeling is best applied continuously throughout a software development project. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the development lifecycle. Ideally, a high-level threat model should be defined in the concept or planning phase, and then refined during the development phases. As more details are added to the system new attack vectors are identified, so the ongoing threat modeling process should examine, diagnose, and address these threats.
Note that it is a natural part of refining a system for new threats to be exposed. 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: the sooner the better, but never too late
Often threat modeling is a conceptual activity rather than a rigorous process, where development teams are brought together and asked to think up ways of subverting their system. To provide some structure it is useful to start with Shostack’s Four Question Framework:
1 What are we working on?
As a starting point the scope of the Threat Model should be defined. This will require an understanding of the application that is being built, and some examples of inputs for the threat model could be:
It is common to represent the answers to this question with one or more data flow diagrams and often supplemental diagrams like message sequence diagrams.
It is best to gather people from different roles with sufficient technical and risk awareness so that they can agree on the framework to be used during the threat modeling exercise.
2 What can go wrong?
This is a research activity to find the main threats that apply to your application. There are many ways to approach the question, including open discussion or using a structure to help think it through. Techniques and methodologies to consider include CIA, STRIDE, LINDDUN, cyber kill chains, PASTA, common attack patterns (CAPEC) and others.
There are resources available that will help with identifying threats and vulnerabilities. OWASP provide a set of cards, Cornucopia, that provide suggestions and explanations for general vulnerabilities. The game Elevation of Privileges threat modeling card game is an easy way to get started with threat modeling, and there is the OWASP version of Snakes and Ladders that truly gamifies these activities.
3 What are we going to do about that?
In this phase turn the threat model findings into specific actions. Consider the appropriate remediation for each threat identified: Transfer, Avoid, Mitigate or Eliminate.
4 Did we do a good enough job?
Finally, carry out a retrospective activity over the work identified to check quality, feasibility, progress, or planning.
The OWASP Threat Modeling Playbook goes into these practicalities in more detail and provides strategies for maintaining threat modeling within an organisation.
There is no one process for threat modeling. How it is done in practice will vary according to the organisation’s culture, according to what type of system / application is being modeled and according to preferences of the development team itself. The various techniques and concepts are discussed in the Threat Modeling Cheat Sheet and can be summarised:
It is worth saying this again: there are many ways to do threat modeling, all perfectly valid, so choose the right process that works for a specific team.
Some final words on threat modeling.
Make it incremental:
Strongly consider using incremental threat modeling. It is almost certainly a bad idea trying to fully model an existing application or system; it can be very time consuming modeling a whole system, and by the time such a model was completed then it would probably be out of date. Instead incrementally model new features or enhancements as and when they are being developed.
Incremental threat modeling assumes that existing applications and features have already been attacked over time and these real world vulnerabilities have been remediated. It is the new features or new applications that pose a greater security risk; if they are vulnerable then they will reduce the security of the existing application or system. Concentrating on the new changes applies threat modeling effort at the place that it is needed most; at the very least the changes should not make the security worse - and ideally the security should be better.
Tools are secondary:
It is good to standardise threat modeling tools across an organisation, but also allow teams to choose how they record their threat models. If one team decides to use Threat Dragon, for example, and another wants to use a drawing board, then that is usually fine. The discussions had during the threat modeling process are more important than the tool used, although you might ask the team using the drawing board how they implement change control for their models.
Brevity is paramount:
It is very easy to create a threat model that looks a lot like a system diagram, with many components and data flows. This makes for a convincing diagram, but it is not a model specific to the threat of exploits. Instead concentrate on the attack / threat surfaces and be robust in consolidating multiple system components into one threat model component. This will keep the number of components and dataflows manageable, and focuses the discussion on what matters most: malicious actors (external or internal) trying to subvert your system.
Choose your methodology:
It is a good strategy to choose a threat categorisation methodology for the whole organisation and then try and keep to it. For example this could be STRIDE or LINDDUN, but if the CIA triad provides enough granularity then that is also a perfectly good choice.
The OWASP Developer Guide is a community effort; if there is something that needs changing then submit an issue or edit on GitHub.
The OWASP ® Foundation works to improve the security of software through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.
OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, and LASCON are trademarks of the OWASP Foundation, Inc. Unless otherwise specified, all content on the site is Creative Commons Attribution-ShareAlike v4.0 and provided without warranty of service or accuracy. For more information, please refer to our General Disclaimer. OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. Copyright 2024, OWASP Foundation, Inc.