What is Threat Modeling?

Threat modeling is the process of mapping security weaknesses in a system and prioritizing how to respond to them. In this in-depth article, we will:

• Define threat modeling and discuss its benefits and challenges.
• Understand the basic requirements to model threats.
• Look at both simple and more advanced frameworks to guide you.
• Explore the effects of AI on threat modeling.

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

What is threat modeling?

Threat modeling is the structured process of identifying and analyzing risks facing your technology systems. The practice of threat modeling informs decision-making and helps build and support your cyber threat intelligence (CTI). Done well, threat modeling is like a map: you can see your weaknesses, so you can take appropriate and prioritized action to mitigate them.

As the name implies, threat modeling produces a model, or multiple models. OWASP defines a threat model as:

A threat model typically includes:

• Description of the subject to be modeled
• Assumptions that can be checked or challenged in the future as the threat landscape changes
• Potential threats to the system
• Actions that can be taken to mitigate each threat
• A way of validating the model and threats, and verification of success of actions taken

Threat modeling follows a well-defined framework and guidelines for a variety of activities, including:

• Building a data pipeline for SIEM data.
• Detecting anomalies.
• Developing and continuously improving AI models for risk profiling.

Threat modeling is both flexible and software agnostic. You can apply threat modeling to software and applications, systems, networks, distributed systems, IoT devices, and business processes.

Threat modeling can take many forms, which we’ll dive into later. Typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation of a given application.

Threat modeling vs. attack surface analysis

Threat modeling is not the same as attack surface analysis. OWASP defines the “recursive relationship” as such:

(Read our attack surface management explainer.)

Benefits of threat modeling

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

• Clarity around your security requirements. Best practices and Top 10 threat lists are only guidelines: they cannot take your specific situation into account. Threat modeling can show you what to prioritize and where to invest resources.
• Preventative nature, faster feedback, lower cost. In the shift left spirit, threat modeling can catch issues early in the development process, even eliminating vulnerabilities before they sprout. Fixing later — in code builds, deployments and especially releases — will cost more.
• Better quality product + increased confidence. Many data breaches highlight how so many teams forgot or ignored security. Threat modeling makes your weaknesses visible, so you can plan for innovation and realistically quantify threats.

Threat modeling today: on-premises vs. distributed systems

Threat modeling in traditional data centers is one thing. The traditional data center environment allows you to model the system behavior exactly, especially with regards to cybersecurity.

Your IT teams know exactly the network infrastructure design and configurations, software architecture, configurations and update cycles of the hardware endpoints, as well as network health and traffic parameters.

With this information, teams can understand how their IT systems behave — and also proactively predict risk in response to external network intrusion attempts and cyberattack incidents.

But modeling threats in cloud environments is a lot more complicated. In fact, threat modeling in today’s cloud age is taking a different approach entirely.

Modern threat modeling

Modern cloud networks consist of large, distributed endpoints, known as distributed systems.

From a service model perspective — where the vendor is responsible for managing the infrastructure — organizations struggle to identify real-time security threats, especially around information that is stored and transmitted between third-party cloud services.

That’s because their view into the data is limited: cloud vendors may not share details on the design and architecture of network systems. Still, users can access a variety of metrics and parameters that describe network health and traffic flows. (This limitation is important in the context of decomposing the systems to identify trusted boundaries, actors and agents within your IT systems.)

Using advanced AI technologies, this information is used to train AI models that learn patterns in these metrics and log data that correspond to an acceptable security performance of their network. A trained model replicates the optimal behavior of a system and is able to read metrics and network log data in real-time to identify anomalies and deviations.

• If these deviations are significant, the AI model classifies the network activity as risky and can be integrated with a Security Information and Events Management (SIEM) to proactively trigger a control action.
• Depending on the severity of the risk, these actions may be configured to inform a network administrator or shut down an entire network zone to contain the damages.

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

How threat modeling works

You should use threat modeling when you’re designing anything new. In a waterfall approach, you can make it an additional step after you flesh out functional requirements.

In an agile environment, you can threat model for a new system or new features, iterating over your models and data flow diagrams every few sprints.

Threat modeling approaches

The de factor threat modeling approach is focused on software. Software threat models use design and diagramming to visualize threats and attack services. Others include:

• Asset oriented threat models center on the different components, or assets, of your system — usually ones that are attack surfaces or trust boundaries.
• 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?

Setting up a threat modeling system

Now, let's look at what you need to develop an effective threat modeling system for your cloud-based technology systems, especially for public clouds where you don’t have access to hardware resources that run your IT infrastructure platform and apps.

Asset discovery & architectural design

It is important to develop a threat model that incorporates all the dependencies within your IT systems.

To start, identify your assets and application components. Asset discovery may be an ongoing effort, especially in microservices-based platforms where containers and the application components running on those systems remain in an ephemeral state. Though ephemeral, the vulnerabilities and threats facing these systems can have a lasting impact on the risk profile of your IT systems.

Secondly, consider the architectural design plans adopted in your IT environments. Many design choices may emerge as a tradeoff to business metrics. For instance, business units may choose to prioritize uptime and performance to security checks and instruments that compromise user experience.

(Read about data architecture.)

Data aggregation & platform

The goal of a threat model is to determine security risks and vulnerabilities by analyzing real-time information. The challenge here is not the scope of data — while vendors may share information on a limited set of parameters, the volume of data assets is large and complex.

To continuously train your AI models on new data assets, via continuous learning, you may require a large-scale data lake platform. Then, build a data pipeline around the data lake to:

1. Store large volumes of complex information in raw format.
2. Process it for AI use cases only when required, following a schema-on-read framework.

The result is an efficient data pipeline that can inject large volumes of information at scale, across all formats of network logs and business metrics. Then, you can integrate external tools to process and analyze this information in real-time, which supports two essential threat modeling activities:

• Anomaly detection
• Continuous improvement to your threat model (updating the present state of risk profiles)

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 Cyber Kill Chains in this step. (More on those later.)

3. What can 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, insider threats: internal users may have wide access to company data, and a disgruntled employee could harm the system.

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. One approach is to work backward, asking a question like:

Then, you want to implement actions that deliver that result. Our data flow diagrams are living documents, and we can update and version them periodically.

Threat modeling frameworks & methodologies

Ready to go beyond these four questions? You can apply specific methodologies to create high-quality threat models. Let’s take a look.

Threat Modeling Manifesto

In 2020, a group of threat modeling practitioners, researchers and authors wrote the Threat Modeling Manifesto in order to “…share a distilled version of our collective threat modeling knowledge in a way that should inform, educate, and inspire other practitioners to adopt threat modeling as well as improve security and privacy during development”.

When to use this model: Reading this is a good entry-point. The Manifesto contains core threat modeling values and principles, and it identifies patterns and anti-patterns to facilitate it.

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 you check the categories on each element, and STRIDE-per-Interaction, where you check the categories on each potential interaction between elements.

When to use this model: STRIDE is a great middle-of-the-road thoroughness to check specific attack surfaces in your model. It allows 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

When to use this model: 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

Short for Process for Attack Simulation and Threat Analysis, PASTA is a risk-centric approach to threat modeling. 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. Analyze the threat. Look at your trust boundaries and attack surfaces. What potential attacks could be made?
5. Analyze weaknesses and vulnerabilities. Look at your current state and see where there may be missing defenses to your analyzed threats.
6. Model the attacks. Simulate potential attack vectors to see what the results could be.
7. Analyze the risk and impact. Figure out what your risks are for each vulnerability to prioritize shoring it up.

When to use this model: 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

The Cyber Kill Chain is a military technique adapted for cybersecurity by Lockheed Martin. It first 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
• Contain

When to use this model: Kill chains can be a great way to answer the questions “What could go wrong? 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.

(Learn more about cyber kill chains.)

MITRE ATT&CK

The MITRE ATT&CK Framework is a depository of known threats and historical attacks — that we can apply to our current systems. Here at Splunk, for example, we leverage these known attacks to automatically map them to your system to find gaps.

Here’s what that can look like:

When to use this model: 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.

(Learn how to get the most value from ATT&CK reporting.)

AI-driven threat models

Finally, let’s look at threat modeling through the lens of AI. Like anything today, we’re wondering what happens when we apply AI — hence the louder and louder calls for AI governance.

Developing AI models for risks profiles is tempting, of course. Beware, though, that this approach does require a set of strategic business decisions that are both subjective and can change invariably. For example:

• The risk profile description and categories must be developed with a view of potential impact and its value to the business.
• Resource allocation is also a business decision and can change rapidly in the short term depending on resource availability and severity of risks.

With all the ways you can model threats today, the only real question to ask now is: “When are we getting started?”