Thoughts on Using and Scaling Threat Modeling

Some of my pet peeves with Threat Modeling, as its currently done by a lot of organisations out there:

1. Threat Models are generated as tomes, rarely used by the people who need to be using it (architects, engineering teams, business owners, even security people)
2. Consequently, Threat Modeling does not scale. It doesn't keep pace with activity (rapid release cycles) or across a large population of apps OR both

Here are some (quick n dirty) rough notes of mine on some approaches to how we can use (and consequently scale) threat models better

‍Keep Scope Small and Iterative

‍To make threat models work for you, I (and some of my friends who do threat modeling) strongly believe you should keep your scope small. Examples of small scope:

• User Story/Feature Definition
• A module of an otherwise larger application
• A MicroService (depends on size)
• A Function as part of a Microservice. I love Threat Modeling for FaaS (Functions as a Service). You can get great (read granular) results threat modeling for functions.

By keeping your scope small, you are additionally facilitating the ability to leverage patterns (from features) of your threat model that can be reused by similar functionality in another app or other segment of the same app.

‍Produce Artifacts from Threat Model

‍Don't let your Threat Model end up as a PDF that no one reads. Use outputs from your Threat Model to:

• define what developers should check/look for while writing code - in the form of checklists, mitigations, static rules, linter rules and secure coding guidelines.
• define what your pentesters and red-teamers should look for when finding security bugs in the app - in the form of offensive security test cases, exploit scripts, attack simulations
• define aspects of your incident management practice - in the form of inputs to security tabletop exercises, logging and monitoring parameters, alerting parameters and thresholds

Continuous Improvement > Perfection

‍A lot of us can't wrap our minds around some of the (nearly impossible to avoid) whitespace around Threat Modeling. Its not perfect. But neither is:

• your Agile SDL. Come on. Tell me its perfect..... I didn't think so
• your security practice. Surely there's room to grow.
• your team's security awareness.

The (perception) problem with Threat Modeling is that its contrasted against existing technology, with its limited room for too many options. This causes people to question their model in an existential way.They also tend to conflate threat modeling with:

• validation of flaws - in the form of testing
• findings - as in, from a vulnerability assessment

which are both not the right ways to go about thinking about threat models. Threat Models fundamentally help you think of what and how things can go wrong.You'll suck at it at first. Then you get better. Like everything else in life.

‍Some materials that allude to aspects of this post:

• My previous article on Modeling stories
• Izar Tarandach's talk from AppSec California 2019
• Adam Shostack's "Threat Modeling 2019" talk from RSA 2019
• ThreatPlaybook - An Open Source Tool I build and maintain to make some of this more repeatable and  automation friendly
• Stephen de Vries' Presentation on Threat Modeling with Architectural Patterns
• Autodesk's Checklist for Developers  - Use with Threat Models. I think this project has great possibilities

I'm sure there are many other useful projects out there as well. This, by no means is an exhaustive list.