• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

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.

Like this presentation? Why not share!

Application Threat Modeling

on

  • 1,563 views

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.

Statistics

Views

Total Views
1,563
Views on SlideShare
1,563
Embed Views
0

Actions

Likes
2
Downloads
91
Comments
2

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Application Threat Modeling Application Threat Modeling Presentation Transcript

    • Threat Modeling WebApps for Risk Mitigation
      Tony UcedaVelez, Managing Director
      VerSprite – 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
    • 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?
      Security
      Perception
      Perceived
      Threats
      Remediation Pill
      4
    • “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
      Understandingthe 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
    • 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
      16
    • 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
      17
    • Exclude Unlikely Attacks
      Debate on what is likely vs unlikely
      18
    • 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
      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:
      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
      • 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
    • 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
      30
    • 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
    • Mapping Use Cases to Misuse Cases
      33
    • 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
      ^ 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
      35
    • 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
      36
    • 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
      37
    • Identifying Attack Vectors for Web Apps
      Defined Threat
      Attack Vector
      Missing attack vectors:
      • Email
      • Mobile Environments
      • Web Services
      • Inside Threat*
      Attacks
      Missing components:
      • Assets (Targets)
      • Actors
      • Vulnerabilities
      • Impact Levels
      Exploits
      38
    • 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
    • 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
      40
    • OWASP Vuln Listing
      41
    • 42
      Attack Pattern Schema - CAPEC
    • 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)
      43
    • 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
      44
    • CWE Contributors
      45
    • 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
    • ESAPI/
      ISAPI Filter
      Custom errors
      Prepared Statements/
      Parameterized Queries,
      Store Procedures
      ESAPI Filtering,
      Server RBAC
      Form Tokenization
      <SCRIPT>alert(“Cookie”+
      document.cookie)</SCRIPT>
      Trusted Authentication,
      Federation, Mutual Authentication
      "../../../../etc/passwd%00"
      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
      Cmd=%3B+mkdir+hackerDirectory
      http://www.abc.com?RoleID
      Trusted Server To Server Authentication, SSO
      Encrypt Confidential PII in Storage/Transit
      Broken Authentication, Connection DB PWD in clear
      Insecure Crypto Storage
      Phishing,
      Privacy Violations,
      Financial Loss
      Identity Theft
      System Compromise, Data Alteration, Destruction
      Hashed/
      Salted Pwds in Storage and Transit
      Insecure Crypto Storage
      47
      47
    • 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
    • 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
      55
    • Q&A