A Threat Modeling Primer

Posted on 29 Apr 2022 by Ray Heffer

What is a Threat Model?

I was first asked that question last year during a job interview. I started to rattle off everything I knew about threat modeling, and I used an example from a privacy standpoint, to highlight risk and why threat modeling is important. I was in the mindset of a CISO, not the security analyst.

The interviewer asked “What examples of threat models do you know?” Of course, he was expecting me to talk about STRIDE, PASTA, or DREAD. He was thinking of threat modeling from a security analysts perspective, whereas I was thinking about the core purpose (the why) of threat modeling, rather than blindly diving straight into a given framework.

A threat model is used to gain insight into the security of a subject or system, resulting in the identification and prioritization of threats, and the steps to mitigate them.

In other words, think like an adversary! so you and your organization can be aware of, and help mitigate potential threats. A threat model can help you understand what could (and probably will) go wrong, how likely is it, and what the impact would be. It’s about being prepared.

The point of threat modeling is to ensure security is NOT an afterthought.

How to Approach Threat Modeling

At first this can seem like an entirely overwhelming task, so where should we start? Many years ago I asked a former manager that question, and he replied “Start somewhere. That will become the beginning.” I’ve never forgotten his clever response, but the right answer is the design phase. If you leave threat modeling until further along in the Software Secure Development Lifecycle (SDLC), or it’s even an afterthought, then you and your organization are in trouble.

NIST defines four steps to threat modeling:

Step 1: Identify and Characterize the System and Data of Interest

Step 2: Identify and Select the Attack Vectors to Be Included in the Model

Step 3: Characterize the Security Controls for Mitigating the Attack Vectors

Step 4: Analyze the Threat Model

Establish a Tiger Team

The first lesson here, is don’t go it alone.

Successful threat-modeling requires a team effort, requiring a broad range of skills and focus areas. This needs to encompass the developers, application owners who have a full understanding of the functional and non-functional requirements of the application, a security focused team thinking as the adversary, and experts in defending the application. This could be a combination of Security Incident and Response (SIRT) engineers, business application owners, developers, project managers, and red / blue team. You may be the security lead, driving the threat-modeling activity, but you will never be a single point of failure or blocker.

By taking this approach to threat modeling you avoid bottlenecks, and security being seen as an obstacle to be worked around. A project manager can have a more holistic overview, but each member of the team owns their topic of expertise. You as the security lead, are there to ensure success and you have the cycles to answer questions, share knowledge, and ensure a consistent approach. You are the quarterback.

Threat Models

Before I dive into specific threat modeling frameworks, let me expand further on the four steps I listed above. We need to determine:

  • Likelihood of threats to the subject or system
  • Assess the risk and testing of potential threats
  • Determine the impact of each potential threat
  • Establish mitigation measures for a given threat
  • Validation of the model an actions taken

Our goal:

  • Discover vulnerabilities
  • Identify threats
  • Secure the design
  • Provide documentation
  • Identify what needs to be validated during testing

With that in mind, what threat models are available?

STRIDE-LM Security Threat Model

This was created by Microsoft security researchers back in 1999. STRIDE stands for; Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, Elevation of privilege, and Lateral Movement.

Spoofing - When spoofing happens, your authentication is compromised. If an identity (or system) can be spoofed, someone is able to pretend they are someone else, or another system. Man-in-the-Middle (MITM) attacks are just one example, others could be DNS spoofing attacks, or using leaked API keys to assume the identity of someone else.

Tampering - This affects the integrity of the system. The immediate exmaple that springs to mind is the tampering of data. Has the integrity of the data been altered? Has an adversary altered audit logs, or worse, tampered with a code to include malware? Also physical tampering can be included here.

Repudiation - Repudiation means to reject something. For example, you may deny that you ever received that email. The sender says you must have it, but there is no proof of delivery, so you reject the premise. In the STIDE model, we strive for non-repudiation, meaning that we can be assured that the sender actually sent the information, with proof. It cannot be denied.

Information Disclosure - We need confidentiality. You need to think of data leaks (or breaches) here, not IF they happen but when. When a data leak occurs, often resulting in privacy regulatory fines (GDPR, or CCPA). This is often overlooked. The data owner is liable should they fail to show due-diligence in securing sensitve data.

Denial of Service - This affects availability. Sure a DDOS (Distributed Denial of Service) attack will affect the availability of a system, but also included here is the ability to recover from failure (backups), eliminating single-points-of-failure (SPOF), or ensuring that components have enough capacity to remain functional and online.

Elevation of Privilege - The principal of least privilege is probably the most well known best practice in security. As an adversary, they will try and circumvent this by using a technique called privilege escalation. One example of this was CVE-2021-4034, which was named PWNKIT. This vulnerability exploited Polkit (formerly Policykit) which provides non-privileged processes elevated privileges. But using the exploit, the adversary is able to gain root privileges with little effort. This vulnerability was hiding for 12 years before being discovered, affecting all versions since May of 2009.

Lateral Movement - This is an addition to STRIDE, added by Lockheed Martin and affects containment. This is where the adversary is able to move laterally in the network, after gaining initial access. It often allows an adversary to avoid detection, one of the tactics described in detail as part of the MITRE ATT&CK framework.


This assess risk and impact, and is a great model to ensure impact is not underestimated. DREAD stands for; Damage potential, Reproducibility, Exploitability, Affected user-base, and Discoverability.

Damage potential - What is the damage a cybersecurity threat can do to the business?

Reproducibility - Can the threat be easily reproduced?

Exploitability - How susceptible is the system for the attack?

Affected user-base - How many people will be affected by the attack?

Discoverability - How detectable is this threat?

For each of these, use scoring on a scale of 1-10, where 1 is very low and 10 scores the highest risk. You can do this easily in a spreadsheet using the following formula:

Risk = (Damage potential + Reproducibility + Exploitability + Affected user-base + Discoverability) / 5

You may even want to combine this with STRIDE (along the horizontal axis).


This is just an introduction to give you a base-level understanding of what threat modeling is and how it is used. If you are studying for the CISSP or other cybersecurity certifications then this worth remembering.

Remember, that using these methodologies together allows you to classify the threats using STRIDE and rate the risk and impact using DREAD.

Comments are closed for this post.