Threat Modeling is a great method to identify potential security flaws, part of any secure design. But instead of investing time + budget in a top-heavy, big-model-up-front threat modeling methodology, we can use a lightweight value-driven approach to embed security right into the agile dev process!

1. VALUE DRIVEN
THREAT MODELING
Security By Design
Avi Douglen
Bounce Security

2. Summary
■ Threat Modeling: most effective security activity
■ Developers shouldThreat Model too!
– Not just the security team
■ It can be Quick! Lightweight! Agile!
■ Prioritize by business value

4. About Me
■ Email: AviD@BounceSecurity.com
■ Twitter: @sec_tigger
■ He / Him
■ The important things:
– Whisky: smokey
– Beer: stout
– Coffee: black
■ Software Security @
■ Researcher / Developer / Architect
■ Moderator Security.StackExchange
■ OWASP Israel Leader
■ Threat Model Project Leader
■ Volunteer High School mentor

5. ■ Worldwide organization
■ Dedicated to software security
■ Free and Open source
■ All volunteers
■ Lots of projects
– Libraries
– Tools
– Guides
■ Israel chapter since 2006
■ AppSecIL conference
– FREE
– Over 800 attended
– Secure CodeTraining
■ AppSec Europe
– May, 2019 inTel Aviv!
– 600 International guests

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

7. Why Threat Modeling?
■ Discover unexpected potential attacks
■ Understand risk and prioritize vulnerabilities
■ Focus security efforts more efficiently
■ Communication
■ Documenting mitigations

8. “Classic” Threat Modeling
■ Data Flows and Attack Surface
■ Focus on Assets,Trust Boundaries
■ Visually with DFDs or other diagrams

9. Data Flow Diagram

10. Process Outline
Step#0: Scoping the Model
Step#1: Decompose the Application
Step#2: Identify theThreats (and risk level)
Step#3: Determine the Countermeasures
Step#4: Analyze Result

11. STRIDE
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privileges

14. Attack Trees

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

18. Developers’
Objections

19. Takes too much time!

20. “Security is everybody’s job”

21. “Think like an attacker”

22. Threats are obvious

23. Use case vs. user story approach

24. Big Model Up Front

25. Threat model separate from design

26. Usually out of date before completed

27. You want me to do WHAT with this?

28. Wasted time on unrealistic threats

29. Mismatch with SecurityTeam

30. Security team drops in and out

31. Security team doesn’t scale

36. Here is
something
different...

37. 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?
“AllThreat Models are wrong, some are useful”

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

41. Align workflow with incentives

42. Value Driven Process

43. Focus
■ Don’t waste time on known threats
– Start from standard baseline
– Assume common threats/attacks (e.g. XSS, HTTPS)
– Relies on basic code hygiene
– Security training for all developers and testers!
– Use aThreat Library

44. Scope
■ For each User Story / Epic / Feature
– During “Discovery” or Sprint Planning
– Agile approach of “just enough” threat model
– Threat model goes into the User Story

45. Find the value of each feature
– Follow the money!
– How do people die?

46. Workflow
1. State story goals
2. Describe correct flow and failure states
3. Highlight assumptions and conditions
4. Validate assumptions and enforce conditions
5. Explicitly handle failure states

47. OWASP Juice Shop

48. OWASP Juice Shop

49. OWASP Juice Shop

50. OWASP Juice Shop

51. OWASP Juice Shop

52. Value Driven Techniques

53. User Story Format
“As a … I want … so that … WITHOUT … ”
As a customer,
I want to complete a purchase
so that my kids stop screaming for juice
WITHOUT my credit card being stolen

54. Acceptance Criteria
When I login with a wrong password,
I should be locked out after X times.

55. Security Unit Tests
Test that accounts are locked after X attempts
Test locked accounts are unlocked afterY time

56. Threat Pyramid

57. Threat Pyramid

58. Threat Pyramid

59. Threat Pyramid

60. Abuser Stories
As an attacker,
I want to impersonate another user
so that I can steal their juicebox

61. Story Points
Relative estimate of effort
Sorry Points
Relative estimate of impact
“What if it goes horribly wrong?”

62. Definition of Done
User stories include a
threat model and security tests.

63. Benefits
■ Enables protection of application
■ Efficient security investment
■ Justify NOT implementing security feature
■ Integrated with agile design
■ Take ownership of security requirements
■ Shared understanding of system security
■ Don’t need piles of expensive consultants

64. Limitations
■ Not complete
■ Misses a LOT of threats
■ Relies on developer experience
■ Best with Security Champion on the team
■ Low assurance for high risk systems

65. Summary
■ Developers – start threat modeling!!
■ TM should be part of dev workflow
■ Focus on business value
■ Start with just the useful part ofTM
■ Skip the overkill – until you really need it

66. THANKS FOR
LISTENING!
Find me on Twitter: @sec_tigger