Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Application Threat Modeling In Risk Management


Published on

How to perform threat modeling of software to protect your business, critical assets and communicate your message to your boss and the Board of Directors

Published in: Technology
  • Be the first to comment

Application Threat Modeling In Risk Management

  1. 1. Making it real for management Mel Drews
  2. 2. Mel Drews CISSP, CISA, GWEB, GCFE, ABCDE Background  Configuring, managing technical security  Penetration testing  Designing governance & controls  Consulting on compliance issues  Operational risk assessments  IT security audit
  3. 3. Focusing on software because...  We deploy infrastructure controls (firewalls, anti-malware, IDS/IPS, etc.), but what are we trying to protect? What is vulnerable? – data and applications.  According to Gartner*, in 2014 enterprises spent $12B securing their network perimeters, but only $600M security applications.  Depending on industry, web applications account for up to 35% of data breaches.*  Lessons are applicable to other attack surfaces  Usefulness of approaching a complex problem from multiple angles
  4. 4. If it’s about people, processes and technology... What do we want these people to get out of the exercise?
  5. 5. We can...  Quantify risks in a realistic manner (disclaimer, disclaimer).  Identify previously unexamined control gaps exposing high-impact systems or processes.  Identify the mitigations that will give the best bang for the buck – not a ROI number, but relative ranking.  Give a realistic picture of how (in)secure we really are
  6. 6. Operationalizing risk assessment
  7. 7. What’s your attack surface?
  8. 8. What is a “threat”? Open Group – “Anything that is capable of acting in a manner resulting in harm to an asset and/or organization; for example, acts of God (weather, geological events, etc.); malicious actors; errors; failures.” (The Open Group, 2009) DHS – “Natural or man-made occurrence, individual, entity, or action that has or indicates the potential to harm life, information, operations, the environment, and/or property.” (Department of Homeland Security [DHS], 2010) BITS – “Threat is anything that can act against an asset resulting in a potential loss.” (BITS, 2012)
  9. 9. Ways to model threats in software  Find all possible / likely bad actions  Attack trees  Misuse / Abuse cases  CAPEC  Analyze the code / application  Architectural Risk Analysis  Attack surface analysis  Attack paths  SDL  Code review  Static analysis  Blackbox methods  Fuzzing  Vulnerability scanning
  10. 10. Challenges to doing threat modeling  Confusion on what constitutes a threat vs. a vulnerability vs. a risk  Lack of guidance on methods to identify assets  Requiring participants with requisite expertise and training in threat analysis, a strong understanding of application design and a well-structured process  Security experts often learn from different risk profiles and use different techniques for modeling  Teaching threat modeling requires an apprentice-based approach that involves an appropriate curricula, adequate investment in effective education tools and a process for educating appropriate constituencies  Different types of applications have very different risk profiles meaning the threats will vary depending factors such as the application architecture (BITS, 2012)
  11. 11. Attack Trees  Identify possible attack goals  Think of all attacks against each goal
  12. 12. Attack Paths  “The attack targets are analyzed based on their connections to attack surfaces through call relationships.” (Brenneman, 2014)
  13. 13. Cyber Kill Chains®  Reconnaissance  Weaponization  Delivery  Exploit  Installation  Command & Control  Actions
  14. 14. Misuse / Abuse Case
  15. 15. Common Attack Pattern Enumeration and Classification (CAPEC) (MITRE Corp, 2014)
  16. 16. “Design flaws account for 50 percent of security problems, and architectural risk analysis plays an essential role in any solid security program.” (McGraw, 2006) Architectural Risk Review
  17. 17. Architectural flaw examples:  Forgot to authenticate the user  Broken authentication mechanism  No mapping of access control to job requirements  Insecure (or no) implementation of auditing functions  Failure to understand trust relationships – too much trust  Failure to employ encryption  Dependence on components with known vulnerabilities (libraries, frameworks, other modules)
  18. 18. Attack Surface Analysis  Targets and enablers Resources (processes and data) that an attacker can use or co-opt.  Channels and protocols Message passing and shared memory between endpoint processes and the rules for exchanging information.  Access rights Associated not only with files and directories, but also channels and endpoint processes. (Howard, Pincus & Wing, 2003)
  19. 19. Microsoft SDL Overview  Education  Continuous process improvement  Accountability (Microsoft. SDL Process: Design, 2014) (Microsoft, 2010)
  20. 20. (Microsoft, 2014)
  21. 21. Threat Modeling in the Microsoft SDL  SDL Phase II – Design:  “Threat modeling is used in environments where there is meaningful security risk. It is a practice that allows development teams to consider, document, and discuss the security implications of designs in the context of their planned operational environment and in a structured fashion. Threat modeling also allows consideration of security issues at the component or application level. Threat modeling is a team exercise, encompassing program/project managers, developers, and testers.” (Microsoft, 2010)
  22. 22. MS Threat Modeling steps  Diagramming  Data flow  Threat Enumeration  Focus on trust boundaries  S•T•R•I•D•E  List of threats  Team exercise engaging program/project managers, developers and testers  Mitigation  Validation  Completeness & accuracy of threats and the model (Shostack, 2008)
  23. 23. STRIDE  Spoofing  Tampering  Repudiation  Information Disclosure  Denial of Service  Escalation of Privilege (Shostack, 2008)
  24. 24. Demo time
  25. 25. (Microsoft, Introducing Microsoft Threat Modeling Tool,2016) Customizing the threat table
  26. 26. Critical Security Controls  CSC 2: Inventory of Authorized and Unauthorized Software.  CSC 4: Continuous Vulnerability Assessment and Remediation.  CSC 18: Application Software Security.  CSC 20: Penetration Tests and Red Team Exercises (in a mature control environment)
  27. 27. Asset Characterization Excerpt from System Characterization Worksheet, available under Creative Commons license at
  28. 28. Asset list or database Impacts Asset Confidentiality Impact Integrity Impact Availability Impact Has Exposure X Has Exposure Y Inherent Risk Control Strength Overall Score Residual Risk LOB App1 $1M $200K $500K Y Y 100 4 25 Customer Svc App $800K $100K $80K N Y 45 3 15
  29. 29. Threat matrix
  30. 30. Risk, impact, likelihood, recommendation Risk Impact Likelihood Recommendation History of poor coding practices: While patches are available to address known vulnerabilities in the currently installed application version, application vendor, SoftCorp, has had a history of severe vulnerabilities recurring in multiple products. Their response to reported vulnerabilities has sometimes taken up to a year to address such issues. Application processes thousands of records daily and stores approximately 1.2 million unique data records. Unauthorized disclosure of this data could lead to costs in excess of risk appetite related to: Communication to regulators and customers, investigations, emergency remediation activities, enhanced regulatory scrutiny Currently known and previously patched vulnerabilities have been susceptible to exploitation by attackers possessing minimal skill or resources and only external connectivity. 1. Apply available patches 2. Deploy a Web Application Firewall between users and the application server. 3. Evaluate the feasibility of migrating to other available products. Management Response:
  31. 31. Quantifying Risk  Granularity?  Percentage of similar organizations experiencing a breach  Detailed analysis of likelihood impacting a given exposure  Control Strength  Threat Capability  Loss Event Frequency  What is the event / scenario?
  32. 32. Loss Magnitude  Direct costs due to loss of integrity  Direct costs due to unavailability  Don’t ask about confidentiality, ask about factors that allow you to calculate it as the expert:  Number of unique data records holding PII/NPII/PHI  Number of financial transactions processed by the application daily / monthly  Dollar value of financial transactions processed by the application if any, daily / monthly
  33. 33. Factor in additional costs  Direct:  Investigating  remediating  communicating  credit monitoring  Indirect:  Regulatory  Legal  Opportunity
  34. 34. Insider Threat  SEI CERT has a database cataloging more than 700 cases of malicious insider activity.*  Methods vary between cases involving technical staff and those that don’t.  Our threat models and controls need to address both
  35. 35. Who uses or recommends threat modeling?  Microsoft  Apple (Apple, 2014)  EMC (Dhillon, 2011)  VMware  Oracle (Oracle, 2014)  Mitre Corporation (MITRE, 2011)  India (Microsoft 2012)  Are you studying for the CSSLP? (ISC2, 2013)
  36. 36. Is it secure enough?
  37. 37. Apple. Risk Assessment and Threat Modeling. Retrieved 23 June 2014, from ual/security_overview/ThreatModeling/ThreatModeling.html#//apple_ref/ doc/uid/TP40002495-SW5 BITS / The Financial Services Roundtable. (2011). Software Assurance Framework. Brenneman, D. Improving Software Security by Identifying and Securing Paths Linking Attack Surfaces to Attack Targets. McCabe Software. Retrieved 9 June 2014, from 0Linking%20Attack%20Surfaces%20to%20Attack%20Targets.pdf BSIMM. Building Security In Maturity Model. Retrieved 24 June 2014, from Department of Homeland Security. (2010). DHS Risk Lexicon.
  38. 38. Dhillon, D. (2011). Developer-Driven Threat Modeling. IEEE Security & Privacy. modeling Dougherty, C., Sayre, K., Seacord, R., Svoboda, D., Togashi, K. (October 2009). Secure Design Patterns. Technical Report CMU/SEI-2009- TR-010 . Carnegie Mellon University Software Engineering Institute. view.cfm?assetid=9115 Hafiz, M., Security Pattern Catalog. Retrieved 13 June 2014 from Howard, M., Pincus, J., & Wing, J. (2003). Measuring Relative Attack Surfaces. Wing03.pdf ISC2. (2013). Certified Secure Software Lifecycle Professional. April 2013. McGraw, G. (2006). Software Security: Building Security In. Addison- Wesley. ISBN-10: 0321356705
  39. 39. Microsoft Corporation. Benefits of the SDL. Retrieved 20 June 2014, from Microsoft Corporation (2012). Government of India Embraces Secure Application Development. us/download/confirmation.aspx?id=29857 Microsoft Corporation. (2014). Introducing Microsoft Threat Modeling Tool 2014. Retrieved 23 June 2014, from microsoft-threat-modeling-tool-2014.aspx Microsoft Corporation. SDL Process: Design. Retrieved 24 June 2014, from Microsoft Corporation. (2010). Simplified Implementation of the Microsoft SDL. us/download/details.aspx?id=12379&751be11f-ede8-5a0c-058c- 2ee190a24fa6=True MITRE Corporation. (2014). Common Attack Pattern Enumeration and Classification. Retrieved 6 June 2014, from
  40. 40. MITRE Corporation. (2011). Threat Assessment and Remediation Analysis (TARA). papers/threat-assessment--remediation-analysis- tara The Open Group. (2009). Risk Taxonomy. Schneier, B. (1999). Attack Trees. Schneier on Security. Retrieved 13 June 2014, from ft.html
  41. 41. Scott, J. & Kazman, R. (2009). Realizing and Refining Architectural Tactics: Availability. Security Architecture Patterns. In Open Security Architecture. Retrieved 13 June 2014 from nlandscape Shostack, A. (2008). Experiences Threat Modeling at Microsoft. s-threat-modeling-at-microsoft.aspx Singhal, A. & Ou, X. (2011). Security Risk Analysis of Enterprise Networks Using Probabilistic Attack Graphs. National Institute of Standards and Technology Interagency Report 7788. 7788.pdf