As delusions of effective risk management for application environments continue to spread, companies continue to bleed large amounts of security spending without truly knowing if the amount is warranted, effective, or even elevating security at all. In parallel, hybrid, thought-provoking security strategies are moving beyond conceptual ideas to practical applications within ripe environments. Application Threat Modeling is one of those areas that, beyond the hype, provides practical and sensible security strategy that leverages already existing security efforts for an improved threat model of what is lurking in the shadows. Tony UcedaVelez, Managing Director An experienced security management professional, Tony has more than 10 years of hands-on security and technology experience and is a vocal advocate of security process engineering – a term that describes the design and development of secure processes and controls working symbiotically to create a unique business workflow. Tony currently serves as Managing Director for an Atlanta based risk advisory firm that focuses on security strategy and delivering effective means for risk mitigation and security process engineering. He has worked and consulted for the Fortune 500, as well as federal agencies in the U.S. on the topic of application security and security process engineering.

1. Threat Modeling WebApps for Risk
Mitigation
Tony UcedaVelez, Managing Director
VerSprite – Navigate Beyond Risk

2. Sea of Issues Across Web App
Development & Management

3. • 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

4. • 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
Perceived
Threats
Remediation Pill

5. • “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

6. Navigating to Strategic Solutions
in Web Application Security

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

11. • 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!!!

12. Taxonomy of Terms

13. 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. 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. 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

16. • 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

17. • 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 & vulns
17
Attacks/ Attack Vectors
Web App
Use Case
Misuse
Case
Vuln Attack
Use Case Vuln Attack

18. 18
Exclude Unlikely Attacks
Debate on what is likely vs unlikely

19. 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. 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. 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

22. Methodology

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

24. • 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. 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. 26
Tailoring Methodology to Approach
• Three distinct approaches to threat modeling:
1. Software Centric – Concentrates on the security of
software for an evaluated web app
2. Asset Centric – Focused on more risk based
approach to application threat modeling
3. 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

27. Hype Mitigation

28. 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. 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. 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

31. Applicability & Use

32. 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. 33
Mapping Use Cases to Misuse Cases
User
Hacker/Malicious User
Brure Force
Authentication
Enter Username and
password
Validate Password
Minimum Length and
Complexity
Application/Server
Includes
Mitigates
User Authentication
Includes
Includes
Includes
Mitigates
Threatens
Show Generic Error
Message
Includes
Includes
Lock Account After N.
Failed Login Attempts
Harverst (e.g. guess)
Valid User Accounts
Dictionary Attack
Mitigates
Mitigates

34. 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

35. 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
^
T
h
r
e
a
t
M
o
d
e
l
v

36. 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

37. • 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. 38
Identifying Attack Vectors for Web Apps
Defined Threat
Attack Vector
Attacks
Exploits
Missing components:
• Assets (Targets)
• Actors
• Vulnerabilities
• Impact Levels
Missing attack vectors:
• Email
• Mobile Environments
• Web Services
• Inside Threat*

39. 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

40. 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. 41
OWASP Vuln Listing

42. 42
Attack Pattern Schema - CAPEC

43. 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. 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. 45
CWE Contributors

46. 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 47
Users
Request
Responses
DMZ(User/WebServerBoundary)
Message
Call
Account/
Transaction
Query Calls
Web Server
Application
Server
Application
Calls
Encryption +
Authentication
Encryption +
Authentication
Financial
Server
Authentication
Data
RestrictedNetwork
(App&DBServer/FinancialServerBoundary)
Database
Server
Application
Responses
Financial
Data
Auth Data
Message
Response
SQL Query Call
Customer
Financial
Data
Internal(WebServer/App&DBServerBoundary)
<SCRIPT>alert(“Cookie”+
document.cookie)</SCRIPT
>
Injection flaws
CSRF,
Insecure Direct Obj.
Ref,
Insecure Remote
File Inclusion
ESAPI/
ISAPI Filter
Custom errors
OR ‘1’=’1—‘,
Prepared Statements/
Parameterized Queries,
Store Procedures
ESAPI Filtering,
Server RBAC
Form 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+ha
ckerDirectory
http://www.abc.com?
RoleID
Phishing,
Privacy Violations,
Financial Loss
Identity Theft
System Compromise,
Data Alteration,
Destruction

48. 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. 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. 50
Tools Along the Way

51. Conveying Risk for Web Apps via
Threat Modeling

52. 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. 53
Internet Facing Stores & Risk

54. 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. 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

56. Q&A