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

1. Join the conversation #DevSecCon
BY AVI DOUGLEN
Value Driven Threat Modeling
A Lightweight Approach

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

4. 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

5. What is Threat Modeling?
•Structured security-based analysis
•Framework to understand threats
•Review of Design Elements
•Prioritize Mitigations by Risk

6. “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

7. Data Flow Diagram

8. Classic Methodologies
•STRIDE / STRIDE-per-element
•Attack Trees
•Asset-Focused
•Software-centric
•Attacker-focused
•Risk-Based

9. STRIDE Per-Element
•Spoofing
•Tampering
•Repudiation
•Information Disclosure
•Denial of Service
•Elevation of Privileges

12. Attack Trees

13. P.A.S.T.A
•Risk-Based Methodology for higher assurance
•Process for Attack Simulation and Threat Analysis
•Seven stage process:

16. From a Developer’s Perspective
•Takes too much time!

17. From a Developer’s Perspective
•“Security is everybody’s job”

18. From a Developer’s Perspective
•“Think like an attacker”

19. From a Developer’s Perspective
•Use case approach to user story development

20. From a Developer’s Perspective
•Big Model Up Front

21. From a Developer’s Perspective
•Threat model separate from design documentation

22. From a Developer’s Perspective
•Usually out of date, often before its complete

23. From a Developer’s Perspective
• Wasted time on unrealistic threats

24. From a Developer’s Perspective
•Dependent on Security

25. From a Developer’s Perspective
•Security team drops in and out

26. From a Developer’s Perspective
•Security team doesn’t scale

27. From a Developer’s Perspective

31. 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”

32. 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?

34. 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

35. Value Driven Process
•Find the value of each feature
• Follow the money!
• How do people die?

36. 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

37. OWASP Juice Shop

38. OWASP Juice Shop

39. OWASP Juice Shop

40. OWASP Juice Shop

41. OWASP Juice Shop

42. Value Driven Techniques
•Acceptance Criteria
•Definition of Done
When I login with a wrong password,
I should be locked out after X times.

43. 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

44. 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

45. Value Driven Techniques
•Threat Pyramid

46. Value Driven Techniques
•Threat Pyramid

47. Value Driven Techniques
•Threat Pyramid

48. Value Driven Techniques
•Threat Pyramid

49. Value Driven Techniques
•Threat Pyramid

50. Value Driven Techniques
Story Points
Relative estimate of effort
Sorry Points
Relative estimate of impact
“What if it goes horribly wrong?”

51. 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

52. 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

53. 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

54. 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

55. Join the conversation #DevSecCon
Thanks for listening!
Find me on Twitter: @sec_tigger