What Is Threat Modeling?

Threat modeling is a process for thinking through, identifying, and documenting known threats and mitigations to a system before that system is deployed. Threat modeling acknowledges that all systems face various threats before, during, and after deployment, and it helps security experts identify and mitigate those threats before they occur.

Threat Modeling and Security

Threat modeling optimizes application security by:

  • Identifying objectives
  • Modeling the architecture
  • Identifying threats
  • Defining controls to prevent or mitigate the effects of threats to the system
  • Maintaining a risk register for threats that are not prevented or mitigated
  • Validating that implemented controls were effective
Threat modeling

Threat modeling is a proactive process for addressing system threats

Why Use Threat Modeling?

Threat modeling helps us make informed decisions about security postures and risk of cyberattacks. While it is possible to run multiple security scanning tools and separate third-party penetration testing engagements on a system, these occur late in the software development lifecycle, at which time the cost of mitigating threats is much higher.

Benefits of Threat Modeling

The benefits of threat modeling for an application can be summarized as follows:

Reduced cost

Threat modeling happens during the design phase, which allows threats to be addressed early in the software development lifecycle and lowers the cost of mitigation.

Better security

Documenting an application’s security architecture and creating a threat model are key steps in ensuring that an application maintains its security assurances and can defend itself against external threats.

Acceptable risk levels

A threat model allows us to take a structured approach to evaluating the security level of an application, prioritize risks, and implement risk-mitigating controls in an effort to reach a state of security assurance that falls within an acceptable risk level.

Threat Modeling Approaches

The process of threat modeling is simple, but it needs to be approached with discipline and care. Since the attack surface of any given system changes as technology changes, and since new threats are constantly emerging, we must understand and acknowledge what we know vs. what we don’t or can’t know about any modern system.

In general, there are three basic approaches to threat modeling: software centric, attacker centric, and asset centric.

Software-Centric Approach

A risk mitigation focusing on software:

  • Evaluates the application being modeled
  • Determines the risk
  • Identifies controls to mitigate
  • Requires a good understand of the application and the system it is running on

Attacker-Centric Approach

An approach that highlights the attacker:

  • Puts the user into the mindset of an attacker
  • Determines what is most at risk
  • Needs to understand the concept of hacking
  • Must have the skill set of a hacker

Asset-Centric Approach

Focusing on assets, this approach:

  • Identifies assets to be protected
  • Classifies assets based on data sensitivity and value potential
  • Determines an “acceptable risk” level
  • Takes a cyber risk–management perspective in satisfying the security auditing process

Threat Modeling Methodologies

In general, threat modeling methodologies establish a catalog of potential threats that are relevant to adversary tactics and techniques as well as attack frameworks. When possible, technology specifics are abstracted away. Resolution or mitigation of identified threats with appropriate security controls establish the security posture of the system. Many different methodologies can be used, including:

STRIDE

This type of threat model, developed at Microsoft, is software centric (developer focused) and uses the pneumonic STRIDE to categorize threats as follows:

Threat Category Property Violated Threat Description
Spoofing Authentication Illegal access and then use of another user’s authentication information, such as username and password
Tampering Integrity The malicious modification of data
Repudiation Accountability (Audit) Associated with users who deny performing an action without other parties having any way to prove otherwise
Information Disclosure Confidentiality Exposure of information to individuals who are not authorized to access it
Denial of Service (DoS) Availability Attacks that deny service to valid users
Elevation of Privileges Authorization Privileged access gained by an unprivileged user, who then has sufficient access to compromise or destroy the entire system

In the STRIDE methodology, data flow diagrams of the application’s use cases are created by decomposing them to identify system entities, events, and boundaries. Threat categories are then used to apply a general set of known threats to the system and assess the system for mitigations to these threats.

data-flow diagram

Sample data-flow diagram

The seven stages of PASTA

The seven stages of PASTA

PASTA

Process for Attack Simulation and Threat Analysis (PASTA) is a risk-based methodology to threat modeling that takes an attacker-centric approach in identifying threats to an application. This methodology follows the seven-stage process shown in the diagram at left.

As PASTA follows an attacker-centric approach, it uses “attack trees” to depict potential attacks on a system in a tree-form diagram. The tree root symbolizes the goal of the attack, and the leaves show ways to achieve that goal. In order to leverage a threat modeling methodology that uses attack trees, one must be familiar with an attacker mindset and capabilities.

Trike

The Trike methodology, which is an open source project that uses threat models as risk-management tools, was originally created to improve the efficiency and effectiveness of existing threat modeling methodologies. It was first implemented as a tool in the programming language Smalltalk and is now implemented through spreadsheets.

Trike stages

Trike stages

VAST

Visual, Agile, Simple Threat Modeling (VAST) is a threat modeling methodology developed by the creators of the ThreatModeler product. Its purpose is to address the enterprise scalability gap by integrating into the full software development lifecycle (SDLC). VAST incorporates three pillars to support a scalable threat modeling solution:

AUTOMATION
  • Eliminates the repetitive portion of threat modeling
  • Provides ongoing threat modeling
  • Is scaled to encompass the entire enterprise
INTEGRATION
  • Integrates with tools throughout the SDLC
  • Supports agile DevOps
COLLABORATION
  • Collaborates with key stakeholders:
    • App developers
    • Systems architect
    • Security team
    • Senior executives

It is important to note here that VAST was developed to define the way that the automated tool ThreatModeler enables enterprises to threat model at scale. Therefore, full details of the stages of this methodology are not relevant here.

Security Cards

Security Cards is a threat modeling methodology developed by the Security and Privacy Research Lab (CSE) and the Value Sensitive Design Research Lab (iSchool) at the University of Washington, Seattle. Its purpose is to facilitate exploration of potential security threats for a particular system; more broadly, it aims to develop a security mindset. It is based on brainstorming and creative thinking rather than a structured modeling approach.

The Security Cards toolkit provides a deck of 42 cards grouped across four dimensions (or suits):

  • Human impact
  • Adversary’s motivations
  • Adversary’s resources
  • Adversary’s methods

Each card contains:

  • Card topic
  • Card dimension
  • Questions to clarify and jump-start thinking
  • Illustrative examples
Example security card

Example security card

Threat Modeling Best Practices

It is best practice to recognize that you will never be able to completely mitigate all threats to an application. In some cases, there will be threats that you won’t be able to identify. Techniques developed in the future will add threats to your application that don’t exist now.

The creation of threat models can be guided by a security expert, but the task is not only for security experts or security teams. A comprehensive understanding of the architecture of the system, design decisions, implementation, and engineering decisions is important and necessary to create a complete threat model. This usually means bringing in experts from across the team to help create a complete picture of the system so that all threats, vulnerabilities, and mitigations can be identified.

Timing

Threat modeling is too often done toward the end of a development phase, immediately before deployment. This is too late. Threat modeling can and should begin as early as possible in the design of the system and continue throughout design and development. Identifying threats early can help avoid security-problematic design decisions and give development teams time to change the design to a more secure system posture.

How Can Wind River Help?

Wind River Simics

Modern tools can test system environments, ensure that they are properly secured, and provide your team with the confidence to work intelligently during the day and sleep peacefully at night.

Wind River® Simics® is a fast, full-system simulation platform that uses scripts to define, link, and execute virtual prototypes. Attacks can be launched automatically by reusing publicly available or in-house proof of vulnerability (PoV) in Python. In addition, simulation can be played back at any time for detailed source code–level analysis with determinism, which provides invaluable insights for threat modeling and documentation.

» Learn more

Wind River can help identify and mitigate system threats

Wind River Professional Services and products can help identify and mitigate system threats

Wind River Professional Services

Wind River Professional Services is a team of experts ready to assist you with threat modeling training or to conduct a threat model of your application, identifying threats and mitigations on your behalf.

» Learn more

Threat Modeling FAQs

Threat modeling is a structured approach to analyzing the security posture of an application, identifying threats, defining mitigating controls, and then documenting and validating the mitigation.
The stages vary, based on the methodology used:
  • STRIDE: Stages are defined by the organization but can be generalized as follows:
    • Identify security requirements
    • Decompose the application
    • Create a diagram that describes how the data flows through the application
    • Identify threats and their mitigations
    • Validate mitigations
    • Document mitigated and accepted threats
  • PASTA: Follows an attacker-centric approach to:
    • Define the business context of the application
    • Enumerate the technology
    • Decompose the application
    • Analyze the threat
    • Identify weaknesses and vulnerabilities
    • Simulate attack
    • Analyze residual risk
  • Trike: Currently uses spreadsheets to:
    • Define a system to develop a requirement model
    • Assess risk using CRUD:
      • Creating
      • Reading
      • Updating
      • Deleting
    • Compose a data flow diagram (DFD)
    • Assign risk values
  • VAST: Does not define stages but rather is integrated into the entire software development lifecycle (SDLC)
  • Security Cards: Uses an unstructured approach and therefore does not define the stages of its methodology
The Microsoft Threat Modeling Tool (MSTMT) allows software architects to identify and mitigate potential security issues early, when they are relatively easy and cost-effective to resolve. As a result, it greatly reduces the total cost of development. It was designed for use by those who are not security experts, making threat modeling easier for all developers by providing clear guidance on creating and analyzing threat models. The tool enables anyone to:
  • Communicate about the security design of a system
  • Analyze that design for potential security issues using a proven methodology
  • Suggest and manage mitigations for security issues
Regardless of what is being threat modeled, the objective is always to address four questions:
  • What are we working on?
  • What could go wrong?
  • What are we going to do about it?
  • Did we do a good enough job?
  • Microsoft Threat Modeling Tool (open source)
  • OWASP Threat Dragon (open source)
  • ThreatModeler (commercial)
  • CAIRIS (open source)
  • IriusRisk (commercial)
  • securiCAD (open source, commercial)
  • Threagile (open source)
Assets are items that are valuable to an organization, whose loss could potentially disrupt the organization’s ability to accomplish its mission.
  • What are we working on?
  • What could go wrong?
  • What are we going to do about it?
PASTA, or Process for Attack Simulation and Threat Analysis, is a risk-based methodology to threat modeling. It follows a seven-stage process that uses “attack trees” to depict potential attacks on a system in a tree-form diagram. It requires its users to understand an attacker mindset and capabilities.
Once threats have been identified against an application, you will prioritize mitigation by applying a risk assessment technique to each threat. Check with your risk-management organization to determine whether your company has a defined risk assessment technique you should follow. Three commonly used techniques are:
  • Average ranking, or (D+R+E+A+DI)/5, which averages:
    • Damage
    • Reproducibility
    • Exploitability
    • Affected users
    • Discoverability
  • Probability x Impact (PxI) ranking:
    • P = (R+E+DI)
    • I = (D+A)
  • Delphi
    • This technique is a method of group decision-making and forecasting that involves successively collating the judgments of experts (security experts, in this case).
The most effective and efficient time to perform threat modeling is in the design phase of the software development lifecycle. The more you shift right in the lifecycle, the more expensive it becomes to implement mitigations for the threats that are identified.
A diagram of the system components, with any external components that they interact with, shows how the data flows through the system. In essence, the diagram should answer the questions:
  • What are we working on?
  • What could go wrong?
  • What are we going to do about it?
  • Did we do a good enough job?