Threat Modeling: Best Practices
8 likes•5,033 views
This document provides best practices and guidance for threat modeling. It discusses key concepts like taxonomy, timing of threat modeling, contributors, audience, and tools. Common pitfalls discussed include not making it a collaborative effort, poor presentation of results, deleting threats, failing to identify assets properly, making unreasonable threats, digging too deep initially, and not versioning threat modeling results. The overall aim is to help people understand how to effectively incorporate threat modeling into their projects and security development lifecycle.
Threat Modeling: Best Practices
- 1. Threat Modeling Best Prac3ces Helping Making Threat Modeling Work 1
- 2. About Robert Zigweid • Principal Compliance Consultant at IOAc3ve • CISSP, PCI QSA, PCI PA-‐QSA • Experienced in threat modeling and SDL 2
- 3. • What does Threat Modeling Mean to You? 3
- 4. Taxonomy • Make sure everyone speaks the same language. • Not just the same words, but the same meanings. 4
- 5. Taxonomy STRIDE DREAD All about the type All about IMPACT –S – Spoofing • D – Damage Poten3al –T – Tampering • R – Reproducibility –R – Repudia3on • E – Exploitability –I – Informa3on Disclosure • A – Affected Users –D – Denial of Service • D – Discoverability –E – Eleva3on of Privilege 5
- 6. Taxonomy The CIA C – Confiden3ality I – Integrity A – Accessibility 6
- 7. Timing • When do you start threat modeling a project? • What you need to know before you start • What are you building? • What needs to be protected? • It’s never too late! 7
- 8. Timing • How o_en? • At the beginning of a new release cycle is a great 3me • It’s not the only 3me • Try QA • Throw it in as part of a security push 8
- 9. Timing • When do you stop • When the project is end-‐of-‐life • When you don’t care anymore 9
- 10. Contributors • Who came up with that idea? • Project Owner • Architects • Developers • Testers • Everyone else! 10
- 11. Contributors • How to Contribute • Ini3al brainstorming • But you said that’s too early! • So, record the sessions • Before QA tes3ng • Emails • Issue tracker • Who cares? 11
- 12. Audience • O_en overlooked • The Audience • Management • Architects • Developers • QA • Forensics/Tes3ng • Others? 12
- 13. Threat Modeling and your SDL • Threat Modeling can be the vehicle for your SDL • Keeps it updated • Security Ques3onnaires when considering features • Deliver development requirements to developers • Test Plans • Test against iden3fied threats • Security Reviews 13
- 14. Templates • Based on Func3on Type • Grow the template library 14
- 15. Perspec3ves! • Ahacker! • How are they going to get me? • How do I stop it? • Assets • What do I care about most? • How do I protect it? 15
- 16. Understand Your Target • Project • Project Delivery 16
- 17. What about Agile? • The good! • Business people and developers must work together daily throughout the project. • At regular intervals, the team reflects on how to become more effec3ve, then tunes and adjusts its behavior accordingly. • Working so_ware is the primary measure of progress. • Security in so_ware is an essen3al part of “working” 17
- 18. What about Agile? • The ....bad • Welcome changing requirements, even late in development. • Deliver working so_ware frequently, from a couple of weeks to a couple of months, with a preference to the shorter 3mescale. • The most efficient and effec3ve method of conveying informa3on to and within a development team is face-‐ to-‐face conversa3on. 18
- 19. Tools • Microso_’s Threat Analysis and Modeling (2.1.2) • Pros • Flexibility • Doesn’t require data flow diagrams • Has a built in threat library to reference • Tracks threat modeling data well • Comes with an ahack library 19
- 20. Tools • Microso_’s Threat Analysis and Modeling (2.1.2) (con3nued) • Cons • No longer supported • Does not use STRIDE/DREAD, but CIA • Data flow diagrams require Visio • Can be difficult to begin working with • Supplied ahack library doesn’t necessarily fit, and can slow you down. 20
- 21. Tools • Microso_ SDL Threat Modeling Tool (3.1) • Pros • Currently supported and developed by Microso_ along with their SDL • Extensible • Can write plug-‐ins into your issue tracking system • Cons • It’s free! • Well sorta • Flexibility • Requires data flow diagrams 21
- 22. Tools • Trike • Pros • Methodology is driven by the tool • Methodology is very flexible • Automated threat genera3on • Cross-‐plaporm • Cons • Does not scale • Development of tool and methodology are somewhat slow 22
- 23. Tools • Others • Prac3cal Threat Analysis • What do I use? • Excel -‐-‐ some3mes • Word 23
- 24. Common Pipalls • It’s not a one person job • Poor presenta3on • Never, ever delete • Once a threat, always a threat • It’s history • Properly iden3fy assets 24
- 25. Common Pipalls • Keep your threats reasonable • Avoid Doomsday • Don’t dig too deep • You can always dive later • Snapshot • Keep it versioned 25
- 26. Ques3ons! 26
- 27. Thank you [email protected] 27