AppSec USA 2014 Denver, Colorado Threat Modeling Made Interactive! Eunsuk Kang Software Design Group...

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?

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

Questions?eskang@mit.edu