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.

DevSecCon Tel Aviv 2018 - Value driven threat modeling by Avi Douglen

398 views

Published on

DevSecCon Tel Aviv 2018 - Value driven threat modeling by Avi Douglen

Published in: Technology
  • Be the first to comment

DevSecCon Tel Aviv 2018 - Value driven threat modeling by Avi Douglen

  1. 1. Join the conversation #DevSecCon BY AVI DOUGLEN Value Driven Threat Modeling A Lightweight Approach
  2. 2. My Core Message • Threat Modeling is great, but not used enough • Developers should Threat Model too, not just security • Prioritize by business value • Make it quick, make it lightweight, make it Agile
  3. 3. About Me • He / Him • Email: AviD@BounceSecurity.com • Twitter: @sec_tigger • The important things: • Whisky: smoky • Beer: stout • Coffee: strong • Software Security at • Researcher / Developer / Architect • OWASP Israel Leader • Moderator Security.StackExchange • Volunteer High School teacher • Threat Model Project Leader
  4. 4. What is Threat Modeling? •Structured security-based analysis •Framework to understand threats •Review of Design Elements •Prioritize Mitigations by Risk
  5. 5. “Classic” Threat Modeling • Data Flows and Attack Surface • Focus on Assets, Trust Boundaries • Visually with DFDs or other diagrams • Step#0: Scoping the Model • Step#1: Decompose the Application • Step#2: Identify the Threats (and risk level) • Step#3: Determine the Countermeasures • Step#4: Analyze Result
  6. 6. Data Flow Diagram
  7. 7. Classic Methodologies •STRIDE / STRIDE-per-element •Attack Trees •Asset-Focused •Software-centric •Attacker-focused •Risk-Based
  8. 8. STRIDE Per-Element •Spoofing •Tampering •Repudiation •Information Disclosure •Denial of Service •Elevation of Privileges
  9. 9. Attack Trees
  10. 10. P.A.S.T.A •Risk-Based Methodology for higher assurance •Process for Attack Simulation and Threat Analysis •Seven stage process:
  11. 11. From a Developer’s Perspective •Takes too much time!
  12. 12. From a Developer’s Perspective •“Security is everybody’s job”
  13. 13. From a Developer’s Perspective •“Think like an attacker”
  14. 14. From a Developer’s Perspective •Use case approach to user story development
  15. 15. From a Developer’s Perspective •Big Model Up Front
  16. 16. From a Developer’s Perspective •Threat model separate from design documentation
  17. 17. From a Developer’s Perspective •Usually out of date, often before its complete
  18. 18. From a Developer’s Perspective • Wasted time on unrealistic threats
  19. 19. From a Developer’s Perspective •Dependent on Security
  20. 20. From a Developer’s Perspective •Security team drops in and out
  21. 21. From a Developer’s Perspective •Security team doesn’t scale
  22. 22. From a Developer’s Perspective
  23. 23. Back to Basics •4 core questions of threat modeling: 1. What are you building? 2. What can go wrong? 3. What are you going to do about it? 4. Did we do a good job? •“All Threat Models are wrong, some are useful”
  24. 24. Reframing TM •Accept that it’s wrong, focus on the usefulness 1. Why are we building this? 2. What needs to go right? 3. How do we make sure that happens?
  25. 25. Value Driven Process • Start from standard baseline • Skip obvious threats (e.g. XSS, HTTPS) • Relies on basic code hygiene • Threats Library • Security training for all developers and testers! • Threat model each User Story / Epic • During “Discovery” or Sprint Planning • Agile approach of “just enough” threat model • Threat model goes into the User Story
  26. 26. Value Driven Process •Find the value of each feature • Follow the money! • How do people die?
  27. 27. Value Driven Process •State story goals •Describe correct flow and conditions •Highlight assumptions and failure states •Validate assumptions and enforce conditions •Explicitly handle failure states
  28. 28. OWASP Juice Shop
  29. 29. OWASP Juice Shop
  30. 30. OWASP Juice Shop
  31. 31. OWASP Juice Shop
  32. 32. OWASP Juice Shop
  33. 33. Value Driven Techniques •Acceptance Criteria •Definition of Done When I login with a wrong password, I should be locked out after X times.
  34. 34. Value Driven Techniques •Security unit tests Test that user accounts are locked after X attempts Test that locked user accounts are unlocked after Y time
  35. 35. Value Driven Techniques •Abuser stories As an attacker, I want to try a large number of passwords, so that I can impersonate another user and steal their juicebox
  36. 36. Value Driven Techniques •Threat Pyramid
  37. 37. Value Driven Techniques •Threat Pyramid
  38. 38. Value Driven Techniques •Threat Pyramid
  39. 39. Value Driven Techniques •Threat Pyramid
  40. 40. Value Driven Techniques •Threat Pyramid
  41. 41. Value Driven Techniques Story Points Relative estimate of effort Sorry Points Relative estimate of impact “What if it goes horribly wrong?”
  42. 42. Value-Driven for Non-Developers Compare: • Cross Site Request Forgery <-> (CSRF) • Stored XSS <-> • AuthZ Bypass <-> • Denial of Service <-> • Black-Box Threat Modeling • Unauthenticated Access to Cash Transfer • Admin Takeover • Change Delivery Address • Loss of Revenue/Market
  43. 43. Benefits over Classic TM • Much quicker – faster to useful TM • In tune with pace of development • Iterative – just like agile development • More natural for developers • Documentation always up to date • Better communication • Easier to integrate with eg Scrum, Kanban • Don’t need piles of consultants • Scalable
  44. 44. Limitations •Not complete •Misses a LOT of threats •Relies on developer experience •Security champion needs to be embedded in team •Low assurance for high risk systems
  45. 45. Summary • Developers – start threat modeling!! • TM should be part of dev workflow • Focus on business value • Start with the useful part of TM – and stop there • Skip the overkill – until you really need it
  46. 46. Join the conversation #DevSecCon Thanks for listening! Find me on Twitter: @sec_tigger

×