Threat Modeling 101: Getting started with application security threat modeling [2021 update]

In today’s world application security has a very important role in network security. Every day, hackers are using new technologies and techniques to access important data and do other malicious activities. 

Therefore, it is very important to secure applications and their related important data. Unfortunately, for many, their approach to application security has proven to be disastrous: many vulnerabilities have gone undetected and applications have been attacked and damaged. This is why network and application security is very important in today’s world. 

However, one method that can assist organizations with implementing application and network security in the design process is threat modeling. 

Threat modeling is a process for optimizing network security by describing objectives and vulnerabilities, which are used to identify the motivations and methods that an attacker would use to exploit a vulnerability or threaten a system. 

The basic objective is to determine where the most effort should be applied to keep a system secure, using a security profile that prioritizes each application.

Learn Threat Modeling

Get hands-on experience with six threat modeling courses covering defense-in-depth, frameworks like STRIDE and Rapid Threat Model Prototyping (RTMP), agile architecture and more.

Start Learning

Key concepts of threat modeling

Threat modeling includes three main parts:

• Assets: a hacker’s main goal is to access a company's assets. Assets can be physical or data-based and, if exploited, can affect things like employee safety or a company’s reputation. Therefore, the security team needs to find which assets need to be protected from unknown users.
• Threats: this is the identification of the groups or persons who may be able to attack your application, including insiders and outsiders. This can also speak to their motivation or goals in attacking your system.
• Vulnerabilities: these are the potential pathways that an attacker can use to gain access to or exploit your system.

Threat model overview

Before you can create a threat model, your organization first needs to inventory all of your assets and prioritize them by their importance to your operations and their risks, if exploited. Assets can be systems, databases, datasets, software and hardware. 

Then, for each asset, in priority order, perform the five major steps in creating a threat model, which is summarized in the figure below:

The five threat modeling steps are:

• Step 1: identify security objectives. Clear objectives help you to see the threat modeling activity and define how much effort to spend on subsequent steps.
• Step 2: create an application overview. Listing the application’s main characteristics, users, inputs and outputs help to identify relevant threats during step 4.
• Step 3: decompose your application. The detailing of the mechanics of your application helps you to identify more relevant and detailed threats.
• Step 4: identify threats. Use the results of steps 2 and 3 to find threats relevant to your application design and use case.
• Step 5: identify vulnerabilities. Use vulnerability categories to find those areas where weaknesses are most likely to be exploited.

Given the evolving threat, you should continuously refine your threat model by regularly performing steps two through five.

Identify trust levels

In addition to following the above steps, defining trust levels allows us to define the access rights or privileges systems or users may have with an asset. For example, a change in access control levels in your application where a specific role or privilege level is required to access a resource or operation would be a change in trust level.

How to identify threats

With so many different vectors and touchpoints, it can be hard to know where to start with identifying potential threats to an asset. 

To facilitate the process, it can help to form a cross-functional team, including members of the development and test team, application architects, security professionals, users and system administrators.

Threat identification models

This group can then follow a structured approach to identify potential threats. Although several exist, Microsoft offers two of its own methods to identify threats.

Microsoft threat models

One example, provided by Microsoft, suggests breaking down potential threats into a threat graph, as shown in the example in the following figure:

Another approach suggested by Microsoft is to create a structured list of who may try to attack an asset. The potential actors are summarized into the following categories:

• Accidental discovery: done by regular users who make a functional mistake in your application and gain access to privileged information or functionality.
• Automated malware: programs or scripts searching for known vulnerabilities that report them back to a central collection site.
• The curious attacker: security researchers or regular users who notice something wrong with an application and decide to explore further.
• The motivated attacker: an attacker seeking financial or other gains from the attack.
• Organized crime: criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

The role of security controls in mitigating threats

Another way to identify and mitigate software threats is by performing a code and configuration review to confirm that the necessary security controls are in place, that they work properly and that they are correctly invoked in all the necessary places. 

To assist with that process, the following checklist can provide a structured approach to perform the software analysis and ensure that all the likely risks have been considered. The result is a security profile for each application as well as a set of action items to be prioritized for remediation or risks accepted by the organization. 

Category Considerations

Input validation Is all input data validated?

• Ensures that a malicious user cannot inject commands or malicious data into the application, such as HTTP headers, input fields, hidden fields, drop-down lists and other web components.
• The proper length checks on all input exist.
• Data is validated on the server side.
• Only well-formed data hits the database.
• That the validation method itself is secure.

Authentication Are all credentials secured as they are passed over the network?

• Are strong password policies used?
• Are strong passwords enforced?
• Are certificates used?

Authorization Are all authorization mechanisms in place and working properly?

• What log-in prompts are used at the entry points of the application?
• Are authorizations checked on every request or session?

Cookie management Is sensitive session information protected?

• Is the proper encryption in use?
• Is session data being validated?
• What cookies are being used by the application and why?

Sensitive data What sensitive data is handled by the application?

• What type of encryption is used?
• How is the data being used?
• How are encryption keys secured?

Session management How is the session generated?  

• How does the application track sessions?
• How are persistent session states secured as they cross the network?
• Does session inactivity timeout?
• How is multithreaded/multi-user session management performed?
• How does the logout functionality function?

Cryptography Are the proper algorithms and cryptographic techniques used?

• Does the application use encryption properly?
• How often are keys recycled?
• Is any sensitive data transferred internally or externally after encryption?

Secure code environment Are the proper memory allocations occurring?

• Examine the file structure.
• Examine any components that should not be directly accessible to the user.
• Ensure that no development information is contained in the production directories.

Exception management How does the application handle error conditions?

• Ensure that exceptions and error conditions are properly working.
• Ensure resources are released if an error occurs
• Ensure no system errors can be returned to the user.
• Ensure that the application fails securely.

Auditing and logging Is necessary application audit activity across your enterprise?

• How are log files secured?
• What information is logged in the event of an error?
• Are both successful and unsuccessful authentication attempts logged?

How to prioritize and evaluate identified threats

All organizations have limits on the number of resources they can apply toward mitigating the threats that they have identified. Therefore, it is important to develop a method to consistently and comprehensively prioritize those risks so those with the biggest potential impact or risk can be addressed first. 

One simple prioritization method is to develop a risk scoring mechanism that represents the probability of the threat be realized and the damage potential:

Risk = probability * damage potential

However, there are other methods to analyze, understand and rank threats. Some of the more common methods include the DREAD system, threat trees, attack patterns and data flow diagrams. These methodologies or threat analysis tools can be used together to provide a more comprehensive understanding of a threat and its potential impact.

The DREAD system

DREAD is a classification scheme for determining and comparing the amount of risk related to each identified threat. In using the DREAD model, a threat modeling team can quantify, or calculate, a numeric value for the security risk provided by each threat. 

DREAD stands for:

Risk Score = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY)

The calculation produces a number between zero to 10, with the higher the number, the higher the risk.

The DREAD components

Each letter of DREAD represents a factor that can be used to evaluate the overall risk a threat presents. Users can rate each factor from zero (minimal to no risk) through to 10 (total compromise or destruction).

• Damage potential: the damage caused when the threat exploits
• Reproducibility: how easily the threat can be exploited
• Exploitability: the frequency or size of the vector related to the threat
• Affected users: how wide the impact of the threat would be felt if realized
• Discoverability: how easy it is to discover the threat

Sample DREAD rating for two different threats could look be represented in the following table:

Threat The attacker obtains authentication credentials by monitoring the network. SQL commands injected into an application.

D 3 3

R 3 3

E 2 3

A 2 3

D 2 2

Total 12 14

Rating High High

The STRIDE threat model

Another popular categorization framework is STRIDE, which is an acronym that outlines six common types of threats and the security controls which are responsible for protecting against them. This is a goal-based approach where you consider the goals of an attacker. 

The letters in STRIDE represent potential attack vectors and include:

• Spoofing identity: a threat action aimed at accesses and using another user’s password and username. 
• Tampering with data: a threat action aimed at changing and modifying data within the system to achieve malicious goals. 

• Repudiation: a threat action aimed at doing an illegal operation in a system. 
• Information disclosure: a threat action aimed to expose the protected data not typically accessible to a user.
• Denial of service: a threat aimed to make a web-based service unavailable or unusable. 
• Elevation of privilege: a threat aimed at gaining unauthorized access to information or to gain privileged access to resources and to compromise a system 

The Trike threat modeling methodology

Trike is another open-source threat modeling methodology. The model was launched in 2006 as an attempt to improve the efficiency and effectiveness of existing threat modeling methodologies. 

Trike is a threat framework similar to Microsoft’s threat modeling processes, using a risk-based approach to categorizing threats. According to the governing body behind the model, the Trike methodology is “requirements-based,” helping to ensure that the assigned level of risk for each asset is “acceptable” to the various stakeholders.

Using the risk model, threats are then enumerated using a data flow diagram (which is explored later in this piece) while associated outcomes and probabilities are prioritized according to the predetermined risk acceptance framework. 

Data flow diagrams

Data Flow Diagrams (DFD) help teams to have a better understanding of the application by generating a visual representation of how an application and its data are structured. In other words, DFDs help to focus teams on the data that is moving through the application and what happens to the data as it moves.

There are six basic shapes used in creating DFDs.

External entity

The external entity shape is used to show where a system interacts with another through an entry or exit point.

Process

The process shape represents a system or user action handled within the application. The task may process the data or perform an action based on data.

Multiple processes

Represents a summary of multiple sub-processes.

Data store

Where application data is stored. This symbol may only interact with multiple processes.

Data flow

The movement of the data in the application, where an arrow shows the direction of the data movement.

Trust or privilege boundary

The boundary between a trust level or privilege as data flows through the application.

The combined data flow diagram

Using these six components, a sample data flow diagram could look like the following:

The OCTAVE threat assessment model

The Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE) model is a security framework for identifying, addressing and managing information security assessments and risk-based planning. 

OCTAVE works for managing overall organizational risk and includes two versions: Full OCTAVE and OCTAVE-S for small organizations. 

Building an asset-based threat profile

This identifies critical assets and the security requirements for each of them. A threat profile for all identified assets is created.

Identifying infrastructure vulnerabilities

This identifies network access paths, critical assets, technology components and the area to which those components are secured against network vulnerabilities and attacks. 

Develop a security strategy and plan

Based on the data collected in previous phases, a plan is created to address the risks associated with the assets.

Once in use, OCTAVE can help organizations to regularly:

• Measure and document business risks efficiently
• Document and measure the overall IT risk
• Comprehensively document risks to a specific application

However, the OCTAVE methodology does have some limitations:

• It assumes a threat will always occur, which can be harder for many organizations to handle or balance
• OCTAVE is large and complex, with many worksheets and practices to implement
• It does not have users deeply inspect each risk, an important stage to help reduce the overall risk

The AS/NZS 4360:2004 approach to risk management

The Australian/New Zealand Standard AS/NZS 4360 risk management model was first published in 1999 and revised in 2004 as AS/NZS 4360:2004. 

This model is one of the most popular methods for documenting and managing risk as it lets the organization customize its approach to best fit the needs of an organization.

The five steps of the AS/NZS 4360 process are:

• Establish context: establish the risk domain, which means identifying which systems or assets are important.
• Identify the risks: identify the relevant risks 
• Evaluate the risks: describe the risk and all its relevant parts
• Analyze the risks: identify the risks and identify any supporting controls in place
• Treat the risks: determine the method to treat or mitigate the risks

A visual depiction of the model is below:

Once in use, the AS/NZS 4360 model has several key advantages:

• Risk management methodology for organizations requiring Sarbanes-Oxley compliance
• Method to manage risks in a standard way
• Well tested and widely applied model to manage risk, which means there are a lot of preexisting tools and supporting documentation

However, there are some limitations to the AS/NZS 4360 approach:

• The AS/NZS 4360 approach works best for business or systemic risks, but not well for the practice of just managing specific technical risks.
• The AS/NZS 4360 does not provide the methodology to perform a structured threat risk modeling exercise.
• The AS/NZS 4360 does not provide a structured method to calculate web application security risks. 

The AS/NZS ISO 31000:2009 risk management model

The adaptation of the Australia/New Zealand model with ISO 31000:2009 superseded AS/NZS 4360:2004 and can be used by any public, private or community enterprise, association, group or individual. Therefore, ISO 31000:2009 provides a flexible approach to risk management, offering an industry-agnostic model.

Comparing AS/NZS ISO 31000:2009 with AS/NZS 4360:2004

The 2009 model has the following enhancements to the 2004 model:

• Expands the framework for risk management 
• Provides more clear and explicit methods to manage risk
• Increases the risk management attributes
• Provides a guide to help organizations start implementing effective risk management process
• Applies to all industries: public, private or community enterprise, association, group or individual

The threat trees modeling approach

Building a threat tree is another well-known method to identify possible vulnerable areas in a system. Threat trees work by helping organizations to determine valid attack paths in a system that an attacker can use to shut the system.

There are two ways to create threat trees: the first is graphically and the second one is text. In both, a threat tree is composed of a root node, which represents a threat, and a child node(s), which represents the condition needed for the threat to occur. By creating attack trees, an organization can create a useful representation of security issues that helps to focus and prioritize their efforts. 

The following is an example representation of a threat tree, which uses root nodes and leaf nodes to map a unique attack. 

Using attack patterns to model threats

An attack pattern is another way to logically represent the goal an attacker may have for exploiting a system and the path or techniques that they may use. It also represents or defines the conditions that must exist for the attack to occur.

An example attack pattern for a code injection attack may look like the following:

• Attack goals: code performance or command
• Required condition(s): weak input validation code on the server
• Attack technique(s):

1. Identity program with a correct input vulnerability
2. Create code using the security context of the target application
3. Construct input value to insert code into the address space
4. Force a stack corruption that causes application execution to jump to the injected code.

• Attack result: An attacker performs a malicious action using their code injection

Threat modeling and the software development lifecycle

Up until this point, we have just been exploring threat modeling in applications already implemented. However, it is just as important to take the time to perform threat modeling during the software development lifecycle, where flaws and issues can be addressed early on in the design process. 

Even the Microsoft Software Development Lifecycle and Agile development processes provide this guidance and include design review into their methodologies. For example, threat identification can be woven into the “bite-size chunks” across various iterations or sprints in Agile software development as well as into the testing phases of the waterfall development methodology.

The Common Vulnerability Scoring System

The NIAC Vulnerability Disclosure Working Group, which was established by the U.S. Department of Homeland Security (DHS) and included input from Cisco, Microsoft, Symantec, ISS, Qualys, CERT/CC and eBay, created the Common Vulnerability Scoring System (CVSS).

This scoring system provides security professionals a consistent, comprehensive, and accurate means to address vulnerabilities:

• Threat notifications from members along with proper mitigations
• A trustworthy severity rating so the appropriate level of action required can be taken
• A reliable ranking system to so risks are properly categorized

However, it is important to remember that there are some limitations to the CVSS:

• The CVSS is just a scoring system, not a threat modeling methodology
• The risk scoring system is more complex than STRIDE or DREAD, requiring a spreadsheet to calculate the risk components and properly prioritize them.

Learn Threat Modeling

Get hands-on experience with six threat modeling courses covering defense-in-depth, frameworks like STRIDE and Rapid Threat Model Prototyping (RTMP), agile architecture and more.

Start Learning

Diving into threat modeling

The purpose of this article was to provide a broad overview of the key steps involved in identifying assets and threats and assigning an appropriate severity level to them for mitigation. Although some of the main methodologies and tools that can support that process were also explored, it is important to remember that the practice of threat modeling is a living process that organizations should regularly perform to attempt to stay ahead of potential cyberthreats. 

 

Original article by Jatin Jain

Partially re-written in 2021 by Patrick Mallory