The top 3 problems with STRIDE threat modeling (and what's next)

Who wants to spend 90 minutes going through spoofing, tampering, repudiation, information disclosure, DoS and privilege escalation for each asset in this huge system diagram with me?

‍

Anyone?

‍

No one?

‍

Hmm… OK… maybe we need to rethink this.

‍

STRIDE is a 25 year old checklist

I don't like STRIDE very much. I don't think anyone really enjoys STRIDE, yet it has remarkable use in the industry. In my experience, the usual STRIDE recipe is to ask (force) an engineering team to make a data flow diagram of their system, and then spend some 60-90 minutes in a large meeting, going and asking the group these questions for each component:

‍

• Spoofing: Can an attacker pretend to be a legitimate user or system component?
• Tampering: Can an attacker modify data in transit or at rest?
• Repudiation: Can a user deny performing an action without sufficient evidence?
• Information Disclosure: Can sensitive information be exposed to unauthorized parties?
• Denial of Service: Can an attacker disrupt the system's availability?
• Elevation of Privilege: Can an attacker gain unauthorized access to privileged functions or data?

‍

You then make a long list of threats, assess risk, prioritize them and hopefully, go fix them. At this point, STRIDE has been around for longer than Agile, first invented in 1999. So being being old and using unnecessarily complicated verbiage (repudiation??) isn't so bad. So what else is wrong with STRIDE?

‍

STRIDE is time consuming and rote

If STRIDE is good for anything, it’s ensuring you’ve thought of everything. That might sound like a feature, but in my opinion, it’s much more of a bug. Do I need to ask myself whether there is a risk of tampering with the font color in the UI component? Or if there's a risk of privilege elevation on a load balancer? No. No I don’t.

‍

STRIDE produces a ton of generic and noisy concerns. Although I generally like the approach of enumerating options before focusing down on specific risks, STRIDE encourages over-enumeration and overly noisy conversations. I shudder at the thought of world wide volume of Microsoft Threat Modeling threats marked as “Ignored” just to satisfy some SDLC/compliance requirements.

‍

Who’s supposed to do the threat model anyway?

To perform a threat model, there are two knowledge prerequisites. You need to understand how the system works, and you need to understand how an attacker could exploit it. Usually, the engineering team knows the first piece, and the security team knows the second piece. In practice this means we have three options:

1. Doing it together (and waste everyone's time)!
2. Up-skill all engineers to expert threat modelers
3. Teach security the intricate details of every system at their company

STRIDE, in my opinion, is an attempted shortcut at #2, but is often used in practice through #1, a large meeting between security and product engineering. Number 3 is impossible when most security engineers operate at around a 1:100 ratio between security and software engineers. This is one of the top challenges we hear when security teams want to evangelize threat modeling across their organization. I'm not sure if it's entirely solvable without great tooling.

‍

Why do I need to make a data flow diagram?

STRIDE requires, or at least works much better with, data flow diagrams (DFDs). I am more than willing to admit DFDs are useful. But is it really worth asking engineering teams to convert their existing documentation into a DFD just for threat modeling? In my opinion, it’s a clear no. I think of engineers as the customers of security teams, and I want to always ensure I’m respecting my customer’s time and priorities. Asking my customer to go through their existing documentation and write it in a format that fits me, doesn't seem to respect either.

‍

LLMs should do STRIDE instead of people

A time consuming and rote process that no one is well-equipped to execute. That sounds like a job for an LLM, and indeed, it is. I’m very excited about the near future of threat modeling when we can outsource most of the threat modeling activity to automated intelligent systems that helps us get through the rote issues. I don’t want to ask myself if my load balancer might have a privilige escalation risk, becuase I’m pretty sure that isn’t the case. On the other hand, if an LLM already checked on it for me, and only told me if in fact there was a risk? Yeah, that sounds pretty nice.

Maybe what I wrote at the top wasn’t quite right. LLMs haven't kill STRIDE, they have just taken STRIDE from us. And as far as I’m concerned, they can keep it!

‍

If you want someone to take away STRIDE from you, get in touch below and we’ll see if Remy can be that someone. We help product security teams scale secure design reviews and threat modeling by solving visibility on engineering work, triage and the reviews themselves. Thanks for reading!

‍