AppSec USA 2014 Denver, Colorado Threat Modeling Made Interactive! Eunsuk Kang Software 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?

Try Poirot at: sdg.csail.mit.edu/poirot Questions?