The Threat Modeling Process Part 2: How to Set Up Your First Threat Model

In the first part of this series, we saw an overview of the threat modeling process. In this post we’re going to dig into details of each of the steps to learn how it works.

Step 1: Identify Security Objectives

Security specific objectives are a subset of project objectives, and we should use them to guide our threat modeling efforts. We may find it helpful to think of security objectives in terms of constraints. Consider the question, “What do you not want to happen?” For example, an attacker must not be able to get customer data.
By identifying our key security objectives, we can determine where to focus our efforts. It also helps to understand goals of potential attackers and concentrate on those areas of applications that require closer attention. If we identify customer account details as sensitive data that needs protecting, we can examine how securely data is stored and how access to the data is controlled and audited.

‍
To determine security objectives, consider following questions:

• What client data do we need to protect? (User account, password, credit card number, bank details, etc)
• Do we have compliance requirements? (Security policy, privacy laws, regulations, etc)
• Do we have specific quality of service requirements? (including availability and performance requirements)
• Are there any intangible assets that we need to protect? (company’s reputation, trade secrets, etc)

Step 2: Decompose the Application

The goal of this step is to gain an understanding of the application and how it interacts with external entities. This 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.
‍

It has the below components:

• Threat Model Information
• Identify Roles
• Identify Key Usage Scenarios
• Identify Technologies
• Identify Application Security Mechanisms
• External dependencies
• Entry points
• Exit points
• Assets
• Trust levels
• Data Flow Diagrams

Threat Model Information

Information identifying the threat model typically includes the the following:

1. Application Name: The name of the application examined.
2. Application Version: The version of the application examined.
3. Description: A high level description of the application.
4. Document Owner: The owner of the threat modeling document.
5. Participants: The participants involved in the threat modeling process for this application.
6. Reviewer: The reviewer(s) of the threat model.

Identify Roles

Identify your applications roles: Identify who can do what within your application. What can your users do? What higher privileged group of users do you have?
‍

Identify what is supposed to happen and what is not.

Identify Key Usage Scenarios

What are the important features of an application? What does it do? Start with the application’s use cases to derive this information. Identify dominant application functionality and usage and capture CRUD aspects.

Identify Technologies

• Operating systems
• Web server software
• Database server software
• Technologies used in the presentation, business and data access layers
• Development languages

It helps identifying technology specific threats and also helps determine the correct mitigation technique.

‍
Identify Application Security Mechanisms

• Input and data validationAuthentication
• Authorization
• Configuration management
• Sensitive data
• Session management
• Cryptography
• Parameter manipulation
• Exception management
• Auditing and logging

External Dependencies

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.

Entry Points

Entry points define the interfaces through which potential attackers can interact with the application or supply it with data. In order for a potential attacker to attack an application, entry points must exist. Entry points in an application can be layered. For example, each web page in a web application may contain multiple entry points.

Exit Points

Exit points prove useful when attacking the client: for example, cross-site-scripting vulnerabilities and information disclosure vulnerabilities both require an exit point for the attack to complete.
In many cases threats enabled by exit points are related to the threats of the corresponding entry point. In the login example, error messages returned to the user via the exit point (the login page) might allow for entry point attacks, such as account harvesting (e.g. username not found), or SQL injection (e.g. SQL exception errors).

Assets

Assets are essentially targets for attackers, i.e. they are the reason threats will exist. Assets can be both physical assets and abstract assets.

Trust Levels

Trust levels represent the access rights that the application will grant to external entities. The trust levels are cross-referenced with the entry points and assets. This allows us to define the access rights or privileges required at each entry point, and those required to interact with each asset.

Data Flow Diagrams

The focus of the DFDs is on how data moves through the application and what happens to the data as it moves. DFDs are hierarchical in structure, so they can be used to decompose the application into subsystems and lower-level subsystems. The high-level DFD will allow us to clarify the scope of the application being modeled. The lower level iterations will allow us to focus on the specific processes involved when processing specific data.

Step 3: Determine and Rank Threats

Threat Categorization

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 is useful in the identification of threats by classifying attacker goals such as:

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

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)
Ranking of Threats

Threats can be ranked from the perspective of risk factors. By determining the risk factor posed by the various identified threats, it is possible to create a prioritized list of threats to support a risk mitigation strategy, such as prioritizing the threats to be mitigated first. Different risk factors can be used to rank threats as High, Medium, or Low risk. In general, threat risk models use different factors to model risks.

Subjective Model: DREAD

In the Microsoft DREAD 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:

• Damage: How big would the damage be if the attack succeeded?
• Reproducibility: How easy is it to reproduce an attack?
• Exploitability: How much time, effort, and expertise is needed to exploit the threat?
• Affected Users: If a threat were exploited, what percentage of users would be affected?
• Discoverability: How easy is it for an attacker to discover this threat?

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:

1. Can an attacker exploit this remotely?
2. Does the attacker need to be authenticated?
3. Can the exploit be automated?

The impact mainly depends on the damage potential and its extent, such as the number of components that may be affected by a threat.

Questions to help determine the damage potential are:

1. Can an attacker completely take over and manipulate the system?
2. Can an attacker gain administrator access to the system?
3. Can an attacker crash the system?
4. Can the attacker obtain access to sensitive information such as secrets or PII?

Questions to help determine the number of components that are affected by a threat:

1. How many connected data sources and systems can be impacted?
2. How many layers into infrastructure components can the threat agent traverse?

These examples help in the calculation of the overall risk values by assigning qualitative values such as High, Medium and Low to the likelihood and impact factors. In this case, using qualitative values, rather than numeric ones like in the case of the DREAD model, help avoid the ranking becoming overly subjective.

Step 4: Determine Countermeasures and Mitigation

The purpose of countermeasure identification is to determine if there is some kind of protective measure (e.g. security control, policies) that can prevent a threat from being realized. Vulnerabilities are then those threats that have no countermeasures.Once threats and corresponding countermeasures are identified, it is possible to derive a threat profile with the following criteria:

• Non mitigated threats: Threats which have no countermeasures and represent vulnerabilities that can be fully exploited and cause an impact.
• Partially mitigated threats: Threats partially mitigated by one or more countermeasures and can only partially be exploited to cause a limited impact.
• Fully mitigated threats: These threats have appropriate countermeasures in place and do not expose vulnerabilities.

Step 5: Create Threat Modeling Report

Creating a report is very undermined but a very important part of any security activity that we carry out, it helps summarize the threat identified in the process, mitigation, affected assets,impact etc to higher management and hence draw attention towards security centric approach.

Conclusion

We've explored the threat modeling process from a high level and from a detailed perspective. By implementing this process you will be able to reduce the overall risk posture of your business. The Harness STO (Security Testing Orchestration) module can also help reduce risk to your business by making application security a policy-driven part of every developers workflow. You can improve the likelihood of hitting your security goals by supporting engineers with the most modern DevSecOps solution.