August 25, 2020

Last Updated on January 15, 2024

Threat modeling is a vital but often overlooked component of the software development lifecycle for secure web applications. “The sooner the better, but never too late,” doing threat modeling helps identify and understand threats early so mitigation approaches can be factored into application architecture and development.
Daniel Cuthbert, OWASP Application Security Verification Standard (ASVS) project leader/co-author, is a big proponent of threat modeling. He offered considerable insight into the value of threat modeling in a recent episode of The Virtual CISO podcast. Another threat modeling buff with insight to share is podcast host John Verry, Pivot Point Security’s CISO and Managing Partner.

Daniel sees threat modeling as central to a more mature application security testing process industry-wide:

“Because if you look at what attackers are doing, they’re going after stuff that often gets forgotten. The dev environment that got spun up and they closed down the two VPCs, but they completely forgot about the database, which is still running, which means it wasn’t patched, and so on. So we want you to be a little bit more structured about how you go into designing stuff, and also have that written down in a format where you can always reference back to it.”
Daniel also shares a cool idea for using threat modeling with bug bounties: “If I was doing bug bounties, right?… (and I don’t do bug bounties)… I would probably take the ASVS and I would take a threat modeling tool, and I would take the application I was supposed to be testing, and I would do a threat model. And I would apply that… and then I’d look at all the areas where I know they’ve probably not done stuff. There are my bugs. I’ve never heard of anybody talking about this.”

When asked how threat modeling differs from risk assessment, Daniel’s reply is funnier than you might imagine possible given the topic:

“So I guess, for me, risk assessments have always been very much like underwear. They’re incredibly personal, and not everybody wears the same one. Everybody’s risk is completely different. I don’t know what your risk is, you don’t know what my risk is, right? And it’s hard to apply risks to somebody’s product, and we did this when we were doing pen testing because we don’t know, we don’t understand. You might have completely different controls or regulatory requirements, or something else that says, ‘You need to do this because you feel that’s a risk.’ We don’t know that.”
“But in a threat model it takes a step back and says, ‘Right, you have an application and that application needs a user to authenticate, and for the authentication you’ve decided to go legacy, a username and password. So therefore, based on those components and those functions, these are the threats that those components will face when put on the internet,’” Daniel explains. “And what I like about threat modeling is that even for people who don’t understand the made and beautiful world of attackers and adversaries and Chinese threats, they can still use a lot of the tools.”

John sums up: “Threat modeling is a form of risk assessment that’s just application-specific. … Any risk is a threat acting on a [vulnerability], right? … So it’s really just a matter of understanding what threats might act on what vulns in what context, correct?”

After bashing a few of the original threat modeling tools like STRIDE and DREAD, Daniel recommends a newer tool called IriusRisk: “It doesn’t assume you know every single attack out there. It’s a drag-and-drop, wizard-based tool that you build in your architecture. You say, ‘Right my application is all Hipster, and I’ve got a Kubes cluster and I make use of all these cloud components and blah, blah, blah, blah.’ And it generates the threat maps and it says, ‘Right, these are the things you need to look for.”
As an example of what happens when you obviously didn’t do threat modeling, Daniel cites Amazon’s Ring, a security device that’s anything but secure: “If you’re going to build something that is quite invasive when it comes to a privacy perspective, people will abuse it—and boy did people abuse it. And you’d almost think somebody didn’t do a threat model, because the fact that there was no 2FA, the fact that it was easy to brute-force the Ring authentication function… that would’ve been picked up in a threat model. … We need to get more serious about how we look at these applications.”
To enjoy all the wisdom from John and Daniel’s discussion, click here to listen to this podcast episode all the way through. If you don’t use Apple Podcasts, click here to access this episode and all the others in The Virtual CISO Podcast series.