I’ve been having a running disagreement with someone senior to me for some time now, and I thought it worth posting on here. 

The backstory is that I’m generally keen on Threat Modelling. I say generally, as there is a value discussion to be had around it. Done properly with the right input at the right time (and if done well –  it’s pretty time intensive). It should yield some decent results. Not just in the technical configuration, but the understanding of the overall business context. Some recent examples of mine include sysadmins accessing crypto keys they shouldn’t, and examples of where a Separation of Duties requirement was missed. However, a good amount of security value can be obtained with a decent set of baseline controls, with no need for Threat Modelling.

For strategic developments, its generally worthwhile to do some Threat Modelling as early as possible in the development cycle. Which brings me to patterns. As I’ve written before, much of mine (and my team’s) work involves creating a set of reusable Security Patterns. There is some pressure to produce a Threat Model for the generic solutions in in the Patterns. This sounds like a great idea, and works to a point, but my resistance to this is that its pretty false, and potentially gives a false sense of security/‘braggability’ “we’re doing Threat Modelling! When that’s not really the case. 

The specific reason I dislike the idea of Threat Modelling patterns is that they are used in a variety of scenarios. For the Threat Modelling to be useful, and not just a list of baseline considerations, there needs to be business and system context to the Threat Modelling. The approach I’ve taken is to identify the technology and business risks the pattern addresses; as well as those it doesn’t. 

To try to bring my point to life, I’ve been using the following analogy: a knife in the hands of a chef in a restaurant’s kitchen is absolutely fine, however, that knife in the hands of a miscreant on the streets outside the restaurant – is a recipe (no pun intended) for disaster. Same item, different threats – different threat model.

Thus, Threat Modelling, like security, like life, is all about context.