Threat modeling definition
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:
- What are we working on?
- What can go wrong?
- What are we doing to do about it?
- 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.
- Decompose the application or infrastructure
- Determine the threats
- Determine countermeasures and mitigations
- 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.
Data flow diagram examples
The diagram in Figure 1 illustrates the flow of data through an online banking application; the dashed lines represent the trust boundaries, where data could be potentially altered and security measures need to be taken.
![CSO data flow diagram for online banking, including information sourced from OWASP [CC BY-SA 4.0]](https://images.idgesg.net/images/article/2020/04/cso_threat_modeling_diagram_data_flow_sourced_from_owasp_via_cc_by-sa_4-0-100838200-orig.jpg)
IDG / OWASP (CC BY-SA 4.0)Figure 1. Data flow diagram for an online banking application (from Wei Zhang & Marco Morana, distributed under the OWASP license)
This Microsoft document from the early days of Redmond’s own threat modeling movement goes into more depth on how to build your own data flow diagram for your system or application.
Because data flow diagrams were developed by system engineers rather than security pros, they include a lot of overhead that isn’t necessary for threat modeling. One alternative to a data flow diagram is a process flow diagram. These are similar in overall concept but more streamlined and focused on ways users and executing code move through a system, more closely mirroring the way attackers think. ThreatModeler has a good primer on building a process flow diagram.
Building an attack tree is a threat modeling technique that becomes important when you reach the stage where you’re determining potential threats against your application or infrastructure. Attack trees were pioneered by infosec legend Bruce Schneier in the late ’90s; they consist of a series of parent and child nodes representing different events, with the child nodes being conditions that must be satisfied for the parent nodes to be true. The root node — the topmost parent in the diagram — is the overall goal of the attack. With an attack tree, threat modelers can see what set of circumstances must come together in order for a threat to be successful. Figure 2 shows a simple attack tree illustrating different ways a virus might be able to successfully infect a file.
![CSO attack tree diagram, including information sourced from Bluefoxicy [CC BY-SA 2.5]](https://images.idgesg.net/images/article/2020/04/cso_threat_modeling_diagram_attack_tree_sourced_from_bluefoxicy_via_cc_by-sa_2-5-100838199-orig.jpg)
IDG / Bluefoxicy (CC BY-SA 2.5)Figure 2. Attack tree (from Bluefoxicy, distributed under Creative Commons license)
Hackinthebox has a great presentation on building attack trees from an attacker’s perspective, which can help you in your quest to understand the threats that face you.
The techniques for determining countermeasures and ranking threats vary more widely depending on the framework or methodology you choose, and we’ll talk about them in a bit more detail in the next section.
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
- STRIDE
- DREAD
- PASTA
- VAST
- Trike
- OCTAVE
- 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:
- 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 threat modeling
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:
- Define objectives
- Define technical scope
- Application decomposition
- Threat analysis
- Vulnerability and weaknesses analysis
- Attack modeling
- 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:
- Build asset-based threat profiles
- Identify infrastructure vulnerability
- 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:
- Identify and characterize the system and data of interest
- Identify and select the attack vectors to be included in the model
- Characterize the security controls for mitigating the attack vectors
- 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.
Copyright © 2020 IDG Communications, Inc.
