This presentation is part of one of talk, I gave in Microsoft .NET Bootcamp. The contents are slightly edited to share the information in public domain. In this presentation, I covered the significance and all related theory of Threat modeling and analysis.This presentation will be useful for software architects/Managers,developers and QAs. Do share your feedback in comments.

1. Application Security-II
Threat Modeling and Analysis
Lalit Kale
lalitkale@gmail.com
http://lalitkale.wordpress.com

2. Overview
•
Introduction
•
Why Threat Modeling?
•
Application Decomposition
•
Threat Mapping
•
Calculating Risks
•
Planning Threat Response & Risk Mitigations
•
Best Practices in Threat Modeling
•
Tools
•
Resources
2

3. Introduction-Basic Terminology
•
Asset: A resource of value, such as the data in a database or on the file system. A system resource.
•
Threat: A potential occurrence, malicious or otherwise, that might damage or compromise your
assets.
•
Vulnerability: A weakness in some aspect or feature of a system that makes a threat possible.
Vulnerabilities might exist at the network, host, or application levels.
•
Attack (or exploit): An action taken by someone or something that harms an asset. This could be
someone following through on a threat or exploiting a vulnerability.
•
Countermeasure: A safeguard that addresses a threat and mitigates risk.
3

4. What is Threat Modeling?
•
A Strategic framework for planning application security aspect in
system design phase
•
Identify, understand, and mitigate threats most likely to affect the
system
•
Can be practiced for both new applications as well as on existing ones
4

5. Why Threat Modeling?
•
Cannot build a secure system until you understand threats to system
•
Find security bugs early (and complex bugs)
•
Address threats in logical order according to greatest risk
•
Reduce overall risk by mitigating important threats
•
How do you know when application is “secure enough”?
5

6. Why Threat Modeling?
•
Helps better understand your application
•
Justification for security features and relation to identified threat
•
Clearly documented assumptions and/or consequences
•
Testers can specifically test against known threats
•
Helps prevent duplication of security efforts
6

7. Threat Modeling in Microsoft SDL
7

8. Types of Threat Modeling
•
Attacker Centric
•
•
Software Centric
•
•
Starts with an attack and evaluates the goals and how attackers might achieve
them
Starts from the design of system and attempts to step through a model of
system, looking for types of attacks against each element of the model
Asset Centric
•
Involves starting from assets entrusted to a system, such as a collection of
sensitive personal information
8

9. Threat Modeling Phases
Application
Decomposition
Threat
Mapping
Threat / Risk
Rating
Threat
Response &
Mitigations
9

10. Application Decomposition
•
Threat Response
& Mitigations
For instance, DFDs and Use Cases are
useful
•
Threat / Risk
Rating
The type of diagram is not
important, but it should focus on data
and how it flows through the system
•
Threat Mapping
Use modelling diagrams for a visual
representation of how the subsystems
operate and work together
•
Application
Decomposition
But don’t go too deep - 2 or 3 levels is
enough
10

11. Application Decomposition
1.
Logical architecture
5.
Physical deployment
6.
Technologies
7.
Identify assets
8.
Mark trust boundaries
9.
Identify data flows, entry points, and assumptions
10.
Threat Response
& Mitigations
Function
4.
Threat / Risk
Rating
Create an architecture overview
3.
Threat Mapping
Define scope
2.
Application
Decomposition
Make note of privileged code
11

12. Identifying Threats
•
Threat Response
& Mitigations
Compare application to common threats
• Are Cross-Site Scripting (XSS) attacks relevant?
• Is canonicalization an issue?
• Can user sessions be hijacked?
• …
•
Threat / Risk
Rating
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?
• …
•
Threat Mapping
Analyse each aspect of the architecture/design
•
Application
Decomposition
Use structured methods to identify threats
12

13. Identifying Threats
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
Threat Response
& Mitigations
•
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?
13

14. STRIDE Model
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
Threat Response
& Mitigations
•
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
14

15. Threat Tree
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
Threat Response
& Mitigations
•
Method to explore valid attack paths
•
Represents conditions needed to exploit the threat
•
Determine all the combined vulnerabilities associated with a threat
•
Focus on mitigating the vulnerabilities that form the “path of least resistance”
15

16. Documenting Threats
•
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
Threat Response
& Mitigations
Each threat should be documented with
1. Title
2. Target component
3. Vulnerability Categorization(s) (e.g. STRIDE)
4. Attack techniques (e.g. threat tree)
5. Risk
6. Mitigation
16

17. Calculating Risks: RPD Model
•
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
Threat Response
& Mitigations
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…
17

18. Calculating Risks: DREAD Model
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
•
Another method for determining risk is 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)
•
Threat Response
& Mitigations
Agree beforehand on values of each factor
18

19. Threat Resolution & Risk Mitigation
•
Application
Decomposition
Threat Mapping
Threat / Risk
Rating
Threat Response
& Mitigations
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
19

20. Best Practices in Threat Modeling
•
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
20

21. Best Practices in Threat Modeling
•
Don’t model too deep – don’t get carried away in the details
•
Document TM results so they could be used later on for:
•
•
Similar products / systems
•
•
Next versions
Education
Use common attack libraries / patterns for consistency and additional ideas
e.g.
http://www.owasp.org/index.php/Category:Attack
•
Always remember – its never too late for Threat Modeling!
21

22. Threat Modeling Tools
•
The Threat Analysis and Modeling Tool (TAM):
•
is an asset-focused tool designed for LOB applications.
•
It is used for applications for which business objectives, deployment
pattern, and data assets and access control are clearly defined.
•
The focus of the tool is to understand the business risk in the
application, help identify controls needed to manage that risk, and
protect the assets.
22

23. Threat Modeling Tools
•
The SDL Threat Modeling Tool:
•
is a software-focused tool designed for rich client/server application
development (for example, Windows and SQL Server, among others)
•
The tool assumes the final deployment pattern of the product is unknown
(that is, if it will be used to manage business-critical applications with
customer credit cards or not), so the focus of the tool is to ensure security
of the software’s underlying code.
23

24. Summary
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
Threat Mapping
•Identifying Threats
•Use STRIDE Model
•Creating Threat Tree
•Documenting each Threat
Calculate Risks
•Use Risk = Probability *
Damage Potential
•Use Risk =
Min(D, (D+R+E+A+D) / 5)
Threat Resolution and Risk
Mitigation
•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
24

25. Resources
•
OWASP (Open Web Application Security Project):
https://www.owasp.org
•
Microsoft Security:
http://www.microsoft.com/security
http://www.Microsoft.com/sdl
•
Wikipedia:
http://en.wikipedia.org/wiki/Threat_model
25

26. Lalit Kale
lalitkale@gmail.com
http://lalitkale.wordpress.com
.
This presentation is shared under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license. More information for this license is available at http://creativecommons.org/licenses/by-nc-sa/4.0/
All trademarks are the property of their respective owners. Lalit Kale makes no warranties, express, implied or statutory, as to the information in this presentation.