application threat modeling
TRANSCRIPT
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
OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling
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
OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling
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
OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling
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