This document discusses application threat modeling (ATM) as a systematic approach to identifying security risks in software applications. It describes how ATM can be used at different stages of the software development lifecycle, from requirements to design to testing. The key steps of ATM include decomposing the application, identifying threats and vulnerabilities, analyzing attack vectors, and determining mitigation strategies. ATM helps prioritize risks and supports decision making around risk acceptance, avoidance, or mitigation.

1. Managing Software Security Risks Using Application Threat Modeling Marco M. Morana Cincinnati Chapter

2. Agenda Application Threat Modeling (ATM) Use cases and definitions, risk models, benefits, security flaws vs. bugs ATM as Architecture Design Review Use And Misuse Cases, Data Flow Diagrams ATM as Threat Analysis Attack Libraries and Attack Trees Other ATM Methodologies: Microsoft OWASP Threat Risk Modeling Step By Step Risk Management And Risk Strategy Q&A References

3. Why Application Threat Modeling? Security Design Flaws Are Prevalent: 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 ) 76% of more than 200 bank websites had at least one security design flaw ( 2008 University of Michigan study ) Fixing Design Flaws Is Expensive: 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 )

4. Threat Modeling Defined A systematic & strategic approach for enumerating threats to an application environment, with the objective of minimizing risk and associated impact levels to the business Methodologies: Define a repeatable process that consistent results with the help of tools( e.g. MS AC, TRIKE, OWASP) Different Approaches to categorize threats, find vulnerabilities and determine countermeasures Offensive: STRIDE/DREAD Defensive: Application Security Frame Asset Centric: Confidentiality, Integrity, Availability

5. Who Benefits Threat Modeling Threat modeling provides different benefits to the project stakeholders depending on their role and responsibility: Architects Developers Security Testers Project Managers Business Managers Information Risk Officers

6. ATM and Application Security Assessments Security Design Flaws Introduced because of lack of security requirements, errors in design, lack of secure design knowledge, lack of architecture design review Cannot be identified by tools since lack contextual knowledge of the application Can be identified with threat modeling/secure architecture reviews Security Coding Bugs Coding errors that result in vulnerabilities Can be identified with source code analysis and tools Requires developers understanding secure coding and following secure coding standards

7. Application Threat Modeling In the SDLC From Insecure Magazine, http://www.net-security.org/dl/insecure/INSECURE-Mag-17.pdf

8. ATM During Requirement Phase: Use and Abuse Cases https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation

9. ATM During The Design Phase: Architecture Analysis From Insecure Magazine http://www.net-security.org/dl/insecure/INSECURE-Mag-17.pdf

10. ATM During Development & Validation Threat Modeling and Secure Code Reviews Bread First vs. Depth First Security flaws vs. security bugs Threat modeling and secure coding standards Map threats to vulnerabilities Document countermeasures Threat Driven Security Tests Use and Misuse Cases for Security Test Cases Unit Tests, Integrated System Tests, User Acceptance Tests

11. ATM And Application Threat Analysis Methodology To Investigate Threats and Attacks in existing applications, determine risks and make informed decisions Attack Libraries Attack Trees Use and Misuse Cases Data Flow Diagrams Risk Driven Security Tests Validate Attack Scenario Identify Vulnerabilities Recommend Countermeasures

12. Attach Tree Theory Bruce Schneider, Attack Trees: http://www.schneier.com/paper-attacktrees-ddj-ft.html

13. Attack Tree Bank Account Attack Example Analyzing the Security of Internet Banking Authentication Mechanisms : http://www.itgi.org/Template.cfm?Section=Home&CONTENTID=35743&TEMPLATE=/ContentManagement/ContentDisplay.cfm

14. Attack Trees And Attack Analysis: Passwords Password Management Concerns with IE and Firefox, part one http://www.securityfocus.com/infocus/1882/2

15. Microsoft Application Threat Modeling MS TM Blog: http://blogs.msdn.com/threatmodeling/archive/2006/03/16/553232.aspx

16. OWASP Threat Risk Modeling OWASP Threat Risk Modeling http://www.owasp.org/index.php/Threat_Risk_Modeling

17. Step 1: Identify Security Objectives Tactical Security Assessments Identification of Security Flaws, the Threats that can exploit them and the mitigations Secure Architecture Reviews Requirements, Decomposition, Threat Mapping, Threat Response & Mitigations Threats and Countermeasures, Risk Mitigation Strategy Application Risk Management Technical Risk and Business Risk Risk Mitigation Strategy Mitigate, Transfer, Accept it

18. Step 2: Application Overview Walkthrough: Creating a Threat Model for a Web Application http://msdn.microsoft.com/en-us/library/ms978538.aspx

19. Step 3: Decompose the Application Objective: understand the application and how it interacts with external entities. Create Use Cases Identify Entry Points Identify Assets Outcome: Data flow diagrams (DFD) for the application show the different paths through the system highlighting the privilege boundaries.

20. Understanding the Application: Data Flow Diagrams OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling

21. Step 4: Threat Identification Objective: Use a systematic approach to identify the application exposure to threats Threat Lists (STRIDE, ASF) Use and Misuse cases Attack Trees Outcome: List of threats relevant to the application environment, the hosts and the application tiers

22. Threat Analysis: Holistic View Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/en-us/library/ms994921.aspx

23. Threat Categorization: ASF Threat List https:// www.owasp.org/index.php/Application_Threat_Modeling

24. Threat Categorization: STRIDE Threat List OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling

25. Step 5: Vulnerability Identification Objective: Identify un-mitigated threats (e.g. threats with no countermeasures) Use and Misuse cases Threat Tree Threat-Countermeasure Lists (STRIDE, ASF) 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.

26. Threats And Vulnerability Conditions: Threat Trees OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling

27. Countermeasure Identification https://www.owasp.org/index.php/Application_Threat_Modeling

28. Threats and Mitigation Techniques

29. Threat and Risk Ranking Threats can be classified (e.g. ranked) according to risk factors to support risk mitigation decision making strategy OWASP Application Threat Modeling https://www.owasp.org/index.php/Application_Threat_Modeling

30. Rating Threats and Risk How do I measure risk? Use a structured methodology Risk = Threat X Vulnerability x Asset Practical Threat Analysis for the Software Industry: http://www.securitydocs.com/library/2848/2

31. Rating Threats and Risk Simple formula: Risk =Probability (Degree of Mitigation, Exploitability) * Impact ( Damage Potential ) Guidelines for risk management http://www.qaa.ac.uk/aboutus/policy/RiskGuidelines.asp

32. DREAD Model Another method for determining risk is the DREAD model: D amage potential – How great is the damage if the vulnerability is exploited? R eproducibility – How easy is it to reproduce the attack? E xploitability – How easy is it to launch an attack? A ffected users – As a rough percentage, how many users are affected? D iscoverability – How easy is it to find the vulnerability? Risk = Min(D, (D+R+E+A+D) / 5) TM For Application Designers and Archietcts http://www.owasp.org/index.php/OWASP_AppSec_Europe_2008_-_Belgium

33. Threat Modeling and Risk Decision Making Threats can be resolved by: Risk Acceptance - doing nothing Risk Transference - pass risk to an externality Risk Avoidance - removing the feature/component that causes the risk Risk Mitigation - decrease the risk Mitigation strategies should be examined for each threat Mitigations should be chosen according to the appropriate technology Resolution should be decided according to risk level and cost of mitigations

34. Risk Mitigation Strategy Best Practices General Objectives: Translate the identified technical risk issues into business risk issues Determine whether standards compliance is violated Determine whether other compensating security controls and mitigation factors are present Determine which protective measure (e.g. security control, policy measures) should be in place to mitigate the threat, how should be implemented and when Determine short term and long term solutions

35. Application Risk Management Best Practices Eliminate vulnerabilities before they become liabilities 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 Set, enforce and report that software assurance thresholds are maintained Measurable reports prove progress internally and for compliance

36. Q & Q U E S T I O N S A N S W E R S