What is Threat Modeling?

Threat modeling is a structured process through which IT pros can identify potential security threats and vulnerabilities, quantify the seriousness of each, and prioritize techniques to mitigate attack and protect IT resources.

This broad definition may just sound like the job description of a cybersecurity professional, but the important thing about a threat model is that it is systematic and structured. Threat modelers walk through a series of concrete steps in order to fully understand the environment they’re trying to secure and identify vulnerabilities and potential attackers.

That said, threat modeling is still in some ways an art as much as a science, and there is no single canonical threat modeling process. The practice of threat modeling draws from various earlier security practices, most notably the idea of “attack trees” that were developed in the 1990s. In 1999, Microsoft employees Loren Kohnfelder and Praerit Garg circulated a document within the company called “The Threats to Our Products” that is considered by many to be the first definitive description of threat modeling.

Kohnfelder and Garg called their proposal “the STRIDE framework,” and we’ll look at the details of it later in this article. But it’s important to know that there are a wide variety of threat modeling frameworks and methodologies out there. Some models have different emphases, while others are specific to certain IT disciplines — some are focused specifically on application security, for instance. In this article, we’ll help you understand what all these methodologies have in common, and which specific techniques may be right for you.

Threat modeling process and steps:

Each individual threat modeling methodology consists of a somewhat different series of steps, and we’ll discuss the nuances of each later in this article. But to start, we’ll look at the basic logical flow that all these methods have in common.  One of the most succinct and straightforward outlines of the threat modeling process comes from software engineer Goran Aviani. As he puts it, the purpose of a threat model is to answer four questions:

1. 1.What are we working on?
2. 2.What can go wrong?
3. 3.What are we doing to do about it?
4. 4.Did we do a good job?

The threat modeling process should, in turn, involve four broad steps, each of which will produce an answer to one of those questions.

1. 1.Decompose the application or infrastructure
2. 2.Determine the threats
3. 3.Determine countermeasures and mitigations
4. 4.Rank the threats

To understand exactly what goes into each of these steps, we need to talk about the specific techniques that underlie threat modeling.

Threat modeling techniques :

Perhaps the most unfamiliar term in the steps listed above is decompose. What does it mean to decompose an application or infrastructure? Software engineer Andrea Della Corte says that, broadly defined, decomposing an application consists of “gaining an understanding of the application and how it interacts with external entities. This involves creating use-cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets (i.e., items/areas that the attacker would be interested in), and identifying trust levels which represent the access rights that the application will grant to external entities.” (He’s specifically talking about application security here, but clearly this can in a broad sense apply to a view into infrastructure as well.)

One of the techniques for decomposing an application is building a data flow diagram. These were developed in the 1970s as a way to visually represent how data moves around an application or system and where that data is altered or stored by various components; the concept of a trust boundary, illustrating a point in the data flow where the data needs to be validated before it can be used by the entity receiving it, was added in the early 2000s, and this idea is key to using a data flow diagram for threat modeling.

Threat modeling frameworks and methodologies :

The varying structured approaches for threat modeling are usually called frameworks or methodologies (the two terms can basically be used interchangeably in this context). There are plenty of them out there, but we’ll recap the most popular.

7 top threat modeling methodologies :

1. 1.STRIDE
2. 2.DREAD
3. 3.PASTA
4. 4.VAST
5. 5.Trike
6. 6.OCTAVE
7. 7.NIST

STRIDE threat modeling :

As we noted above, STRIDE is the granddaddy of threat modeling, first developed at Microsoft in the late ’90s. STRIDE stands for the six categories of threat, each of which violates a specific property from variations of the CIA triad:

Get Experts Curated Cyber Security Training From Real-Time Experts

• Instructor-led Sessions
• Real-life Case Studies
• Assignments

Explore Curriculum

• Spoofing, or impersonating another person or computer, which violates authenticity
• Tampering with data, which violates integrity
• Repudiation, or making it impossible to link an action you performed to you, which violates non-repudiability
• Information disclosure, which violates confidentiality
• Denial of service, which violates availability
• Elevation of privilege, which violates authorization

DREAD was conceived of as an add-on to the STRIDE model that allows modelers to rank threats once they’ve been identified. DREAD stands for six questions you would ask about each potential threat:

• Damage potential: How great is the damage if the vulnerability is exploited?
• Reproducibility: How easy is it to reproduce the attack?
• Exploitability: How easy is it to launch an attack?
• Affected users: As a rough percentage, how many users are affected?
• Discoverability: How easy is it to find the vulnerability?

Each of these questions is answered with a rating between one and three.

PASTA threat modeling :

PASTA, which stands for Process for Attack Simulation and Threat Analysis, is a seven-step process focused on aligning technical security requirements with business objectives. Each step is fairly complex, consisting of several substeps, but the overall sequence is as follows:

1. 1.Define objectives
2. 2.Define technical scope
3. 3.Application decomposition
4. 4.Threat analysis
5. 5.Vulnerability and weaknesses analysis
6. 6.Attack modeling
7. 7.Risk and impact analysis

VAST threat modeling :

VAST stands for Visual, Agile Threat Modeling. This model underlies ThreatModeler, an automated threat modeling platform that distinguishes between application and operational threat models. VAST is designed specifically to integrate into workflows built around the devops philosophy. 

Trike threat modeling :

Trike is a framework and accompanying open source tool for threat modeling and risk assessment, which operates from a defensive viewpoint rather than trying to emulate the thought process of an attacker. With Trike, you model the system you are trying to defend, assessing every component through the viewpoint of CRUD — that is, who has the capabilities to create, read, update, or delete that entity. Threats are identified by iterating through a data flow diagram, with each threat falling into only two categories: denial of service or elevation of privilege.

OCTAVE threat modeling :

OCTAVE, which stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation, is a threat modeling methodology developed at Carnegie Mellon University that focuses on organizational rather than technological risks. It consists of three phases:

1. 1.Build asset-based threat profiles
2. 2.Identify infrastructure vulnerability
3. 3.Develop a security strategy and plans

NIST threat modeling :

The U.S. National Institute of Standards and Technology has its own data-centric threat modeling methodology, which consists of four steps:

1. 1.Identify and characterize the system and data of interest
2. 2.Identify and select the attack vectors to be included in the model
3. 3.Characterize the security controls for mitigating the attack vectors
4. 4.Analyze the threat model

The NIST draft also includes a detailed example of how this methodology would be applied in practice. If you’re looking for a threat modeling example, this is a great document to read to see how the process works.

Threat modeling best practices :

No matter which methodology you choose, there are a few practices you should follow. Perhaps the most important — though often one that is hard to follow in practice — is to make threat modeling a priority during system development. If you can do it at the start of a project, you can save yourself a lot of grief later on, because a secure viewpoint will be baked into your application or system.

Another best practice, is not to view applications and systems in isolation from one another. “If the various threat models are connected to one another in the same way in which the applications and components interact as part of the IT system,” writes Michael Santarcangelo, “the result is a comprehensive attack surface which the CISO can use to understand the entire threat portfolio across the enterprise.”

We also urge you to avoid common threat modeling mistakes. The short version: don’t focus too much on whatever threats are in the headlines; don’t forget that your users can be some of the biggest inadvertent threats of all; and don’t forget that a threat model should be a living document and needs constant updating.

Threat modeling tools :

You will have noted that a couple of the methodologies listed above — VAST and Trike — are actually built around specific software tools. Tools support other methodologies as well; for instance, Microsoft has a free threat modeling tool available, and the OWASP Foundation has desktop and web app versions of its own tools.

But in truth many of the methodologies described here are conceptual and not tied to any software implementation. Attack trees or data flow diagrams can be drawn with pen and paper. As this presentation from Luca Bongiorni explains, some of the most popular tools for threat modeling are Microsoft Visio and Excel. The barriers to getting started with threat modeling for your infrastructure are low — and the rewards are high.