Defenses for Developers (Threat Model Thursday)
Defenses are often confusing, and developers make the security choices that are hard to reverse. But if you can handle git, you can handle threat modeling.
Every developer ought to know as much about threat modeling as they know about git, because developers are the ones making the decisions about security, and making choices that are hard to reverse. And so they ought to have tools to consider what can go wrong in security, and what to do about it.
One of the challenges they face is that defenses are... hard to understand. From the language we use (“controls”? “solutions?” Why doesn’t the product do what it needs to be safe out of the box?) to the multitude of types of defenses, we could productively focus more on thinking clearly, considering their needs, and and working to communicate well.
One of the major drivers for the second edition (Threat Modeling: Designing for Security in an AI World) has been to address developers’ needs in ways that complement Threats. And so, in this edition, I’ve focused a lot of my work rebuilding the way that I present defenses. The first edition had a set of chapters:
- Processing and Managing Threats
- Defensive Tactics and Technologies
- Trade-Offs When Addressing Threats
- Validating That Threats Are Addressed
In retrospect, that’s not organized great. “Trade-Offs” is a chapter which is largely about risk management, with a sideline into prioritization, and doesn’t really talk about tradeoffs we might make, such as usability or performance. So I rebuilt that. It’s now:
- Technical Defenses
- Defense Project Management
- Risk Manage What Remains
That starts from the concrete, “what can I do about this?” That’s shaped by the sort of thing we’re working on. If I’m building a Windows app, I have different choices to make than if I’m building on Android or AWS. It continues to how well developed a product or feature are: the more people who’ve taken dependencies on something, the harder it is to change.
The answers are frequently singular, and perhaps “obvious” to those with technical skill in security. And as we teach, we routinely see people tying... strange defenses to the threats. (We rarely correct it very aggressively: we’re defending hypothetical systems, and we hope that those building real defenses will do a bit more dilligence.) But people are often faced with complex choices and they need to integrate those many choices into complex software projects, and that requires project management, including much of what was previously in the chapter on processing and managing threats.
The new edition also includes an appendix on Defense Technologies, which tries to act as a guide to the many catalogs of defenses.
With that, let me loop around to my opening line: As much as git? Is that a good thing? Most engineers don’t understand git very well, and use it with a small cookbook of techniques (and support from an LLM). Is that an aspirational endgoal for threat modeling? Frankly, no. But it is an aspirational milestone. Threat modeling is simper than git. The complexities of branches, staging areas, commits, and more are nearly inescapable, giving git a very steep learning curve. (Much steeper than competing version control systems, to enable its decentralized nature.) So I believe that much of the work of the past decades to democratize and make threat modeling accessible makes it reasonable to say “if you can handle git, you can handle threat modeling.”
Image by midjourney: "A watercolor painting of a person standing at a fork in a winding path, with several trails branching ahead, each marked by a simple signpost in a different shape. One trail is lit more brightly than the others. Soft bleeding washes, visible paper texture, loose edges, deep indigo purple background, lime green and bright orange accents, red-orange highlights."