Threat modeling is a practice to identify potential threats and security issues that may negatively impact an application, an IT system, or a business process, and then developing relevant security requirements as countermeasures to threats. By applying threat modeling you can embed security by design as early as possible in the (secure) development process.
Threat modeling comes in many shapes, and sizes. There isn’t one true way of performing threat modeling. In fact, there are many formal threat modeling methodologies, many different threat modeling tools, and many customizations that are possible.
Threat modeling has the following characteristics:
- Threat modeling is structured and repeatable, meaning you can apply it consistently to different objects in scope (i.e., applications, IT systems, business processes, etc.), and get predictable results.
- Threat modeling identifies potential threats (or bad things that could happen), to understand what can go wrong.
- Threat modeling results in security requirements or countermeasures to mitigate threats (or bad things that could happen), this is a key net positive result of performing threat modeling.
- Threat modeling often includes thinking about who or what could potentially harm your object in scope (i.e., application, IT system, or business process).
The Advantages of Threat Modeling
There are many advantages to threat modeling. These are the most important ones:
Understand your threats
For your specific application, IT system or business process: what are the threats that you face?
The threats can vary from industry to industry (i.e., building an app in the crypto space alters the potential threats, to building a solution in the defense industry).
The threats can vary from the type of thing you are securing or building (i.e., building a web application versus building an app in an App Store).
The threats can even vary at a technical level, based on the tech stack that you use.
By understanding the threats that you face, you can build security requirements and countermeasures to those threats.
Understand who may want to attack your system, and what they’re after
As part of threat modeling you can also think about the attackers (known as threat actors). By understanding their motives and methods, you can understand likely attack patterns and pin point ‘how’ you will likely be attacked.
Another part of thinking about your attackers is defining what they’re after within your application, IT system, or business process. What do you have that is valuable? Is it business data, personal data from your users, or access to money?
Develop security requirements early
A typical development process does not include security requirements.
Threat modeling changes that by understanding the threats that you may face – and developing security requirements and countermeasures to those threats.
Not only that, but threat modeling can enforce using security best practices such as NIST CSF, ISO27001, CIS, OWASP top 10 or NIST SSDF.
Develop a better overall product
If you develop securely from the very start (using threat modeling), you’ll develop a better overall product because you’ll have less security debt. A solid and secure base provides a better maintainable product for the long term.
Understand risk
It is difficult to fully understand, visualize and quantify IT risk.
The main factor for this difficulty is not identifying specific threats and overall understanding of ‘what can go wrong’. Threat modeling highlights ‘what can go wrong’ effectively, making it easier to understand the risk involved.
The Threat Modeling Manifesto
The threat modeling manifesto is a great place to start reading about what threat modeling is, and why we threat model at the highest level. It doesn’t go into a great level of detail, but you can read more about threat modeling right here on this site.
The threat modeling manifesto defines threat modeling as:
- Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.
The threat modeling manifesto also uses Shostack’s four-question framework (see below).
Shostack’s Four Question Framework
Threat modeling doesn’t have to be overly complicated. It can be as simple as answering Adam Shostack’s four questions:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good (enough) job?
We’ll explain how these four questions help:
- What are we working on?
- In order to secure something, we must understand what we have, or what we’re building. You can define what you’re working on through diagrams, architectural diagrams, design documents, and more. With threat modeling, we also want to understand what we have and/or are working on, preferably described in a simple understandable way.
- What can go wrong?
- Once we know what we have, we want to understand what can go wrong with the thing that we have. This is different for every system out there. Although there are common factors for each type of system. For example, a typical web application will have common threats, weaknesses, and types of vulnerabilities.
- What are we going to do about it?
- Once you have a good understanding of what can go wrong (along with what we have and/or are building), we can develop countermeasures to make sure the things that can go wrong are contained. Another way of putting it is, we can develop security requirements.
- Did we do a good (enough) job?
- As a last step, we want to verify whether we did a good job on the three previous questions (or steps). Based on this question, we know whether we need to do more work. And don’t forget, you’re never entirely finished with threat modeling (or security in general).
Threat Modeling Methods & Methodologies
There are many different kinds of threat modeling methods and threat modeling methodologies.
One thing to know about the many different threat modeling methods: They do not have the exact same purpose and results. One method may focus only on threats and classifying threats, while another may focus on the bigger picture and include business background & risk, threats, controls, laws, and regulations, etc.
A non-exhaustive list of threat modeling methods: STRIDE, PASTA, Attack Trees, VAST, DREAD, and TRIKE.
I’ll provide a short description of two popular threat modeling methods:
STRIDE threat modeling
STRIDE threat modeling is a specific kind of threat modeling methodology (or method). It is a mnemonic of six types of security threats. Each letter of STRIDE stands for one of the six types of security threats:
- Spoofing: Spoofing is a type of threat whereby an attacker maliciously impersonates (or pretends to be) a different user (or system). You can also use Spoofing more loosely during STRIDE threat modeling to classify threats related to users and access rights.
- Tampering: Tampering is a type of threat whereby an attacker maliciously modifies data. You can also use Tampering more loosely during STRIDE threat modeling to classify threats related to the security of data.
- Repudiation: Repudiation relates to the ability to prove or disprove that an action or activity was performed by a specific user (or not). Repudiation is thus a type of threat whereby an attacker denies having performed a malicious action.
- Information Disclosure: Information Disclosure is a type of threat whereby the attacker gains access to information that should be confidential or secret (and not available to an attacker).
- Denial of Service: Denial of Service is a type of threat whereby an attacker will prevent a system (or application) from working for valid users. This is often achieved by overloading a system with fake requests so that no time or resources remain for legitimate users.
- Elevation of Privilege: Elevation of Privilege is a type of threat whereby an attacker will elevate their current level of access privilege. This can include elevating access privileges where an attacker has no privileges at all (i.e., not a user) or elevating access privileges where an attacker already has ‘some’ privileges (i.e., a basic user).
STRIDE threat modeling is helpful because it can tell us ‘what can go wrong’ with an application, IT system, or business process. I have described many examples of STRIDE threat modeling, as well as many examples of STRIDE threats.
PASTA threat modeling
PASTA threat modeling is a specific method of threat modeling. As with all threat modeling methods, PASTA threat modeling will allow you to identify potential threats in your object of scope. PASTA threat modeling can be performed on applications (mobile, web, Internet of Things, etc.) and more generally IT systems.
PASTA stands for Process for Attack Simulation and Threat Analysis (PASTA). It is a risk-centric threat modeling method, meaning that risk plays a central role and the focus is on the highest and most relevant risks that can affect your business. After all, IT (such as applications, systems, etc.) serve business, and that is their reason for existing.
PASTA threat modeling has seven steps (making PASTA a thorough, granular and prescriptive threat modeling method):
- Define the Objectives
- Define the Technical Scope
- Decompose the Application
- Analyze the Threats
- Vulnerability Analysis
- Attack Analysis
- Risk and Impact Analysis
PASTA is helpful because it is very thorough and will provide you with the big picture, on top of potential threats and security requirements. I have described an example case of using PASTA threat modeling.
Threat modeling versus vulnerability management
Threat modeling and vulnerability management are different exercises, but share some of the same results: both methods identify weaknesses in applications and IT systems. The types of weaknesses differ.
Threat Modeling Tooling
Threat modeling can be performed with or without threat modeling tooling.
The advantages of tooling:
- Easier to follow a specific threat modeling method.
- Easier to standardize the process because you can let the tool guide the users (instead of the users having to specify minimum steps).
- Results are kept in one centralized location (within the tool).
- Better metrics and reporting, because you can extract it directly from the tool, and automatically update based on changes to the threat model.
- Easier roll out within a (large) company.
- Easier to get the latest threat information, potential vulnerabilities, and potential security requirements (countermeasures to threats), which can be used as input within your threat model.
There are some disadvantages too:
- Tooling is not free, meaning that you’ll need a budget.
- Tooling requires setup and integration.
- Tooling requires training in its usage.
Use our Threat Modeling Tool
We have a tool that you can use immediately. Just follow these easy steps:
- Go to our threat modeling tool page.
- Sign up for free.
- That’s it – get started.
Our tool has great reporting options, showing you the results of the threat model.
Our tool has data flow diagram features, allowing you to accurately diagram your application, IT system, or business process.
Our tool has a powerful assessment system, which allows you to think about potential threats and security requirements.
Diagramming
Diagramming is an important part of threat modeling. The goal is to provide an improved understanding of the application, IT system, or business process that we’re working on (and in the scope of threat modeling).
There’s no right or wrong way to diagram something. However, using Data Flow Diagrams is common within threat modeling. That’s because Data Flow Diagrams can be understood by pretty much anybody – it does not require a technical background. It also helps to keep the diagram high-level and abstract enough to focus on the bigger picture.
However, it can certainly help to include other diagram types, especially ones that engineers and technical people are used to seeing. Think cloud application diagrams (in AWS or Azure), diagrams with technical components like databases, compute, firewalls, etc., and network diagrams.
The Differences Between Threats and Vulnerabilities
Threat modeling is not the same as Vulnerability Management.
Threats are not the same as vulnerabilities.
- A threat is a potential weakness within an application, IT system, or business process that can potentially be attacked. The threat can be very high level, to very specific, and is mostly conceptual.
- A vulnerability is a known or unknown specific issue that can be exploited by an attacker. If an attacker exploits a vulnerability, a specific outcome will occur (like bypassing a security measure, extracting data, XSS, SQL injection, etc.).
Threat Modeling Stakeholders
Development teams and DevOps teams: Anyone developing and operating software, IT systems, and/or integrating with business processes can benefit from using threat modeling. In fact, it’s a great way for teams to proactively think about security. DevOps is new and the standard for developing and operating software, and DevOps works well with threat modeling.
Security teams: Security teams are stretched thin at many companies. And giving development & DevOps teams the opportunity to help themselves (using threat modeling) is also a win for security teams. Security teams can teach teams to threat model instead of doing threat modeling themselves. Output from threat models can be used to provide an improved understanding of the security picture. Security teams that provide threat modeling as a capability will often work on things like 1) training, 2) tooling, 3) reporting and dashboards, and 4) availability in case of questions.
Pen-testers / Ethical Hackers: Pen-testers and ethical hackers can use threat models to understand a target more effectively and thus scope pen-testing activities. Compare this to a typical pen-testing scenario where a pentester only receives a URL or an IP to test something (without additional information).
