Adam again. I hope you’re still enjoying this as we hit #5 in the threat modeling series.
In my last post, I talked about how almost everyone in software draws on whiteboards regularly, and this makes it an ideal first step. It’s an ideal first step because everyone can do it, see that they’ve done it, and feel like they’re making progress.
That wasn’t quite complete. Not only do we want people to see that they’ve done it, we want to give them a way to validate their work or other people’s work. So we ask them to tell a story. We’re not asking for Shakespeare here, we’re asking them to explain how their software will be used, and to make sure that their diagram supports that story, and that it relates to their actual software.
We also give them rules of thumb (lots of rules of thumb) about things we often see wrong in diagrams:
- Don’t have data sinks: you write the data for a reason. Show who uses it.
- Data can’t move itself from one data store to another: show the process that moves it.
(Larry Osterman has some in his blog post, “Threat Modeling Rules of Thumb” I helped edit those, but want to suggest additional changes. In particular, “you need to be concerned” is not actionable. “Review this carefully,” or “Focus your attention here” are more actionable. People threat modeling are already concerned.)
Good “rules of thumb” encourage flow by empowering people to make a snap decision and move along.