How To Create A Threat Model

Almost all software systems today face a variety of threats, and the number of threats grows as technology changes. Malware that exploits software vulnerabilities grew 151 percent in the second quarter of 2018, and cyber-crime damage costs are estimated to reach $6 trillion annually by 2021. Threats can come from outside or within organizations, and they can have devastating consequences. Attacks can disable systems entirely or lead to the leaking of sensitive information, which would diminish consumer trust in the system provider. To prevent threats from taking advantage of system flaws, administrators can use threat-modeling methods to inform defensive measures. In this blog post, I summarize 12 available threat-modeling methods.

Threat-modeling methods are used to create

an abstraction of the system
profiles of potential attackers, including their goals and methods
a catalog of potential threats that may arise

Many threat-modeling methods have been developed. They can be combined to create a more robust and well-rounded view of potential threats. Not all of them are comprehensive; some are abstract and others are people-centric. Some methods focus specifically on risk or privacy concerns.

Threat modeling should be performed early in the development cycle when potential issues can be caught early and remedied, preventing a much costlier fix down the line. Using threat modeling to think about security requirements can lead to proactive architectural decisions that help reduce threats from the start. Threat modeling can be particularly helpful in the area of cyber-physical systems.

Cyber-physical systems integrate software technology into physical infrastructures, such as smart cars, smart cities, or smart grids. While innovative, cyber-physical systems are vulnerable to threats that manufacturers of traditional physical infrastructures may not consider. Performing threat modeling on cyber-physical systems with a variety of stakeholders can help catch threats across a wide spectrum of threat types.

The 12 threat-modeling methods summarized in this post come from a variety of sources and target different parts of the process. No one threat-modeling method is recommended over another; organizations should choose which method to use based on the specific needs of their project. I encourage readers interested in more detailed information about these methods to read our SEI white paper on the same topic.

STRIDE and Associated Derivations

Invented in 1999 and adopted by Microsoft in 2002, STRIDE is currently the most mature threat-modeling method. STRIDE has evolved over time to include new threat-specific tables and the variants STRIDE-per-Element and STRIDE-per-Interaction.

STRIDE evaluates the system detail design. It models the in-place system. By building data-flow diagrams (DFDs), STRIDE is used to identify system entities, events, and the boundaries of the system. STRIDE applies a general set of known threats based on its name, which is a mnemonic, as shown in the following table:

Table 1: STRIDE Threat Categories

STRIDE has been successfully applied to cyber-only and cyber-physical systems. Although Microsoft no longer maintains STRIDE, it is implemented as part of the Microsoft Security Development Lifecycle (SDL) with the Threat Modeling Tool, which is still available. Microsoft also developed a similar method called DREAD, which is also a mnemonic (damage potential, reproducibility, exploitability, affected users, discoverability) with a different approach for assessing threats.

PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat-modeling framework developed in 2012. It contains seven stages, each with multiple activities, which are illustrated in Figure 1 below:

3166_threat-modeling-12-available-methods_1

Figure 1: Adapted from Threat Modeling w/PASTA: Risk Centric Threat Modeling Case Studies

PASTA aims to bring business objectives and technical requirements together. It uses a variety of design and elicitation tools in different stages. This method elevates the threat-modeling process to a strategic level by involving key decision makers and requiring security input from operations, governance, architecture, and development. Widely regarded as a risk-centric framework, PASTA employs an attacker-centric perspective to produce an asset-centric output in the form of threat enumeration and scoring.

LINDDUN

LINDDUN (linkability, identifiability, nonrepudiation, detectability, disclosure of information, unawareness, noncompliance) focuses on privacy concerns and can be used for data security. Consisting of six steps, (see Figure 2), LINDDUN provides a systematic approach to privacy assessment.

Figure 2: LINDDUN Steps

LINDDUN starts with a DFD of the system that defines the system's data flows, data stores, processes, and external entities. By systematically iterating over all model elements and analyzing them from the point of view of threat categories, LINDDUN users identify a threat's applicability to the system and build threat trees.

CVSS

The Common Vulnerability Scoring System (CVSS) captures the principal characteristics of a vulnerability and produces a numerical severity score. CVSS was developed by NIST and is maintained by the Forum of Incident Response and Security Teams (FIRST) with support and contributions from the CVSS Special Interest Group. The CVSS provides users a common and standardized scoring system within different cyber and cyber-physical platforms. A CVSS score can be computed by a calculator that is available online.

As shown in Figure 3, the CVSS consists of three metric groups (Base, Temporal, and Environmental) with a set of metrics in each.

Figure 3: CVSS v3.0 Metric Groups

A CVSS score is derived from values assigned by an analyst for each metric. The metrics are explained extensively in the documentation. The CVSS method is often used in combination with other threat-modeling methods.

Attack Trees

Using attack trees to model threats is one of the oldest and most widely applied techniques on cyber-only systems, cyber-physical systems, and purely physical systems. Attack trees were initially applied as a stand-alone method and has since been combined with other methods and frameworks.

Attack trees are diagrams that depict attacks on a system in tree form. The tree root is the goal for the attack, and the leaves are ways to achieve that goal. Each goal is represented as a separate tree. Thus, the system threat analysis produces a set of attack trees. See examples in Figure 4.

Figure 4: Attack Tree Examples

In the case of a complex system, attack trees can be built for each component instead of for the whole system. Administrators can build attack trees and use them to inform security decisions, to determine whether the systems are vulnerable to an attack, and to evaluate a specific type of attack.

In recent years, this method has often been used in combination with other techniques and within frameworks such as STRIDE, CVSS, and PASTA.

Persona non Grata

Persona non Grata (PnG) focuses on the motivations and skills of human attackers. It characterizes users as archetypes that can misuse the system and forces analysts to view the system from an unintended-use point of view. See examples in Figure 5.

PnG can help visualize threats from the counterpart side, which can be helpful in the early stages of the threat modeling. The idea is to introduce a technical expert to a potential attacker of the system and examine the attacker's skills, motivations, and goals. This analysis helps the expert understand the system's vulnerabilities from the point of view of an attacker.

PnG fits well into the Agile approach, which uses personas.

Figure 5: Examples of Personae non Grata

Security Cards

Security Cards identify unusual and complex attacks. They are not a formal method but, rather, a kind of brainstorming technique. With help from a deck of cards (see an example in Figure 6), analysts can answer questions about an attack, such as

Who might attack?
Why might the system be attacked?
What assets are of interest?
How can these attacks be implemented?"

Figure 6: Security Card Example

This method uses a deck of 42 cards to facilitate threat-discovery activities: Human Impact (9 cards), Adversary's Motivations (13 cards), Adversary Resources (11 cards), and Adversary's Methods (9 cards). The different categories within each dimension are shown in Table 2.

Table 2: Security-Card Dimensions

hTMM

The Hybrid Threat Modeling Method (hTMM) was developed by the SEI in 2018. It consists of a combination of SQUARE (Security Quality Requirements Engineering Method), Security Cards, and PnG activities. The targeted characteristics of the method include no false positives, no overlooked threats, a consistent result regardless of who is doing the threat modeling, and cost effectiveness.

The main steps of the method are

Identify the system to be threat-modeled.
Apply Security Cards based on developer suggestions.
Remove unlikely PnGs (i.e., there are no realistic attack vectors).
Summarize the results using tool support.
Continue with a formal risk-assessment method.

Quantitative Threat Modeling Method

This hybrid method consists of attack trees, STRIDE, and CVSS methods applied in synergy. It aims to address a few pressing issues with threat modeling for cyber-physical systems that had complex interdependences among their components.

The first step of the Quantitative Threat Modeling Method (Quantitative TMM) is to build component attack trees for the five threat categories of STRIDE. This activity shows the dependencies among attack categories and low-level component attributes. After that, the CVSS method is applied and scores are calculated for the components in the tree.

Trike

Trike was created as a security audit framework that uses threat modeling as a technique. It looks at threat modeling from a risk-management and defensive perspective.

As with many other methods, Trike starts with defining a system. The analyst builds a requirement model by enumerating and understanding the system's actors, assets, intended actions, and rules. This step creates an actor-asset-action matrix in which the columns represent assets and the rows represent actors.

Each cell of the matrix is divided into four parts, one for each action of CRUD (creating, reading, updating, and deleting). In these cells, the analyst assigns one of three values: allowed action, disallowed action, or action with rules. A rule tree is attached to each cell.

After defining requirements, a data flow diagram (DFD) is built. Each element is mapped to a selection of actors and assets. Iterating through the DFD, the analyst identifies threats, which fall into one of two categories: elevations of privilege or denials of service. Each discovered threat becomes a root node in an attack tree.

To assess the risk of attacks that may affect assets through CRUD, Trike uses a five-point scale for each action, based on its probability. Actors are rated on five-point scales for the risks they are assumed to present (lower number = higher risk) to the asset. Also, actors are evaluated on a three-dimensional scale (always, sometimes, never) for each action they may perform on each asset.

VAST Modeling

The Visual, Agile, and Simple Threat (VAST) Modeling method is based on ThreatModeler, an automated threat-modeling platform. Its scalability and usability allow it to be adopted in large organizations throughout the entire infrastructure to produce actionable and reliable results for different stakeholders.

Recognizing differences in operations and concerns among development and infrastructure teams, VAST requires creating two types of models: application threat models and operational threat models. Application threat models use process-flow diagrams, representing the architectural point of view. Operational threat models are created from an attacker point of view based on DFDs. This approach allows for the integration of VAST into the organization's development and DevOps lifecycles.

OCTAVE

The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) method is a risk-based strategic assessment and planning method for cybersecurity. It was created by the CERT Division of the SEI in 2003 and refined in 2005. OCTAVE focuses on assessing organizational risks and does not address technological risks. Its main aspects are operational risk, security practices, and technology.

As shown in Figure 7, OCTAVE has three phases.

Build asset-based threat profiles. (This is an organizational evaluation.)
Identify infrastructure vulnerability. (This is an evaluation of the information infrastructure.)
Develop a security strategy and plans. (This is an identification of risks to the organization's critical assets and decision making.)

Figure 7: OCTAVE Phases

Wrapping Up and Looking Ahead

Threat modeling can help make your product more secure and trustworthy. This post presented 12 threat-modeling methods. Some are typically used alone, some are usually used in conjunction with others, and some are examples of how different methods can be combined. A future SEI blog post will provide guidance on how to evaluate these models for use in specific contexts.

To choose what method is best for your project, you need to think about any specific areas you want to target (risk, security, privacy), how long you have to perform threat modeling, how much experience you have with threat modeling, how involved stakeholders want to be, etc. Table 3 summarizes features of each threat modeling method. These methods can all be used within an Agile environment, depending on the timeframe of the sprint and how often the modeling is repeated.

Table 3: Features of Threat-Modeling Methods

Additional Resources

Read the SEI White Paper, Threat Modeling: A Summary of Available Methods, on which this post is based.

Read the SEI Technical Note, A Hybrid Threat Modeling Method by Nancy Mead and colleagues.

Read Evaluation of Threat Modeling Methodologies by Forrest Shull.

Read the SEI blog post The Hybrid Threat Modeling Method by Nancy Mead and Forrest Shull.

Browse SEI OCTAVE-related information.

Read an SEI Technical Report about Security Quality Requirements Engineering (SQUARE).