26
Application Security- II Threat Modeling and Analysis Lalit Kale [email protected] http://lalitkale.wordpress.com

Threat Modeling And Analysis

Embed Size (px)

DESCRIPTION

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.

Citation preview

Page 1: Threat Modeling And Analysis

Application Security-IIThreat Modeling and AnalysisLalit Kale

[email protected]

http://lalitkale.wordpress.com

Page 2: Threat Modeling And Analysis

2

Overview

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

Page 3: Threat Modeling And Analysis

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.

Page 4: Threat Modeling And Analysis

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

Page 5: Threat Modeling And Analysis

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”?

Page 6: Threat Modeling And Analysis

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

Page 7: Threat Modeling And Analysis

7

Threat Modeling in Microsoft SDL

Page 8: Threat Modeling And Analysis

8

Types of Threat Modeling• Attacker Centric

• Starts with an attack and evaluates the goals and how attackers might achieve them

• Software Centric• 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

Page 9: Threat Modeling And Analysis

9

Threat Modeling Phases

Application Decomposition

Threat Mapping

Threat / Risk Rating

Threat Response & Mitigations

Page 10: Threat Modeling And Analysis

10

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

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 11: Threat Modeling And Analysis

11

Application Decomposition

1. Define scope

2. Create an architecture overview

3. Function

4. Logical architecture

5. Physical deployment

6. Technologies

7. Identify assets

8. Mark trust boundaries

9. Identify data flows, entry points, and assumptions

10. Make note of privileged code

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 12: Threat Modeling And Analysis

12

Identifying Threats• Analyse 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

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 13: Threat Modeling And Analysis

13

Identifying Threats• 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?

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 14: Threat Modeling And Analysis

14

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

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 15: Threat Modeling And Analysis

15

Threat Tree• 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”

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 16: Threat Modeling And Analysis

16

Documenting Threats• Each threat should be documented with

1. Title2. Target component3. Vulnerability Categorization(s) (e.g. STRIDE)4. Attack techniques (e.g. threat tree)5. Risk6. Mitigation

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 17: Threat Modeling And Analysis

17

Calculating Risks: RPD Model• 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…

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 18: Threat Modeling And Analysis

18

Calculating Risks: DREAD Model

• 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)

• Agree beforehand on values of each factor

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 19: Threat Modeling And Analysis

19

Threat Resolution & Risk 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

Application Decomposition

Threat Mapping

Threat / Risk Ratin

g

Threat

Response & Mitigations

Page 20: Threat Modeling And Analysis

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

Page 21: Threat Modeling And Analysis

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:• Next versions• Similar products / systems• 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!

Page 22: Threat Modeling And Analysis

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.

Page 23: Threat Modeling And Analysis

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.

Page 24: Threat Modeling And Analysis

24

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

Summary

Page 25: Threat Modeling And Analysis

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

Page 26: Threat Modeling And Analysis

.

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.

Lalit [email protected]

http://lalitkale.wordpress.com