Starting Threat Modeling: Focused Retrospectives are Key
Don't skip this important step.
There's a good, long article at MartinFowler.com "A Guide to Threat Modelling for Developers." It's solid work and I'm glad its out there. And I want to do something I don't usually do, which is quibble with footnotes.
Jim writes in footnote 2:
Adam Shostack, who has written extensively on threat modelling and has provided feedback on this guide takes credit for the three question structure. He also adds a fourth question "Did we do a good enough job?" I don't disagree with Adam that we need to reflect and improve on the outcomes of our threat modelling. However, I have omitted this question from the basic structure as I believe it can be addressed elsewhere.
So why is that worth quibbling with? It's certainly kind and respectful, and everything one could hope for in a disagreement, and I hope to answer in the same spirit.
The reason I include "did we do a good enough job" in my Four Question Framework is twofold. First, retrospectives are often given short shrift in practice. When your software development is in a reasonably steady state, it may be okay to hold a 30 minute session monthly... or quarterly... or when someone makes noise about it. But far more importantly, threat modeling is usually an addition to an existing software process. Because it is new, different work, setting aside a time to specifically ask 'did we do a good enough job at threat modeling' is helpful.
In fact, in my consulting work, I recommend that the first time a team is exposed to threat modeling, you set aside as much time for a retrospective as you do for performing the work. Many times the problems you hear about are "this is new, and we're still building muscle." But that's okay. People want to be heard. They want a chance to express those perspectives. Making listening part of threat modeling helps them, and you, get it done.
Image from T2 Informatik.