Is the STRIDE Approach Still Relevant for Threat Modeling?

Threat modeling is becoming a more commonly used tool by software development teams as they integrate security into their development lifecycle.

Threat modeling was created to be a very tailorable tool. Teams are able to determine the processes that work best for them while negating other processes they deem non-valuable.

STRIDE, one of the processes that have become a common part of threat modeling over the years, was recently in question by my fellow colleagues here at Security Innovation. They were questioning whether STRIDE was still a useful process in threat modeling.

What Is STRIDE, Anyhow?

For those unfamiliar with STRIDE as a threat classification model, it is an acronym for:

Spoofing - Tampering - Repudiation - Information Disclosure - Denial of Service - Escalation of Privilege

This classification model can be used as part of a threat modeling exercise that helps participants determine “What can go wrong in this application or feature we are creating?” Participants can then brainstorm potential threats to the application or feature by creating abuse scenarios that fall under the six threat classifications of STRIDE.

But, is this process still useful to the team members creating the threat model? My opinion is a strongly worded “probably.”

Consider the Six Classifications of Threats

I see value in using STRIDE for the inexperienced members of a threat modeling team. Many software engineers today are still unaware and uneducated about the types of commonly used attacks that their applications and features may be forced to defend themselves from.

When these inexperienced threat modelers are asked to brainstorm a list of threats, the STRIDE model can be a useful place to start so that all six classifications of threats are considered by the team.

Clear Application Vision Using the Eyes of an Attacker

Inexperienced threat modelers may be unaware of how exposing application specific technical information could be used by an attacker to gain an understanding of where vulnerabilities may be present within an application or feature. But, by requiring these inexperienced threat modelers to educate themselves about STRIDE, they can begin to see the application through the eyes of the attacker, which is an extremely useful skill when attempting to build more secure applications.

Checking Off the STRIDE Check-List

I also see value in using STRIDE for experienced members of a threat modeling team. But, in this case, STRIDE can be used as a checklist once the threat modeling team has created a list of threats. For example, if a list of threats has been created, but there are no examples of privilege escalation threats, an experienced team using STRIDE as a checklist would notice that a threat classification has been missed and perhaps put more thought into determining if there aren’t any privilege escalation threats present or if they’d missed something.

Threat modeling was built to be customized so that teams could gain some benefit by using this helpful process no matter how little time or resources could be allocated to it. If a threat modeling team is experienced and feels comfortable not using STRIDE so they can spend their time performing other threat modeling processes they believe are more beneficial, that’s perfectly fine. But, I feel that STRIDE is still an effective tool to thoroughly understanding "what threats could this application potentially experience in our production environment.”