Threat Modeling: Which Method Should You Choose for Your Company? (Stride, Dread, QTMM, LINDDUN, PASTA)

There are several threat modeling methods. The best model for your organization’s needs will depend on the types of threats you are trying to model and what your goals are. Not all of these methods are complete. Some are abstract, others focus on people, risks or privacy issues.

However, these methods can be combined to create a more robust and comprehensive view of the potential threats facing your IT assets. In this article, we will present an overview of five of these methods.

What is threat modeling?

Threat modeling was initially a technical activity, limited to large-scale developments, in an agile context.

Over the past decade, this activity has developed to the point where it is now part of the controls required for compliance with the 2022 version of the ISO 27002 cybersecurity standard.

This relatively simple activity places security at the beginning of projects, where changes are the least resource-intensive. This is the first brick in the foundation of security by design.

Why is threat modeling important?

The goal is to use a simple analysis to discover the structural points where information security is at risk, in architectures or in systems, such as in applications which are being developed.

For new deployments, this preliminary analysis ensures that there are no obstacles in the implementation of security measures, such as reliance on insecure systems, weak authentication or protocols.

Traditionally, threat modeling has mostly been focused on application development. However, it is also possible to extend the analysis to availability issues, such as scaled deployments (e.g., redundancy), authentication, upgrades and cross-border data transfer issues. An approach for entire systems can easily be modeled on application architectures.

When should you start threat modeling?

According to best practices, the necessary security criteria must be defined in advance in order to validate the design or the architecture.

This analysis is used to check compliance with the generic criteria and to review the technical choices made during this design/architecture phase.

This security operation can therefore be performed during all stages of the project. Nevertheless, it is better if this is done before validating the design or the architecture. In this way, it will be less expensive to make any necessary modifications. It is also possible to do intermediate or partial modeling in order to identify security problems as early as possible and again to reduce design costs.

What resources are needed?

Few human resources are needed, but they can be difficult to find depending on the business environment.

First of all, it is necessary to have at least one person who understands the structure to be analyzed (the software, infrastructure, etc.) and the underlying deployment.

Depending on the method and the tool used, it is necessary/indispensable to have someone who is familiar with cybersecurity attacks and is able to translate them, in a defensive context, into protection measures.

The person in charge of the analyzed component (application, infrastructure, etc.) and usually the person in charge of the evolution of this component (e.g., the SCRUM master) need to integrate the findings into the ongoing evolutions.

The risk manager should attend the meetings to identify the technical risks so that they can be better assessed.

For broader analyses, it is important to have a legal representative who understands the legal requirements in the countries concerned.

In the context of ISO 27001 certifications, the ISMS manager must be aware of and supervise the activity (e.g., planning, reporting, collection of deliverables, monitoring of changes) to ensure that the process meets the standard.

Some existing threat modeling methods

Different methods are possible for defining risks, all of which have their advantages and disadvantages. The method to be used depends on the goals, the maturity of the company and the practices which have already been implemented.

A short description and summary of the most relevant methods is given below.

Threat modeling method no. 1: STRIDE

In the past, the reference methodology was the STRIDE method:

• Spoofing,
• Tampering,
• Repudiation,
• Information disclosure,
• Denial of service,
• Elevation of privilege

The possibilities in each of the categories that make up the acronym must be identified for each of these components. To create an exhaustive list of attack scenarios, it is best to use a knowledge base (see the section below).

These points represent the attack techniques used to breach information security.

This method is widely known and is still applied because it is easy to assimilate. However, Microsoft no longer supports it and now prefers the DREAD method.

Threat modeling method no. 2: DREAD

As previously, the concepts that make up this new acronym:

• Damage potential,
• Reproducibility,
• Exploitability,
• Affected users,
• Discoverability.

Although easier for everyone to understand, the scoring of each of these categories is more subject to interpretation. It is also necessary to take into account the last D (Discoverability), which promotes security through obscurity. However, this practice is strongly discouraged, because it creates a false sense of security.

This method is not easy to implement, because of the following biases:

• D: Represents an impact. No bias there.
• R: This value often remains the same in this initial phase. It does not allow the different threats to be qualified.
• E: Ease of operation. No bias there.
• A: It is difficult to define the importance of each user population in relation to one another. Security must also be considered as a whole, because a vulnerability may only occasionally impact a particular population (with the possible exception of system administrators)
• D: Promotes safety through obscurity, which is a “false friend.”

This analysis therefore focuses primarily on impacts and operability, which are values usually used for risks, but the method offers little help in identifying threats and vulnerabilities.

Threat modeling method no. 3: Quantitative threat modeling

The approach consists in identifying the severity of vulnerabilities based on the CVSS scores. Threats are identified by using attack trees whose root is each of the categories in the STRIDE method (as mentioned above).

However, attack trees can take a lot of time to set up and CVSS scores do not take into account the business environment (and any measures already in place to limit the impact).

This highly technical method should be considered for small, highly critical developments/architecture where vulnerabilities could have strong impacts, regardless of the environment.

Threat modeling method no. 4 : LINDDUN

Once again, an acronym is used for:

• Linkability,
• Identifiability,
• Non-repudiation,
• Detectability,
• Disclosure of information,
• Unawareness,
• Noncompliance

This approach can be useful for identifying discrepancies with the EU 2016/679 GDPR regulation and compliance with the key concepts of “privacy by design” and “privacy by default” defined in this regulation.

However, it is difficult to assess the impact of a vulnerability by using these criteria. This method is intended more for compatibility analysis with respect to privacy regulations than for searching for technical vulnerabilities.

Threat modeling method no. 5: PASTA

This method uses a relatively logical process to combine business objectives and technical risks.

However, this method is not widely used and takes a long time to implement. The result is nevertheless comprehensive and integrates with other business activities (e.g., IT operations and risk assessment).

Source: Shevchenko, N., 2018: Threat Modeling: 12 Available Methods. Carnegie Mellon University’s Software Engineering Institute Blog

Which threat modeling method should you choose for your organization?

The method used depends on both the discovery objectives and the integration of the activity within the project (such as integration with risk analysis with the PASTA method or compliance needs with LINDDUN).

Although outdated, the STRIDE method is easy to understand and yields relevant results. In cases where the threat modeling activity is new, the STRIDE method yields concrete results that ensure the sustainability of this approach in project processes, though possibly in the future, other methods may be used.

In contexts where the activity is already established, a more integrated approach such as PASTA may be recommended, for example, in synergy with the risk management department.

Threat modeling tools

Although these analyses do not require any tools, and a simple sheet of paper would be sufficient, there are tools that can be used to help with some of the methods suggested above. These tools usually provide a clear visual representation and a list of vulnerabilities and associated threats that most people can easily read.

Automated tools

There are many tools available. We can identify two tools that should work with open-source or free tools:

• IsiusRisk platform
• MTMT (“Microsoft Threat Modeling Tool”). Threats can be added to existing threats according to knowledge bases.

Manual tools

Manual approaches, on the other hand, require compliance with a knowledge base and/or people with experience in threat modeling, which sometimes justifies the use of an external service in order to have the people with necessary experience.

The open-source tools are:

• OWASP Threat Dragon
• Manual diagramming (in workshop) / whiteboard approach, if needed, with tools like Microsoft VISIO

Knowledge base of threats and attack scenarios

Possible attacks on each system can be identified by using the MITRE ATT&CK knowledge base (https://attack.mitre.org/matrices/enterprise/).

There are also CAPEC taxonomies (https://capec.mitre.org/data/index.html) and CWE (https://cwe.mitre.org/data/index.html) that are more technical and product-oriented. This can be useful for detailed threat modeling on one or more key systems that do not change often. For most systems, this can be a little too labor-intensive and is not very sustainable.

Nevertheless, it is necessary to choose the desired level of detail in order to limit the time it takes to complete the analysis. This trade-off obviously depends on the resources available and the criticality of the component being analyzed (depending on whether it is the company’s overall infrastructure or a tool for a service, a tool not accessible via the Internet).

Possible inputs

The following documents may be useful for the analysis:

• UML diagrams
• Deployment diagrams
• Workshops with the technical teams (especially for an a posteriori action)
• Data flow diagrams (DFD)
• Attack trees
• Previous lessons learned

Possible deliverables

This activity produces (depending on the method used and the goals of the activity):

• A list of threats
• Deployment diagrams (usable for certifications)
• Additional data flow diagrams
• Threat analysis diagrams
• A threat chart (to be integrated into SCRUMs and other project measures)
• Detailed additions to the risk analysis
• A GDPR compliance analysis

General threat modeling approach used

Threats are identified according to the methodology used in the different paradigms (vulnerability/attack concepts/privacy). Only the PASTA method is more comprehensive, and it is perhaps too comprehensive in many contexts.

Depending on the method used, the impact is primarily on threat detection.

Examples of data flow diagrams

These diagrams identify the boundaries and the flows (which are potentially technical, i.e., with protocols, encryption etc., as in the third diagram).

These diagrams often allow developers and technical business analysts to gain a more synthetic view of their product. This visibility is one of the major advantages of this method.

Source: OWASP Application Threat Modeling

Source: OWASP Application Threat Modeling

Example of a technical deployment diagram

To start a mixed diagram:

Source: Threat Modeling – Secodis GmbH

Source: OWASP Application Threat Modeling

As in the previous diagram, flows can be defined technically, i.e., with protocols, encryption, etc.

Country boundaries can also be included (to identify legal constraints) and regulatory constraints (e.g., PCI-DSS or FINMA in the last diagram, if the country is Switzerland).

How can threat modeling impact your GRC approach?

This activity can be integrated into an GRC approach to support the implementation of security measures, especially for DevSecOps teams, and also to reinforce the risk analysis for the applications and infrastructures on which they are deployed.

This may also be relevant in the case of organizational security improvements, such as defining personal data flow diagrams. These processes are rarely updated and can be improved through this approach.

In particular, PASTA can be used to identify technical risks, but this approach requires a certain structural maturity and a significant willingness to get involved.

These diagrams, which can be read by everyone, can be used to create a common approach between teams.

Finally, this activity is a way to secure the systems architecture which is expected in the 2022 version of the ISO 27002 standard.