Threat Modeling - Improve Security, Drive Testing, & Reduce Costs

7,806 views

Published on

Over the last few years, significant progress has been made in back end SDLC security controls. Vendors have developed sophisticated analysis tools focusing on code inspection and application testing and organizations are incorporating both automated and manual assessment methods into the latter half of their development process. However, adoption of architectural risk analysis has not been as widespread. Although threat modeling is not a new concept and approaches such as Microsoft's STRIDE are well known, companies have not internalized and adopted design related security controls with the same vigor. The purpose of this presentation is to provide an understanding of what threat modeling is, why it is important, and champion its benefits.

Praetorian's goal is to help our clients understand minimize their overall security exposure and liability. Through our services, your organization can obtain an accurate, independent security assessment.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,806
On SlideShare
0
From Embeds
0
Number of Embeds
4,153
Actions
Shares
0
Downloads
234
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Threat Modeling © 2009 Praetorian. All rights reserved. According to BSIMM all 9 organizations surveyed include security activities in the design phase; however, these are companies such as Microsoft, Google, Adobe, etc where a real and concerted efforts is being made in the way of software security. Most of the focus by organizations, vendors, and service providers is on backend security controls in the development and testing phases such as code reviews (static analysis) or application penetration tests (dynamic analysis). Odd considering the cost benefit analysis graph presented earlier
  • Threat Modeling © 2009 Praetorian. All rights reserved. Threat modeling is a security control integrated into the design phase of the SDLC
  • The cost to correct a bug (and vulnerabilities should be treated as flaws or bugs) exponentially increases the further along a product is in the SDLC. According to the IEEE Computer Society fixing a single bug in the requirements phases will cost on average $139. A bug during the deployment phase will cost on average $14,102. Statistics for the maintenance phases were not found, but given maintenance fixes will be even more expensive and that the maintenance phase accounts for 60 to 70% of the SDLC, you have to scratch your head why companies are not focusing as much effort on integrating security into the front two phases. Threat Modeling © 2009 Praetorian. All rights reserved.
  • Threat Modeling © 2009 Praetorian. All rights reserved. In Michael Howard ’s book, Secure Coding, you can see the rise of importance of threat modeling between the two editions. In the first edition, threat modeling is a subsection of the design chapter. By the second edition, its has its own chapter outright. Gary McGraw may make a stink on the term threat modeling and how it relates to architectural risk analysis, but for the purposes of this presentation, this is the definition we are using.
  • Threat Modeling © 2009 Praetorian. All rights reserved. This is not an all encompassing list, there are actually quite a few more benefits to threat modeling.
  • Threat Modeling © 2009 Praetorian. All rights reserved.
  • Threat Modeling © 2009 Praetorian. All rights reserved. Several methodologies available including Microsoft ’s SDL, Cigital’s ARA, and Foundstone’s SDDLC. Integration should work within current architecture and design process
  • Various pictorial representations are available. The visual mapping chosen should coincide with teams familiarity to a particular representation and not driven by a consultants expertise in one area (or lack there of in others). Remember, threat modeling will be considered additional process and headache for architects and developers. The harder you make it on them, the quicker they will tune you out!
  • Threat Modeling © 2009 Praetorian. All rights reserved. That said, flow charts are probably one of the worst visual representations of a systems architecture for threat modeling because it is difficult to overlay the threats
  • Threat Modeling © 2009 Praetorian. All rights reserved. A few core elements compromise Microsoft DFDs. These elements have changed over the years and some have been added and removed.
  • Threat Modeling © 2009 Praetorian. All rights reserved. The problem with UML is it means different things to different people. Again, the key is to go with what the developers have already created.
  • Threat Modeling © 2009 Praetorian. All rights reserved. The Microsoft STRIDE/DREAD model is perhaps one of the most commonly referred to methods when people discuss threat modeling. What people need to understand is STRIDE an internal Microsoft process that they decided to release to the world in an effort to promote software security, but Microsoft is also the first to admit that their methodology is not a one size fits all and may not be right for every organization.
  • Threat Modeling © 2009 Praetorian. All rights reserved. The ASF is a common approach to how things are categorized at Foundstone
  • Threat Modeling © 2009 Praetorian. All rights reserved.
  • Threat Modeling © 2009 Praetorian. All rights reserved.
  • Threat Modeling © 2009 Praetorian. All rights reserved. According to BSIMM all 9 organizations surveyed include security activities in the design phase; however, these are companies such as Microsoft, Google, Adobe, etc where a real and concerted efforts is being made in the way of software security. Most of the focus by organizations, vendors, and service providers is on backend security controls in the development and testing phases such as code reviews (static analysis) or application penetration tests (dynamic analysis). Odd considering the cost benefit analysis graph presented earlier
  • Threat Modeling © 2009 Praetorian. All rights reserved. Moreover, in many organizations security is inserted to the SDLC, but does not really work within the process. In other words its disconnected. Under such circumstances, the output of a threat model can devolve to nothing more than a software artifact that no one reads.
  • Threat Modeling © 2009 Praetorian. All rights reserved. Moreover, in many organizations security is inserted to the SDLC, but does not really work within the process. In other words its disconnected. Under such circumstances, the output of a threat model can devolve to nothing more than a software artifact that no one reads.
  • Threat Modeling © 2009 Praetorian. All rights reserved. Moreover, in many organizations security is inserted to the SDLC, but does not really work within the process. In other words its disconnected. Under such circumstances, the output of a threat model can devolve to nothing more than a software artifact that no one reads.
  • Threat Modeling - Improve Security, Drive Testing, & Reduce Costs

    1. 1. Threat Modeling "Threat modeling at the design phase is really the only way to bake security into the SDLC.” – Michael Howard, Microsoft Nathan Sportsman Founder and Chief Executive Officer1 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    2. 2. Agenda  Introduction  Process Overview  Current State Analysis  Workshop2 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    3. 3. Introduction3 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    4. 4. Activities Core Security Secure Development Lifecycle Planning Functional Requirements Requirements Non Functional Requirements Security Objectives and Analysis Technical Requirements Architecture Design Guidelines Threat Modeling and Design Architecture and Design Review Architectural Risk Analysis Unit Tests Development Code Review Security Code Review Daily Builds Integrated Testing Testing Security Testing System Testing Deployment Review Deployment Penetration Testing Maintenance Risk Assessment4 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    5. 5. Requirements $139 Design $455 Development $977 Testing $7,136 Estimates provided by IEEE Computer Society Deployment $14,1025 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    6. 6. Threat Modeling Is  …a security control performed during the architecture and design phase of the SDLC to identify and reduce risk within software » Also called architectural risk analysis depending what camp you talk to » Sit down between security experts and architects & development leads » Performed through white boarding and thoughtful discussion » Accomplished over 2 to 5 day time period depending on application complexity6 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    7. 7. Threat Modeling Benefits  Improves Security » Champions threat analysis » Uncovers logical/architectural vulnerabilities » Reduces risk and minimizes impact  Drives Testing » Validates design meets security requirements » Reduces scope of code inspection » Serves as a guide for verification testing  Reduces Cost » Identifies expensive mistakes early on » Improve understanding and structure of application » Decreases new hire ramp up time7 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    8. 8. Threat Modeling Process8 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    9. 9. Threat Modeling Approaches  Attack Centric » Evaluates from the point of view of an attacker  Defense Centric » Evaluates weakness in security controls  Asset Centric » Evaluates from asset classification and value  Hybrid » Evaluates application design using combination of methodologies to meet security objectives9 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    10. 10. Threat Modeling Process » Identify Security Objectives » Application Overview » Decompose Application » Identify Threats (and Countermeasures) » Identify Vulnerabilities » Repeat10 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    11. 11. Application Understanding11 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    12. 12. Application Overview  Review any related documentation provided before the threat model  Documentation is usually out of date, but can still provide an overview of the application  Developers should give an overview of the applications purpose and key features  Review security requirements and how the design fulfills those specifications12 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    13. 13. Characterize The System  Scenarios are very useful in identifying threats  Common use and abuse cases should be understood  Cases should come from security requirements, If cases are not available, create and analyze your own abuse cases with developers13 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    14. 14. Application Decomposition14 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    15. 15. Application Modeling  Flow Chart » Less commonly used » Difficult to overlay threats  Data Flow Diagrams (DFD) » Hierarchical in nature » Focused on data input » Representation used by Microsoft  Universal Modeling Language (UML) » Familiar to developers » OO and component diagramming15 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    16. 16. Flow Chart16 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    17. 17. Data Flow Diagram17 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    18. 18. Universal Modeling Language (Functional) Client Teller Authenticate Authorize Process Check Deposit Withdrawal Balance Update Account Log Transaction18 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    19. 19. Threat Identification19 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    20. 20. Microsoft STRIDE Categorization20 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    21. 21. Application Security Frame Categorization21 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    22. 22. Threat Trees Steal money Stick up bank teller Bribe bank teller Impersonate client Intimidate client I P P I P – Probable I - Improbable22 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    23. 23. Vulnerability Prioritization23 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    24. 24. General Risk Approach Risk = Threat X Vulnerability X Cost Threat = An action intended to do damage or harm Vulnerability = Likelihood of success of a threat Cost = Total impact or cost of the incident24 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    25. 25. Microsoft DREAD Categorization25 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    26. 26. Structured Lists  Round table discussion  Prioritization based on consensus  Utilize Praetorian Risk Approach  Numbered list generated26 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    27. 27. Current State Analysis27 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    28. 28. Activities Organizations Are Doing Now  Only a handful of companies are actually introducing security into the SDLC in any meaningful way  Prior focus by vendors, security service providers, and clients tended to be on back end security controls  Other than industry thought leaders, little effort is being paid to the importance of front end controls such as security requirement reviews and threat modeling  Backwards approach due to lack of awareness, preexisting systems, and legacy code28 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    29. 29. Adoption Constraints  In its current form threat modeling generally requires outside security expertise  Expensive cost limits threat modeling to one off expenditures for only the most critical applications  Difficult to internalize and reproduce process across application portfolios  Tools limited functionality and to scalability inhibits development team empowerment29 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    30. 30. Future Predictions  Software security initiatives at more and more organizations will mature and incorporate threat modeling  Threat modeling tools will become more sophisticated and enterprise ready30 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    31. 31. References  Frank Swiderski and Window Snyder. Threat Modeling. Microsoft Press, 2004.  Michael Howard and David LeBlanc. Writing Secure Code 2nd Edition. Microsoft Press, .  Microsoft Application Threat Modeling Blog http://blogs.msdn.com/threatmodeling/  Microsoft SDL Threat Modeling Tool http://msdn.microsoft.com/en-us/security/dd206731.aspx  Building Maturity in Security Model http://www.bsi-mm.com/  OWASP Application Threat Modeling http://www.owasp.org/index.php/Application_Threat_Modeling31 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    32. 32. Unlock Conundrum Workshop  Cell Phone Manufacturer is caught with its pants down and has found out that $6,000,000 worth of unlock codes have been sold by their overseas support personnel  Using a internal, web based tool, support personnel are able to query unlock codes used to unlock the phone for diagnostic purposes  Unfortunately, employees are abusing the system and setting up websites and selling unlock codes out of band to customers for personal profit  Manufacturer has asked a threat model be performed on the new design of the application which they hope will stop the abuse32 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured
    33. 33. Threat Modeling “In fact, during the Windows Security Push (and all pushed that followed at Microsoft, we found that the most important aspect of the software design process, from a security viewpoint, is threat modeling.” – Michael Howard, Microsoft, Writing Secure Code 2nd Edition Nathan Sportsman Founder and Chief Executive Officer33 Entire contents © 2011 Praetorian. All rights reserved. Your World, Secured

    ×