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 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:
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.
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.
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
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
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:
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.
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.
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.
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:
- Eliminates the repetitive portion of threat modeling
- Provides ongoing threat modeling
- Is scaled to encompass the entire enterprise
- Integrates with tools throughout the SDLC
- Supports agile DevOps
- 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 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
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.
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.
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.
Threat Modeling FAQs
- 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:
- 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
- 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
- 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)
- What are we working on?
- What could go wrong?
- What are we going to do about it?
- Average ranking, or (D+R+E+A+DI)/5, which averages:
- Affected users
- Probability x Impact (PxI) ranking:
- P = (R+E+DI)
- I = (D+A)
- This technique is a method of group decision-making and forecasting that involves successively collating the judgments of experts (security experts, in this case).