On Threat Modeling
Alex recently asked for thoughts on Ian Grigg’s “Why Threat Modeling Fails in Practice.”
I’m having trouble responding to Ian, and have come to think that how Ian frames the problem is part of my problem in responding to him. So, as another Adam likes to say, “I reject your reality, and substitute my own.” Here you go:
- “Experiences Threat Modeling at Microsoft” covers the trouble that threat modeling is an aspirational tabula rasa, and people project all sorts of requirements onto processes and methodologies.
- However, I agree with Ian that there’s lots of “Trouble with Threat Modeling.”
- See also my MSDN magazine articles “Uncover Security Design Flaws Using The STRIDE Approach” and “Reinvigorate your Threat Modeling Process” is about how I’m thinking about
threat modeling and some lessons learned. MSDN also published “Getting Started With The SDL Threat Modeling Tool.”
But that’s not my final answer. My final answer is your threat modeling fails because you’re not using Elevation of Privilege.
(Actually, I don’t think that’s why Ian’s threat modeling fails in practice. He’s a smart guy, and I think the issue seems to be one of expectations versus approach, and I think either could be usefully changed, depending on the context.)
Part of the problem seems be exactly what Ian describes on his blog entry: A question of semantics. Microsoft (and now a large part of the security industry) seems to use the terms Threat Modelling and Risk Analysis interchangeably. Ian is just more fastidious in his use of definitions and seems be very much in favour of Risk Analysis because that includes some analysis of vulnerabilities, and therefore probability.
And the processes at Microsoft also seem to be geared towards Risk Analysis as stated in their “Microsoft Security Development Lifecycle (SDL) – Version 5.1” document:
“Threat modelling (described in Design Phase: Risk Analysis) is the other critical security activity that must be completed during the design phase.”
Potato potato.