ISOL 536Security Architecture and DesignThreat Modeling.docx
- 1. ISOL 536 Security Architecture and Design Threat Modeling Session 6a “Processing Threats” Agenda • When to find threats • Playing chess • How to approach software • Tracking threats and assumptions • Customer/vendor • The API threat model • Reading: Chapter 7 When to Find Threats • Start at the beginning of your project
- 2. – Create a model of what you’re building – Do a first pass for threats • Dig deep as you work through features – Think about how threats apply to your mitigations • Check your design & model matches as you get close to shipping Attackers Respond to Your Defenses Playing Chess • The ideal attacker will follow the road you defend – Ideal attackers are like spherical cows — they’re a useful model for some things • Real attackers will go around your defenses • Your defenses need to be broad and deep “Orders of Mitigation” Order Threat Mitigation 1st Window smashing Reinforced glass
- 3. 2nd Window smashing Alarm 3rd Cut alarm wire Heartbeat signal 4th Fake heartbeat Cryptographic signal integrity By Example: • Thus window smashing is a first order threat, cutting alarm wire, a third-order threat • Easy to get stuck arguing about orders • Are both stronger glass & alarms 1st order mitigations? (Who cares?!) • Focus on the concept of interplay between mitigations & further attacks How to Approach Software • Depth first – The most fun and “instinctual” – Keep following threats to see where they go – Can be useful skill development, promoting “flow” • Breadth first – The most conservative use of time • Best when time is limited
- 4. – Most likely to result in good coverage Tracking Threats and Assumptions • There are an infinite number of ways to structure this • Use the one that works reliably for you • (Hope doesn’t work reliably) Example Threat Tracking Tables Diagram Element Threat Type Threat Bug ID Data flow #4, web server to business logic Tampering Add orders without payment checks 4553 “Need integrity controls on channel” Info disclosure Payment instruments sent in clear 4554 “need crypto” #PCI
- 5. Threat Type Diagram Element(s) Threat Bug ID Tampering Web browser Attacker modifies our JavaScript order checking 4556 “Add order- checking logic to server” Data flow #2 from browser to server Failure to authenticate 4557 “Add enforce HTTPS everywhere” Both are fine, help you iterate over diagrams in different ways Example Assumption Tracking Assumption Impact if it’s wrong Who to talk to Who’s following up Follow-up
- 6. by date Bug # It’s ok to ignore denial of service within the data center Availability will be below spec Alice Bob April 15 4555 • Impact is sometimes so obvious it’s not worth filling out • Who to talk to is not always obvious, it’s ok to start out blank • Tracking assumptions in bugs helps you not lose track • Treat the assumption as a bug – you need to resolve it The Customer/Vendor Boundary • There is always a trust boundary when: – Your code goes to someone else’s (device/premises) – Their data comes to your code • All about human trust issues • You need to think about it while deciding what
- 7. happens over the data flow shown Your software Customer device Your software Your data center Generic API Threat Model • Perform security checks inside the boundary • Copy before validation for purpose – Is http://evil.org/pwnme.html “valid”? • Define the purpose for data, validate near that definition • Manage error reporting • Document what checks happen where • Do crypto in constant time • Address the security requirements for your API Recap • When to find threats
- 8. • Playing chess • How to approach software • Tracking threats and assumptions • Customer/vendor • The API threat model