GETTING STARTED WITH

THREAT MODELING
Threat Modeling Overview

Experience shows Threat modeling is a structured activity for identifying and evaluating software
that nearly 50% of application threats and vulnerabilities. It remains one of the most impactful but
security flaws will be under-utilized risk mitigation techniques. Effective threat modeling ensures that
limited resources are spent addressing the most critical threats, whether it’s
discovered from
conducting deeper scrutiny in certain areas or expanding mitigating controls.
Threat Modeling
because it finds This guide will provide the necessary high‐level knowledge needed to quickly
different threats than create a basic threat model for your software application scenario that can be used
those found through to help refine your application’s design throughout all stages of development, and
other assessment serve as a central reference among teams. This approach leads to the goal of
identifying and addressing vulnerabilities.
techniques.
The security objectives, threats, and attacks that you identify in the early stages of
Michael Howard the process are designed to help you later find vulnerabilities in your application to
Sr. Security Architect
help shape your design, drive development, and refine your security testing.
Microsoft

2
Preparing to Threat Model

The primary objective of threat modeling is to improve security design. This can be
done by scoping the model, using existing documents, using an iterative approach,
adapting, and having the information you need.

Existing Iterative
Scope the model Adapt Information
documentation approach

Scope the model

Use scenarios to scope the modeling activity. Identify scenarios that are out of
scope to help limit your threat modeling activity. Clarify what you are not going to
talk about. For example, are operational practices out of scope?

Existing documentation
Use any existing design documents such as use cases or user stories, data flow
diagrams, architecture diagrams, and other design documentation. A helpful tip is
to start with a whiteboard. It can be easier to get started by modeling on a
whiteboard before you start capturing information in documents or getting lost in
the details.

Another helpful technique is to use a digital camera or a whiteboard with print

capability to document and distribute the information from the whiteboard.

3
Preparing to Threat Model

Iterative approach
A threat model is not a static asset. Add more detail and evolve your threat model
as you continue to design and develop. Use ongoing modeling to reduce risk and to
inform your design decisions. For example, early in the design process, you may
have only basic use cases, an initial deployment topology, and an idea of how you
will layer your application. By using an iterative approach, you both become more
familiar with the modeling process and can evolve your threat model to examine
“what if” scenarios as more information becomes available to you.

You might choose to adopt a more formal approach and identify milestones for
revisiting your model. What is most important is that you revisit the model when
you need to make an engineering decision, as you introduce new levels of risk, and
when you contemplate significant design choices.

Adapt
Adapt the activity for your situation. If you have existing applications, you can use
the threat and vulnerability identification approaches in Steps 4 and 5. With this
information, you can determine where to focus your efforts.

Information
To be able to draw and understand your end-to-end deployment scenario, you need
to have information about the host configuration, firewall policies, allowed
protocols and ports, and so on. Obtain this information, and other information
about host and network constraints, by talking to your system and network
administrators.

4
The Threat Modeling
Process

The threat modeling process consists of five steps.

1. Identify Security Objectives – This helps you focus the threat modeling activity
and determine how much effort to spend on subsequent steps.

2. Create an Application Overview – This provides an overview of the key

functionality, usage scenarios, deployment technologies, and security mechanisms
of your application to help identify relevant threats and constrain the scope of
modeling.

3. Decompose Your Application – To better understand application mechanics it’s

important to break down your application from the standpoint of trust boundaries,
data flows, and entry and exit points to facilitate the next steps.

4. Identify Threats – With a clear understanding of the application, gather a diverse

team to identify threats relevant to your application scenario and context.

5
The Threat Modeling Process

5. Identify Vulnerabilities – Review the layers of your application to identify

weaknesses related to your threats and use vulnerability categories to help you
focus on those areas where mistakes are most often made.

As you move through your application development lifecycle and discover more
details about your application, you will progressively add more detail to your threat
model. Continually repeat this process as necessary as you gain more
understanding of your application and its weaknesses.

Tip: Try not to get stuck on the steps or implementation; instead, focus on the
overall approach. If you get blocked on any of the early steps, start to identify
threats (step 4).

1 Identify Security Objectives

Security objectives are security goals you want to achieve for your application. These
goals should be the guiding principles for every step in the threat modeling
process. You can classify nearly all security objectives under one of the CIA Triad
categories: Confidentiality, Integrity, and Availability.

You may find it helpful to think of security objectives in terms of constraints.

Consider the question, “What do you not want to happen?” Your answer might be,
for example, that an attacker must not be able to steal user credentials. By
ity

identifying your key security objectives, you can determine where to focus your
ial

In
nt

efforts.
te
e

g
fid

rit

Identifying your objectives also helps you to understand the goals of potential
n

y
Co

attackers and concentrate on those areas of your application that require closer
Availability
attention. If, for example, you identify customer account details as sensitive data
that needs protecting, you can then examine how securely the data is stored and
how access to the data is controlled and audited

Confidentiality Integrity Availability

Assures that data can only be
accessed by those with proper
authorization, e.g.:
• Sufficient encryption for data
in transit and at rest
• Strong authentication
• Proper permissions and other
authorization controls
Guarantees that data is in its
original state, free from
corruption or modification, e.g.:
• Verification checksums and
verification hashes
• Digital signatures
• Encrypted data transports
such as TLS
Ensures users are always able to
access a system, e.g.:
• Adequate server uptime
when under attack
• Adequate backups to recover
from server failures or
compromise
• Sufficient bandwidth and
proper firewalls to withstand
DoS attacks

6
The Threat Modeling Process

To determine your security objectives, consider the following questions:

• What to Protect – Does your application use user accounts and passwords,
customer account details including personalization information, financial history
and transaction records, customer credit card numbers, bank details, or travel
itineraries?

• Compliance Requirements – Do you need to adhere to security policies, privacy

laws, regulations, and standards?

• Quality requirements – Do you have specific availability of service and

performance requirements?

• Protect intangible assets – Do you need to protect your company’s reputation,

trade secrets, and intellectual property?

After asking yourself these questions, security objectives become more clear.
Some common security objectives include:

• Prevent attackers from obtaining sensitive user data like passwords and profile
information

• Meet service-level agreements for application availability

• Protect the company’s online business credibility

2 Create an Application Overview

In this step, you create a high-level synopsis of your application. Your goal is to
identify your application’s key functionality, characteristics, and clients, if applicable.
This overview will help you to identify relevant threats later.

To create an application overview, draw the end-to-end deployment scenario,

identify roles, key usage scenarios, technologies, and application security
mechanisms.

• Draw the end-to-end deployment scenario – Describe the composition and

structure of your application and its subsystems.

• Identify roles – Identify who can do what within your application.

• Identify key usage scenarios – Describe what your application does. Focus on
the Create, Read, Update, and Delete functionality.

• Identify technologies – Operating systems, web server software, application

frameworks, database server software, and development languages.

• Identify application security mechanisms – Identify any key information that

you know about security controls.

7
The Threat Modeling Process

Draw the End-to-End Deployment Scenario

Using a whiteboard or paper, draw a rough diagram that describes the composition
and structure of your application, its subsystems, and its deployment
characteristics.

Add details about the authentication, authorization, and communication

mechanisms as you discover them. Remember that you may not have all the details
early in the design process.

Your deployment diagram should generally show end-to-end deployment topology,

including the layout of the servers, and indicate intranet, extranet, or Internet
access. Start with logical network topologies, and then refine the diagram to show
physical topologies when you have those details.

Next, add logical layers. Show where the presentation layer, business layer, and data
access layers reside.

Refine the diagram to include physical server boundaries when you know them.
Add key components and services within each logical layer. Refine the diagram to
include actual process and component boundaries when that information
becomes available. Include communication ports and protocols; show which
servers, components, and services communicate with each other and which
protocols they use.

Finally, show the main identities and roles used for the application and any relevant
service accounts if you have this information. Be sure to include authentication
protocols and account storage locations.

Identify User Roles

After you’ve sketched out the deployment scenario, it’s important to identify your
application’s roles, duties, and functions. For example:

• What can users do?

• What higher-privileged groups and roles exist?

• Who can perform sensitive functions like read, update data, or delete data?

Use role identification to determine both what is supposed to happen and what is
not supposed to happen. Like the other steps, this activity will be a continual
documenting process that gets more detailed with each iteration.

Identify Key Usage Scenarios

With user roles in place, next map out the key usage scenarios for your application.
What are the important features of your application? What does it do?

Utilize your application’s use cases, if available, to derive this information. Identify
the application’s main functionality and usage, with a primary focus on the Create,
Read, Update, and Delete functionality.

8
The Threat Modeling Process

For example, a self-service, employee human resources application might include

the following use cases: Employee views financial data; Employee updates personal
data; Manager views employee details; and Manager deletes employee record.

In these cases, you can look at the possibilities of the business rules being misused.
For example, consider a user trying to modify personal details of another user. You
often need to consider several use cases happening simultaneously to perform a
complete analysis.

Also identify which scenarios are out of scope and use your key scenarios to
constrain the discussion. For example, you might decide that operational practices,
such as backup and restore, are out of scope for the initial threat modeling exercise.

Identify Technologies

Where possible, list the technologies and key features of the software and platforms
that you use. Also identify the following:

• Operating systems

• Web server software

• Application frameworks

• Database server software

• Development languages

Identifying technologies helps you to focus on technology-specific threats later in

the threat modeling activity. It also helps you determine the correct and most
appropriate mitigation techniques.

Identify Application Security Mechanisms

Finally, identify any key information that you know about your application’s security
mechanisms, including:

• input & data validation • sensitive data handling

• authentication • session management

• authorization • parameter manipulation

• cryptography • exception management

• auditing & logging • configuration management

These details are important because they will be key starting points when
identifying threats later in the process

Tip: Threat modeling is an iterative process, so you don’t need to have a complete
application overview before identifying threats. For example, if you are in the
middle of your design and have not yet tackled physical deployment, you can still
perform this step, and add more detail on deployment when available

9
The Threat Modeling Process

3 Decompose Your Application

In this step, break down your application to identify trust boundaries, data flows,
entry points, and exit points. The more you know about the mechanics of your
application, the easier it is to uncover threats and discover vulnerabilities.

Trust boundaries Data flows Entry points Exit points

Identify Trust Boundaries

Identify your application’s trust boundaries to help focus your analysis on areas of
concern. Trust boundaries indicate where trust levels change. You can think of trust
from the perspective of confidentiality and integrity. For example, a change in
access control levels in your application where a specific role or privilege level is
required to access a resource or operation would be a change in trust level.

Another example would be at an entry point in your application where you might
not fully trust the data passed to the entry point.

To help identify trust boundaries:

• Start by defining your outer application boundaries. For example, your web
servers might connect to shared file resources as well as application and
database servers. This core cluster of services defines your application boundary.

• Next, identify access control points or the key places where access requires
additional privileges or role membership. For example, a specific page might
be restricted to managers. The page might require authenticated access and
require membership in the administrators’ group.

• Finally, identify trust boundaries from a data flow perspective. For each
subsystem, consider whether you trust the upstream data flow or use case, and if
not, consider how the data flow and input might be validated, authenticated, and
authorized.

Knowing which entry points exist between trust boundaries allows you to focus
your threat identification on these key entry points. For example, you are likely to
have to perform more validation on data passed through an entry point at a trust
boundary. Some examples of trust boundaries include:

• Perimeter firewall – The firewall is likely to be the first trust boundary. It moves
qualified information from the untrusted Internet to your trusted data center.

• The boundary between a web server and database server – Your database may
or may not be included in your application’s trust boundary. Often the web

10
The Threat Modeling Process

servers act as a second firewall to the databases. This practice significantly limits
network access to the databases and thereby reduces the attack surface,
although you will also need to consider the network topology within your data
center.

• Database access points – Do any other applications write to the database? If

they do, do you trust those applications? If you trust the applications that write to
the database, you may still not want to trust the database—is it protected?

• Entry points into components which handle privileged data – In the case of a
business component that handles privileged data, you need an access check to
ensure that only the appropriate callers are allowed access; that is, data should be
available (exposed) to only particular users.

Identify Data Flows, Entry Points, and Exit Points

To identify data flows, trace your software application’s data as it moves through the
various subsystems, starting with user input. This activity helps you gain a better
understanding of the interaction between each of your application’s components.

A good approach is to start at the highest level and then deconstruct the
application by analyzing the data flow between individual subsystems. For example,
start by analyzing the data flow between your web application, your middle-tier
servers, and your database server.

Then consider page-to-page and component-to-component data flows. Pay close

attention to data flow across trust boundaries and how that data is validated at that
entry point. Also pay close attention to sensitive data items and how these flow
through your system, as they pass over a network, and where they persist in
storage.

The entry points of your application also serve as entry points for attacks and can
include the front-end web application listening for HTTP requests. This entry point
is intended to be exposed to clients. Other entry points, such as internal entry
points exposed by subcomponents across the layers of your application, may exist
only to support internal communication with other components. However, you
should know where these are and what types of input they receive in case an
attacker manages to bypass the front door of the application and directly attack an
internal entry point.

Consider the trust levels and features required to access each entry point. Early in
the threat modeling activity, focus your attention on entry points that expose
privileged functionality, such as administration interfaces. Identify the points where
your application sends data to the client or to external systems.

Prioritize the exit points where your application writes data that includes client
input or includes data from untrusted sources such as shared databases.

Tip: You are likely to have to perform more validation on data passed through an
entry point at a trust boundary.

11
The Threat Modeling Process

4 Identify Threats
In this step, you identify threats and classes of attacks that might lead to
compromise or otherwise affect your application’s security. To conduct this
identification process, bring members of the development and test teams together
to conduct an informed brainstorming session. Ideally, the team consists of
application architects, security professionals, developers, testers, and system
administrators.

Identify
threats

Common Threats Along

Threats Data Flows

Threats Along
Use Cases

Identify threats based on what you have learned so far in defining your security
objectives and identifying the application’s trust boundaries.

During this step, you

• Identify Threats

• Common Threats

• Threats Along Use Cases

• Threats Along Data Flows

Two common approaches to brainstorm threats are either to start with common
threats and attacks, or to use a question-driven approach.

If using the common threats and attacks approach, make a list of common threats
grouped by application vulnerability categories. For example, you might create a
server list and a user’s list. Under server you may have path traversal, denial of
service, SQL injection, and XSS. Under users, you may list malware, brute force, and
spam.

Next, using the information gathered in the previous steps, determine how each
threat applies to your own application. The determination will enable you to
eliminate some threats from the list, as well as to refine those threats that apply to
your application.

12
The Threat Modeling Process

Alternatively, you can use a question-driven approach to identify relevant threats

and possible vulnerabilities. This approach is goal-based, where you consider the
goals of an attacker.

For example, could an attacker spoof an identity to access your server or web
application? Could someone tamper with data over the network or in a data store?
Is sensitive information disclosed when you report an error message or log an
event?

While identifying threats, examine the application tier by tier, layer by layer, and
feature by feature. By focusing on vulnerability categories, you can target those
areas most susceptible to vulnerabilities. Nevertheless, keep in mind that the
threats identified at this stage do not necessarily indicate vulnerabilities. The
objective here is to identify potential threats and the actions that an attacker might
try to use to exploit the application.

Identify Common Threats

While each software application will carry unique threats, there are common ones
that should always be considered. Is the server vulnerable to identity spoofing? Is
the data vulnerable to tampering? Is the Sensitive information in error messages?

Server Users

• Path Traversal • Malware

• Denial of Service • Brute Force

• SQL Injection • Spam

• Cross-site Scripting (XSS)

Identify Threats Along Use Cases

Now that you have a list of common threats, look for threats that might be unique
to your application.

Examine each of the application’s use cases identified earlier, identifying ways in
which others might maliciously or unintentionally cause the application to perform
an unauthorized operation or disclose sensitive or private data.

As you go through this process, approach the application as an attacker might do.
Examples of the types of questions you should ask include the following:

• How can a client inject malicious input here?

• Is data written out based on unvalidated user input?

• How could an attacker manipulate session data?

• How could an attacker obtain sensitive data as it is passed over the network?

• How could an attacker bypass your authorization checks?

13
The Threat Modeling Process

Identify Threats Along Data Flows

Next, review the key use cases and scenarios, and analyze the data flows between
individual components in your architecture. Data flow across trust boundaries is
particularly important. A piece of code should assume that any data from outside
the code’s trust boundary is malicious. The code should perform thorough
validation of the data.

When identifying threats associated with data flows, ask the following questions:

• How does data flow from the front end to the back end of your application?
Which components call which components?

• What does valid data look like? How is the data constrained? How is data
validated against expected length, range, format, and type? Where is validation
performed?

• What sensitive data is passed between components and across networks, and
how is that data secured while in transit?

5 Identify Vulnerabilities
The final step in threat modeling is to look at all the potential threats you’ve
gathered and determine which of those affect your application. Previously, you
looked at the hypothetical threats, and now you must determine which specific
vulnerabilities you must address.

The best way to identify vulnerabilities is to examine your application layer by layer,
considering each of the vulnerability categories in each layer. To make sure you
cover the full range of vulnerabilities, it’s best to utilize an existing model or
checklist. Some of the best examples are STRIDE, ATT&CK, and CAPEC.

Microsoft’s STRIDE is a mature model that focuses on the high-level categories of

Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and
Elevation of privilege. STRIDE focuses more on the threat end but is also useful in
enumerating vulnerabilities.

MITRE’s ATT&CK is a comprehensive matrix of attacks that is useful for identifying

vulnerabilities as well as mitigating and detecting vulnerabilities in production
applications. ATT&CK enumerates dozens of attacks under twelve major categories
and includes models for different server platforms.

MITRE’s CAPEC (Common Attack Pattern Enumeration and Classification) is a

dictionary of attack patterns and is the most comprehensive resource for
identifying attacks. CAPEC in conjunction with MITRE’s CWE (Common Weakness
Enumeration), which is a dictionary of specific vulnerabilities, is helpful in the later
stages of threat modeling in the application development lifecycle.

Depending on the level of detail required, any of these resources can benefit the
last stage of threat modeling and help you uncover your application’s
vulnerabilities.

14
Document and Report

Capture your threat model in a document, and keep it as lightweight and simple as
possible. Avoid over-formatting so that you can easily update it, but be sure to
include:

• Security objectives

• Key scenarios

• Protected resources

• Threat list

• Vulnerability list

Use the vulnerabilities to help shape your security design and implementation. For
example, developers should notice anti-patterns related to the identified
vulnerabilities and use appropriate patterns to address the issues. You can also use
the vulnerabilities to plan and scope your system testing. For example, testers
should test against the vulnerabilities to verify that the development team fixed or
addressed all known vulnerabilities.

Lastly, track and prioritize vulnerabilities in your work item tracking system. And
don’t forget to communicate the information you capture to relevant team
members, which may include your application development team, your test team,
and your network and system administrators.

15
Summary

Hopefully this guide provides useful information on getting started with Threat
Modeling. Once foundational knowledge is built, you can start to incorporate more
advanced technqiues such as building attack and threat trees. There are many
resources for that including Microsoft Threat Modeling.

• Microsoft Security Development Lifecycle (SDL) Threat Modeling Tool

• OWASP Threat Modeling Resource Center

• Security Innovation Fundamentals of Threat Modeling Course

About Security Innovation

Security Innovation is a pioneer in software security and literally wrote the book
on How to Break Software Security. Since 2002, organizations have relied on the
company’s assessment and training solutions to secure software wherever it runs.
Recognized 6x on the Gartner Magic Quadrant for computer-based security
training, its CMD+CTRL SaaS platform combines role-based courses with hands-on
cyber ranges to build skills that stick. With over 3.5 million users, CMD+CTRL helps
all software security stakeholders address the risk of today’s tech stacks – flawed
design, defenseless code, expanded attack surface, and misconfigured
deployments.

Security Innovation also offers threat modeling as a stand-alone risk assessment

service and as a precursor to objective-based security code reviews and software
penetration testing.

For more information, visit https://www.securityinnovation.com/

16