02 Threat Modeling

Threat Modeling
Dan Sellers
.Net Developer Specialist
Microsoft Canada
Copyright Microsoft Corp. 2004

2
What is Threat Modeling?

A process to understand and document
security threats to a system that:
Is methodical and complete.
Will describe the system’s threat profile.
Allows the security of the system to be
characterized.
May find vulnerabilities.

3
Key Concepts
A Threat Model describes a system’s
threat profile.
A threat is not a vulnerability.
The point of a threat model is more than
just finding vulnerabilities.
A system is anything that exposes
functionality to an end user, and can
describe anything from a single feature to
a web application and its supporting
infrastructure.
Threat Modeling Process
Collect Model the Determine
Background System Threats
Information
Use Scenarios
Entry Points
External Identify Threats

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
6
Collect Background Information
Background information bounds the

threat modeling discussion.
It gathers information about
dependencies that are security-critical.
It provides necessary information for
people to understand the threat model.

Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams/Process
Models
Internal Security
Notes
8
Identify Use Scenarios

A use scenario explains how the system is
intended or not intended to be used in
deployment.
Use scenarios help bound the threat modeling
by describing the situations that were
considered during the security design of the
system.
They can also explain situations where, if the
system is deployed in an unsupported
configuration, the security can be
compromised.
Use scenarios can be used as mitigation for
threats to the system.
Tool: Use Scenarios Table
Use Scenarios
ID Description
1 The Fabrikam Phone 1.0 will be connected to the public switched telephone network.
The security of this network is beyond the control of the Phone 1.0.
2 If the Phone 1.0 is installed in a location where untrusted users can access it, it should
have local access control enabled.
Use Scenarios: Relevance
 Who uses the information? Use scenarios are used by the threat
modeling team to limit the scope of the analysis. Managers and
development leads must sign off on the individual use scenarios for the
Threat Model to be valid. Later, the security test team can use these
scenarios when conducting a penetration test, either to verify their
validity or prove that they are not consistent with actual deployment.
 How is the information collected? The information is best
provided by the designer of the system being modeled. If the system is
a component that other teams are using, those teams may have input
as to how the component is being used.
 How is it used in the rest of the Threat Model? Use scenarios
can limit the discussion by describing scenarios that will not be
considered (in other words, that are outside of the “safe” use of the
system). During threat analysis, use scenarios can be used as the
mitigation for conditions (for example, a condition may only be true if the
system is used in an unsupported or “unsafe” scenario). Use scenarios
may also help identify additional assets. For example, if a system is
expected to run at a certain elevated privilege level, execution rights at
that privilege level is an asset.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams/Process
Models
Internal Security
Notes
12
Identify External Dependencies
External dependencies are requirements levied on

systems outside of the system being modeled.
They are dependencies on a certain behavior or
specification compliance in an external system that, if
broken, could cause threats in the system being
modeled to manifest vulnerabilities.
Often, these dependencies describe functions such as
algorithm consistency across systems. For example, if
two systems both normalize a string of text and take
action based on the result, it is typically important that
the normalized representation is the same across both
systems.

Tool: External Dependencies
Table
External Dependencies
ID Description
1 The Fabrikam Phone 1.0 depends on the PSTN for providing power. There is a 2-day
power cell in the Phone 1.0 that provides backup power should the power provided by
the PSTN go down.
External Dependencies:
Relevance
 Who uses the information? External dependencies are primarily
used by the threat modeling team to validate assumptions between
systems being modeled. The act of identifying, documenting, and
investigating external dependencies can ensure that disparate systems
and groups do not result in inconsistencies leading to vulnerabilities.
 How is the information collected? The designers and
implementers of the system should be able to identify external systems
that it depends on. Further, they can characterize the functionality of
the external system that is used, thus providing a list of dependencies.
 How is it used in the rest of the Threat Model? External
dependencies result in action items that must be resolved with the
target system’s team before a Threat Model can be considered valid.
They validate cross-system assumptions that, if incorrect, might
otherwise result in vulnerabilities.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
16
Identify Implementation Assumptions
It is good to start the Threat Modeling process before a

system is implemented.
Implementation Assumptions are used when some or
all of the system is in the design phase, and dictate
specifics about how features must be implemented for
the system to remain secure.
Implementation Assumptions should be validated on
completion of the implementation, in addition to revising
the Threat Model as a whole to reflect the
implementation.

Tool: Implementation
Assumptions Table
Implementation Assumptions
ID Description
1 The voice-command dialing option has yet to be implemented. When this is added, it
should not introduce a way to bypass current security features, such as long-distance
call lockout.
2 If encrypted communication is added, key exchange should be done according to
industry-accepted standards.
Implementation
Assumptions: Relevance
 Who uses the information? The information is used by the implementer of
the relevant feature in the system. It is essentially a coding guideline that the
implementer must adhere to. Post-implementation, the Threat Model team
should validate that the implementation assumption holds true. Implementation
assumptions can also be validated in code reviews and during penetration
testing.
 How is the information collected? When threats are being identified, they
often include threats that are common globally or to the team responsible for the
system. If the threat is best mitigated in implementation and not design, the
team usually has a common method of mitigating that threat in code.
Implementation assumptions are then simply notes for the coder that include this
information.
 How is it used in the rest of the Threat Model? Implementation
assumptions are invalidation points for the Threat Model if they do not remain
true after the functionality is implemented. In addition, they are used as
discussion points during the revising of a Threat Model if it is started during the
design phase.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
20
Identify External Security Notes
External Security Notes are the counterpart to external

dependencies.
They provide security-relevant information to users that interface
with the system being modeled.
This information can be in the form of warnings against potential
misuse that, while not constituting a vulnerability in the system
being modeled, may surface a vulnerability in another system if it
is not used correctly.
Or, the information can be in the form of guarantees that the
system makes for users.
As an example, it may contain the specification for how filenames
are normalized internal to the system.

Tool: External Security
Notes Table
External Security Notes
ID Description
1 The Phone 1.0 has a remote administration interface that has a default numeric
password. While the interface is disabled by default, the end user should ensure that
the password is changed if it the feature is enabled.
2 If the end user wants to protect the speed dial list and whether the remote
administration is enabled, he should enable local access control.
External Security Notes:
Relevance
 Who uses the information? The information is primarily consumed by
users whose systems in turn depend upon this system. Those users can
validate dependencies based on this information, or request explanation of
functionality to be added.
 How is the information collected? During the threat model process,
potential misuses of externally-supplied functionality are often identified. This
information should be proactively included in the Threat Model. In addition,
external dependencies on this system can force investigations that result in
information in this table.
 How is it used in the rest of the Threat Model? External security notes
are used as validation of external dependencies. In addition, they can
sometimes be used as mitigation for threats. In this case, the threat is mitigated
through end-user education rather than design or implementation changes.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
24
Identify Internal Security Notes
Internal security notes are information that

readers of the threat model should know to
make the model more clear.
They are often used to explain tradeoffs made
in the design or implementation of the system
that affect security.
They should not be used as a replacement for
threats and vulnerabilities.

Tool: Internal Security Notes
Table
Internal Security Notes
ID Description
1 Speed dial information, messages, and the outgoing message are all stored in volatile
RAM. The combination of volatile RAM and a battery backup for the Phone 1.0 is
cheaper to manufacture than to use non-volatile RAM. This means, however, that
power loss to the Phone 1.0 can cause loss of information if the battery backup is
depleted.
Internal Security Notes:
Relevance
 Who uses the information? Internal security notes are
used by reviewers of the threat model to understand security
tradeoffs that were made in the design or implementation of the
system.
 How is the information collected? Internal security
notes are usually collected when the system is being modeled or
when threats are being investigated. Often internal security
notes come about when a threat exists because of a particular
design decision, but that design decision was made to satisfy
other, non-security requirements.
 How is it used in the rest of the Threat Model?
Internal security notes are used when the threat model is
reviewed for completeness. They are also used when mitigation
for vulnerabilities is discussed.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
28
Model the System
Modeling the system is critical to

determining threats.
It helps the threat modeling team
understand the adversary’s view of the
system.
It helps the team understand the internal
workings of the system, allowing them to
identify design- and implementation-
specific threats.

Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams/Process
Models
Internal Security
Notes
30
Identify Entry Points

Entry Points define the boundary of the system being
modeled.
They list all places where the system consumes data
from, provides data to, or performs actions on behalf of
external entities.
Entry points are often obvious: exposed APIs, listening
sockets, RPC servers, Web Services, etc. Note
however, that any place where the system interacts
with external entities could be considered an entry
point. For example, reading data from the file system is
an entry point because the file system is likely not
private to the system being modeled.

Tool: Entry Points Table
Entry Point
ID Name Description Trust Level
1 Handset The handset is used by the end user for voice (1) Administrator
communication. Voice dialing will also be (2) Long-distance user
implemented via this interface. (3) Local call user
(4) Denied user
2 Keypad The keypad is used for dialing, entering local (1) Administrator
access passwords, and other administrative (2) Long-distance user
functions on the Phone 1.0. (3) Local call user
(4) Denied user
3 Telephone Line The telephone line is where the Phone 1.0 (5) Anonymous remote user
interfaces with the public switched telephone
network.
4 Alphanumeric Display The alphanumeric display shows information, (1) Administrator
such as speed dial numbers, caller ID, (2) Long-distance user
administrative menus, etc. (3) Local call user
(4) Denied user
5 Audible Ringer The ringer is an exit point used to alert the end (1) Administrator
user of incoming calls. (2) Long-distance user
(3) Local call user
(4) Denied user
6 Remote Administration Remove administration is a menu-driven interface (1) Administrator
that is accessed remotely over the PSTN. It is
enabled when the answering machine feature of
the Phone 1.0 is enabled, and is accessed by
pressing 9 once the phone answers.
Entry Points: Relevance
 Who uses the information? The entry points are primarily used
internally to the threat modeling process as described below.
 How is the information collected? Both the designers and
implementers of the system provide the list of entry points.
Occasionally, additional entry points surface during the data flow
modeling of the system.
 How is it used in the rest of the Threat Model? Entry points
are used to prioritize the threat modeling discussion. They also provide
the basis for discussion. For each entry point, the question must be
answered: What functionality does the entry point expose? This
information is used to decompose security-critical processing using data
flow diagrams. Further, they are used to ensure a complete analysis.
That is, a Threat Model can only be considered thorough if all entry
points are identified and explored.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
34
Identify Assets
Assets are those things, both concrete
and abstract, that could be targets of an
attack by an adversary.
Because of the widely varied functionality
of systems, protected resources can also
be widely varied. For example, a
concrete example might be corporate
data stored in a database. A more
abstract example might be network
coherency in a peer to peer application.
Assets should be nouns.
Tool: Assets Table
Assets
ID Name Description Trust Level
1 Speed-dial list The speed dial list contains the names and (1) Administrator
numbers of often-used contacts. (2) Long-distance user
(3) Local call user
2 Caller ID Provides information about the incoming (1) Administrator
caller. (2) Long-distance user
(3) Local call user
3 Access to the PSTN The Phone 1.0 indirectly protects access to (1) Administrator
the PSTN. (2) Long-distance user
(3) Local call user
4 Long-distance calls The Phone 1.0 has optional lock-out for long (1) Administrator
distance calling so that only authorized users (2) Long-distance user
can make long distance calls.
5 Phone configuration The administrative configuration for the (1) Administrator
Phone 1.0
6 Messages Messages left by callers when the Phone 1.0 (1) Administrator
has the answering machine feature enabled. (2) Long-distance user
(3) Local call user
…
Assets: Relevance
 Who uses the information? The Threat Modeling team
uses the information when identifying threats. When analyzing
security-critical processing, points where an asset is referenced
should be scrutinized. The assets are, in essence, the targets of
threats to the system. That is, a threat is what an attacker might
try to do to or with an asset that would result in a violation of the
systems expected security bounds.
 How is the information collected? Many assets are
identified when discussing system functionality, use scenarios,
and other background information. Questions to ask are: Does
the system have access to any resources that an external entity
would not normally have access to? What aspects of the
system are critical to proper functionality?
Assets are used during threat identification to identify an
adversary’s goals. Assuming that an adversary picks a
protected resource as a target, what might he try to do to it?
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams/Process
Models
Internal Security
Notes
38
Identify Trust Levels
Trust levels characterize either entry points or

assets.
In the case of entry points, they describe the external
entity that can interface with the entry point.
For assets, they should indicate what privilege level
would normally be able to access the resource.
The type of trust level is specific to the entry
point or protected resource. For example,
some trust levels may correspond to NT
groups. Other trust levels may simply describe
what is known about the external entity (remote
anonymous user, in the case of a public web
server).
39
Identify Trust Levels
Trust Levels that have more

preconditions (such as requiring
authentication) typically have a lower risk.
The Trust Level table can be used to
prioritize further discussion based on
which categories pose the highest risk.

Tool: Trust Levels Table
Trust Levels
ID Name Description
1 Administrator The Phone 1.0 administrator has access to all features, and can
bypass all security checks.
2 Long-distance user The Phone 1.0 can be configured to restrict long distance calling.
The long-distance user is a phone user that is allowed to make long-
distance calls.
3 Local call user The local call user can only place outgoing local calls.
4 Denied user The Phone 1.0 can be configured to not allow access to the phone
without a password. The denied user is a user with no access.
5 Anonymous remote user The anonymous remote user represents any data or incoming calls
over the PSTN.
Trust Levels: Relevance
 Who uses the information? The Threat Modeling team
uses trust levels to determine high-risk entry points and prioritize
the discussion. The team can also use them when discussing
assets. They are particularly relevant in elevation of privilege
attacks.
 How is the information collected? The designers of
the system should have this information readily available. It is
simply an enumeration of who should and should not have
access to an entry point or asset.
Trust levels are used to prioritize discussion. They are also
used when discussing mitigation and risk. For example, one
could argue that a buffer overflow at an entry point that requires
administrative-level privileges is not high risk because the
administrator would not gain access to any assets that he or she
does not already have access to. (Of course, this depends on
the definition of “administrator,” and is system-specific.)
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
43
Describe Processing on the Threat

Path
The “Threat Path” is the processing that

occurs based on the input to the
enumerated entry points.
Follow processing from the component’s
entry point and determine what it does to
the input data, or based on the input data.

44
Describe Processing on the Threat

Path
While a threat path can simply be described

based on a component’s inputs, outputs, and
processing based on the input, it can help to
use a visual tool such as a Data Flow Diagram.
DFDs should start with both Context and Level
0 diagrams
More detailed diagrams should be created to
further describe security-critical processing.

Tool: Data Flow Diagram
Context
A Process
Transforms or manipulates
data.
Level 0
Multiple Processes
Transforms or manipulates
data.
A Data Store
A location that stores
temporary or permanent
data
Boundary
A machine, physical,
address space or trust Level 1 Level 2
boundary.
Interactor
Input to the system.
Auth Data Data Flow

Depicts data flow from
data stores, processes or
interactors.
* Diagrams taken from Writing Secure Code, 2nd Edition

DTMF input for admin
Audible input via handset interface
Numeric keypad input Telephone

conversation
1 Fabrikam
Local User PSTN
Visual display Phone 1.0 Telephone
output conversation
Ringer
Admin
menus /data
Telephone
conversation
Administrative privilege User dials 9 after
boundary answering machine
picks up Interface enabled
User via 1.1 Enable privilege boundary
PSTN password
User enters entering
digit in
Menus, password
mode
data entering mode
Password enter
enable
Selections,
data
1.5 1.2 Read digit

Administrative
interface
Digit
Wait for
next digit
Admin enable
1.4 Enable
admin Password ring
mode buffer (stores
8 digits)
1.3 Check if
buffer
Successful
matches
8-digit password
completion password
Data Flow Diagrams:
Relevance
 Who uses the information? DFDs can be used by security
testers to get a better understanding of the system’s functionality and
implementation. The visual representation of the data flows allows the
tester to create attack hypotheses.
 How is the information collected? The designers and
implementers of the system provide this information. It is often partially
completed before any threat modeling meetings. During the meetings,
however, they are usually expanded and more diagrams are created as
the team analyzes the system.
 How is it used in the rest of the Threat Model? The
DFDs are used during threat identification as a way to direct threat
hypotheses. They allow the threat modeling team to better understand
the functionality exposed by the system, and what an attacker’s goals
might be.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats /
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
50
Determine Threats
Enumerating threats creates a threat profile for
a system, describing all of the potential attacks
that should be mitigated against.
Threats with valid attack paths are
vulnerabilities.
The security of a system can be expressed in
terms of threats with appropriate mitigation vs.
total threats, taking into account the severity of
the threats with insufficient mitigation
(vulnerabilities).

Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams/Process
Models
Internal Security
Notes
52
Enumerate Threats
Identifying threats, as the critical point in creating a
usable threat model, is appropriately the most difficult
step in the process.
The Threat Modeling team must take the information
produced up to this point and create attack hypotheses.
The team should not limit themselves to known

vulnerabilities, rather, they should consider threats
regardless of known mitigation.
For a given entry point where a specific external entity
interfaces with the system, what security-critical
processing occurs, and what might a malicious external
entity try to do to thwart that processing or otherwise
use an asset outside of its expected use?

53
Enumerate Threats
It is important not to confuse threats with
vulnerabilities. A threat is simply what an
adversary might try to do to a protected
resource in the system. A vulnerability is
a specific way that a threat is exploitable
based on an unmitigated attack path.
Threats become more specific as the
process model becomes more specific.

54
Enumerate Threats
A key aspect to enumerating threats is understanding
specifications (and whether or not they are adhered to).
Protocol specifications, file format specifications, etc.
can define the adversary’s sandbox. While they are
often constrained by specifications, they can often
create spec-valid data that causes corruption or other
errors.
As specifications become more complex, the corner
cases that allow for spec-valid but malicious data
increase.
Note that if the system includes a parser for a given
specification, then the adversary will also try spec-
invalid data to attack the parser itself.

55
Enumerate Threats
Threats can apply a verb to an asset
(adversary does something to an asset):
Adversary captures [password data] using a sniffer.
Or, they can result in an asset:
Adversary supplies a path name that exceeds
MAX_PATH, causing a buffer overflow that may
result in the [ability to execute native code].
In either case, threats are verbs.

56
Using STRIDE
STRIDE is used to classify the effect of threats.
Spoofing. Spoofing allows an adversary to pose as another
user, component, or other system that has an identity in the
system being modeled.
Tampering. Tampering is the modification of data within the
system to achieve a malicious goal.
Repudiation. Repudiation is the ability of an adversary to
deny performing some malicious activity because the
system does not have sufficient evidence to prove
otherwise.
Information Disclosure. Information Disclosure is the
exposure of protected data to a user that is not otherwise
allowed access to that data.
Denial of Service. Denial of Service is when an adversary
can prevent legitimate users from using the normal
functionality of the system.
Elevation of Privilege. Elevation of Privilege is when and
* Some information taken from Writing Secure Code, 2 Edition
nd
adversary
assumes a Trust Level with different privileges
Tool: Threats Table
Threats
Threat
ID 1
Name Adversary gains access to the remote administration interface resulting in access
to the phone configuration.
Description The Phone 1.0 has a remote administration interface that allows an authorized
user to configure it via the PSTN. The interface is disabled by default, but can be
enabled using the local keypad.
STRIDE Classification Tampering
Information Disclosure
Denial of Service
Elevation of Privilege
Mitigated? No
Known Mitigation If the remote administration interface is enabled, the end user should change the
default password.
Investigation Notes (none)
Entry Points (6) Remote Administration

(3) Telephone Line
(2) Keypad
Assets (5) Phone configuration
Tool: Threats Table
Threats
Threat
ID 2
Name Adversary reads the speed dial list
Description The speed dial list has sensitive information (names and telephone numbers).
STRIDE Classification Information Disclosure
Mitigated? No
Known Mitigation
Related Use Scenarios:
(2) If the Phone 1.0 is installed in a location where…
Entry Points (2) Keypad

(4) Alphanumeric Display
Assets (1) Speed-dial list

Tool: Threats Table
Threats
Threat
ID 3
Name Adversary makes a long distance call
Description Access to long distance can be restricted. Often it is not desirable for arbitrary
users to make long distance calls.
STRIDE Classification Elevation of Privilege

Mitigated? No
Known Mitigation
Related Use Scenarios:
(2) If the Phone 1.0 is installed in a location where…
Entry Points (1) Handset

(2) Keypad
Assets (4) Long distance calling

Update DFD for Threat Types
60
Each element in
TID 6.0 the DFD is
susceptible to
one or more
TID
SR 5.0 threat types
TID 7.0
1.0 STRI
DE
TID 8.0
10.0
STRI
SR DE
2.0. TID
11.0 9.0
TID
4.0
STRI
3.0DE

Threats: Relevance
 Who uses the information? Managers use threats to
determine the security strengths of the system they are
responsible for. Security testers use threats and their
associated threat trees to test how well the system is resilient to
attacks. Further, threats can be used as a plan of attack for a
penetration test.
 How is the information collected? Persons
responsible for the system’s implementation and design are
good sources. However, it is best to also include persons who
did not work on the system during the threat modeling process.
They are often able to think more critically about the system.
Threats are later analyzed to determine if there are any
vulnerabilities associated with them. They provide the basis for
determining the strengths and weaknesses of the system.
Information
Use Scenarios
Entry Points

Dependencies
Assets
Implementation
Assumptions
Trust Levels
Analyze Threats/
Determine
External Security
Vulnerabilities
Notes
Data Flow
Diagrams /Process
Models
Internal Security
Notes
63
Determine if Vulnerabilities Exist
A Threat that has no (or insufficient)

mitigating factors results in a Vulnerability
—that is, something an attacker can
exploit.
For each Threat, determine if there are
sufficient protections. Enumerate those
that are Vulnerabilities.

64
Formulate Attacks
Using threat trees
Threat trees start with what an attacker might try to
do to or with a protected resource (threat), and create
a tree of conditions that must be met in order obtain
access to that protected resource.
Each condition can be translated to a test that can be
performed programmatically or confirmed via code or
design review. Conditions may or may not have
mitigation, but do have DREAD ratings.
Access to one protected resource can facilitate
access to others. Chaining threat trees can create
more complex attacks (“attack chaining”).

65
Tool: Threat Trees

Threat Trees (also called Attack Trees: Bruce Schneier,
Dr. Dobb's Journal December 1999, “Modeling Security
Threats”) are used in Threat Modeling to analyze how a
threat might be accomplished.
A threat tree is a hierarchical representation of
conditions, with the root node being the threat.
An attack path is a route from a leaf condition to the
root threat, inclusive of any and condition.
Threat Trees are used to determine valid attack paths
for a threat. That is, any attack path that does not have
a mitigating node is classified as a vulnerability.
In its most basic form, a Threat Tree consists of a
single Threat, and multiple Mitigated Conditions and
Unmitigated Conditions.

Tool: Threat Trees
67
Tool: Threat Trees

In the previous Threat Tree, Mitigated
Conditions are represented with white
boxes, and Unmitigated Conditions are
represented as orange boxes.
This example shows four possible attack
paths, of which only one (the path 1.3.2
-> 1.3 -> 1) has no mitigating nodes and
thus represents a valid attack or
vulnerability.

68
Sample: Threat Mitigations

Threat #1 (I)
Compromise
password
1.1 1.3 1.2

Access “in-use” Access password Guess password
password in database
1.3.1 1.3.2
1.1.1 1.1.2 1.2.1 1.2.2
Password is in Compromise
Sniff network ‘Phishing’ attack Password is weak Brute force attack
cleartext database
Store Salted Enforce strong

Encryption Education Hash passwords
1.3.2.1 1.3.2.2
SQL injection Access database
Application
Defenses
 Programming
Best Practice
attack directly
Infrastructure
Defenses
 Close ports 1.3.2.2.1
1.3.2.2.2
Weak db account
Enforce strong
Copyright Microsoft Corp. 2004 to Internet Port open passwords
password(s)
69
Using DREAD
DREAD is a method of characterizing the risk
associated with a vulnerability. It is an acronym for
the following categories, and is calculated as an
average of values assigned to each of:
Damage Potential. Damage Potential ranks the extent of the
damage that occurs if a vulnerability is exploited.
Reproducibility. Reproducibility ranks how often an attempt
at exploiting a vulnerability works.
Exploitability. Exploitability assigns a number to the effort
required to exploit the vulnerability, and also considers
preconditions (such as whether the user must be
authenticated).
Affected Users. Affected Users is a numeric value
characterizing the ratio of installed instances of the system
that would be affected if an exploit became widely
available.
Discoverability. Discoverability is the likelihood that, if the
vulnerability were to go unpatched, it would be found by
external security researchers, hackers, etc.
* Some information taken from Writing Secure Code, 2 Edition
nd

Tool: Vulnerabilities Table
Vulnerabilities
Vulnerability
ID 1
Name A user gains access to the administration interface.
Description If the default password is left unchanged, and the remote administration
interface is enabled, then remote anonymous users can easily obtain access to
the interface.
Denial of Service
DREAD Rating 7.6 (D: 10, R: 10, E: 8, A: 2, D: 8)
Corresponding Threat 1 (Adversary gains access to the remote administration interface resulting in
access to the phone configuration.)
Tool: Vulnerabilities Table
Vulnerabilities
Vulnerability
ID 2
Name A user takes advantage of the password ring buffer
Description If a user takes advantage of the fact that the password for the admin interface is
a ring buffer, the attack could take significantly less than 10^8 attempts
Denial of Service
DREAD Rating 3.8 (D: 10, R: 5, E: 1, A: 2, D: 1)
Corresponding Threat 1 (Adversary gains access to the remote administration interface resulting in
access to the phone configuration.)
72
Applying Risk
•Damage potential
Threat
•Affected Users
-or-
•Damage
Condition Condition
•Reproducibility
Condition Condition •Exploitability
•Discoverability
-or-
•Chance
Condition Condition Condition

Vulnerabilities: Relevance
 Who uses the information? Vulnerabilities are
entered as bugs for the system. Designers and
implementers must fix or mitigate these bugs.
Security testers can use vulnerabilities to look for
similar problems, or create regression tests.
 How is the information collected?
Vulnerabilities are collected by analyzing the
enumerated threats, and determining which threats
have insufficient mitigation. This can be done using
threat trees or other techniques.
 How is it used in the rest of the Threat
Model? Vulnerabilities are an output of the threat
modeling process.
74
Knowing when you are done
A complete model is one that explores all entry

points.
The model should also consider external
dependencies (i.e., are you dependent on file
system normalization matching your internal
normalization).
Threat models should include participation and
review by persons not familiar with the
components.

75
Knowing when you are done
If the component is not yet implemented,

an update to the threat model should be
done post-implementation.
Finally, models are done when there are
no more threats left that require further
investigation. It does not depend on the
number of vulnerabilities found.

76
Conclusion
Analyzing the security of an application is not simply

about finding security bugs.
Methodologies for analyzing the security in an
application are only recently appearing.
Threat Modeling takes into account all types of attacks
against the system.
While this sounds like an extensive amount of work and
that it would be easier to just look for vulnerabilities,
such an approach would not only be incomplete, but
would not be able to characterize the security strengths
of a system.

77
Additional Resources
http://www.microsoft.com/downloads/details.aspx?FamilyID
=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en

78
Questions?

79
Definitions

80
Definitions
System: Anything that exposes functionality to
an end user. It can describe anything from a
single feature to a web application and its
supporting infrastructure.
Entry Point: A location where an external entity
interfaces with the component and component
processing begins. Examples include any
accessible API, or a socket endpoint.

81
Definitions
Asset: Those things, both concrete and
abstract, that could be targets of an attack by
an adversary.
Trust Level: A classification for an external
entity that interfaces to a component or
supplies it with data. It describes the
characteristics of that entity that are relevant to
security processing, such as credentials and
assumptions.

82
Definitions
Threat Path: A data or processing flow that
starts at an Entry Point. Threat Paths diagram
the critical processing that an external entity
can cause to execute. Threat Paths also
contain security-specific information, such as
process and trust boundaries.
Threat: What a malicious external entity bound
to a specific Access Category might try to do to
attack the processing along a threat path. A
Threat does not constitute a Vulnerability

83
Definitions
Effect Classification: Categorization of
the result of an adversary realizing a
Threat. Example: STRIDE
Vulnerability: A weakness in a system
that can be exploited by an external
entity. A Vulnerability exists when there
is a Threat that goes unmitigated.

84
Definitions
Attack Path: In a threat tree, an attack
path is a path from a leaf condition to the
root threat, inclusive of any anded
conditions.
Threat Profile: An enumeration of all
potential threats to a system, regardless
of whether that system is vulnerable to
them.

85
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
© 2001 Microsoft Corporation. All rights reserved.

02 Threat Modeling

Uploaded by

Copyright:

Available Formats

02 Threat Modeling

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 Threat Modeling

Uploaded by

Copyright:

Available Formats

Threat Modeling

Copyright Microsoft Corp. 2004

What is Threat Modeling?

Copyright Microsoft Corp. 2004

External Identify Threats

External Identify Threats

Collect Background Information

Background information bounds the

Copyright Microsoft Corp. 2004

External Identify Threats

Identify Use Scenarios

External Identify Threats

Identify External Dependencies

External dependencies are requirements levied on

Copyright Microsoft Corp. 2004

External Identify Threats

Identify Implementation Assumptions

It is good to start the Threat Modeling process before a

Copyright Microsoft Corp. 2004

External Identify Threats

Identify External Security Notes

External Security Notes are the counterpart to external

Copyright Microsoft Corp. 2004

External Identify Threats

Identify Internal Security Notes

Internal security notes are information that

Copyright Microsoft Corp. 2004

External Identify Threats

Model the System

Modeling the system is critical to

Copyright Microsoft Corp. 2004

External Identify Threats

Identify Entry Points

Copyright Microsoft Corp. 2004

External Identify Threats

External Identify Threats

Identify Trust Levels

Trust levels characterize either entry points or

Identify Trust Levels

Trust Levels that have more

Copyright Microsoft Corp. 2004

External Identify Threats

Describe Processing on the Threat

The “Threat Path” is the processing that

Copyright Microsoft Corp. 2004

Describe Processing on the Threat

While a threat path can simply be described

Copyright Microsoft Corp. 2004

Auth Data Data Flow

* Diagrams taken from Writing Secure Code, 2nd Edition

Numeric keypad input Telephone

1.5 1.2 Read digit

External Identify Threats

Copyright Microsoft Corp. 2004

External Identify Threats

The team should not limit themselves to known

Copyright Microsoft Corp. 2004

Copyright Microsoft Corp. 2004

Copyright Microsoft Corp. 2004

Copyright Microsoft Corp. 2004