Have you ever watched a movie where the good guys had to 'get into the mind' of the bad guys in order to figure out how to stop them? What if we told you that security engineers do the exact same thing when they perform Threat Modeling?
Look, it's not like threat modeling is like Minority Report or anything, so don't get too excited. But it's still an incredible way to gain insight into the exploitability of your apps. When you know how to break into your own app, you automatically get the blueprints that will help you patch up those security flaws.
In this article, we're going to look at what threat modeling even is, different types of threat modeling methodologies, and courses where you can learn to perform threat modeling.
When an attacker attempts to break into your application, here is what they're trying to do:
This—broadly speaking—is how a cybersecurity attack goes. When you're performing a threat modeling exercise on your app, you're essentially repeating the exact same steps (without all the illegal bits, of course). According to OWASP, most threat modeling methodologies need to ask (and ultimately answer) 4 fundamental questions about your application:
Threat modeling is usually done at the very start of building the application, while it's still in the design phase. This is the point where you understand what kind of app you're developing. For example, what kind of architecture are you building on (cloud native, containerised, serverless)? What kind of resources, database, or workflows will you be using.
By asking detailed questions like this, you're not only eliminating ambiguities in the design of your software, but making it easier to formulate a security strategy later on.
This is where it gets really interesting. Once you know what kind of app you're building, you'll need to figure out what specific weaknesses an attacker can exploit in order to break your app. This process involves identifying security controls, modelling attack possibilities, and locating threat agents that will be the main source of your security problems.
Once you know where your application is vulnerable, it's time to figure out how to build security measures to protect it. You'll need to determine the sort of countermeasures and mitigations to employ against the biggest security weaknesses that pose a threat to your app.
This is a retrospective stage, where you go over the threat model you've developed and check for things like quality, feasibility, progress and planning.
Note: There's a common misconception that threat modeling and pentesting are similar or the same. Just to be clear, they are totally different security activities that serve different purposes. Penetration testing helps you find bugs and vulnerabilities in your application's code. Threat modeling helps you find vulnerabilities and flaws in the design of your app.
There are several types of threat modeling you can apply your software, many of them with goofy-sounding acronyms. Threat modeling needs to follow a set structure or approach to be effective, which is why AppSec professionals have developed methodologies to follow. While there are a lot more of them out there, we'll talk about the 5 most popular ones here.
STRIDE has been described as the granddaddy of threat modeling. It was developed by Microsoft way back in the '90s, and has become the most popular methodology ever since. The letters in STRIDE stand for the different types of security threats it helps you find:
PASTA stands for Process for Attack Simulation and Threat Analysis (told you they had goofy acronyms). It's a 7-step process that is meant to correlate business objectives with technical requirements. Here are the 7 steps involved in threat modeling with PASTA:
VAST stands for Visual, Agile Threat Modeling, and as the name suggests, this methodology was developed specifically for workflows incorporating the DevOps philosophy. The idea behind VAST is that the threat modeling process can only be effective when it's scaled across the infrastructure and integrated with Agile development environments. This will ensure that the threat model is viable and useful for developers, security engineers, and senior executives.
Trike threat modeling stands in contrast with most other methodologies in that, rather than trying to emulate the attacker and their techniques, you're instead taking a defensive approach. Trike has you modelling the target app or system, enumerating the threats, assigning the appropriate risk values, and then apply mitigating controls to address the most serious threats.
It's both a framework and an open-source tool, which you can find here.
OCTAVE stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation, and it was developed at the Carnegie Mellon University. This methodology focuses more on security risks at an organisational rather than technological level. OCTAVE helps organisations identify data assets most at risk, and direct them to implement more robust security measures across their information assets. OCTAVE has 3 phases:
Threat modeling, unlike a lot of traditional security testing methods, looks at flaws and vulnerabilities in the design of your apps rather than the code itself. It's one of the most reliable ways to document the various components of a system and understand why they are at risk.
But perhaps even more importantly, threat modeling is a really effective way to get to know how your application works at a very granular level.
"The message on threat modeling actually isn't for the security teams," says Dinis Cruz, CISO of Glasswall. "I view threat modeling as a technique to document and to create a real-world view of the application. One of the side-effects of this is [identifying] the security risks, but the most important objective is [understanding] how the thing works."
You can watch our full interview with Dinis Cruz on the AppSecEngineer Youtube channel.
Threat modeling is a great way to identify and document problems with your application at a very early stage in the SDLC, often even before the coding begins. It also lets you know the security requirements of your software early on so you can prioritise the most important tasks that need immediate attention.
A detailed, well-documented threat model also helps you think beyond standard attacks to scenarios unique to your application.
There a few options if you want to learn threat modeling for for free. Microsoft has a'Threat Modeling Security Fundamentals'learning path where you can go through short documents that take you step-by-step through the process of basic threat modeling.
Martin Fowler also has a very in-depth Guide to Threat Modelling for Developers, which is a detailed, dev-focused blog post on how to get started with threat modeling.
But this is one of those things where you can't really learn threat modeling without doing it yourself. You'd need to get hands-on with the process if you want to understand how it really works. After all, how you threat model one app won't be how you do another.
That's why AppSecEngineer offers two full-fledged courses on threat modeling. We cover all practical aspects of the process with detailed videos, and reinforce it with hands-on labs where you can practice what you've learnt. They're intuitive, easy to follow, and are by far the most effective way to learn threat modeling.
You can find both courses on our Threat Modeling Learning Path.
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.