Application Threat Modeling

Copyright 2008 © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

OWASP

http://www.owasp.org

Managing Software Security Risks Using Application Threat Modeling

Marco M. Morana

Cincinnati Chapter

2OWASP

Agenda1. Application Threat Modeling (ATM)

Use cases and definitions, risk models, benefits, security flaws vs. bugs

2. ATM as Architecture Design Review Use And Misuse Cases, Data Flow Diagrams

3. ATM as Threat Analysis Attack Libraries and Attack Trees

4. Other ATM Methodologies: Microsoft5. OWASP Threat Risk Modeling Step By Step6. Risk Management And Risk Strategy7. Q&A8. References

3OWASP

Why Application Threat Modeling?

Security Design Flaws Are Prevalent:Security design flaws account 70% of the defects

being analyzed and among them about 47% being of medium and high business impact and easily exploitable (2002 study from @stake)

76% of more than 200 bank websites had at least one security design flaw (2008 University of Michigan study)

Fixing Design Flaws Is Expensive:The cost of fixing a flaw during design is 7 times

cheaper than during implementation and 100 times cheaper then during production (IBM Systems Sciences Institute study)

4OWASP

Threat Modeling DefinedA systematic & strategic approach for

enumerating threats to an application environment, with the objective of minimizing risk and associated impact levels to the business

Methodologies: Define a repeatable process that consistent results with the help of tools( e.g. MS AC, TRIKE, OWASP)

Different Approaches to categorize threats, find vulnerabilities and determine countermeasuresOffensive: STRIDE/DREADDefensive: Application Security FrameAsset Centric: Confidentiality, Integrity, Availability

5OWASP

Who Benefits Threat Modeling Threat modeling provides different benefits to

the project stakeholders depending on their role and responsibility:ArchitectsDevelopersSecurity TestersProject ManagersBusiness Managers Information Risk Officers

6OWASP

ATM and Application Security Assessments

Security Design Flaws Introduced because of lack of security

requirements, errors in design, lack of secure design knowledge, lack of architecture design review

Cannot be identified by tools since lack contextual knowledge of the application

Can be identified with threat modeling/secure architecture reviews

Security Coding BugsCoding errors that result in vulnerabilitiesCan be identified with source code analysis and

toolsRequires developers understanding secure coding

and following secure coding standards

7OWASP

Application Threat Modeling In the SDLC

Threat Modeling in the SDLCD

esig

nD

esig

nD

evel

opm

ent

Dev

elop

men

tT

estin

gT

estin

gD

eplo

ymen

tD

eplo

ymen

tD

efin

ition

Def

initi

on Use and Abuse Cases

Security Requirements

Threat ModelingData Flow Diagrams

Attack Trees

Secure Code Reviews

Security Integrated Testing

Vulnerability Assessments

(User Acceptance Test)

Secure Architecture

Modeling

Secure Coding Standards

Secure Configuration &

Installation

Security Testing Guidelines

(System Tests)

Secure Requirements Engineering

Security Testing Guidelines (Unit

Tests)Security Unit

Testing

Vulnerability Assessments (Production)

From Insecure Magazine, http://www.net-security.org/dl/insecure/INSECURE-Mag-17.pdf

8OWASP

ATM During Requirement Phase: Use and Abuse Cases

User

Hacker/Malicious User

Brure ForceAuthentication

Enter Username andpassword

Validate PasswordMinimum Length and

ComplexityApplication/Server

Includes

Mitigates

User Authentication

Includes

Includes

Includes

Mitigates

Threatens

Show Generic ErrorMessage

Includes

Includes

Lock Account After N.Failed Login Attempts

Harverst (e.g. guess)Valid User Accounts

Dictionary Attack

Mitigates

Mitigates

https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation

9OWASP

ATM During The Design Phase: Architecture Analysis

From Insecure Magazine http://www.net-security.org/dl/insecure/INSECURE-Mag-17.pdf

10OWASP

ATM During Development & Validation

Threat Modeling and Secure Code ReviewsBread First vs. Depth FirstSecurity flaws vs. security bugs

Threat modeling and secure coding standardsMap threats to vulnerabilitiesDocument countermeasures

Threat Driven Security TestsUse and Misuse Cases for Security Test CasesUnit Tests, Integrated System Tests, User

Acceptance Tests

11OWASP

ATM And Application Threat Analysis

Methodology To Investigate Threats and Attacks in existing applications, determine risks and make informed decisions

Attack LibrariesAttack TreesUse and Misuse CasesData Flow Diagrams

Risk Driven Security TestsValidate Attack Scenario Identify VulnerabilitiesRecommend Countermeasures

12OWASP

Attach Tree Theory

Bruce Schneider, Attack Trees: http://www.schneier.com/paper-attacktrees-ddj-ft.html

13OWASP

Attack Tree Bank Account Attack Example

Analyzing the Security of Internet Banking Authentication Mechanisms : http://www.itgi.org/Template.cfm?Section=Home&CONTENTID=35743&TEMPLATE=/ContentManagement/ContentDisplay.cfm

14OWASP

Attack Trees And Attack Analysis: Passwords

Password Management Concerns with IE and Firefox, part one http://www.securityfocus.com/infocus/1882/2

15OWASP

Microsoft Application Threat Modeling

MS TM Blog: http://blogs.msdn.com/threatmodeling/archive/2006/03/16/553232.aspx

16OWASP

OWASP Threat Risk Modeling

OWASP Threat Risk Modeling http://www.owasp.org/index.php/Threat_Risk_Modeling

17OWASP

Step 1: Identify Security Objectives

Tactical Security Assessments Identification of Security Flaws, the Threats

that can exploit them and the mitigations Secure Architecture Reviews

Requirements, Decomposition, Threat Mapping, Threat Response & Mitigations

Threats and Countermeasures, Risk Mitigation Strategy

Application Risk ManagementTechnical Risk and Business RiskRisk Mitigation Strategy

Mitigate, Transfer, Accept it

18OWASP

Step 2: Application Overview

Walkthrough: Creating a Threat Model for a Web Application http://msdn.microsoft.com/en-us/library/ms978538.aspx

19OWASP

Step 3: Decompose the Application

Objective: understand the application and how it interacts with external entities. Create Use Cases Identify Entry Points Identify Assets

Outcome: Data flow diagrams (DFD) for the application show the different paths through the system highlighting the privilege boundaries.

20OWASP

Understanding the Application: Data Flow Diagrams

OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling

21OWASP

Step 4: Threat Identification

Objective: Use a systematic approach to identify the application exposure to threats Threat Lists (STRIDE, ASF) Use and Misuse cases Attack Trees

Outcome: List of threats relevant to the application environment, the hosts and the application tiers

22OWASP

Threat Analysis: Holistic View

Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/en-us/library/ms994921.aspx

23OWASP

Threat Categorization: ASF Threat List

https://www.owasp.org/index.php/Application_Threat_Modeling

24OWASP

Threat Categorization: STRIDE Threat List


25OWASP

Step 5: Vulnerability Identification

Objective: Identify un-mitigated threats (e.g. threats with no countermeasures) Use and Misuse cases Threat Tree Threat-Countermeasure Lists (STRIDE, ASF)

Outcome: threat profile describing each security application flaw in terms of the threat impacting it, the host, tier, component impacted the vulnerability being exposed and the suggested mitigation control/countermeasure.

26OWASP

Threats And Vulnerability Conditions: Threat Trees


27OWASP

Countermeasure Identification

https://www.owasp.org/index.php/Application_Threat_Modeling

28OWASP

Threats and Mitigation Techniques

29OWASP

Threat and Risk Ranking

Threats can be classified (e.g. ranked) according to risk factors to support risk mitigation decision making strategy


30OWASP

Rating Threats and Risk

How do I measure risk?Use a structured methodologyRisk = Threat X Vulnerability x Asset

Practical Threat Analysis for the Software Industry: http://www.securitydocs.com/library/2848/2

31OWASP

Rating Threats and Risk

Simple formula: Risk =Probability (Degree of Mitigation, Exploitability) * Impact (Damage Potential)

Guidelines for risk management http://www.qaa.ac.uk/aboutus/policy/RiskGuidelines.asp

32OWASP

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)TM For Application Designers and Archietcts http://www.owasp.org/index.php/OWASP_AppSec_Europe_2008_-_Belgium

33OWASP

Threat Modeling and Risk Decision Making Threats can be resolved by:

Risk Acceptance - doing nothingRisk Transference - pass risk to an externalityRisk Avoidance - removing the

feature/component that causes the riskRisk 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

34OWASP

Risk Mitigation Strategy Best Practices

General Objectives: Translate the identified technical risk issues into

business risk issues Determine whether standards compliance is

violated Determine whether other compensating

security controls and mitigation factors are present

Determine which protective measure (e.g. security control, policy measures) should be in place to mitigate the threat, how should be implemented and when

Determine short term and long term solutions

35OWASP

Application Risk Management Best Practices Eliminate vulnerabilities before they become liabilities

Manage the risks of serious financial loss, negative publicity, legal liability, loss of contracts, erosion of market share, degraded performance or other serious business impact as a result of a failure in security

Set, enforce and report that software assurance thresholds are maintained

Measurable reports prove progress internally and for compliance

36OWASP

Q&Q U E S T I O N SQ U E S T I O N SA N S W E R SA N S W E R S

Technology

Application Threat Modeling