Any piece of code can have a vulnerability. Whether application code or infrastructure code, errors, oversights and misconfigurations happen. The question developers must answer is, how many negative outcomes an attacker could realize because of that vulnerability.
The number of bad things that can happen from a single vulnerability has achieved a popular new description in the cyber community: blast radius. From Mimecast, “The blast radius of a security incident is defined as the amount of damage that the incident could potentially cause. It’s every account, file, application, server or other corporate asset that could be compromised once an attacker gets ‘inside’ the system.”
Knowing the blast radius of a vulnerability helps developers prioritize which vulnerabilities to address first. Unfortunately, you cannot uncover the blast radius of a vulnerability through defect discovery. For that, you‘ll need threat modeling.
Understanding Blast Radius
To understand blast radius, you first have to visualize the exploit chain, which is what connects the attack surface of an application or device to the valuable assets to be exploited.
“An Exploit Chain is an attack that involves multiple exploits or attacks that are chained together to fully compromise a device. In these attacks, Hackers cannot use a single exploit to compromise their target but instead can combine a series of exploits that ultimately lead to malware getting installed.”
Every vulnerability lies somewhere along an exploit chain. The blast radius of any vulnerability is tied to how many different exploit chains it enables. In other words, the blast radius depends on how many chains go through the vulnerability.
Naturally, exploit chains of applications became exponentially more complicated as applications migrated to the cloud. Harder to visualize and easier to exploit. And as the industry embraces zero-trust architecture, even more visibility is required into cloud computing environments. That’s where threat modeling comes in.
Threat Modeling to the Rescue
To understand and minimize an application’s blast radius, you must do two things. First, you must evaluate the entire exploit chain from the attacker’s access to the surface, all the way to compromise, misuse or destruction of the asset. Here you’ll identify all the vulnerabilities along the chain.
Second is an exercise in identifying which of these vulnerabilities are most impactful. Which vulnerabilities enable the most attack chains? And then of course you remove or mitigate them.
This ability to identify vulnerabilities along an exploit chain and then prioritize them according to impact is the key to minimizing an application’s blast radius. Threat modeling is ideally suited for both these activities because that’s essentially what threat modeling does.
Early threat modeling efforts produced data flow diagrams to depict how data moves through a process or system. More modern data modeling tools produce process flow diagrams. These are better at analyzing the overall security risk across assets. But both are ways of defining exploit chains. And since the most modern threat modeling tools also help prioritize threats and suggest mitigation, they accomplish both of the steps mentioned above.
Its capabilities are so well-aligned with the problem, it’s almost as if threat modeling was created to minimize an application’s blast radius. If you’d like to learn more about a threat modeling tool that can help you minimize your application’s blast radius, we suggest you check out ThreatModeler. ThreatModeler software reduces threat drift from cloud to code (and also reduces blast radius).