You’ve probably already heard the phrase “threat modeling” more than a few times. Threat modeling is a highly undervalued, often overlooked aspect of building secure applications—which is a shame, because you don’t have to be a large enterprise with hundreds of developers and architects to benefit from threat modeling. It helps organizations of all sizes.

In this article, we’ll dive into what threat modeling is and why it’s an important tool for building more secure, stable, and resilient applications. Specifically, we’re going to answer the following questions that often come up when threat modeling first makes an appearance:

  • What do we mean when we use the phrase “threat modeling”?
  • Why should threat modeling be a part of the secure software development lifecycle?
  • At what stages in the lifecycle should threat modeling be used?
  • What strategies exist for threat modeling?

Okay! Let’s get started.

What Is Threat Modeling?

We all do threat modeling every day when going about our lives—when keeping an eye out for bad drivers on the commute to work or taking steps to prevent injuries while on a hike. We worry about what might happen. Threat modeling is nothing more than applying this same thought process to a system in order to identify potential risks or threats.

At its core, threat modeling is a means of identifying, enumerating, and prioritizing potential threats to a system from the point of view of an attacker. A threat can be anything that adversely affects the system: for instance, a broken file upload process that causes the application to run out of memory. No matter what you’re trying to secure—a building, a web application, or something else entirely—you can use threat modeling to uncover potential security issues. By knowing about and analyzing potential threats, you can figure out where you lack mitigations. If you currently have mitigations, you can analyze them to determine their efficacy.

That said, the knowledge and experience of the people involved in creating the threat model differ widely. Securing a building takes an entirely different knowledge set than securing an application.

Why Threat Model?

It’s often quite difficult to ascertain the business risks that come with a specific vulnerability. Often the risks are murky and don’t directly correlate with the number of accounts or customers affected. Plus, a minor vulnerability to a large company could be a business-ending event for a smaller one. The business of predicting a vulnerability’s possible impact has become even more interesting with the various cyber insurance policies that have come onto the market. For instance, the business credit rating institution Moody’s has begun to consider the risk of a business-ending hack as part of their credit scoring system.

Threat modeling can help answer questions about your application’s resiliency and risk. With the right people working on the threat model, you can discover how a specific threat might affect your business. Threat modeling forces you to understand where your business might be vulnerable; it’s the springboard that prompts an educated discussion about risk mitigation. Using threat modeling can ensure that your application has the right controls in place to protect yourself.

In short, threat modeling helps you develop a deeper understanding of the security needs of and risks faced by your organization.

When to Threat Model

Threat modeling is ongoing. Its biggest advantages come when it’s incorporated as a recurring activity into the software development lifecycle. During the initial design phase of an application, threat modeling will identify areas for improvement at a time when those issues are cheaper to fix. Threat modeling will also help you understand your application’s security requirements: what they are, if they’re clear enough, if they even exist.

After you’ve built your application, the threat model can be updated during release, when you’re planning for new integrations or major features. For applications that have already been released, your best bet is to approach threat modeling in an iterative fashion. Schedule a one-hour session during each sprint (or iteration) and focus on the current updates; bring in the rest of the system as time allows. Due to the enormous number of existing and legacy applications out there, this is the approach that most developers will end up taking.

Threat modeling also aids in penetration testing. Penetration testing can serve as an experimental validation of the threat model’s hypothetical risks; it can ascertain if the mitigations in place are effective. The threat model can also help you determine the scope of a penetration test by focusing the testing on the most critical areas of the application.

Identifying Threats

When using threat modeling, how do you know what to look for? Often, the advice here is to “think like an attacker.” This sounds great, but it doesn’t provide a ton of meaningful value. Not everyone instinctively thinks about what could go wrong with a system from the attacker’s viewpoint. Luckily, you don’t need the knowledge of a would-be attacker to use threat modeling effectively. There are tons of brainstorming strategies to help you activate your “attacker mindset.”

One of the more popular threat modeling strategies is called STRIDE, which originates from the Microsoft Secure Development Lifecycle. STRIDE is a mnemonic that stands for:

  • Spoofing: An attacker masquerading as another user.
  • Tampering: Modifying data in transit or in a database.
  • Repudiation: Ensuring that a user did what they said they did.
  • Information Disclosure: Unintentional release of private or sensitive data.
  • Denial of Service: Causing the application to be unusable or unavailable.
  • Elevation of Privilege: Exploiting a bug or design flaw to gain access to otherwise restricted functionality.

Requirements, threats, and mitigations all interplay to determine what risk a vulnerability poses to the business. Sometimes a threat doesn’t align with business requirements and may be safe to ignore.

Remember that threats can take on many forms. They don’t always come from attackers. Abnormal application usage leading to instability can also be a threat to the business.

How to Use the Threat Modeling Strategy STRIDE

Using this mnemonic is straightforward. For any application or piece of functionality, the mnemonic provides a way to start reasoning about threats in a systematic way. Let’s take the example of a financial application that’s receiving a major update to allow for a new money transfer. In this case, think through the following vulnerabilities:


In a spoofing attack, an attacker takes action and makes it look like that action came from another user. This doesn’t mean the attacker has access to the user’s account. With a money transfer request, the user might be able to replicate an identifier to indicate where the money is coming from or going to. So when thinking this through, you’d want to ask, “What already exists in my application to ensure that only the authorized user can initiate a transaction?”


Network traffic, databases, log files—all these can be tampered with. An attacker may be able to tamper with network traffic from users if you’re not using proper encryption. Data tampering can also occur through a SQL injection flaw.* *

When thinking about this, consider what the application is doing for data verification and protection. Are proper audit controls in place on the database to limit user permissions? Are all communications between systems (external as well as internal) utilizing up-to-date, secure communications?

To mitigate these issues, you might enhance the application’s transport layer security (TLS) or create good development guidelines for preventing SQL injections. Or you might improve the application’s authentication and authorization models.


Audit trails are extremely important for legal and compliance reasons. You should always be able to prove a user performed a certain action. So consider this: how is your application tracking user activity and ensuring that a proper audit trail exists in the case of a dispute?

This can be a complex issue if an attacker compromises a user’s account. What authentication controls are in place, and what improvements could be made (maybe multifactor authentication, for instance?)?

Information Disclosure

Even the simplest applications today have access to personal, and oftentimes sensitive, data. Is the application exposing any of this data unintentionally or needlessly? What restrictions and guidelines exist to determine what systems can read data and how the data is displayed?

Denial of Service

A denial of service (DoS) attack can take on many forms. It could be an attacker overloading the application with requests that the server can’t process, or it could be a coding or configuration error that results in the application crashing. Regardless, it means downtime, which you definitely don’t want. Consider whether you have a proper monitoring solution in place that can alert you of DoS attacks—that way, you can deal with them before they become major issues.

Elevation of Privilege

In all but the simplest of applications, there’s always some delineation of users. Some users may have limited access while others may have administrative access. A user might have access that allows them to impersonate other users for troubleshooting or customer service issues. This is normal, but it can make you vulnerable. An attacker may be able to exploit flaws in permission validation to gain access to functionality they shouldn’t have—or even gain access to another user’s account. Ask questions about how your user roles are managed and create relevant guidelines and documentation for them. And make sure you know whose responsibility is it to review the current user roles. It’s a good idea to take a look at these every now and then.

Depending on your level of involvement with the application, you may not know how to answer some of the STRIDE questions. This just illustrates that while it’s possible to threat model alone, it’s preferable to have a small group of people working together to develop the model. For our hypothetical application, this group may consist of developers, architects, security, operations, quality assurance—maybe even someone from accounting. The goal is to get the right people in the room to ask the right questions and determine what threats the application may be vulnerable to.

How to Respond to Identified Threats

If you use threat modeling and identify areas that need further discussion, it will result in a more thorough understanding of the risk a threat poses and what you can do about it.

For each relevant threat, determine what the system is currently doing to mitigate said threat. If the application isn’t mitigating, add the threat and mitigation to your issue tracking system. This gets it into the development pipeline and (hopefully) into the release schedule.

It can happen that the mitigation for a threat may be too costly or time-consuming to undertake. Don’t ignore it, though! If you’re not going to mitigate a threat, take careful notes. The right people (sometimes even C-suite personnel) need to make that decision. You should also document the decision and track the threat. This serves to educate others in the organization as to what the risk is and why the business is accepting the risk.

While threat modeling may touch on cross-site scripting (XSS) or SQL injection, these are broader issues of input and output handling that threat modeling can address. Your focus should remain on issues that other tools can’t identify. Threats can be added to an internal threat library that all development groups can draw from, ensuring the knowledge spreads throughout different development groups.


Threat modeling, no matter when you start implementing it, will provide you with new insights and train you to have an attacker’s mindset. All companies and industries can benefit from threat modeling. In the end, threat modeling will help you build safer, more secure, and overall better products.

Interested in learning more? Check out a great reference, Threat Modeling: Designing for Security, by Adam Shostack.

Author: Casey Dunham