Application Threat Modeling


Published on

Published in: Technology
1 Comment
  • I'm sorry I only saw this comment now - I guess I had not subscribed to followup comments)....

    but the statement that 'if Hannaford (and other data loss events) had followed security best practices' they would have prevented the data loss event - must be refuted properly.

    All of the data loss events in the past 5 years (and we are talking about over 250 million personal data records leaked as of end of 2008) were lost or stolen from institutions that were PCI DSS compliant. You will agree that 100% of a sample data set is sufficient empirical evidence that compliance is not a sufficient condition to forecast or prevent a major data loss event.

    The reason for this is that the PCI DSS standard was written by the credit card associations through the eyes of large well-managed financial institutions with good security best practices. The standard is also quite old and many of the items are outdated to the point of being quaint - for example using routers as firewalls or calling an anti-virus threat management.

    In addition - most merchants (if you do less than 1Million transactions/year) self-comply - which means that compliance is a relative expression.

    But the real reason that compliance cannot prevent major data loss events is that a data loss event is a complex interaction of people and technology an interaction that includes social influences and corporate culture as well as spontaneous, unpredictable actions by individuals that were fired or felt mistreated by the company.

    None of the social, psychological and cultural issues are accounted for in compliance - which is why compliance standards like PCI DSS cannot predict or prevent a major data loss event like Hannaford.

    Specifically - regarding Hannaford - I don't buy the malware story because store back office servers in a retail POS system are not connected to the public Internet and therefore could not be attacked directly. It is possible that there was network connectivity from the company's internal operational network of Windows users to store back office servers and this served as a vector for malware. Possible but not very probable.

    I submit that we will never know because none of the players in this major data loss event were forthwith with the facts.

    My personal gut feeling is that it was an inside job or a simple case of credit card authorization requests being saved in temporary files that were accessible from a Windows share on the administration network. Which made it childs play to steal

    Danny Lieberman - Data Loss Prevention specialists
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Application Threat Modeling

    1. 1. Managing Software Security Risks Using Application Threat Modeling Marco M. Morana Cincinnati Chapter
    2. 2. Agenda <ul><li>Application Threat Modeling (ATM) </li></ul><ul><ul><li>Use cases and definitions, risk models, benefits, </li></ul></ul><ul><ul><li>security flaws vs. bugs </li></ul></ul><ul><li>ATM as Architecture Design Review </li></ul><ul><ul><li>Use And Misuse Cases, Data Flow Diagrams </li></ul></ul><ul><li>ATM as Threat Analysis </li></ul><ul><ul><li>Attack Libraries and Attack Trees </li></ul></ul><ul><li>Other ATM Methodologies: Microsoft </li></ul><ul><li>OWASP Threat Risk Modeling Step By Step </li></ul><ul><li>Risk Management And Risk Strategy </li></ul><ul><li>Q&A </li></ul><ul><li>References </li></ul>
    3. 3. Why Application Threat Modeling? <ul><li>Security Design Flaws Are Prevalent: </li></ul><ul><ul><li>Security design flaws account 70% of the defects being analyzed and among them about 47% being of medium and high business impact and easily exploitable ( 2002 study from @stake ) </li></ul></ul><ul><ul><li>76% of more than 200 bank websites had at least one security design flaw ( 2008 University of Michigan study ) </li></ul></ul><ul><li>Fixing Design Flaws Is Expensive: </li></ul><ul><ul><li>The cost of fixing a flaw during design is 7 times cheaper than during implementation and 100 times cheaper then during production ( IBM Systems Sciences Institute study ) </li></ul></ul>
    4. 4. Threat Modeling Defined <ul><li>A systematic & strategic approach for enumerating threats to an application environment, with the objective of minimizing risk and associated impact levels to the business </li></ul><ul><li>Methodologies: Define a repeatable process that consistent results with the help of tools( e.g. MS AC, TRIKE, OWASP) </li></ul><ul><li>Different Approaches to categorize threats, find vulnerabilities and determine countermeasures </li></ul><ul><ul><li>Offensive: STRIDE/DREAD </li></ul></ul><ul><ul><li>Defensive: Application Security Frame </li></ul></ul><ul><ul><li>Asset Centric: Confidentiality, Integrity, Availability </li></ul></ul>
    5. 5. Who Benefits Threat Modeling <ul><li>Threat modeling provides different benefits to the project stakeholders depending on their role and responsibility: </li></ul><ul><ul><li>Architects </li></ul></ul><ul><ul><li>Developers </li></ul></ul><ul><ul><li>Security Testers </li></ul></ul><ul><ul><li>Project Managers </li></ul></ul><ul><ul><li>Business Managers </li></ul></ul><ul><ul><li>Information Risk Officers </li></ul></ul>
    6. 6. ATM and Application Security Assessments <ul><li>Security Design Flaws </li></ul><ul><ul><li>Introduced because of lack of security requirements, errors in design, lack of secure design knowledge, lack of architecture design review </li></ul></ul><ul><ul><li>Cannot be identified by tools since lack contextual knowledge of the application </li></ul></ul><ul><ul><li>Can be identified with threat modeling/secure architecture reviews </li></ul></ul><ul><li>Security Coding Bugs </li></ul><ul><ul><li>Coding errors that result in vulnerabilities </li></ul></ul><ul><ul><li>Can be identified with source code analysis and tools </li></ul></ul><ul><ul><li>Requires developers understanding secure coding and following secure coding standards </li></ul></ul>
    7. 7. Application Threat Modeling In the SDLC From Insecure Magazine,
    8. 8. ATM During Requirement Phase: Use and Abuse Cases
    9. 9. ATM During The Design Phase: Architecture Analysis From Insecure Magazine
    10. 10. ATM During Development & Validation <ul><li>Threat Modeling and Secure Code Reviews </li></ul><ul><ul><li>Bread First vs. Depth First </li></ul></ul><ul><ul><li>Security flaws vs. security bugs </li></ul></ul><ul><li>Threat modeling and secure coding standards </li></ul><ul><ul><li>Map threats to vulnerabilities </li></ul></ul><ul><ul><li>Document countermeasures </li></ul></ul><ul><li>Threat Driven Security Tests </li></ul><ul><ul><li>Use and Misuse Cases for Security Test Cases </li></ul></ul><ul><ul><li>Unit Tests, Integrated System Tests, User Acceptance Tests </li></ul></ul>
    11. 11. ATM And Application Threat Analysis <ul><li>Methodology To Investigate Threats and Attacks in existing applications, determine risks and make informed decisions </li></ul><ul><li>Attack Libraries </li></ul><ul><ul><li>Attack Trees </li></ul></ul><ul><ul><li>Use and Misuse Cases </li></ul></ul><ul><ul><li>Data Flow Diagrams </li></ul></ul><ul><li>Risk Driven Security Tests </li></ul><ul><ul><li>Validate Attack Scenario </li></ul></ul><ul><ul><li>Identify Vulnerabilities </li></ul></ul><ul><ul><li>Recommend Countermeasures </li></ul></ul>
    12. 12. Attach Tree Theory Bruce Schneider, Attack Trees:
    13. 13. Attack Tree Bank Account Attack Example Analyzing the Security of Internet Banking Authentication Mechanisms :
    14. 14. Attack Trees And Attack Analysis: Passwords Password Management Concerns with IE and Firefox, part one
    15. 15. Microsoft Application Threat Modeling MS TM Blog:
    16. 16. OWASP Threat Risk Modeling OWASP Threat Risk Modeling
    17. 17. Step 1: Identify Security Objectives <ul><li>Tactical Security Assessments </li></ul><ul><ul><li>Identification of Security Flaws, the Threats that can exploit them and the mitigations </li></ul></ul><ul><li>Secure Architecture Reviews </li></ul><ul><ul><li>Requirements, Decomposition, Threat Mapping, Threat Response & Mitigations </li></ul></ul><ul><ul><li>Threats and Countermeasures, Risk Mitigation Strategy </li></ul></ul><ul><li>Application Risk Management </li></ul><ul><ul><li>Technical Risk and Business Risk </li></ul></ul><ul><ul><li>Risk Mitigation Strategy </li></ul></ul><ul><ul><ul><li>Mitigate, Transfer, Accept it </li></ul></ul></ul>
    18. 18. Step 2: Application Overview Walkthrough: Creating a Threat Model for a Web Application
    19. 19. Step 3: Decompose the Application <ul><li>Objective: understand the application and how it interacts with external entities. </li></ul><ul><ul><li>Create Use Cases </li></ul></ul><ul><ul><li>Identify Entry Points </li></ul></ul><ul><ul><li>Identify Assets </li></ul></ul><ul><li>Outcome: Data flow diagrams (DFD) for the application show the different paths through the system highlighting the privilege boundaries. </li></ul>
    20. 20. Understanding the Application: Data Flow Diagrams OWASP Application Threat Modeling
    21. 21. Step 4: Threat Identification <ul><li>Objective: Use a systematic approach to identify the application exposure to threats </li></ul><ul><ul><li>Threat Lists (STRIDE, ASF) </li></ul></ul><ul><ul><li>Use and Misuse cases </li></ul></ul><ul><ul><li>Attack Trees </li></ul></ul><ul><li>Outcome: List of threats relevant to the application environment, the hosts and the application tiers </li></ul>
    22. 22. Threat Analysis: Holistic View Improving Web Application Security: Threats and Countermeasures
    23. 23. Threat Categorization: ASF Threat List https://
    24. 24. Threat Categorization: STRIDE Threat List OWASP Application Threat Modeling
    25. 25. Step 5: Vulnerability Identification <ul><li>Objective: Identify un-mitigated threats (e.g. threats with no countermeasures) </li></ul><ul><ul><li>Use and Misuse cases </li></ul></ul><ul><ul><li>Threat Tree </li></ul></ul><ul><ul><li>Threat-Countermeasure Lists (STRIDE, ASF) </li></ul></ul><ul><li>Outcome: threat profile describing each security application flaw in terms of the threat impacting it, the host, tier, component impacted the vulnerability being exposed and the suggested mitigation control/countermeasure. </li></ul>
    26. 26. Threats And Vulnerability Conditions: Threat Trees OWASP Application Threat Modeling
    27. 27. Countermeasure Identification
    28. 28. Threats and Mitigation Techniques
    29. 29. Threat and Risk Ranking <ul><li>Threats can be classified (e.g. ranked) according to risk factors to support risk mitigation decision making strategy </li></ul>OWASP Application Threat Modeling
    30. 30. Rating Threats and Risk <ul><li>How do I measure risk? </li></ul><ul><ul><li>Use a structured methodology </li></ul></ul><ul><ul><li>Risk = Threat X Vulnerability x Asset </li></ul></ul>Practical Threat Analysis for the Software Industry:
    31. 31. Rating Threats and Risk <ul><li>Simple formula: Risk =Probability (Degree of Mitigation, Exploitability) * Impact ( Damage Potential ) </li></ul>Guidelines for risk management
    32. 32. DREAD Model <ul><li>Another method for determining risk is the DREAD model: </li></ul><ul><ul><li>D amage potential – How great is the damage if the vulnerability is exploited? </li></ul></ul><ul><ul><li>R eproducibility – How easy is it to reproduce the attack? </li></ul></ul><ul><ul><li>E xploitability – How easy is it to launch an attack? </li></ul></ul><ul><ul><li>A ffected users – As a rough percentage, how many users are affected? </li></ul></ul><ul><ul><li>D iscoverability – How easy is it to find the vulnerability? </li></ul></ul><ul><li>Risk = Min(D, (D+R+E+A+D) / 5) </li></ul>TM For Application Designers and Archietcts
    33. 33. Threat Modeling and Risk Decision Making <ul><li>Threats can be resolved by: </li></ul><ul><ul><li>Risk Acceptance - doing nothing </li></ul></ul><ul><ul><li>Risk Transference - pass risk to an externality </li></ul></ul><ul><ul><li>Risk Avoidance - removing the feature/component that causes the risk </li></ul></ul><ul><ul><li>Risk Mitigation - decrease the risk </li></ul></ul><ul><li>Mitigation strategies should be examined for each threat </li></ul><ul><li>Mitigations should be chosen according to the appropriate technology </li></ul><ul><li>Resolution should be decided according to risk level and cost of mitigations </li></ul>
    34. 34. Risk Mitigation Strategy Best Practices <ul><li>General Objectives: </li></ul><ul><ul><li>Translate the identified technical risk issues into business risk issues </li></ul></ul><ul><ul><li>Determine whether standards compliance is violated </li></ul></ul><ul><ul><li>Determine whether other compensating security controls and mitigation factors are present </li></ul></ul><ul><ul><li>Determine which protective measure (e.g. security control, policy measures) should be in place to mitigate the threat, how should be implemented and when </li></ul></ul><ul><ul><li>Determine short term and long term solutions </li></ul></ul>
    35. 35. Application Risk Management Best Practices <ul><li>Eliminate vulnerabilities before they become liabilities </li></ul><ul><li>Manage the risks of serious financial loss, negative publicity, legal liability, loss of contracts, erosion of market share, degraded performance or other serious business impact as a result of a failure in security </li></ul><ul><li>Set, enforce and report that software assurance thresholds are maintained </li></ul><ul><li>Measurable reports prove progress internally and for compliance </li></ul>
    36. 36. Q & Q U E S T I O N S A N S W E R S