I’d like to talk about the STRIDE per element chart in the sixth post of my threat modeling series. I’d like to talk about where it’s from, some of the issues that come with that heritage, and how you might customize it in your own threat modeling process.
Michael Howard and Shawn Hernan did an analysis of our bulletins and some CERT and CVE data. Their goal was to validate work they’d done on threat tre es. (Covered in the SDL book.) They were looking for classes of things that would cause us to ship updates. That’s tremendously important, so I’ll repeat it. They were looking for classes of things that would cause us to ship an update. If we wouldn’t update for it, it doesn’t exist in the chart. That’s not to say it doesn’t exist. If there’s an elevation of privilege against an external entity, well, by definition, we can’t fix it. It’s external. So is there value in calling out that risk in threat modeling? Sometimes there might be.
Breach Disclosure Laws
Sometimes organizations lose control of data that’s been entrusted to them. You might find that risk as an instance of “information disclosure by external entity.” So should we have a check there? Well, on the one hand, we don’t have any control over it – unless we hand them that information by design. In which case, perhaps we could design to hand over less. At Microsoft, we haven’t added it to the chart we ask people to use, and we’ll revisit that over time.
Another thing you might note is that the STRIDE chart is sorta vague. A process could be an exe, a .NET assembly, or an a.out executable running on Unix v7. Each of those will be vulnerable to different instantiations of threats. Your exe or a.out will be vulnerable to simple stack smashing overflows, but the .NET assembly won’t be. As you make your elements more specific, you can provide more prescriptive guidance as to what threats to look for, and how to effectively mitigate them.
Customizing the Chart for Your Threats
The chart is centered on our needs at Microsoft. Those may not be your needs. Perhaps you’re building a threat modeling process to focus on voting. You can get much more specific about what a process is, and what threats it might come under. You might have really specific threats against voter lists (a type of data store) or vote tallies (another store).
Being able to enumerate the assets in data stores helps you motivate threats, and assess their risk and importance of fixing them. When we build a threat modeling process for the SDL, it gets used in Windows, Office, SQL, Exchange, Dynamics, and a slew of other products. We need some degree of consistency, so we can deliver consistent products and messages to our customers. We also need to encourage customization and specificity, so that the process is as prescriptive as we can make it. Doing so allows you to make it more prescriptive, appropriate and evocative for your users.