├── .gitignore ├── Gemfile ├── _config.yml ├── assets └── images │ └── README.md ├── .github ├── dependabot.yml └── workflows │ └── validate-owasp-metadata.yaml ├── leaders.md ├── info.md ├── project.owasp.yaml ├── README.md ├── index.md ├── tab_resources.md ├── tab_threatmodeling.md └── tab_application-tm.md /.gitignore: -------------------------------------------------------------------------------- 1 | /Gemfile 2 | /Gemfile.lock 3 | /favicon.ico 4 | _site/ -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'https://rubygems.org' 2 | group :jekyll_plugins do 3 | gem "github-pages" 4 | end -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | remote_theme: "owasp/www--site-theme@main" 2 | plugins: 3 | - jekyll-include-cache-0.2.0 -------------------------------------------------------------------------------- /assets/images/README.md: -------------------------------------------------------------------------------- 1 | # placeholder 2 | 3 | Put images you wish to link to in this folder 4 | 5 | link would be in form /assets/images/ 6 | -------------------------------------------------------------------------------- /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | updates: 3 | - package-ecosystem: github-actions 4 | directory: / 5 | schedule: 6 | interval: weekly 7 | time: '00:45' 8 | -------------------------------------------------------------------------------- /leaders.md: -------------------------------------------------------------------------------- 1 | ### Leaders 2 | 3 | * [Matt Coles](mailto:matthew.coles@owasp.org) 4 | * [Avi Douglen](mailto:avi.douglen@owasp.org) 5 | * [Brook Schoenfield](mailto:brook.schoenfield@owasp.org) 6 | * [Adam Shostack](mailto:adam.shostack@owasp.org) 7 | * [John Taylor](mailto:john.taylor@owasp.org) 8 | -------------------------------------------------------------------------------- /info.md: -------------------------------------------------------------------------------- 1 | ### OWASP Threat Model Information 2 | * [Documentation Project](#) 3 | * [Builder](#) 4 | 5 | ### Downloads or Social Links 6 | * [Download](#) 7 | * [Meetup](#) 8 | 9 | ### Code Repository 10 | * [repo](https://github.com/OWASP/www-project-threat-model/) 11 | 12 | ### Change Log 13 | * [changes](#) 14 | 15 | -------------------------------------------------------------------------------- /.github/workflows/validate-owasp-metadata.yaml: -------------------------------------------------------------------------------- 1 | name: Validate OWASP entity metadata 2 | 3 | on: 4 | pull_request: 5 | paths: 6 | - '*.owasp.yaml' 7 | push: 8 | paths: 9 | - '*.owasp.yaml' 10 | 11 | permissions: 12 | contents: read 13 | 14 | concurrency: 15 | cancel-in-progress: true 16 | group: ${{ github.repository }}-${{ github.workflow }}-${{ github.ref }} 17 | 18 | jobs: 19 | validate-metadata: 20 | runs-on: ubuntu-latest 21 | 22 | steps: 23 | - name: Checkout code 24 | uses: actions/checkout@v6 25 | 26 | - name: Validate metadata file 27 | uses: owasp/nest-schema/.github/actions/validate@7e55a04dce2fea3606abdf49e9cb8e7f465ab801 28 | -------------------------------------------------------------------------------- /project.owasp.yaml: -------------------------------------------------------------------------------- 1 | audience: 2 | - builder 3 | leaders: 4 | - name: Matt Coles 5 | email: matthew.coles@owasp.org 6 | github: colesmj-owasp 7 | - name: Avi Douglen 8 | email: avi.douglen@owasp.org 9 | github: avidouglen 10 | - name: Brook Schoenfield 11 | email: brook.schoenfield@owasp.org 12 | github: bschoenfield 13 | - name: Adam Shostack 14 | email: adam.shostack@owasp.org 15 | github: adamshostack 16 | - name: John Taylor 17 | email: john.taylor@owasp.org 18 | github: jt-infosec 19 | level: 2 20 | name: OWASP Threat Modeling Project 21 | pitch: Central repository of threat modeling information, techniques, and methodologies 22 | repositories: 23 | - name: www-project-threat-modeling 24 | url: https://github.com/OWASP/www-project-threat-modeling 25 | description: OWASP Foundation Web Repository 26 | tags: 27 | - threat-modeling 28 | - threat-model 29 | - documentation-project 30 | type: documentation 31 | website: https://owasp.org/www-project-threat-modeling 32 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Threat Modeling Project 2 | 3 | OWASP is well-known for providing quality and comprehensive information to the developers and others worldwide. 4 | Our goal as leaders of the Threat Modeling Project is to build a functional “umbrella” project 5 | where differing views on threat modeling can coexist, drawing from and supporting the threat modeling community 6 | with clear, consistent, practical guidance and capabilities. 7 | 8 | We wish to foster a community that enables people to learn, share and 9 | create content that serves both OWASP members and those of the broader community. 10 | We want to ensure the content made available through this project is both comprehensive and practically-oriented. 11 | The direction of the community will build on the foundational work of the past 12 | and provide sufficiently clear guidance to ensure that OWASP’s threat modeling resources are cohesive. 13 | 14 | We’re getting together to figure out things like defining a set of community activities including calls, 15 | and an open process for defining a charter, and plan to have some of that practical stuff by mid-December 2025. 16 | 17 | We look forward to revitalizing the OWASP Threat Modeling Project and bringing consistency to the threat modeling practices 18 | and guidance supporting OWASP’s mission to be a gold-standard resource for development efforts. 19 | We also hope you will be active partners in building this community further. 20 | 21 | The easiest way to get in contact with the OWASP Threat Model community is 22 | through the OWASP Slack Threat model channel [#threat-modeling](https://owasp.slack.com/messages/C1CS3C6AF). 23 | 24 | You can [subscribe](https://owasp.org/slack/invite) if you are not yet a member of the OWASP Slack community. 25 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: OWASP Threat Modeling Project 5 | tags: threatmodeling 6 | level: 2 7 | type: documentation 8 | pitch: Central repository of threat modeling information, techniques, and methodologies 9 | 10 | --- 11 | 12 | This is a documentation project. We provide information on threat modeling techniques for applications of all types, with a focus on current and emerging techniques. 13 | 14 | Most threat model techniques answer one or more of the following questions: 15 | 16 | * What are we working on? 17 | * What can go wrong? 18 | * What are we going to do about that? 19 | * Did we do a good enough job? 20 | 21 | This project will gather techniques, methodologies, tools and examples. We will group these using the four questions. This will allow people to easily find advice they can use. 22 | 23 | Example: if you are looking for different diagramming techniques you will want to look for all the techniques answering the question "What are we working on." 24 | 25 | ### Guiding principles: 26 | 27 | This project follows a number of principles that all contributions must adhere to: 28 | 29 | - We are vendor, methodology and tool independent: we strive to have examples in as many methodologies and/or tools as possible. 30 | - Open discussion is promoted: all topics are open for discussion with just one rule: don't be a jerk. If you feel information is lacking or missing, let us know via the OWASP #threat-modeling slack channel. 31 | - We come to an agreement: we discuss things mainly in google docs and on slack, if the project leaders feel a consensus is made, we will publish the content to our main website. All published content can be changed by submitting change requests on the Github repository that serves the website. 32 | 33 | -------------------------------------------------------------------------------- /tab_resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | title: Resources 4 | layout: null 5 | tab: true 6 | order: 3 7 | tags: threatmodeling 8 | 9 | --- 10 | 11 | The best resource to start learning about threat modeling or improving your existing process, is the [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/). This Manifesto was created by a group of leading threat modeling professionals. 12 | 13 | ## Threat Modeling OWASP Projects (Tools and Guidance) 14 | 15 | - [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) 16 | - [OWASP PyTM](https://owasp.org/www-project-pytm/) 17 | - [OWASP Ontology Driven Threat Modeling](https://owasp.org/www-project-ontology-driven-threat-modeling-framework/) 18 | - [OWASP Threat Model Library](https://owasp.org/www-project-threat-model-library/) 19 | - [OWASP SAP Threat Modeling Builder](https://owasp.org/www-project-sap-threat-modeling-builder/) 20 | - [OWASP Cumulus - gamified threat modeling for the cloud](https://owasp.org/www-project-cumulus/) 21 | - [OWASP Cornucopia - gamified threat modeling](https://owasp.org/www-project-cornucopia/) 22 | - [OWASP Threat Modelling Guide](https://owasp.org/www-project-threat-modelling-guide/) 23 | - [OWASP Threat Modeling Playbook](https://owasp.org/www-project-threat-modeling-playbook/) 24 | - [OWASP Dragon GPT](https://owasp.org/www-project-dragon-gpt/) 25 | 26 | ## Additional OWASP References 27 | 28 | - [Threat Modeling in OWASP Security Culture](https://owasp.org/www-project-security-culture/v10/6-Threat_Modelling/) 29 | - [Threat Modeling in OWASP Community Pages](https://owasp.org/www-community/Threat_Modeling) 30 | - [Threat Modeling Process in OWASP Community Pages](https://owasp.org/www-community/Threat_Modeling_Process) 31 | - [Threat Modeling at the OWASP DevSecOps Guideline Project](https://owasp.org/www-project-devsecops-guideline/latest/00b-Threat-modeling) 32 | 33 | 34 | 35 | 36 | 37 | ## Additional References 38 | 39 | - [Adam Shostack - "Threat Modeling: Designing for Security"](https://shostack.org/books/threat-modeling-book) 40 | - [Tony Uceda-Velez - "Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis"](https://versprite.com/author/tony-ucedavelez/) 41 | - [Brook Schoenfield - "Securing Systems: Applied Security Architecture and Threat Modeling"](http://brookschoenfield.com/?page_id=245) 42 | - [Microsoft's Security Development Process](https://www.microsoft.com/en-us/securityengineering/sdl) 43 | - [Microsoft Threat Modeling & Tool](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) 44 | - [SAFECode - "Tactical Threat Modeling"](https://safecode.org/tactical-threat-modeling/) 45 | - [Matt Coles & Izar Tarandach - "Threat Modeling: A Practical Guide For Development Teams"](https://threatmodeling.dev) 46 | -------------------------------------------------------------------------------- /tab_threatmodeling.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | title: ThreatModeling 4 | displaytext: Threat Modeling 5 | layout: null 6 | tab: true 7 | order: 1 8 | tags: threatmodeling 9 | 10 | --- 11 | 12 | ## Overview 13 | 14 | The term "Threat Modeling" has become quite popular. The "[State Of Threat Modeling Report](https://www.threatmodelingconnect.com/state-of-threat-modeling-2024-25)" points at a robust and improving practice across companies and enterprises of all sizes, embracing a growing number of tools and methodologies. 15 | 16 | In 2020, a group of threat modeling practitioners, researchers and authors got together to write the [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/) 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. 17 | 18 | One of the outputs of the Manifesto was this consensus-driven definition: 19 | 20 | "Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics." 21 | 22 | A threat model is essentially a structured representation of all the 23 | information that affects the security of an application. In essence, it 24 | is a view of the application and its environment through security glasses. 25 | 26 | Threat modeling is a process for capturing, organizing and analyzing 27 | all of this information. Threat modeling enables informed 28 | decision-making about application security risk. In addition to 29 | producing a model, typical threat modeling efforts also produce a 30 | prioritized list of security threats identified, and possibly mitigations to the risk they create. 31 | 32 | ## Why Threat Model? 33 | 34 | Threat modeling embodies a family of activities for improving security by 35 | identifying threats, understanding their criticality, and then defining 36 | countermeasures to prevent, or mitigate the effects of these threats to the 37 | 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. 38 | 39 | ## Threat Modeling Across the Lifecycle 40 | 41 | Threat modeling is best applied continuously throughout a software 42 | development project - at whatever resolution may be practical for that specific project. 43 | 44 | The process is essentially the same at different 45 | levels of abstraction, although the information gets more and more 46 | granular throughout the lifecycle. Ideally, a high-level threat model 47 | should be defined in the ideation or design phase, and then refined 48 | throughout the lifecycle. As more details are added to the system, new 49 | attack vectors may be created and exposed. The ongoing threat modeling 50 | process examines, diagnoses, and addresses these threats. 51 | 52 | Note that it is a natural part of refining a system for new threats to 53 | be exposed. For example, when you select a particular technology -- such 54 | as Java for example -- you take on the responsibility to identify the 55 | new threats that are created by that choice. Even implementation choices 56 | such as using regular expressions for validation introduce potential new 57 | threats to deal with. 58 | 59 | 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. 60 | 61 | ## Benefits 62 | 63 | Done right, threat modeling provides visibility across a 64 | project that helps justify and support security efforts. The threat model allows security decisions to be made rationally, with all the information on 65 | the table. The alternative is to make ad-hoc security decisions with 66 | 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. 67 | 68 | ## Where to go from here? 69 | 70 | Check the [Resources tab](https://owasp.org/www-project-threat-modeling/#div-resources) for more extensive documentation, books and tools to start you on your journey! 71 | -------------------------------------------------------------------------------- /tab_application-tm.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | title: application-tm 4 | displaytext: Application Threat Modeling 5 | layout: null 6 | tab: true 7 | order: 2 8 | tags: threatmodeling 9 | 10 | --- 11 | 12 | ## Application Threat Modeling 13 | 14 | Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value. 15 | 16 | Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things 17 | in the Internet of things, business processes, etc. There are very few technical products which cannot be threat modeled; more or less 18 | rewarding, depending on how much it communicates, or interacts, with the world. Threat modeling can be done at any stage of development, 19 | preferably early - so that the findings can inform the design. 20 | 21 | ### What 22 | 23 | Most of the time, a threat model includes: 24 | 25 | - A description / design / model of what you’re worried about 26 | - A list of assumptions that can be checked or challenged in the future as the threat landscape changes 27 | - A list of potential threats to the system 28 | - A list of actions to be taken for each threat 29 | - A way of validating the model and threats, and verification of success of actions taken 30 | 31 | Our motto is: Threat modeling: the sooner the better, but never too late. 32 | 33 | ### Why 34 | 35 | The inclusion of threat modeling in the SDLC can help 36 | 37 | - Build a secure design 38 | - Efficient investment of resources; appropriately prioritize security, development, and other tasks 39 | - Bring Security and Development together to collaborate on a shared understanding, informing development of the system 40 | - Identify threats and compliance requirements, and evaluate their risk 41 | - Define and build required controls. 42 | - Balance risks, controls, and usability 43 | - Identify where building a control is unnecessary, based on acceptable risk 44 | - Document threats and mitigation 45 | - Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact 46 | - Identification of security test cases / security test scenarios to test the security requirements 47 | 48 | ### 4 Questions 49 | 50 | The Threat Modeling Manifesto has adopted the [4 Questions Framework](https://github.com/adamshostack/4QuestionFrame) 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: 51 | 52 | #### What are we building? 53 | 54 | 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, 55 | examples of helpful techniques are: 56 | 57 | - Architecture diagrams 58 | - Dataflow transitions 59 | - Data classifications 60 | - 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. 61 | 62 | #### What can go wrong? 63 | 64 | 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 65 | question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others. 66 | 67 | #### What are we going to do about that? 68 | 69 | In this phase you turn your findings into specific actions. 70 | 71 | #### Did we do a good enough job? 72 | 73 | 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. 74 | 75 | ### Process 76 | 77 | The effort, work, and timeframes spent on threat modeling relate to the process in which engineering is happening and products/services are 78 | delivered. The idea that threat modeling is waterfall or ‘heavyweight’ is based on threat modeling approaches from the early 2000s. Modern 79 | threat modeling building blocks fit well into agile and are in wide use. 80 | 81 | #### When to Threat Model 82 | 83 | When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious. 84 | 85 | 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 86 | architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being 87 | 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 88 | 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 89 | 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 90 | threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task. 91 | 92 | After a security incident, going back and checking the threat models can be an important process. 93 | 94 | #### Threat Modeling: Engagement Versus Review 95 | 96 | Threat modeling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model 97 | that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be 98 | meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for 99 | documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modeling, 100 | yet quite different. 101 | --------------------------------------------------------------------------------