Embed Size (px)
Citation preview
AppSec USA 2014
Denver, Colorado
Threat Modeling Made Interactive!
Eunsuk KangSoftware Design Group
CSAIL, MIT
• Software Design Group, Computer Science and Artificial Intelligence Laboratory (CSAIL)
• Leader: Prof. Daniel Jackson• Research interests: Architecture, modeling,
requirements, security, safety, program analysis, verification, testing
• Systems: Electronic voting, radiation therapy system, network protocols, biometric access control, web application, smart grids…
Introduction
• “What could possibly go wrong with my system?”
• Three components– Policy: What customers care about – System model: Not just the software!– Environment model: Both good & bad agents
• What are possible ways in which the system, operating under the specified environment, may fail to satisfy its security policy?
What is Threat Modeling?
• “All models are wrong, but some models are useful.” (George Box)
• Identify & prioritize risks early in development• Explore security implications of design decisions • Build mitigations into the design• BUT not intended for:– Finding implementation bugs (e.g., SQL injection)– Proving that your system is 100% secure
Why Threat Model?
Threat Modeling Today
• Whiteboards & diagramming tools• SDL Threat Modeling Tool (Microsoft)• Elevation of Privilege (Adam Shostack)• TRIKE (Saitta, Larcom, Eddington)• ThreatModeler (myappscurity.com)
Threat Modeling Today
• Diversity of threats– Multiple types of attacks, chained together
• Initial unknowns about system & threats– Design decisions impact knowledge
• Throw away once used• Expressing & checking policy
What Makes Threat Modeling Hard?
• Interactive & incremental modeling– Start small, evolve model & re-analyze
• Reusable models– Capture & reuse domain knowledge– Extensible attack library
• Automated analysis– Find subtle, corner cases with exhaustive analysis
• Visualization– Generate & step through sample attack scenarios
Threat Modeling With Poirot
Demo
Poirot
• Dataflow for basic representation• Attack trees (Bruce Schneier)– Chaining together attacker’s actions
• CVE, CWE, CAPEC, and other databases• Information flow labels (Dorothy Denning)– Specifying security policies
• Techniques from program verification– Exhaustive checking of properties
Ideas We’re Borrowing From
How Poirot Work
• Access control through API operations– Constraints on parameters
• Partiality– Start with underspecified design & strengthen
• Knowledge reuse through instantiation• Automation– Attack generation as constraint solving
Poirot: Key Ideas
• Cannot check implementation for security vulnerabilities
• Cannot tell you about attacks outside the attack library
• Cannot tell you whether your system model is accurate
What Poirot Can’t Do
• How can Poirot be useful to you?• Looking beyond the Web– Poirot is generic, and can be populated with
knowledge from other domains– Medical devices– Internet of Things
What’s Next?
