• Like


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Application Threat Modeling

Uploaded on

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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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
    Standards, Frameworks, & Shelf ware
  • 4. 4
    Right Direction Falling Short
    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?
    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.
    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
    • 8. SDLC Integration
    • 9. Migrating from understanding perceived security to perceived threats
    • 10. Evolution of the attack plan to the web app environment
    • 11. Thinking like an attacker across the app environment
    • 12. Conceptualize likely attacks based upon motives and identified attack vectors
  • 8
    Integrating the What Could Happen ?
    • Vulnerability Assessment results reveal areas of weakness
    • 13. Pen Testing results provide probabilistic values for exploiting identified vulns
    • 14. Dynamic/ Static Analysis results for vulnerable code and program objects
    • 15. Social Engineering exercises reveals security un-awareness
    • 16. 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
    • 17. Leverage existing security info & analysis
    • 18. Security Incident Data Feeds
    • 19. Intrusion Prevention/ Detection Systems
    • 20. Firewalls
    • 21. Host Based Agents
    • 22. Web Application Firewalls (WAFs)
  • 10
    Understandingthe What We Have?
    • Security Governance in Action via technology guidelines & standards – Governance at work!
    • 23. Standards as countermeasures for application / platform/ network related threats
    • 24. Identifying what technology controls are present
    • 25. Web Server (ModSecurity, HTTP Authentication, W3 Security Extensions)
    • 26. Platform/ Application Level (Server Hardening, Segregating the Web Sites, Signed Libraries, Programmatic checks, delete default content, unrelated to domains, etc)
    • 27. 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 $$$
    Tailored Countermeasures = Strategic Risk Mitigation
    This has the perfect amount of countermeasures!!!
  • 28. Taxonomy of Terms
  • 29. 13
    Actors/ Assets (Targets)
    • End users that use thick, thin client applications (userID: bsmith, sue.taylor, etc)
    • 30. System administrators who regularly interact/ support any part of the application ecosystem
    • 31. Identified via Data Flow Diagramming (DFD)
    • 32. Application accounts used for automated or batched APIs or data interfaces
    • 33. 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
    • 34. Addresses issues related to impersonation, federated identities in applications
    • 35. C.R.U.D analysis (rights to Create, Read, Update, and Delete) across use cases
    • 36. 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!
    • 37. Defines branches in attack tree to which attacks, vulns, exploits are correlated
    • 38. Defines how the apps can be used & misused
    • 39. Business logic formerly addressed as part of threat modeling
  • Vulnerabilities
    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
    Likely vs. Unlikely Attack Vectors
  • 40. Attacks/ Attack Vectors
    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
  • 41. Exclude Unlikely Attacks
    Debate on what is likely vs unlikely
  • 42. 19
    • Mitigate risk of successful attacks
    • 43. Developed based upon residual risk
    • 44. Traverses all layers of the application environment and asset (platform and software)
    • 45. Protection against real risk areas
  • 20
    Data Flow Diagramming (DFD)
    • Exercise to connect the dots for APIs and other data interfaces
    • 46. Maps out data interfaces across application layers (presentation, app, data, etc)
    • 47. Maps out relationship amongst actors, assets, data sources, trust boundaries, and eventually the variables of the attack tree
    • 48. Incorporates actors and assets as data flow start & end points
  • 21
    Trust Boundaries
    • Boundaries that define where trust exist and to what degree
    • 49. Determination on what level of validation to use within and across trust boundaries
    • 50. Less vulnerability based and more paranoia or preventative based
    • 51. Adds an extra layer of security strategy that is based upon preventive measures of what could happen
    • 52. Who is requesting this data?
    • 53. Are they authorized?
    • 54. What is the expected output
    • 55. Has their ID been validated by a trusted third party?
    • 56. Allows for the consideration of new threats (privilege escalation, etc) and countermeasures (authentication controls) that relate to trust amongst application calls
  • Methodology
  • 57. 23
    First a brief Definition: Decomposing an application in order to identify attack vectors and software vulnerabilities for the purpose of applying effective countermeasures.
  • 58. OWASP simplified methodology
    Functional and mostly geared for security centric threat models
    Excludes more risk based analysis
    Threat analysis takes place at different levels
    Simplified Methodology
  • 59. 25
    Key Components to Threat Modeling
    • Steps 3,4,5,6 equate to ‘secret sauce’
    • 60. Step 3: App Decomposition allows for greater understanding of app to all involved parties (threat modeler, developers, architects, sys admins)
    • 61. Step 4: Vuln Mapping integrates unmanaged vulnerabilities in order to ID a window for an exploit. Something to worry about.
    • 62. Step 5: Attack Tree evolves beyond the theoretical to lets let our guys try to exploit this
    • 63. Step 6: Threat Analysis shows the net effect of vulns * attacks - countermeasures
  • 26
    Tailoring Methodology to Approach
    • Three distinct approaches to threat modeling:
    Software Centric – Concentrates on the security of software for an evaluated web app
    Asset Centric – Focused on more risk based approach to application threat modeling
    Security Centric – Addresses security and technical risks to threats revealed by application threat model
    • No one is better, different strokes for different folks
    • 64. Legitimate use cases for each type of approach
    • 65. Largely dependent on org culture and audience
  • Hype Mitigation
  • 66. 28
    Beyond The Hype
    • As with any new buzz in security, its not long before a good thing mutates in meaning and application
    • 67. Not a replacement for other traditional application assessments
    • 68. Risk assessments have their place for ongoing risk analysis of deployed application environment
    • 69. Pen Testing, Social Eng, Static/ Dynamic analysis are not comparative alternatives to threat modeling
    • 70. 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.
    • 71. By widely, we simply mean no organization has defined and patented a threat modeling
    • 72. STRIDE & DREAD are not methodologies, threat and risk classifications respectively
    • 73. Threat modeling is not all just about improved software design
    • 74. Depends on approach
    • 75. Asset (risk), Software, Security Centric
  • 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
  • 76. Applicability & Use
  • 77. 32
    Using Use Cases to ID Misuse Cases
    • Every function has a potential dysfunction; need to enumerate and test application functions
    • 78. Listing of vulns for mapping can originate from subscribed vulnerability feeds/ vulnerability signatures from vendors
    • 79. Some Sources: SecurityFocus, US-CERT,MITRE, Microsoft
    • 80. Map vulns to employed platforms and software technologies
    • 81. Attack tree begins to take shape
  • Mapping Use Cases to Misuse Cases
  • 82. 34
    Threat Identification is Key
    • Enumerate threats and impact to application components
    • 83. Threats based upon known intel
    • 84. Prior assessment info (where applicable & useful)
    • 85. Other application assessments
    • 86. PII theft
    • 87. XSS
    • 88. SQL Injection
    • 89. MITM
    • 90. Sabotage driven threats
    • 91. CMS exploits to web application (Zope, Joomla, Mambo, etc)
    • 92. FTP Brute Force attacks
    • 93. iFrame Injection attacks
    • 94. Malware upload
    • 95. Identify most likely attack vectors
    • 96. Address entire application footprint (email, client app, etc)
    • 97. Web Forms/ Fields
    • 98. WSDLs/ SWF Objects
    • 99. Compiled Libraries/ Named Pipes
  • Threat Modeling Web Apps via SDLC
    ^ Threat Model v
    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
  • 100. 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
  • 101. Split Personality to Web Development
    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
    Security Dr. Jekyll & Mr. Hyde
  • 102. Identifying Attack Vectors for Web Apps
    Defined Threat
    Attack Vector
    Missing attack vectors:
    Missing components:
  • 109. 39
    Vuln & Attack Library Buildout
    • Exploitation is the proof. We all need proof.
    • 110. Given time constraints, partial exploits may be acceptable; educating that attacks are layered.
    • 111. Exploitation may address identified vulns, business logic flaws, and/ or non-published vulnerabilities
    • 112. Content management for vuln and attack library a key to effective Application Threat Modeling
  • Managing & Mapping Vulns to Attacks
    • Content & interop is key
    • 113. Need to pull vuln and attack libraries from notable sources
    • 114. OWASP, MS, and MITRE have lists from which to leverage as vuln and attack libraries
    • 115. Threat feeds from Sophos, TrendMicro, Symantec, etc can work as well
    • 116. Libraries used to map to assets, application components, and use cases for assessed web application
    • 117. With MITRE, why CWEs make more sense for Threat Modeling than CVE for content
  • 118. OWASP Vuln Listing
  • 119. 42
    Attack Pattern Schema - CAPEC
  • 120. MITRE CWE Cross-Section:20 of the Usual Suspects
    • Absolute Path Traversal (CWE-36)
    • 121. Cross-site scripting (XSS) (CWE-79)
    • 122. Cross-Site Request Forgery (CSRF) (CWE-352)
    • 123. CRLF Injection (CWE-93)
    • 124. Error Message Information Leaks (CWE-209)
    • 125. Format string vulnerability (CWE-134)
    • 126. Hard-Coded Password (CWE-259)
    • 127. Insecure Default Permissions (CWE-276)
    • 128. Integer overflow (wrap or wraparound) (CWE-190)
    • 129. OS Command Injection (shell metacharacters) (CWE-78)
    • 130. PHP File Inclusion (CWE-98)
    • 131. Plaintext password Storage (CWE-256)
    • 132. Race condition (CWE-362)
    • 133. Relative Path Traversal (CWE-23)
    • 134. SQL injection (CWE-89)
    • 135. Unbounded Transfer ('classic buffer overflow') (CWE-120)
    • 136. UNIX symbolic link (symlink) following (CWE-61)
    • 137. Untrusted Search Path (CWE-426)
    • 138. Weak Encryption (CWE-326)
    • 139. Web Parameter Tampering (CWE-472)
  • 140. MITRE CWE Cross-Section:22 More Suspects
    • Design-Related
    • 141. High Algorithmic Complexity (CWE-407)
    • 142. Origin Validation Error (CWE-346)
    • 143. Small Space of Random Values (CWE-334)
    • 144. Timing Discrepancy Information Leak (CWE-208)
    • 145. Unprotected Windows Messaging Channel ('Shatter') (CWE-422)
    • 146. Inherently Dangerous Functions, e.g. gets (CWE-242)
    • 147. Logic/Time Bomb (CWE-511)
    • 148. Low-level coding
    • 149. Assigning instead of comparing (CWE-481)
    • 150. Double Free (CWE-415)
    • 151. Null Dereference (CWE-476)
    • 152. Unchecked array indexing (CWE-129)
    • 153. Unchecked Return Value (CWE-252)
    • 154. Path Equivalence - trailing dot - 'file.txt.‘ (CWE-42)
    • 155. Newer languages/frameworks
    • 156. Deserialization of untrusted data (CWE-502)
    • 157. Information leak through class cloning (CWE-498)
    • 158. .NET Misconfiguration: Impersonation (CWE-520)
    • 159. Passing mutable objects to an untrusted method (CWE-375)
    • 160. Security feature failures
    • 161. Failure to check for certificate revocation (CWE-299)
    • 162. Improperly Implemented Security Check for Standard (CWE-358)
    • 163. Failure to check whether privileges were dropped successfully (CWE-273)
    • 164. Incomplete Blacklist (CWE-184)
    • 165. Use of hard-coded cryptographic key (CWE-321)
    … and about 550 more
  • 166. CWE Contributors
  • 167. 46
    Visualizing Attacks/ Vulns via DFDs
    • Identify entry and exit points as well as related access levels
    • 168. Internal and external interfaces
    • 169. What are the trust boundaries?
    • 170. Single/ Cross Domain traversals
    • 171. Mapping out Networks
  • ESAPI/
    ISAPI Filter
    Custom errors
    Prepared Statements/
    Parameterized Queries,
    Store Procedures
    ESAPI Filtering,
    Server RBAC
    Form Tokenization
    Trusted Authentication,
    Federation, Mutual Authentication
    XSS, SQL Injection,
    Information Disclosure
    Via errors
    Broken Authentication/ Impersonation, Lack of Synch Session Logout
    OR ‘1’=’1—‘,
    Injection flaws CSRF,
    Insecure Direct Obj. Ref,
    Insecure Remote File Inclusion
    Trusted Server To Server Authentication, SSO
    Encrypt Confidential PII in Storage/Transit
    Broken Authentication, Connection DB PWD in clear
    Insecure Crypto Storage
    Privacy Violations,
    Financial Loss
    Identity Theft
    System Compromise, Data Alteration, Destruction
    Salted Pwds in Storage and Transit
    Insecure Crypto Storage
  • 172. 48
    Exploits beget countermeasures
    • Unacceptable risks give way to countermeasure development
    • 173. Develop countermeasures based upon the net risk of an application environment at multiple levels
    • 174. Baseline configuration
    • 175. Design and programmatic controls
    • 176. 3rd party software/ COTS
  • 49
    • Identify mitigations to the previously identified attacks-to-vuln relationship by locating the countermeasures
    • 177. Native configuration countermeasures
    • 178. ESAPI encryption (web.config)
    • 179. TCP Wrappers
    • 180. Mod Security
    • 181. HTTPS/ HTTP validation
    • 182. Develop new countermeasures
  • 50
    Tools Along the Way
  • 183. Conveying Risk for Web Apps via Threat Modeling
  • 184. 52
    Do We Know Real Risk?
    • Risk = ((Threats (probability) * Vulnerability)/Countermeasures) * Impact
    • 185. Impact assumes threat will take place
    • 186. Impact = # of occurrences * SLE
    • 187. Occurrences may equate to incidents (records lost, number of servers, etc)
    • 188. SLE = Exposure factor * Asset value
    • 189. Is risk relevant for Web Apps?
    • 190. Unitizing business impact with $$$
    • 191. However, attack landscape too large to mitigate
    • 192. Plausible deniability
    • 193. Proving due care in lieu of negligence
  • 53
    Internet Facing Stores & Risk
  • 194. 54
    Drivers & Value-Add
    • Remediation takes place for risky findings
    • 195. Understanding threats catalyzes remediation
    • 196. Abides by Building Security In concept
    • 197. Improves software assurance model
    • 198. Cost/ Time savings stem from time savings across multiple efforts
    • 199. Chg Mgt, Post Implementation Security Testing, Exception Management
  • Closing thoughts on Threat Modeling
    • Threat modeling extends beyond awareness of vulns and attacks by creating threat awareness
    • 200. Develops need to sense the viability of ‘it could happen to me’
    • 201. Only way to integrate analysis of misuse cases with insecure coding & design based upon motives
    • 202. Threat modeling to botnets requires more of a security approach exclusively.
    • 203. Building Security In: A new risk modeling paradigm for developing applications
    • 204. Case & Point: Demonstrating how attack happen (pen test results, dynamic analysis, static analysis)
    • 205. Understanding Threats: Incorporates threat feeds, network traffic logs, intrusion attempts
  • 206. Q&A