From f765c246ad566942fd259610eb69bf8f7578cae2 Mon Sep 17 00:00:00 2001 From: Adam Shostack <1176137+adamshostack@users.noreply.github.com> Date: Sun, 31 Mar 2024 19:54:28 +0000 Subject: [PATCH] Update Threat_Modeling_Process.md (#918) * Update Threat_Modeling_Process.md Four q frame, less consultant. * Update Threat_Modeling_Process.md removed ASF, removed risk quantification, clarified assets, removed DREAD, clarified what's in a sample. * Update Threat_Modeling_Process.md --------- Co-authored-by: Rick M --- pages/Threat_Modeling_Process.md | 162 ++++++++++++------------------- 1 file changed, 63 insertions(+), 99 deletions(-) diff --git a/pages/Threat_Modeling_Process.md b/pages/Threat_Modeling_Process.md index d543cb81e6..c2aab7be21 100644 --- a/pages/Threat_Modeling_Process.md +++ b/pages/Threat_Modeling_Process.md @@ -3,7 +3,7 @@ title: Threat Modeling Process layout: col-sidebar author: Larry Conklin -contributors: ["Victoria Drake", "Sven strittmatter", "Zoe Braiterman"] +contributors: ["Victoria Drake", "Sven strittmatter", "Zoe Braiterman", "Adam Shostack"] tags: ["threat modeling"] permalink: /Threat_Modeling_Process --- @@ -11,29 +11,31 @@ permalink: /Threat_Modeling_Process {% include writers.html %} - [Introduction](#introduction) - - [Step 1: Decompose the Application](#step-1-decompose-the-application) - - [Step 2: Determine and Rank Threats](#step-2-determine-and-rank-threats) + - [Step 1: Scope your work](#step-1-decompose-the-application) + - [Step 2: Identify Threats](#step-2-determine-and-rank-threats) - [Step 3: Determine Countermeasures and Mitigation](#step-3-determine-countermeasures-and-mitigation) -- [Decompose the Application](#decompose-the-application) - - [Threat Model Information](#threat-model-information) - - [External Dependencies](#external-dependencies) - - [Entry Points](#entry-points) - - [Exit Points](#exit-points) - - [Assets](#assets) - - [Trust Levels](#trust-levels) - - [Data Flow Diagrams](#data-flow-diagrams) - - [Example Diagrams](#example-diagrams) -- [Determine and Rank Threats](#determine-and-rank-threats) - - [Threat Categorization](#threat-categorization) - - [STRIDE](#stride) -- [STRIDE Threat List](#stride-threat-list) - - [Threat Analysis](#threat-analysis) - - [Ranking of Threats](#ranking-of-threats) - - [Subjective Model: DREAD](#subjective-model-dread) - - [Qualitative Risk Model](#qualitative-risk-model) -- [Determine Countermeasures and Mitigation](#determine-countermeasures-and-mitigation) - - [ASF Threat & Countermeasures Examples](#asf-threat--countermeasures-examples) - - [STRIDE Threat & Mitigation Techniques](#stride-threat--mitigation-techniques) + - [Step 4: Assess your work](#Step 4: Assess your work) +- +- A Sample threat model(#(Sample) Scope the work) +- [Scope your work (Samples)](#decompose-the-application) + - [Threat Model Information](#threat-model-information) + - [External Dependencies](#external-dependencies) + - [Entry Points](#entry-points) + - [Exit Points](#exit-points) + - [Assets](#assets) + - [Trust Levels](#trust-levels) + - [Data Flow Diagrams](#data-flow-diagrams) + - [Example Diagrams](#example-diagrams) + - [Determine Threats (samples) ](#determine-and-rank-threats) + - [STRIDE](#stride) + - [STRIDE Threat List (sample)](#stride-threat-list) + - [Threat Analysis](#threat-analysis) + - [Ranking of Threats](#ranking-of-threats) + - [Subjective Model: DREAD](#subjective-model-dread) + - [Qualitative Risk Model](#qualitative-risk-model) + - [Determine Countermeasures and Mitigation (Sample)](#determine-countermeasures-and-mitigation) + - [STRIDE Threat & Mitigation Techniques](#stride-threat--mitigation-techniques) + - [Assess your work] - [Complementing Code Review](#complementing-code-review) ## Introduction @@ -42,46 +44,59 @@ This document describes a structured approach to application threat modeling tha Threat modeling looks at a system from a potential attacker's perspective, as opposed to a defender's viewpoint. Making threat modeling a core component of your [SDLC](https://en.wikipedia.org/wiki/Systems_development_life_cycle) can help increase product security. -The threat modeling process can be decomposed into three high level steps. Each step is documented as it is carried out. The resulting document is the threat model for the application. +The threat modeling process can be decomposed into four high level steps. Frequently, each step is documented as it is carried out. The resulting document is the threat model for the application. Experts distinguish between the work of doing threat modeling and the work to create threat model documents. -### Step 1: Decompose the Application +### Step 1: Scope your work -The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves: +The first step in the threat modeling process is concerned with gaining an understanding of what you're working on. This can involve: -- Creating use cases to understand how the application is used. +- Drawing diagrams, often data flow diagrams. - Identifying entry points to see where a potential attacker could interact with the application. -- Identifying assets, i.e. items or areas that the attacker would be interested in. +- Trying to identifying "assets" - Identifying trust levels that represent the access rights that the application will grant to external entities. +- Reading a user story or creating one. (This step is sometimes extended to abuser stories, misuse cases, etc.) + -This information is documented in a resulting Threat Model document. It is also used to produce data flow diagrams ([DFDs](https://en.wikipedia.org/wiki/Data-flow_diagram)) for the application. The [DFDs](https://en.wikipedia.org/wiki/Data-flow_diagram) show the different paths through the system, highlighting the privilege boundaries. +Data flow diagrams ([DFDs](https://en.wikipedia.org/wiki/Data-flow_diagram)) are frequently used to show what we're working on. The [DFDs](https://en.wikipedia.org/wiki/Data-flow_diagram) show the different paths through the system, highlighting the privilege or trust boundaries. -### Step 2: Determine and Rank Threats +This is sometimes called "decompose the application," which is an approach that consultants use when they're brought in to do a threat model or architectural review. Consultants will often provide output in the form of a Threat Model document. -Critical to the identification of threats is using a threat categorization methodology. A threat categorization such as [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) can be used, or the Application Security Frame ([ASF](https://pathlock.com/learn/what-are-application-security-frameworks/)) that defines threat categories such as Auditing & Logging, Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, and Exception Management. +Tarandach has advocated for "Threat modeling every story," which is work that developers, operations or SRE would do. When threat modeling every story, "decompose the application" is meaningless. -The goal of the threat categorization is to help identify threats both from the attacker ([STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29)) and the defensive perspective ([ASF](https://pathlock.com/learn/what-are-application-security-frameworks/)). [DFDs](https://en.wikipedia.org/wiki/Data-flow_diagram) produced in step 1 help to identify the potential threat targets from the attacker's perspective, such as data sources, processes, data flows, and interactions with users. +This step often calls out "assets", which can be any of things you want to protect, stepping stones, or things attackers want. Often times those assets are out of scope for a project, and are a distraction. Other times, they're hard to identify in advance of an attacker drawing attention to them. -These threats can be classified further as the roots for threat trees; there is one tree for each threat goal. From the defensive perspective, [ASF](https://pathlock.com/learn/what-are-application-security-frameworks/) categorization helps to identify the threats as weaknesses of security controls for such threats. Common threat lists with examples can help in the identification of such threats. Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. The determination of the security risk for each threat can be made using a value-based risk model such as [DREAD](https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)), or a less subjective qualitative risk model based upon general risk factors (e.g. likelihood and impact). +### Step 2: Determine Threats + +Critical to the identification of threats is using a threat categorization methodology. [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) is frequently used in threat modeling, and kill chains including MITRE ATT&CK are frequently used for operational threat modeling. + +The goal of the threat categorization is to help identify threats both from the attacker ([STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29)). [DFDs](https://en.wikipedia.org/wiki/Data-flow_diagram) produced in step 1 help to identify the potential threat targets from the attacker's perspective, such as data sources, processes, data flows, and interactions with users. + +These threats can be organized further using threat trees; there is one tree for each threat goal. Common threat lists with examples can help in the identification of such threats. Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. ### Step 3: Determine Countermeasures and Mitigation -A vulnerability may be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking is assigned to the threats in step 2, it is possible to sort threats from the highest to the lowest risk and prioritize mitigation efforts. +A vulnerability may be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threat-countermeasure mapping lists. Prioritization of countermeasures is a complex and contentious topic. Many approaches exist, and organizations need to select ones that will work for them. Frequently included factors are likelihood of attack, damage from an attack, and complexity or cost of fix. The risk mitigation strategy might involve evaluating these threats from the business impact they pose. Once the possible impact is identified, options for addressing the risk include: -- Accept: decide that the business impact is acceptable +- Accept: decide that the business impact is acceptable, and document who has chosen to accept the risk - Eliminate: remove components that make the vulnerability possible - Mitigate: add checks or controls that reduce the risk impact, or the chances of its occurrence +- Transfer: Transfer risk to an insurer or customer. The following sections examine these steps in depth and provide examples of the resulting threat model in a structured format. -## Decompose the Application +### Step 4: Assess your work + +First, determine if you've done the work. Are there records showing a diagram, a threats list and a control list. + +## (Sample) Scope the work -The goal of this step is to gain an understanding of the application and how it interacts with external entities. This goal is achieved by information gathering and documentation. The information gathering process is carried out using a clearly defined structure, which ensures the correct information is collected. +This version frames the work as aimed at helping those not involved with the application's development gain an understanding of the application and how it interacts with external entities. This goal is achieved by information gathering and documentation. The information gathering process is carried out using a clearly defined structure, which ensures the correct information is collected. -### Threat Model Information +### (Sample) Threat Model Information -Information identifying the threat model typically includes the the following: +Waterfall-style or consultant-delivered threat model documents typically includes the the following: 1. **Application Name**: The name of the application examined. 2. **Application Version**: The version of the application examined. @@ -92,7 +107,7 @@ Information identifying the threat model typically includes the the following: Example: -> ## Threat Model Information +> ## Threat Model Information (Sample) > > **Application Version:** 1.0 > @@ -110,7 +125,7 @@ Example: > > **Reviewer:** Eoin Keary -### External Dependencies +### External Dependencies (Sample) External dependencies are items external to the code of the application that may pose a threat to the application. These items are typically still within the control of the organization, but possibly not within the control of the development team. The first area to consider when investigating external dependencies is the production environment and requirements. @@ -123,7 +138,7 @@ External dependencies should be documented as follows: Example: -> ## External Dependencies +> ## External Dependencies (Sample) > > | ID | Description | > | --- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -168,11 +183,9 @@ In many cases threats enabled by exit points are related to the threats of the c ### Assets -The system must have something that the attacker is interested in; these items or areas of interest are defined as assets. +Many have something that one or more attackers are interested in; these items or areas of interest are often labelled "assets." Assets can be both physical assets and abstract assets. For example, an asset of an application might be a list of clients and their personal information; this is a physical asset. An abstract asset might be the reputation of an organization. It is unclear how talking about the reputation of the organization aids in threat modeling. -Assets are essentially targets for attackers, i.e. they are the reason threats will exist. Assets can be both physical assets and abstract assets. For example, an asset of an application might be a list of clients and their personal information; this is a physical asset. An abstract asset might be the reputation of an organization. - -Assets are documented in the threat model as follows: +Assets are documented in this sample threat model as follows: 1. **ID**: A unique ID is assigned to identify each asset. This will be used to cross-reference the asset with any threats or vulnerabilities that are identified. 2. **Name**: A descriptive name that clearly identifies the asset. @@ -256,15 +269,12 @@ _Figure 1: Data Flow Diagram for the College Library Website._ _Figure 2: User Login Data Flow Diagram for the College Library Website._ -## Determine and Rank Threats - -### Threat Categorization +## Determine Threats (Sample) -The first step in the determination of threats is adopting a threat categorization. A threat categorization provides a set of categories with corresponding examples so that threats can be systematically identified in the application in a structured and repeatable manner. ### STRIDE -A threat categorization such as [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) is useful in the identification of threats by classifying attacker goals such as: +A threat mnemonic such as [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) is useful in the identification of threats by prompting us to think about attacker steps such as: - **S**poofing - **T**ampering @@ -273,7 +283,7 @@ A threat categorization such as [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%2 - **D**enial of Service - **E**levation of Privilege -A list of generic threats classified using [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) is provided in the following table along with their security controls: +A list of generic threats using [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) is provided in the following table along with their security controls: ## STRIDE Threat List @@ -290,11 +300,7 @@ Threat lists based on the [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28secur ### Threat Analysis -A prerequisite in the analysis of threats is the understanding of the generic definition of risk. Risk is a potential for loss determined by two factors: the likelihood, or probability, that an attack will occur; and the potential impact, or cost, of such an attack occurring. Risk is calculated as: - -_(Probability that threat occurs) x (Cost to organization)_ - -From the perspective of risk management, threat modeling is a systematic and strategic approach for identifying and enumerating threats to an application environment with the objective of minimizing risk and potential impact. +It is frequently claimed that "a prerequisite in the analysis of threats is the understanding of the generic definition of risk." But this is not the case. You can analyze what can go wrong without being able to measure or quantify it. Threat analysis is the identification of threats to the application, and involves the analysis of each aspect of the application's functionality, architecture, and design. It is important to identify and classify potential weaknesses that could lead to an exploit. @@ -324,39 +330,10 @@ Threats can be ranked from the perspective of risk factors. By determining the r _Figure 5: Ranking Risk Factors._ -### Subjective Model: DREAD - -In the Microsoft [DREAD](https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)) risk assessment model, risk factorization allows the assignment of values to the different influencing factors of a threat. This provides a subjective process to rank threats. To determine the ranking of a threat, the threat analyst answers questions for each factor of risk, for example: -- **D**amage: How big would the damage be if the attack succeeded? -- **R**eproducibility: How easy is it to reproduce an attack? -- **E**xploitability: How much time, effort, and expertise is needed to exploit the threat? -- **A**ffected Users: If a threat were exploited, what percentage of users would be affected? -- **D**iscoverability: How easy is it for an attacker to discover this threat? - -A point system of numbers 1-10, representing low to high severity, is used to calculate a [DREAD](https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)) score that can help compare one threat to another. - -Example: - -> ## Threat: Malicious user views confidential information of students, faculty members and librarians. -> -> 1. **Damage potential:** Threat to reputation as well as financial and legal liability (8) -> 2. **Reproducibility:** Fully reproducible (10) -> 3. **Exploitability:** Require to be on the same subnet or have compromised a router (7) -> 4. **Affected users:** Affects all users (10) -> 5. **Discoverability:** Can be found out easily (10) -> -> Overall DREAD score for this threat: (8+10+7+10+10) / 5 = 9 - -The [DREAD](https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)) model does not have widespread use across the industry, as its ratings are subjective. Within an organization, however, models that employ subjective ranking can help to clarify priorities when addressing risk. ### Qualitative Risk Model -A generic risk model considers risk as a calculation. Recall that risk is determined by the likelihood of an attack and the impact of that attack: - -_(Probability that threat occurs) x (Cost to organization)_ - -The likelihood, or probability, can be determined by the ease of exploitation. This depends on the type of threat and the system characteristics, as well as considers any countermeasures that may already be in place. The following is a set of considerations for determining ease of exploitation: @@ -386,20 +363,7 @@ The purpose of countermeasure identification is to determine if there is some ki Provided below is a brief and limited checklist which is by no means an exhaustive list for identifying countermeasures for specific threats. -### [ASF](https://pathlock.com/learn/what-are-application-security-frameworks/) Threat & Countermeasures Examples - -| Threat Type | Countermeasure | -| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Authentication | 1. Credentials and authentication tokens are protected with encryption in storage and transit
2. Protocols are resistant to brute force, dictionary, and replay attacks
3. Strong password policies are enforced
4. Trusted server authentication is used instead of SQL authentication
5. Passwords are stored with salted hashes
6. Password resets do not reveal password hints and valid usernames
7. Account lockouts do not result in a denial of service attack | -| Authorization | 1. Strong ACLs are used for enforcing authorized access to resources
2. Role-based access controls are used to restrict access to specific operations
3. The system follows the principle of least privilege for user and service accounts
4. Privilege separation is correctly configured within the presentation, business and data access layers | -| Configuration Management | 1. Least privileged processes are used and service accounts with no administration capability
2. Auditing and logging of all administration activities is enabled
3. Access to configuration files and administrator interfaces is restricted to administrators | -| Data Protection in Storage and Transit | 1. Standard encryption algorithms and correct key sizes are being used
2. Hashed message authentication codes (HMACs) are used to protect data integrity
3. Secrets (e.g. keys, confidential data ) are cryptographically protected both in transport and in storage
4. Built-in secure storage is used for protecting keys
5. No credentials and sensitive data are sent in clear text over the wire | -| Data Validation / Parameter Validation | 1. Data type, format, length, and range checks are enforced
2. All data sent from the client is validated
3. No security decision is based upon parameters (e.g. URL parameters) that can be manipulated
4. Input filtering via allow list validation is used
5. Output encoding is used | -| Error Handling and Exception Management | 1. All exceptions are handled in a structured manner
2. Privileges are restored to the appropriate level in case of errors and exceptions
3. Error messages are scrubbed so that no sensitive information is revealed to the attacker | -| User and Session Management | 1. No sensitive information is stored in clear text in the cookie
2. The contents of the authentication cookies is encrypted
3. Cookies are configured to expire
4. Sessions are resistant to replay attacks
5. Secure communication channels are used to protect authentication cookies
6. User is forced to re-authenticate when performing critical functions
7. Sessions are expired at logout | -| Auditing and Logging | 1. Sensitive information (e.g. passwords, PII) is not logged
2. Access controls (e.g. ACLs) are enforced on log files to prevent un-authorized access
3. Integrity controls (e.g. signatures) are enforced on log files to provide non-repudiation
4. Log files provide for audit trail for sensitive operations and logging of key events
5. Auditing and logging is enabled across the tiers on multiple servers | -When using [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29), the following threat-mitigation table can be used to identify techniques that can be employed to mitigate the threats. ### STRIDE Threat & Mitigation Techniques