Threat Modeling: The Ultimate Guide

As software professionals, we have to juggle a lot of balls. Performance, functionality, usability, architecture and observability — now security is one more ball to keep in the air.

We need tools that we can easily reach for and leverage. Threat modeling is one of these tools for security, but in software circles it may feel more like mysticism than a tool you can learn. It doesn’t help that threat modeling seems to be diverging: Many different frameworks and tools arrive weekly, and we haven’t yet converged on a “best method” for it.

That said, this articles aims to be a comprehensive guide that turns threat modeling from a mystic art to an extra hand in your juggling act. In this article, we will:

• Define threat modeling
• Discuss its benefits, where it’s best used, and who participates in it
• Offer a simple framework to follow and more advanced paths to walk from there
• Dispel and translate much of the jargon

When we’re done, you should be able to confidently inject threat modeling to give your team the upper hand over security risks. 

What is threat modeling?

Threat modeling is the process of mapping security weaknesses in a system and evaluating how to manage them. It helps build and support your cyber threat intelligence (CTI).

Think of security weaknesses as a battle: we want to know where the enemy is likely to strike, how costly it could be, and, thus, where we should put most of our defenses. For example, in a military campaign, I may point out that the coast makes us vulnerable to an opponent with a large navy and that we should put artillery along the cliffside. 

Threat modeling can take many forms, which we’ll dive into later.

Threat modeling vocabulary

Before we get into the methodologies at your disposal, let’s define some jargon they use. If you want to go deeper on any of these, I recommend this article.

• Threat: An actor with intent to attack your system (e.g., a human who wants to sell your users’ personal info). 
• Risk: The probability that a threat’s attack will impact your system in certain ways, given as an estimate or percentage (e.g., a medium chance an attacker could gain read access to your database and sell that information because you accidentally left passwords in a codebase that was shown in a demo to vendors). 
• Attack surface: A boundary of your system that’s exposed to an attacker (e.g., any public-facing URL of your application). 
• Vulnerability: An attack surface that’s not secured against attacks (e.g., a public-facing URL that doesn’t require authentication, yet has access to commands that potentially exploit your system). 
• Attack: A series of attack vectors made by a threat that exploit vulnerabilities in your system for some negative result (e.g., accessing a public-facing URL without authentication to gain valuable information). 
• Trust boundary: Any place in your system where data flows that changes its level of trust. These may also be attack boundaries. For example, a web server that receives purchase orders will validate the order data, increasing the level of trust the order data has. You often need fewer restrictions around high-trust data. 
• Attack vector: The series of steps a threat makes for an attack; many times, vectors are automated. For example, to access your company’s prototype projects, the threat may use a combination of requests to your URLs to see where you don’t require authentication. The next vector would then see which URLs produce successful status codes.

(Master the basics: how vulnerabilities lead to threats, then to risk.)

Benefits of threat modeling

Threat modeling brings a few key benefits to your juggling act, ultimately meeting the goals of effectively managing security risks.

Clearer understanding of your security requirements 

There are many security best practices—for example the OWASP Top 10 risks. But these are general guidelines. They don’t take your specific situation into account. Threat modeling will help you know where to invest your effort and what to prioritize.

Faster feedback, cheaper to fix

In the popular spirit of shifting left, threat modeling can let you catch issues as early as possible—in the design process. Threat modeling could completely eliminate vulnerabilities before they could sprout, which means no loss of trust from customers and no effort needed to rework the issue.

Like preventative medicine, the cheapest way to fix something is to not get sick in the first place. Anything that comes after—in the code builds, in deployed environments and especially releases—will have a higher cost to resolve. 

(See how DevSecOps shifts security left.)

Increased confidence

Fear of the unknown can cause irrational and risky behavior, even in the spirit of reducing risk. Holistic security can often feel like a mystery, but threat modeling makes it known to your team. It gives you confidence to move fast and go forward with your innovative plans. 

Better quality product

Security is traditionally an invisible feature in that it is difficult to quantify. Often when developers are in a rush to release value to customers, they can leave security in the dust of their designs—until it’s too late. Many of the recent data breaches we’ve heard about can attest to this. Threat modeling makes it visible. It brings it to the forefront of your planning, where it can be quantified and prioritized accordingly.

How threat modeling works

Let’s take a look at the who what where and when of threat modeling.

Where to apply threat modeling

Threat modeling is very flexible. It can apply to both waterfall and agile approaches. Although, if you’re doing waterfall, it’s good to have a threat modeling veteran help out, as missing something could be costly. 

It is also software agnostic—it applies equally to desktop, web, API, IoT applications and more. It can even be done in a larger scope, across multiple software systems in your organization.

When to use threat modeling

You should use threat modeling when you’re designing your system. In waterfall, you can make it an additional step after you flesh out functional requirements. In agile, you can threat model for a new system or new features, iterating over your models and data flow diagrams every few sprints. 

Who participates in threat modeling

Threat modeling isn’t just for security professionals. However, it’s good to have them facilitate the activity to guide teams who design the system. Usually, it’ll be the software developers or infrastructure engineers who begin the threat model, be it drafting the data flow diagram or documenting your four questions, which we’ll cover below.

It’ll be key for project or product management to both:

• Understand the threat models clearly.
• Collaborate to establish business objectives. 

Types of threat modeling approaches

The various threat-modeling methodologies often focus on a few themes:

• Asset-focused threat models center on the different components, or assets, of your system — usually ones that are attack surfaces or trust boundaries. Then you work your way from the asset to the various potential attack vectors that could exist for it.
• Attacker-focused threat models put us in the mindset of our threats/attackers. What are they looking for? How do they find information and exploit it in a system? Then we connect those thoughts to the attack surfaces that may connect.
• Software-focused threat models use design and diagramming to visualize threats and attack surfaces. This is the de facto threat modeling style that leads to a more holistic and clearer picture of where your vulnerabilities may lie. After all, a picture is worth a thousand words. 

Start modeling threats: The 4 Question Framework

There are many threat modeling methodologies, but before picking one or more for your team, it can be worth starting at a simpler point. Adam Shostack in his book Threat Modeling: Designing for Security explain that threat modeling can be as straightforward as asking four key questions: 

1. What are we working on? 

First, we must understand what we’re building: be it a new software, an IoT ecosystem or a feature. It’s useful to create a data flow diagram of it as well. Then we can annotate the trust boundaries of the system.

2. What can go wrong?

Generate possible threats on each element or connection in your data flow diagram. You can also leverage methodologies like Security Cards, STRIDE., or Kill Chains in this step. We’ll briefly cover those later. 

3. What do we do about it?

Given your system’s current state and potential threats, start tracking and prioritizing vulnerabilities. This may come in the form of malicious User Stories or test cases in your requirements. Create measures to manage these vulnerabilities:

• Mitigate: Make it harder for a threat to take advantage of the system, e.g., require authentication on an application by default. 
• Eliminate: Minimize features to decrease an application’s attack surface. Cut that scope!
• Transfer: Move the responsibility of handling the risk. For example, leverage an API manager to handle your authentication.
• Accept: It might be too expensive to mitigate, eliminate or transfer the risk; accepting it is the last resort. We still need to document this as part of the process and so everyone is aware of the remaining risk. For example, internal users may have wide access to company data, and a disgruntled employee could harm the system. But if we don’t extend trust to our employees, why did we hire them?

4. How did we do?

Make sure that steps 1 to 3 of “What We Do About It” are specific and actionable enough that future revisions are for new threats discovered. Think about it like a retrospective in Agile. I often like to work backward, starting at “what will we see when this vulnerability is eliminated?” and then implementing the efforts that deliver that result. Our data flow diagrams are living documents, and we can update and version them periodically. 

Threat modeling methodologies

As a supplement to these four questions, we can apply specific methodologies to create high-quality threat models. Let’s take a look.

Security Cards

The Security Cards methodology isn’t very comprehensive but can be a great way to provide probing questions about the system being made and specific examples of threats. Developed by Tamara Denning, Batya Friedman and Tadayoshi Kohno from the University of Washington in 2013, it comprises a deck of cards with probing questions around four dimensions:

• Adversary’s motives
• Adversary’s resources
• Adversary’s methods
• Human impact 

An example card is “Indirect attack - Adversary’s Methods. How might an adversary use an indirect or overlooked property to bypass your system’s direct defenses?”

Where this model shines: Security Cards are great as both a threat modeling learning tool and a brainstorming guide for professionals finding threats. 

STRIDE Model

Praerit Garg and Loren Kohnfelder at Microsoft developed STRIDE, a mnemonic about general categories of threats to a system that can answer “What can go wrong?”:

• Spoofing: How do we ensure a user’s authenticity?
• Tampering: How do we check the integrity of our data?
• Repudiation: How do we audit actions in our system to verify that someone did or didn’t attempt something?
• Information Disclosure: How do we keep confidential information from those who shouldn’t see it?
• Denial of Service: How do we prevent our resources from becoming maliciously exhausted?
• Elevation of Privilege: How do we stop someone from getting additional access that they shouldn’t be authorized to gain?

Variations include STRIDE-per-Element, where we check the categories on each element, and STRIDE-per-Interaction, where we check the categories on each potential interaction between elements.

Where this model shines: STRIDE can make for a great middle-of-the-road thoroughness to check specific attack surfaces in your model. It allows us just a little bit of structure to ensure we have thought through a surface.

DREAD

DREAD is used to quantify the risk resulting from a threat. Each letter of the mnemonic stands for the factors considered in the computation of risk.

DREAD RISK = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5

Where this model shines: DREAD can be great when it comes to prioritizing threats. It’s a smart choice for when you have a variety of threats without an immediately clear idea of risk. 

PASTA

PASTA stands for Process for Attack Simulation and Threat Analysis. It’s a risk-centric approach to threat modeling that was developed in 2012. PASTA consists of the following steps:

1. Define Business Objectives: What are your current milestones or product goals?
2. Define the Technical Scope: What is the story map or written functional requirements of those goals?
3. Decompose the Application: Break the architecture of the application into its deployable artifacts, infrastructure, and even smaller components, if necessary. 
4. Threat Analysis: Look at your trust boundaries and attack surfaces; what potential attacks could be made?
5. Weakness and Vulnerability Analysis: Look at your current state and see where there may be missing defenses to your analyzed threats.
6. Attacks Enumeration and Modeling: Simulate potential attack vectors. See what the results could be. 
7. Risk and Impact Analysis: Figure out what your risks are for each vulnerability to prioritize shoring it up. 

Where this model shines: PASTA is a comprehensive modeling methodology that’s great when you have potential high-risk or high-impact areas that you’re unsure about. IT can help give a holistic view of your security and puts security as a centerpiece of your design. 

Cyber Kill Chain 

Kill Chain is a military technique adapted for cybersecurity by Lockheed Martin. It describes the chain of an attack: reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objective. It also describes what sort of steps can occur at each phase of the chain: detect, deny, disrupt, degrade, deceive, and contain.

Cyber kill chains are a key element in Splunk Security Essentials, which make it easy to track potential chains.

Where this model shines: Kill chains can be a great way to answer the questions “what could go wrong?” and “what do we do about it?” Once you identify a specific threat, attack surface, or trust boundary, you can model the kill chain and your defenses.

MITRE ATT&CK 

Another advanced methodology, MITRE ATT&CK centers on a depository of known threats and historical attacks — that we can apply to our current systems. Splunk, for example, leverages these known attacks to automatically map them to your system to find gaps.

Here is an example screenshot: 

Where this model shines: There is nothing like real-word experience to produce defenses. In these cases, we can learn from the past to prevent issues in the future. 

Threat modeling tools

There’s not a lot of well-known tooling for threat modeling, but something as simple as a whiteboard can get you started—be it a physical one or a virtual one such as Miro or Mural.

Beyond that, there are a couple of specific tools we recommend:

• Threat Dragon is an open-source tool that creates diagrams for your system. It also creates reports related to the created model.
• Splunk Security Essentials is a free application that offers a complete solution to the whole threat modeling process — including threat detection, severity measurement, countermeasures creation and success measurement. It uses Kill Chain and MITRE ATT&CK frameworks.

Threat modeling gives critical insight

In the juggling act that is software development, you can see that the flexibility of threat modeling gives everyone in the organization an extra hand. Individual contributors, development teams, security teams, and management — threat modeling lets you all start taking steps to make your organization more secure. 

What is Splunk?

This post was written by Mark Henke. Mark has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. 

This posting does not necessarily represent Splunk's position, strategies or opinion.