Synopsys Security Event Israel Presentation: Value Driven Threat Modeling
•
1 like•172 views
Avi Douglen, Software Security Advisor, Bounce Security presented at the Synopsys Security Event - Israel. For more information please visit us at www.synopsys.com/software
Recommended
More Related Content
Similar to Synopsys Security Event Israel Presentation: Value Driven Threat Modeling
Similar to Synopsys Security Event Israel Presentation: Value Driven Threat Modeling (20)
More from Synopsys Software Integrity Group
More from Synopsys Software Integrity Group (20)
Recently uploaded
Recently uploaded (20)
Synopsys Security Event Israel Presentation: Value Driven Threat Modeling
- 1. VALUE DRIVEN THREAT MODELING A Lightweight Approach By Avi Douglen
- 2. Summary ■ 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 ■ Email: AviD@BounceSecurity.com ■ Twitter: @sec_tigger ■ He / Him ■ The important things: – Whisky: smokey – Beer: stout – Coffee: strong ■ Software Security @ ■ 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
- 8. Classic Methodologies ■ STRIDE / STRIDE-per-element ■ Attack Trees ■ Asset-Focused ■ Software-centric ■ Attacker-focused ■ Risk-Based
- 9. STRIDE Per-Element ■ SSppooooffiinngg ■ TTaammppeerriinngg ■ RReeppuuddiiaattiioonn ■ IInnffoorrmmaattiioonn DDiisscclloossuurree ■ DDeenniiaall ooff SSeerrvviiccee ■ EElleevvaattiioonn ooff PPrriivviilleeggeess
- 11. Attack Trees
- 12. P.A.S.T.A ■ Risk-Based Methodology for higher assurance ■ PProcess for AAttack SSimulation and TThreat AAnalysis ■ Seven stage process:
- 15. From a Developer’s Perspective ■ Takes too much time!
- 16. From a Developer’s Perspective ■ “Security is everybody’s job”
- 17. From a Developer’s Perspective ■ “Think like an attacker”
- 18. From a Developer’s Perspective ■ Use case approach to user story development
- 19. From a Developer’s Perspective ■ Big Model Up Front
- 20. From a Developer’s Perspective ■ Threat model separate from design documentation
- 21. From a Developer’s Perspective ■ Usually out of date, often before its complete
- 22. From a Developer’s Perspective ■ Wasted time on unrealistic threats
- 23. From a Developer’s Perspective ■ Dependent on Security
- 24. From a Developer’s Perspective ■ Security team drops in and out
- 25. From a Developer’s Perspective ■ Security team doesn’t scale
- 26. From a Developer’s Perspective
- 30. 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”
- 31. 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?
- 33. Value Driven Process ■ Start from standard baseline – Skip obvious threats (e.g. XSS, HTTPS) – Relies on basic code hygiene – Security training for all developers and testers! – Threat Library ■ 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
- 34. Value Driven Process ■ Find the value of each feature – Follow the money! – How do people die?
- 35. 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
- 36. Value Driven for Non-Developers ■ Result of Threat Model: x Cross Site Request Forgery (CSRF) <-> x Stored XSS <-> x AuthZ Bypass <-> x Denial of Service <-> ■ Black-Box Threat Modeling ü Unauthenticated Access to Cash Transfer ü Admin Takeover ü Change Delivery Address ü Loss of Revenue/Market
- 37. 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
- 38. Limitations ■ Not complete ■ Misses a LOT of threats ■ Relies on developer experience ■ Security champion must be part of team ■ Low assurance for high risk systems
- 39. 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
- 40. THANKS FOR LISTENING! Find me on Twitter: @sec_tigger