Threat Modeling WebApps for Risk Mitigation

Tony UcedaVelez, Managing DirectorVerSprite – Navigate Beyond Risk

Sea of Issues Across Web App Development & Management

• Platform and Web Server software security standards not incorporated

• A lot of good resources out there, so why aren’t we incorporating them?

• Do technologists understand what they are securing?– Awareness Deficit

Continues

3

Standards, Frameworks, & Shelf ware

• Security awareness continues to grow-good!– Right direction– Developer heavy– What about all the SysAdmins?

Network Engineers?

• Threat Awareness is next level– ‘We understand what we have to do,

but why?’ –Developer

• Healthy balance of security and threat awareness

• Results from Static/Dynamic Analysis add fire to remediation tables and change mgt workflows– Doesn’t mean we stop doing these

efforts– The question is, how do we articulate

risk to different audience members? 4

Right Direction Falling Short

4

Security Perception

PerceivedThreats

Remediation Pill

• “Us vs. Them” (Security & Dev/IT) Problem

• Demonstrating Threats & Mitigation Techniques is Absent

• Remediation is drudgery• Summary: Does not foster

collaboration amongst those whose ID risk and those who mitigate it.

5

Adversarial Approach to Mitigation

Navigating to Strategic Solutions in Web Application Security

7

Application Threat Modeling for the Masses

• Identify probable threats based upon motives• SDLC Integration

– Migrating from understanding perceived security to perceived threats

• Evolution of the attack plan to the web app environment– Thinking like an attacker across the app environment– Conceptualize likely attacks based upon motives and

identified attack vectors

8

Integrating the What Could Happen ?

• Vulnerability Assessment results reveal areas of weakness

• Pen Testing results provide probabilistic values for exploiting identified vulns

• Dynamic/ Static Analysis results for vulnerable code and program objects

• Social Engineering exercises reveals security un-awareness

• Automated Software Testing of Misuse Cases/ Exploits

9

Integrating the What Does/ Did Happen ?

• Key missing element that is not shared to those responsible for risk mitigation

• Leverage existing security info & analysis • Security Incident Data Feeds• Intrusion Prevention/ Detection Systems• Firewalls • Host Based Agents• Web Application Firewalls (WAFs)

10

Understanding the What We Have?• Security Governance in Action via technology guidelines &

standards – Governance at work!• Standards as countermeasures for application / platform/

network related threats• Identifying what technology controls are present

• Web Server (ModSecurity, HTTP Authentication, W3 Security Extensions)

• Platform/ Application Level (Server Hardening, Segregating the Web Sites, Signed Libraries, Programmatic checks, delete default content, unrelated to domains, etc)

• Network Infrastructure (Firewall rules for ingress/ egress traffic across trust boundaries)

• Reducing the cost of remediation $$$

• Reducing Exception Handling & Change Mgt Time Investments $$

• Extend Security Awareness to encompass Threat Perception $

• Security => Efficiency $$$

11

Tailored Countermeasures = Strategic Risk Mitigation

This has the perfect amount of

countermeasures!!!

Taxonomy of Terms

13

Actors/ Assets (Targets)

• End users that use thick, thin client applications (userID: bsmith, sue.taylor, etc)

• System administrators who regularly interact/ support any part of the application ecosystem

• Identified via Data Flow Diagramming (DFD)• Application accounts used for automated or batched

APIs or data interfaces• Threat modeling terminology lends from Risk

Management, Software Development, and IT Architecture

14

Roles & Privileges • Rights awarded to pre-defined groups or users

for application • Addresses issues related to impersonation,

federated identities in applications • C.R.U.D analysis (rights to Create, Read,

Update, and Delete) across use cases • Under what security context do you handle

report creation, authentication, sensitive transactions, delete account, etc?

15

Use/ Misuse Cases

• Allows for use cases to be built from functional & security requirements – fat apps are vulnerable!

• Defines branches in attack tree to which attacks, vulns, exploits are correlated

• Defines how the apps can be used & misused • Business logic formerly addressed as part of

threat modeling

• Vuln libraries equally important to threat model

• Relationship of vulns to assets (platform/ software, information) needs to be mapped

• Legacy yet imperfect vulnerability management stalled by remediation– Leverage existing vuln scanning

efforts into threat modeling workflow

– Catalyzing remediation via illustration of attacks

16

Vulnerabilities

Likely vs. Unlikely Attack Vectors

Web App

Use Case

Misuse Case

Vuln

Use Case Vuln

• Attacks: misuse cases/ exploits that target a web app– Fueled by motive

• Attack vectors: channels for which attacks can be introduced

• ‘Walking’ the app allows for threats to be ID-ed while understanding motives

• Identify likely attack scenarios based upon threat feeds & observed incidents– Collaborative Security

• Building an Attack Library is key to effective Threat Model– Attack base used to map to use/

misuse cases & vulns17

Attacks/ Attack Vectors

Web App

Use Case

Misuse Case

Vuln Attack

Use Case Vuln Attack

18

Exclude Unlikely Attacks

Debate on what is likely vs unlikely

19

Countermeasures

• Mitigate risk of successful attacks

• Developed based upon residual risk

• Traverses all layers of the application environment and asset (platform and software)

• Protection against real risk areas

20

Data Flow Diagramming (DFD)

• Exercise to connect the dots for APIs and other data interfaces• Maps out data interfaces across application

layers (presentation, app, data, etc)• Maps out relationship amongst actors, assets,

data sources, trust boundaries, and eventually the variables of the attack tree

• Incorporates actors and assets as data flow start & end points

21

Trust Boundaries• Boundaries that define where trust exist and to what degree

• Determination on what level of validation to use within and across trust boundaries

• Less vulnerability based and more paranoia or preventative based• Adds an extra layer of security strategy that is based upon

preventive measures of what could happen• Who is requesting this data?• Are they authorized?• What is the expected output• Has their ID been validated by a trusted third party?• Allows for the consideration of new threats (privilege

escalation, etc) and countermeasures (authentication controls) that relate to trust amongst application calls

Methodology

23

Methodology•Identify Business Objectives•Identify Security Objectives•Business Impact Analysis1. Define Objectives

•Understanding application boundaries•Identify application interfaces and communication protocols•Data Flow Diagramming Exercises or Software Modeling•ID process boundaries that affect application environment

2. Scope Definition

•Use Cases•Actors•Data Sources/ APIs•Assets

3. Application Decomposition

•Probabilistic attack scenarios •Qualify attack scenarios•Define countermeasures where appropriate4. Threat Analysis

•Technology vulnerabilities mapped to application components•Use case to misuse case mapping•Vulnerabilities with technical requirements•Business logic vulnerabilities

5. Vulnerability Mapping

•Use to Misuse Case Mapping•Asset to vuln matching•Vulnerability - Exploit Matching6. Attack Tree

•ID risk mitigation strategies•Integrate metrics for financial impact•Qualify/ quantify business impact7. Risk & Impact Analysis

First a brief Definition: Decomposing an application in order to identify attack vectors and software vulnerabilities for the purpose of applying effective countermeasures.

• OWASP simplified methodology– Functional and mostly

geared for security centric threat models

– Excludes more risk based analysis

– Threat analysis takes place at different levels

24

Simplified Methodology

25

Key Components to Threat Modeling

• Steps 3,4,5,6 equate to ‘secret sauce’• Step 3: App Decomposition allows for greater

understanding of app to all involved parties (threat modeler, developers, architects, sys admins)

• Step 4: Vuln Mapping integrates unmanaged vulnerabilities in order to ID a window for an exploit. Something to worry about.

• Step 5: Attack Tree evolves beyond the theoretical to lets let our guys try to exploit this

• Step 6: Threat Analysis shows the net effect of vulns * attacks - countermeasures

26

Tailoring Methodology to Approach

• Three distinct approaches to threat modeling:1. Software Centric – Concentrates on the security of

software for an evaluated web app2. Asset Centric – Focused on more risk based

approach to application threat modeling3. Security Centric – Addresses security and technical

risks to threats revealed by application threat model• No one is better, different strokes for different folks

⁻ Legitimate use cases for each type of approach⁻ Largely dependent on org culture and audience

Hype Mitigation

28

Beyond The Hype

• As with any new buzz in security, its not long before a good thing mutates in meaning and application

• Not a replacement for other traditional application assessments – Risk assessments have their place for ongoing risk

analysis of deployed application environment– Pen Testing, Social Eng, Static/ Dynamic analysis are not

comparative alternatives to threat modeling• Traditional app and network assessments are embellished

by the Threat Model Methodology in different ways

29

Threat Modeling Methodology Myths

• No widely accepted methodology exists today.• By widely, we simply mean no organization has

defined and patented a threat modeling • STRIDE & DREAD are not methodologies, threat

and risk classifications respectively• Threat modeling is not all just about improved

software design• Depends on approach• Asset (risk), Software, Security Centric

30

Not Another Silver Bullet

• Aimed at elevating the predictive nature of risk analysis by understanding viable threats and attack patterns for apps

• Still warrants and depends on auxiliary processes and disciplines across security, compliance, and IT– Vuln mgt, – Business impact analysis, – Security governance (policy/ standard mgt), – Incident analysis & response, – DLP solutions, – Network Operations

• Requires a collaborative work environment– Barriers to information gathering poses a problem

Applicability & Use

32

Using Use Cases to ID Misuse Cases

• Every function has a potential dysfunction; need to enumerate and test application functions

• Listing of vulns for mapping can originate from subscribed vulnerability feeds/ vulnerability signatures from vendors

• Some Sources: SecurityFocus, US-CERT,MITRE, Microsoft

• Map vulns to employed platforms and software technologies

• Attack tree begins to take shape

33

Mapping Use Cases to Misuse 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

34

Threat Identification is Key• Enumerate threats and impact to application components

− Threats based upon known intel − Prior assessment info (where applicable & useful)− Other application assessments

− PII theft− XSS− SQL Injection− MITM

− Sabotage driven threats− CMS exploits to web application (Zope, Joomla, Mambo, etc)− FTP Brute Force attacks− iFrame Injection attacks

− Malware upload• Identify most likely attack vectors

– Address entire application footprint (email, client app, etc)– Web Forms/ Fields– WSDLs/ SWF Objects– Compiled Libraries/ Named Pipes

Threat Modeling Web Apps via SDLC• Asset based threat model is able to address inherent

and new risks that should be mitigated based upon baseline of info.

– Pen Tests, Risk Assessments, Compliance Audits, etc– Business Risk Mitigation Key

• Software based threat models will build upon understood threats to software environ

– Comparable web apps, prior static/ dynamic analysis, and other web app assessments

– Safeguarding software integrity is key and fosters building security in

• Security centric threat model focused on security of web application environment

– More focused on attack identification and applying countermeasures

• PMs, business analysts, business owners devise functional requirements (Definition Phase)

• Architects and IT Leaders speak to architectural design and platform solutions (Design Phase)

• Governance leaders inject compliance & standards requirements for during he design phase; BIA

• Threat Model* (SOC/ NOC fed), DFDs Introduced, Trust Boundaries defined, Countermeasures proposed

Define•Biz Objectives•The C Word

Design•Security Arch•Security Frameworks•AntiSamy (Java, .NET)•OWASP ModSecurity

Develop•OWASP Top 10•OWASP Development Guide•ESAPI•OWASP Dev Guide/ OWASP .NET Project

Test (QA)• ASVS (3rd Party Dev)• OWASP Testing Guide (Internal)

35

^ Threat Model v

36

Dev to Secure Dev via Threat Modeling

• Developers now more aware of potential threats– Security Aware and Perception of Threats to Web Apps– Easier for them to understand applicability to their

development efforts • Countermeasures developed within applications

– Validation Checks– Reduced Privs– Proper encoding techniques – Parameterized queries – Countermeasures based upon actual threats or risk as

revealed by threat model

• Balance of functional and secure code (development)• Balance of functional and security testing (QA)

– Rising trend to leverage QA as security testing group– QA tests functional features; scope creep in use

cases– Apply fuzzing techniques across different APIs

(web services)– Reverse engineering workflow for compiled SWF

files• Threat modeler creates a workflow for secure

development & testing for:− config flaws, logic flaws, bad design, escalation

flaws, authentication weaknesses, insecure communication, etc

• Threat modeler facilitates threat awareness to both groups– Application Decomposition– Illustrating Attack Tree

37

Split Personality to Web Development

Security Dr. Jekyll & Mr. Hyde

38

Identifying Attack Vectors for Web AppsDefined Threat

Attack Vector

Attacks

ExploitsMissing components:• Assets (Targets)• Actors• Vulnerabilities• Impact Levels

Missing attack vectors:• Email• Mobile Environments• Web Services• Inside Threat*

39

Vuln & Attack Library Buildout

• Exploitation is the proof. We all need proof.

• Given time constraints, partial exploits may be acceptable; educating that attacks are layered.

• Exploitation may address identified vulns, business logic flaws, and/ or non-published vulnerabilities

• Content management for vuln and attack library a key to effective Application Threat Modeling

Vulns Attacks

MITM

XML Injection

Repudiation Attack

Unencrypted Connection Strings w/ SQL Auth

FrontPage Extension Vulns

40

Managing & Mapping Vulns to Attacks

• Content & interop is key• Need to pull vuln and attack libraries

from notable sources• OWASP, MS, and MITRE have lists

from which to leverage as vuln and attack libraries

• Threat feeds from Sophos, TrendMicro, Symantec, etc can work as well

• Libraries used to map to assets, application components, and use cases for assessed web application

• With MITRE, why CWEs make more sense for Threat Modeling than CVE for content

41

OWASP Vuln Listing

42

Attack Pattern Schema - CAPEC

43

MITRE CWE Cross-Section:20 of the Usual Suspects

• Absolute Path Traversal (CWE-36)• Cross-site scripting (XSS) (CWE-79)• Cross-Site Request Forgery (CSRF) (CWE-352)• CRLF Injection (CWE-93)• Error Message Information Leaks (CWE-209)• Format string vulnerability (CWE-134)• Hard-Coded Password (CWE-259)• Insecure Default Permissions (CWE-276)• Integer overflow (wrap or wraparound) (CWE-190)• OS Command Injection (shell metacharacters) (CWE-78)• PHP File Inclusion (CWE-98)• Plaintext password Storage (CWE-256)• Race condition (CWE-362)• Relative Path Traversal (CWE-23)• SQL injection (CWE-89)• Unbounded Transfer ('classic buffer overflow') (CWE-120)• UNIX symbolic link (symlink) following (CWE-61)• Untrusted Search Path (CWE-426)• Weak Encryption (CWE-326)• Web Parameter Tampering (CWE-472)

44

MITRE CWE Cross-Section:22 More Suspects

•Design-Related• High Algorithmic Complexity (CWE-407)• Origin Validation Error (CWE-346) • Small Space of Random Values (CWE-334) • Timing Discrepancy Information Leak (CWE-208) • Unprotected Windows Messaging Channel ('Shatter') (CWE-422)• Inherently Dangerous Functions, e.g. gets (CWE-242)• Logic/Time Bomb (CWE-511)

•Low-level coding• Assigning instead of comparing (CWE-481)• Double Free (CWE-415)• Null Dereference (CWE-476)• Unchecked array indexing (CWE-129)• Unchecked Return Value (CWE-252)• Path Equivalence - trailing dot - 'file.txt.‘ (CWE-42)

•Newer languages/frameworks• Deserialization of untrusted data (CWE-502)• Information leak through class cloning (CWE-498)• .NET Misconfiguration: Impersonation (CWE-520)• Passing mutable objects to an untrusted method (CWE-375)

•Security feature failures• Failure to check for certificate revocation (CWE-299)• Improperly Implemented Security Check for Standard (CWE-358)• Failure to check whether privileges were dropped successfully (CWE-273)• Incomplete Blacklist (CWE-184)• Use of hard-coded cryptographic key (CWE-321)… and about 550 more

45

CWE Contributors

46

Visualizing Attacks/ Vulns via DFDs

• Identify entry and exit points as well as related access levels– Internal and external interfaces– What are the trust boundaries? – Single/ Cross Domain traversals– Mapping out Networks

47 47

Users

Request

Responses

DM

Z (U

ser/W

eb

Serve

r Bo

un

dary)

Message Call

Account/ TransactionQuery Calls

Web Server

ApplicationServer

Application Calls

Encryption +Authentication

Encryption + Authentication

Financial Server

Authentication Data

Res

tricted N

etw

ork

(Ap

p &

DB

Server/F

ina

ncia

l Se

rver B

ou

nd

ary)

DatabaseServer

Application Responses

FinancialData

Auth Data

MessageResponse

SQL Query Call

CustomerFinancial

Data

Inte

rnal (W

eb

Serve

r/ Ap

p &

DB

Server B

ou

nd

ary)

<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT>

Injection flaws CSRF,Insecure Direct Obj. Ref, Insecure Remote File Inclusion

ESAPI/ISAPI FilterCustom errors

OR ‘1’=’1—‘,

Prepared Statements/Parameterized Queries,Store ProceduresESAPI Filtering,Server RBACForm Tokenization

XSS, SQL Injection, Information Disclosure Via errors

Broken Authentication, Connection DB PWD in clear

Hashed/Salted Pwds in Storage and Transit

Trusted Server To Server Authentication, SSO

Trusted Authentication,Federation, Mutual Authentication

Broken Authentication/ Impersonation, Lack of Synch Session Logout

Encrypt Confidential PII in Storage/Transit

Insecure Crypto Storage

Insecure Crypto Storage

"../../../../etc/passwd%00"

Cmd=%3B+mkdir+hackerDirectory

http://www.abc.com?RoleID

Phishing,Privacy Violations,Financial LossIdentity TheftSystem Compromise, Data Alteration, Destruction

48

Exploits beget countermeasures

• Unacceptable risks give way to countermeasure development

• Develop countermeasures based upon the net risk of an application environment at multiple levels– Baseline configuration – Design and programmatic controls– 3rd party software/ COTS

49

Countermeasures

• Identify mitigations to the previously identified attacks-to-vuln relationship by locating the countermeasures– Native configuration countermeasures– ESAPI encryption (web.config)– TCP Wrappers – Mod Security– HTTPS/ HTTP validation

• Develop new countermeasures

50

Tools Along the Way

Conveying Risk for Web Apps via Threat Modeling

52

Do We Know Real Risk?– Risk = ((Threats (probability) *

Vulnerability)/Countermeasures) * Impact– Impact assumes threat will take

place– Impact = # of occurrences * SLE – Occurrences may equate to incidents

(records lost, number of servers, etc)– SLE = Exposure factor * Asset value

– Is risk relevant for Web Apps?– Unitizing business impact with $$$– However, attack landscape too large

to mitigate– Plausible deniability – Proving due care in lieu of

negligence

53

Internet Facing Stores & Risk

54

Drivers & Value-Add• Remediation takes place for risky findings

– Understanding threats catalyzes remediation• Abides by Building Security In concept• Improves software assurance model• Cost/ Time savings stem from time savings

across multiple efforts– Chg Mgt, Post Implementation Security Testing,

Exception Management

55

Closing thoughts on Threat Modeling

• Threat modeling extends beyond awareness of vulns and attacks by creating threat awareness• Develops need to sense the viability of ‘it could happen to me’• Only way to integrate analysis of misuse cases with insecure coding

& design based upon motives• Threat modeling to botnets requires more of a security approach

exclusively.• Building Security In: A new risk modeling paradigm for developing

applications• Case & Point: Demonstrating how attack happen (pen test results,

dynamic analysis, static analysis)• Understanding Threats: Incorporates threat feeds, network traffic logs,

intrusion attempts

Q&A