Application Threat Modeling


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

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Application Threat Modeling

  1. 1. Threat Modeling WebApps for Risk Mitigation Tony UcedaVelez, Managing Director VerSprite – Navigate Beyond Risk
  2. 2. Sea of Issues Across Web App Development & Management
  3. 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. 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. 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. 6. Navigating to Strategic Solutions in Web Application Security
  7. 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. 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. 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. 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. 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. 12. Taxonomy of Terms
  13. 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. 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. 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. 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. 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. 18 Exclude Unlikely Attacks Debate on what is likely vs unlikely
  19. 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. 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. 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. 22. Methodology
  23. 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. 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. 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. 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. 27. Hype Mitigation
  28. 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. 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. 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. 31. Applicability & Use
  32. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41 OWASP Vuln Listing
  42. 42. 42 Attack Pattern Schema - CAPEC
  43. 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. 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. 45 CWE Contributors
  46. 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 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 RoleID Phishing, Privacy Violations, Financial Loss Identity Theft System Compromise, Data Alteration, Destruction
  48. 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. 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. 50 Tools Along the Way
  51. 51. Conveying Risk for Web Apps via Threat Modeling
  52. 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. 53 Internet Facing Stores & Risk
  54. 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. 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. 56. Q&A