OWASP Europe Conference 2008

Practical Threat Modeling for

Software Architects & System
Developers

Shay Zalalichin
CISSP, PCI:DSS QSA

AppSec Division Manager

OWASP Comsec Consulting

Copyright © The OWASP Foundation

Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.

The OWASP Foundation

http://www.owasp.org
Agenda

 Why Threat Modeling?

 System / Application Decomposition
 Threat Mapping
 Threat & Risk Rating
 Planning Threat Response & Mitigations
 Best Practices in TM

OWASP
Why Threat Modeling?

OWASP
What is Threat Modeling?

 A formal (or semi-formal) framework for

security-based analysis
 Identify, understand, and mitigate threats

 Can be practiced on both new applications

as well as on existing ones
We all know that it is much cheaper to
discover security bugs earlier …

OWASP
What is Threat Modeling? (Cont.)

 Should be used by Architects, Designers,

Developers & Security personnel

 (Usually) composed of the following phases:

Decomposition
Threat Mapping
Threat / Risk Rating
Threat Response & Mitigations

OWASP
Why Threat Modeling?

 Simple:
You cannot build a secure system until you
understand your threats

OWASP
Why Threat Modeling (Cont.)?
 Security-based analysis
 Find security bugs early (and complex bugs)
 Think about security in a (relatively) formal way
 Address threats in logical order according to
greatest risk
 Reduce overall risk by mitigating important threats
 How do you know when your application is
“secure enough”?

OWASP
Why Threat Modeling (Cont.)?

 Additional Benefits:
Helps better understand your application
 Complex interactions
Justification for security features and relation to
identified threat
Clearly documented assumptions and/or
consequences
Educational (e.g. new team members)
Testers can specifically test against known threats
Helps prevent duplication of security efforts

OWASP
System / Application Decomposition

OWASP
System / Application Decomposition

 Define scope
 Create an architecture overview
Function
Logical architecture
Physical deployment
Technologies
 Identify assets
 Mark trust boundaries
 Identify data flows, entry points, and
assumptions
 Make note of privileged code
OWASP
System / Application Decomposition

 Remember: The goal of security mechanisms is

covering your “assets”
 Assets could be:
Web pages Web pages
Sensitive data Sensitive data
Server resources Server resources
 Define asset CIA requirements:
Confidentiality
Integrity
Availability

OWASP
System / Application Decomposition

 Use modelling diagrams for a visual representation of

how the subsystems operate and work together
 The type of diagram is not important, but it should focus
on data and how it flows through the system
 For instance, DFDs and Use Cases are useful
 But don’t go too deep - 2 or 3 levels is enough

OWASP
System / Application Decomposition

 Create a security profile for the application

 Ignore inner workings when modelling the
architecture
 Note events or requests that the system
recognizes
 Notice data sources that relate to each request
and response
 Ascertain the recipient of each response

OWASP
Demo

OWASP
Threat Mapping

OWASP
Identifying Threats
 Analyze each aspect of the architecture/design
 Ask questions with regards to attacker goals
Can the user’s identity be spoofed?
Can data be accessed without authorization?
Can the system be easily blocked?
…
 Compare application to common threats
Are Cross-Site Scripting (XSS) attacks relevant?
Is canonicalization an issue?
Can user sessions be hijacked?
…
 Use structured methods to identify threats
OWASP
Identifying Threats (Cont.)

 To identify threats or goals, ask the following

questions:
How can the adversary use or manipulate the asset
to modify or control the system?
Retrieve information within the system?
Manipulate information within the system?
Cause the system to fail or become unusable?
Gain additional rights?
 Can the adversary access the asset -
Without being audited?
And skip any access control checks?
And appear to be another user?
OWASP
STRIDE Model

 A common model for classifying attacker goals is the

STRIDE model:
 Spoofing – Posing as another user, component, or external
system that should be identified by the system
 Tampering – Unauthorized modification of data
 Repudiation – Denying performing an action without the
system being able to prove otherwise
 Information Disclosure – Exposure of protected data to an
unauthorized user
 Denial of Service – Disallowing valid users to access the
system
 Elevation of Privileges – Gaining privileged access by a lower
privileged user

OWASP
Threat Trees
 Threat trees can be another useful method to explore valid
attack paths
 A threat tree represents conditions needed to exploit the
threat
 Threat trees are used to determine all the combined
vulnerabilities associated with a threat
 Focus on mitigating the vulnerabilities that form the “path of
least resistance”

OWASP
Identifying Threats

 Each threat should be documented with:

Title
Target component
Threat type(s) (e.g. STRIDE)
Attack techniques (e.g. threat tree)
Risk
Mitigation

OWASP
Demo

OWASP
Threat & Risk Rating

OWASP
Rating Threats and Risk

 How do I measure risk?

Use a structured methodology
Predefine general values to avoid confusion
 Record the calculated risk
 Simple formula:
Risk = Probability * Damage Potential
Define expected damage for each value
Divide scale in three bands: High, Medium, Low
Simple, yet lacking dimension
Not always easy to agree…

OWASP
DREAD Model

 Another method for determining risk is

the DREAD model:
Damage potential – How great is the damage if the
vulnerability is exploited?
Reproducibility – How easy is it to reproduce the attack?
Exploitability – How easy is it to launch an attack?
Affected users – As a rough percentage, how many users are
affected?
Discoverability – How easy is it to find the vulnerability?
 Risk = Min(D, (D+R+E+A+D) / 5)
 Agree beforehand on values of each factor
OWASP
Demo

OWASP
Planning Threat Response & Mitigations

OWASP
Vulnerability Resolution and Mitigation

 Threats can be resolved by:

Risk Acceptance - doing nothing
Risk Transference - pass risk to an externality
Risk Avoidance - removing the feature/component
that causes the risk
Risk Mitigation - decrease the risk
 Mitigation strategies should be examined for
each threat
 Mitigations should be chosen according to the
appropriate technology
 Resolution should be decided according to risk
level and cost of mitigations
OWASP
Demo

OWASP
Best Practices in TM

OWASP
Best Practices in TM

 Use structured & consistent methodologies

 Predefine and agree on risk ratings that work for
you
 Include all relevant shareholders in TM
discussions:
Security
Architecture / Design
Coding
Testing
 Don’t let TM discussions to degenerate to finding
solutions before the threats have been fully
identified

OWASP
Best Practices in TM (Cont.)

 Don’t model too deep – don’t get carried away in the

details
 Document TM results so they could be used later on for:
 Next versions
 Similar products / systems
 Education
 Use common attack libraries / patterns for consistency
and additional ideas
 For example:
 http://www.owasp.org/index.php/Category:Attack

 Always remember – its never too late for Threat

Modelling!

OWASP
Questions?

OWASP