Promoting Threat Modeling Work
Some thoughts on promoting others’ threat modeling work.
Quick: are all the flowers the same species?
People regularly ask me to promote their threat modeling work, and I'm often happy to do so, even when I have questions about it. There are a few things I look at before I do, and I want to share some of those because I want to promote work that moves things forward, so we all benefit from it. Some of the things I look for include:
- Specifics. If you have a new threat modeling approach, that's great. Describe the steps concisely and crisply. (If I can't find a list in your slide deck or paper, it's not concise and crisp.) If you have a new variant on a building block or a new way to answer one of the four questions, be clear about that, so that those seeing your work can easily put it into context, and know what's different. The four question framework makes this easy. For example, "this is an extension of 'what are we working on,' and you can use any method to answer the other questions." Such a sentence makes it easy for those thinking of picking up your tool to put it immediately in context.
- Names. Name your work. We don't discuss Guido's programming language with a strange dependence on whitespace, we discuss Python. For others to understand it, your work needs a name, not an adjective. There are at least half a dozen distinct 'awesome' ways to threat model being promoted today. Their promoters don't make it easy to figure out what's different from the many other awesome approaches. These descriptors also carry an implication that only they are awesome, and the rest, by elimination, must suck. Lastly, I don't believe that anyone is promoting The Awesome Threat Modeling Method — if you are, I apologize, I was looking for an illustrative name that avoids calling anyone out.
(Microsoft cast a pall over the development of threat modeling by having at least four different things labeled 'the Microsoft approach to threat modeling.' Those included DFD+STRIDE, Asset-entry, patterns and practices and TAM, and variations on each.) Also, we discuss Python 2 versus Python 3, not 'the way Guido talked about Python in 2014 in that video that got taken off Youtube because it used walk-on music..' - Respect. Be respectful of the work others have done, and the approaches they use. Threat modeling is a very big tent, and what doesn't work for you may well work for others. This doesn't mean 'never criticize,' but it does mean don't cast shade. It's fine to say 'Threat modeling an entire system at once doesn't work in agile teams at west coast software companies.' It's even better to say 'Writing misuse cases got an NPS of -50 and Elevation of Privilege scored 15 at the same 6 west coast companies founded in the last 5 years.'
I won't promote work that tears down other work for the sake of tearing it down, or that does so by saying either 'this doesn't work' without specifics of the situation in which it didn't work. Similarly, it's fine to say "it took too long" if you say how long it took to do what steps, and, ideally, quantify 'too long.'
I admit that I have failed at each of these in the past, and endeavor to do better. Specifics, labels, and respectful conversation help us understand the field of flowers.
What else should we do better as we improve the ways we tackle threat modeling?
Photo by Stephanie Krist on Unsplash.