One of the critiques of the threat modeling
blog posts process is that it can seem interminable. And so, in this final post, I’d like to offer up some final thoughts on language, and cognitive load.
Specification versus Analysis
When Larry Osterman was writing about threat modeling, he casually tossed out:
A threat model is a specification, just like your functional specification (a Program Management spec that defines the functional requirements of your component), your design specification (a development spec that defines the architecture that is required to implement the functional specification), and your test plan (a test spec that defines how you plan on ensuring that the design as implemented meets the requirements of the functional specification).
Just like the functional, design and test specs, a threat model is a living document – as you change the design, you need to go back and update your threat model to see if any new threats have arisen since you started.
I found this pretty surprising. I think of threat modeling as an analysis technique, but hey, if test plans are specs, threat models aren’t that different. (It took some private back and forth with Larry to convince me.) This brings me to the topic of what words we use to describe things.
[The English language] becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of our language makes it easier for us to have foolish thoughts. The point is that the process is reversible. Modern English, especially written English, is full of bad habits which spread by imitation and which can be avoided if one is willing to take the necessary trouble. If one gets rid of these habits one can think more clearly, and to think clearly is a necessary first step toward political regeneration: so that the fight against bad English is not frivolous and is not the exclusive concern of professional writers. (George Orwell, Politics and the English Language.)
We ask people to threat model (as part of the SDL) by threat modeling their application. To do that, they model the design, and then have a threat modeling meeting in which someone runs the threat modeling tool to produce a threat modeling document. In our particular case, I’m not sure it’s easily avoided.
“We ask people to analyze their designs (as part of the SDL). To do that, they diagram the design, then have a threat modeling meeting in which someone runs the codename tool to produce a threat modeling document.”
In fact, I’ve worked hard to reduce jargon in the process, but at one point, went too far. I tried to convince people to say “diagram” instead of DFD, and they revolted. Actually, they didn’t really revolt, but they did refuse to go along. Experienced threat modelers actually felt that the term DFD was more clear than saying ‘diagram,’ because DFD includes a specification of what kind of diagram, and they had already integrated the acronym into their thinking. Having integrated it, they could use it without thinking about it. Well, as Adam Barr points out, “you can pick your friends, and you can pick your nose, but you can’t pick your online community’s lexicon.”
It didn’t add to their cognitive load to say “DFD.”
People can only handle so much new information at one time. Learning to drive a stick shift is harder than learning on an automatic, because there’s a whole set of tasks you can ignore while the automatic transmission handles them for you. In my approach, this relates pretty closely to the concept of flow. If you’re so focused on rules and jargon, you can’t focus on what you should be building. Cool, well-designed features to help your customers.
We started this series by looking at the trouble with threat modeling. How people had trouble getting started, relating the process to their other work, or validating what they’d done. We’ve looked at the new threat modeling process, and the steps involved. We talked about how to get into the flow with threat modeling. How clear goals, direct and immediate feedback, and balancing ability and challenges set people up to focus their attention and succeed. We’ve talked a bit about making threat modeling work better by adding structure to chaos, and how to use self-checks and rules of thumb to give people confidence they’re on the right trail. We’ve talked a very little bit about how to customize the process for your own needs, and where that customization can be dangerous.
All of this has come out of looking at our threat modeling activity as a human activity, and asking how we can best shape it to help people get to the results that we want. I hope that our readers have enjoyed the series, which we’ve converted into a downloadable document (here.)