The Ultimate Guide to Threat Modeling

What is threat modeling?

Threat modeling is the process of identifying flaws, that are potential threats, in an application or system and recommending mitigations to stop those threats.

It involves accurately mapping the component parts of the application or system, along with their roles and functions, and uncovering potential threats based on various factors such as protocols used, environment and data sensitivity.

One key aspect to threat modeling is that it is a process not a project. It’s easy to think of threat modeling as a project with a beginning, middle and end. Identify threats during the design phase, mitigate them and move on. But in a world where applications are continuously deployed in ever-changing cloud environments, threat modeling must become an ongoing process for it to be effective.

The importance of threat modeling

It’s natural to assume that threat modeling applies to applications residing in the cloud. And while that’s mostly true, threat modeling applies to many more systems, most of which do not reside in the cloud, but represent an even greater threat target.

Threat modeling is important because there are at-risk systems whose failure could be catastrophic. A sampling of those systems include the following:

Systems that control automobile breaking and collision avoidance
Internet-of-Things (IoT) devices that operate control systems in utility plants and refineries
Medical monitoring and drug delivery devices
Aerospace systems for guidance and control

Threat modeling is also important because it identifies more than just security threats. It can also be used to identify compliance threats. Threats, that if realized, could prove just as costly to an organization, in terms of fines, as a security breach.

The scope of threat modeling

In practice, the scope of threat modeling encompasses more than might be inferred from the definition above. That’s because threat modeling is not done in isolation. Rather it’s done by taking a holistic view of the organization.

In addition to application threats, threat modeling considers business threats, asset threats and infrastructure problems. And it does more than just address threats and problems.

Threat modeling includes defining security requirements and test cases; producing Center for Internet Security (CIS) benchmarks; conducting risk assessments; and analyzing regulatory compliance.

Thorough threat modeling also attempts to answer business questions like the following:

Am I spending too much on security?
What is secure enough?
Are my security controls ready for changes to my business?

Objectives of Threat Modeling

The definition of a threat

A threat is also referred to as a threat agent or adversary. It is either a person or code operating on behalf of a person. For it to be a threat, it must harbor ill will toward your organization, have the capability to execute on it and have the motivation to do so.

The purpose of threat modeling

As alluded to previously, the purpose of threat modeling is more than just to model threats. As a way of simplifying, you can picture threat modeling as a Venn diagram of two overlapping circles: assets you care about and assets threat agents care about.

The purpose of threat modeling is to identify the overlap of those two circles. Then prioritize it and then protect it from threat agents. Of utmost urgency are those assets in the overlap area that represent the doomsday scenarios your business fears.

The role of threat modeling in identify and assessing application threats and vulnerabilities

For threat modeling to be truly effective, it cannot be done as an afterthought, or in an ad hoc or unplanned manner. Threat modeling must bring a discipline to identifying and assessing application threats and vulnerabilities.

When done properly, threat modeling’s role is to provide a systematic and repeatable way to ensure you’re both thorough in modeling the attacks, as well as focusing on the attacks that matter most. In general, this level of analysis cannot be achieved by simply checking off items in a list. Instead, you must look to attain visibility into attack surface entry points, exploit chains and vulnerable assets. There are tools available today that make this exercise easier.

Threat Modeling across the Lifecycle

The importance of continuous threat modeling

There is a fundamental paradigm of when to update a threat model: whenever anything changes. That includes both technologically and business-wise. So, unless your organization and applications are frozen, threat modeling is going to be more or less a continuous activity.

But continuous doesn’t mean periodic. With most development today predicated on agile methodologies, and multiple releases per day not uncommon, continuous threat modeling means exactly that. Real-time and near-real time updates to your threat models are not only required, they are essential.

Examples of events that warrant updating threat models

Here are some examples of when to update a threat model:

When adopting a new tech stack (e.g., web, mobile, IoT, cloud, IaC, FaaS)
When exploring new business models (e.g., mobile checking, self-service IT)
Every time an application changes
Every time regulations change (e.g., GDPR, PCI, PII)

Consistency of the process at different levels of abstraction

You can threat model an organization. You can threat model a portfolio of applications. You can threat model a single application and you can even threat model a chunk of code. Effective threat modeling requires that you apply the same risk methodology, consistently, at any of those levels.

One of the benefits of a consistent threat modeling process is that it helps you decide where to spend your time in the organization modeling threats. More importantly, which applications to start with.

Refining the threat model throughout the lifecycle

You already know you should be threat modeling continuously throughout the lifecycle. You should also be refining those threat models as you go as well. An accurate threat model from ten iterations back, probably is accurate any more.

As an application evolves, it is important for you to focus on the elements of the threat model that are impacted by that evolution. In other words, focus on the change.

How does Threat Modeling work?

Identifying types of threat agents

How you define a threat agent depends a great deal on your organization, as the definition tends to be organization specific. The types of threat agents depend on their motivation and who is sponsoring them. As a simplification, there are four categories of threat agents:

Casual/lone wolf
Organized crime
Hacktivist
State-sponsored

Understanding the different threat agents is an important first step in adopting the perspective of a hacker.

Adopting the perspective of malicious hackers

More than just a tool, and even more than a process, threat modeling is discipline that can be developed throughout an organization. The discipline comprises several unique and specific skills. And one of the most important is learning to think like a malicious hacker.

As mentioned previously regarding the purpose of threat modeling, the overlap of the Venn diagram includes those assets malicious hackers care about. And what are assets hackers care about? It depends on the threat agent. For number one and two in the list above, it’s money and things that can be easily exchanged for money.

So, to adopt the perspective of a hacker, you must learn to ask empowering questions. Questions like, if I were organized crime, what assets does my organization possess that is money or can be exchanged for money easily?

Analysis of the software architecture and business context

For threat modeling to be successful, you must address impacts to the technology side as well as the business side. After all, not all threats are technical in nature (e.g., social engineering).

Analyzing the business risk of software architecture is an essential element in prioritizing mitigations. For example, suppose some system is vulnerable, but only makes publicly available information vulnerable. In that case, the technological risk may be high, but the business risk is small, so prioritize mitigations accordingly. Bottom line? All threats must be analyzed within the context of the business.

Conducting threat modeling during the design stage

To fully understand the threats to a system, process or application, you must do threat modeling as early as possible in the software development lifecycle (SDLC) to ensure that threats are identified and mitigated appropriately. When you do threat modeling earlier in the life cycle, security issues are less expensive to resolve and less likely to delay a project.

Steps for developers to perform threat modeling

Here is 10-step, high-level overview for developers to perform threat modeling:

Enumerate threat actors
Elicit misuse/abuse cases
Discover attack surfaces
Diagram security architecture
Automate with security controls
Detail flow and trust
Hypothesize vulnerabilities
Verify security design
Detect via security testing
Manage risk

Advantages of Threat Modeling

Provides a clear line of sight across software projects

Several advantages accrue when you develop a company-wide threat modeling discipline. One of the most important is that it standardizes security across all applications and systems in the enterprise. Furthermore, it reduces the burden and expense of having to make risk models from scratch and repeated calculations.

Aids in spotting design flaws

Threats are commonly due to design flaws In essence, it is the design flaw that allows the attack to occur. So, one byproduct of threat modeling is spotting some design flaws. Of course some threats are the result of a lack of attention to detail. Those types of threats don’t do much in the way of finding design flaws.

Other advantages of threat modeling

Incorporates a process for documenting security threats
Helps in making rational decisions about prioritizing threats
Detects problems early in the SDLC
Assists in evaluating new forms of attack/threats beyond standard attacks
Identifies security requirements
Justifies security efforts while maximizing testing budgets
Enables remediation of problems before software release
Keeps frameworks one step ahead of internal and external attackers
Highlights assets, threat agents and mitigating controls
Models the location of threat agents

Best Practices for Threat Modeling

Promote security understanding across the whole team

Threat modeling works best when a commitment to threat modeling permeates the entire team, not just the security folks. The idea is to create an inclusive security culture. One that exists on a collaborative platform that makes interacting seamless.

With this commitment, threat modeling happens in a repeatable process. It’s done on all applications and systems. It’s integrated right into the DevOps process and made part of all cloud transformation initiatives.

Define the scope and depth of analysis

Threat modeling must be done at the portfolio level to define the scope and depth of analysis. You start by asking one question: How much security work is required? And the answer is, it depends on how capable your adversaries are and how valuable your assets are.

Those answers help you define the scope and depth of the analysis required. If your adversary is a lone wolf hacker, that requires a different scope and depth of analysis than if your adversary is a nation state. The end goal is knowing when you can stop threat modeling.

Gain a visual understanding of the system

One of the real benefits of threat modeling is that it can produce a visual depiction of your system and the threats it faces. Threat diagrams make it easier to understand the threats as well as collaborate with team members.

It’s important when doing threat modeling to do more than just fill out a checklist. It’s a best practice to create a visual understanding of the system, and there are a few different ways to do that.

Model the attack possibilities

When gaining a visual understanding of the system, it’s a best practice to include modeling the attack possibilities. You don’t truly understand your adversaries until you can model all of the different ways they can attack your system.

Create a threat traceability matrix

An essential part of threat modeling is to create a threat traceability matrix. In the matrix, each row is a unique threat and the columns are as follows:

Who: the adversary
Where: the attack surface
What: attack itself
How: the steps in the exploit chain
Why you care: the impact
What to do about it: the mitigations

One of the important things to come out of creating the threat traceability matrix are the blank cells. Blanks cells represent unknowns in your threat model which need to be addressed.

Conducting a Threat Analysis

There are two general categories for identifying security threats: checklists and non-checklist based approaches. By far the simplest, and least expensive, is checklists.

Checklist-based approaches

The idea behind checklists is that you start with a roadmap when looking for threats. The goal is to be able to answer questions like the following:

Do you have authentication?
Do you have authorization?
·Are you vulnerable to spoofing?

Checklists are, by definition, incomplete because they fail to consider who and how, and also fail to prioritize assets.

STRIDE

One of the first of these checklists is STRIDE. STRIDE is a mnemonic for six threat categories, each of which if violated, represents a potential threat:

Spoofing

Tampering

Repudiation

Information disclosure

Denial of service

Elevation of privileges

ASVS

ASVS, or Application Verification Security Standard, is a project by OWASP (Open Worldwide Application Security Project) which provides a basis for testing web application technical security controls. The AVSV reference can be used as a metric, as guidance for developers and during procurement.

OWASP Top 10

According to their own website, The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

Essentially, the OWASP Top 10 is a checklist of the top 10 security categories which threaten web applications at any point in time. The list is continually updated as threats change. Since they are the most pervasive threats, the list represents a good starting point for checking off threats and mitigations in an application.

Non-checklist-based approaches

The non-checklist based approaches are all predicated on taking a different view of the threat landscape. There are attack centric approaches that consider the threat landscape from the attackers point of view.

There are asset centric approaches which start by looking at which assets are valuable and which are vulnerable. There are also software centric approaches which attempt to analyze the software in detail and look for vulnerabilities in the application design and in the code.

One non-checklist based approach which supports enterprise-wide scalability is VAST. VAST is a mnemonic that stands for Visual, Agile, Simple Threat modeling. The VAST methodology is unique because it is founded on the idea that threat modeling is only useful if it encircles the entire software development life cycle (SDLC), throughout the whole enterprise.

Which non-checklist approach is the right one? They can all be the right one, as long as they force you to think through all your security threats.

Synopsys threat analysis

Synopsis is a leading provider of electronic design automation solutions and services. One of their services is to provide threat modeling. They have developed a three-step high-level approach to analyzing threats:

Model the system
Conduct a threat analysis
Prioritize the threats.

Prioritizing the Threats

One of the main aspects of threat modeling is prioritizing the threats you uncover. Here we discuss some guidelines for prioritizing those threats.

NIST approach

The NIST approach to prioritizing threats can be found in NIST’s Special Publication 800-154, Guide to Data-Centric Threat Modeling.

To aid in prioritizing threats, NIST focuses on the security objectives of the data (as opposed to the system). Specifically, confidentiality, integrity and availability are used to establish priority.

The first step is to identify which data sets are most valuable. Step two is to identify which of the three objectives is most important for any particular data set. Step three is to identify what are the threats to that security objective.

Guidelines for quantifying the likelihood and impact of each threat

The best way to quantify the likelihood and impact of a threat is to take a risk management perspective. Because individual risks are different for each organization, the same threats may produce very different numbers for likelihood and impact for different organizations.

There are many resources available you can use to quantify risk. Here is a list of some of them:

FAIRTM (Factor Analysis of Information Risk)

Microsoft Threat Modeling Tool

person typing on a laptop with cybersecurity holograms

Microsoft was one of the first companies to explore the potential of threat modeling. In 1999, two employees developed the STRIDE framework. Since then, the company has developed what they simply refer to as the Microsoft Threat Modeling Tool.

According to the company, The Microsoft Threat Modeling Tool makes threat modeling easier for all developers through a standard notation for visualizing system components, data flows, and security boundaries. It also helps threat modelers identify classes of threats they should consider based on the structure of their software design.

The tool was designed with non-security experts in mind, making threat modeling easier for all developers by providing clear guidance on creating and analyzing threat models.

What is cloud threat modeling?

Cloud threat modeling helps companies understand where to make investment when securing their cloud deployments. And it does all that by executing on the two steps mentioned above.

Expands on standard threat modeling

Threat modeling was initially envisioned for applications which reside on a physical server on-premises. With the migration to the cloud, threat modeling needed to expand its capabilities to match the dynamic nature of cloud-based applications.

VMs and containers get spun up and decommissioned without warning. Storage and processing services are added and removed continuously. To keep up, modern threat modeling has become more responsive to keep up with ever-changing cloud architecture and security control requirements.

Accounts for unique cloud services

Not only has threat modeling been forced to become more responsive, but it now must integrate seamlessly into a variety of cloud service providers (CSP). And, it must also accommodate the Shared Responsibility Model of security adopted by most CSPs, which means the responsibility for the security of an application is shared between the customer and the CSP.

Threat modeling must also be broad enough to address the variety of cloud services offered by the various CSPs. Each CSP offers different services, and even where they offer the same service, they may vary in a way that impacts threat models.

Threat Modeling Methods

Threat modeling involves modeling systems in such a way as to highlight the threats. But how to model a system to do that is not always straightforward. Here we discuss a few different approaches to modeling systems for threat analysis.

Data flow diagramming

Data flow diagramming (DFD) documents the flow of data into, out of and around a system, application or process. In some ways it looks similar to a flowchart. Threat modeling got its start from system engineers who were attempting to map out how data moves within and interacts with a system. They did this with DFDs.

The challenge with DFDs is that the data are uncategorized. That makes it difficult to use this type of model to prioritize threats, since all data are treated equally.

Process flow diagramming

Process flow diagramming (PFD) is a type of flowchart that illustrates the relationships between major system or application components (rather than the data passing through them).

The key advantage of PFDs, compared to DFDs, is that PFDs illuminate how the major components of the system interact with business assets. Because of this, PFDs can be used to prioritize threats.

PASTA (Process for Attack Simulation and Threat Analysis)

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric methodology. It provides a seven-step process for aligning business objectives and technical requirements, taking into account compliance issues and business analysis.

PASTA utilizes the view of a would-be attacker on identified threats, as well as an analysis of the risk and impact of the attack being successful. This is beneficial, as the contextualized approach always ties back to business context.

TRIKE

TRIKE is an open source threat modeling methodology that is used when auditing security from a risk management perspective. It is a combination of a requirements model and an implementations model.

The requirements model assigns acceptable levels of risk to each asset. The implementation model uses DFDs. In this way, TRIKE is like DFDs, only with the ability to categorize, and therefore prioritize, threats.

VAST (Visual, Agile, and Simple Threat modeling)

VAST is an enterprise-wide scalability threat modeling methodology that integrates into workflows built around the DevOps philosophy. It is unique because it is founded on the idea that threat modeling is only useful if it encompasses the entire software development life cycle (SDLC), throughout the whole enterprise.

It was designed for anyone to be able to threat model, even if they have little to no security expertise. It works well for organizations leveraging DevOps or agile frameworks, and makes use of two separate threat models: one for application threats and another for operational threats.

Common Mistakes in Threat Modeling

Over-reliance on templates

Many threat modeling approaches begin with a template, which is based on some previously effective threat model. It makes sense to use a template and avoid having to start each new threat model from scratch. But it is a mistake to be overly reliant on templates.

For starters, the threat landscape changes too quickly to use any template as is. More importantly, businesses change too, which must also be reflected in the threat model. Start with a template, but make changes accordingly.

Relying solely on automated tools

Just as it is with templates, over-reliance on automated tools can lead to outdated or ineffective threat models. And just as with templates, let the automated tool create a threat model that serves as the starting point for your threat model and then make changes accordingly.

Lack of stakeholder involvement

Threat modeling is an enterprise-wide undertaking. It should be reflective of all aspects of technology and business within the enterprise. As such, it’s not possible to get a complete picture of the enterprise without all the stakeholders involved.

At a minimum, technology, business and corporate executives must be represented and provide meaningful inputs to the threat model.

Failure to update the threat model

The threat landscape changes quickly. In the cloud, so too does the attack surface. For threat models to be effective, they must be updated constantly. That’s why we say threat modeling is a process, not a project. An ongoing process at that.

Ignoring non-technical threats

It’s easy to assume threat modeling only needs to model technology threats. Threats that are the result of some technological flaw. But that isn’t the case. One of the hardest threats to model (and defend against) are people-based threats, both with and without intent.

With intent is the malicious insider intent on doing harm to the organization. Without intent is any employee susceptible to social engineering and/or phishing attacks. That pretty much includes everyone.

When threat modeling, it is a mistake to overlook non-technical threats.

Focusing on specific threat scenarios instead of the big picture

Your gut reaction might be to look at a list of top vulnerabilities and focus your threat modeling energy on those. And you should, but not at the expense of the big picture.

Hackers take a holistic view of your organization and the threat landscape. If everyone is focused on the top vulnerabilities, hackers understand they’ll be more successful avoiding them. That’s why it’s a mistake to not keep the big picture in mind when threat modeling.

Benefits of Integrating Threat Modeling into DevSecOps

Identifying and prioritizing risks early in the development process

It’s a trending topic in DevSecOps. Shift left—or more accurately shift counterclockwise. There are many benefits to shift left. For example, the sooner in the development process developers discover a security flaw, the sooner they can address it. This helps them prioritize risks earlier in the development process too.

Reducing the cost and time of fixing vulnerabilities later in the development cycle

Another benefit of shift left is that the sooner you find a security flaw in the development process, the less it costs to fix. And the best way to do that is to turn DevOps into DevSecOps by integrating threat modeling right into the process.

Improving communication and collaboration

As previously discussed, threat modeling is not for solo practitioners—it’s about including stakeholders. Consequently, it works best with open communication and strong collaboration.

When security is “bolted on” at the end of development, collaboration and communication are, by definition, not very good. By embedding security into the development process, it becomes a necessity for development, security and operations teams to communicate and collaborate.

Creating a shared understanding of security requirements and goals

One of the results of strong communication and collaboration is the shared understanding of security requirements and goals. A complete understanding of the architecture, as well as the upstream/downstream impact of a threat, can be achieved.

Enabling continuous security testing and feedback loops

Most modern DevOps is based on continuous integration and continuous delivery (CI/CD), which is essentially a never-ending loop of incremental development. By incorporating threat modeling into DevOps (making it DevSecOps), security testing and feedback is also put on a loop of continuous incremental improvement.

Tools and Technologies for Threat Modeling

There have been many advancements in tools and technologies to make threat modeling easier, faster and more repeatable. We discuss some of them here.

Threat modeling software

Microsoft Threat Modeling Tool
IriusRisk
ThreatModeler

Code analysis techniques

SAST (static application security testing): analyzes source code
DAST (dynamic application security testing): probes front end for vulnerabilities
Automated SAST: tightly integrated with CI/CD, uses incremental scanning

Automated security testing tools

OWASP ZAP
Burp Suite

Security testing frameworks

Conclusion

In this Ultimate Guide to Threat Modeling, we covered some often overlooked aspects of threat modeling. For example, threat modeling does not just apply to applications in the cloud (e.g., medical devices) and it is used to identify more than just security threats (e.g., compliance violations).

We pointed out that threat modeling is best done with a holistic view of the organization and can answer important questions like, am I spending too much on security? We also noted that threat modeling occurs at the intersection of the assets you care about and the threat agents you worry about. And that it’s an ongoing process, not a one-time project.

Recall that embracing a threat modeling discipline offers many advantages to your organization, including improved collaboration and communication within the development community. It encourages stakeholder involvement and lowers the cost of identifying and fixing flaws in the code.

We concluded with a quick tour of the various threat modeling tools, methods, techniques and technologies. We also noted some common mistakes to avoid, the benefits of integrating into DevOps and the importance of prioritizing threats

The bottom line is that threat modeling has rapidly become an indispensable part of creating secure applications and secure organizations. And while there are a lot of choices to be made in terms of tools and technologies, the number one decision to make is to do threat modeling.

NEXT STEPS

If you would like to learn more about Threat Modeler and how it can help secure your deployments, you can request a free demo here or you can contact ThreatModeler directly here.