Vulnerability

You’ve found a bug. We’ll provide an example bug. Forget any previous vulnerability risk framework you’ve learned over the years, including color coding, zero-to-ten scales, or high/medium/low. We’re going to think about the bug critically and communicate the nuances that distinguish this bug from other bugs.

Example: We’ve found an internet exposed Jenkins server (build001) with the scripting console accessible.

Probably familiar to you. A very common vulnerability many of us have run into. Our build environment is a Jenkins is a CI/CD server that companies use to continuously build software. The scripting console is basically a web based shell available to an attacker, giving remote code execution.

Sounds like a critical finding. Right? Under normal circumstances this is a “just fix it” vulnerability that shouldn’t require a whole lot of debate to prioritize. Or… so you’d think.

We register the vulnerability in build001 as VULN-0 in some fancy task management sytem or tracker.

Historically, you might write label the bug as critical, Unbreak Now!, CVSS 10, P0, or other terms I’d like you to forget for now. Despite these scary sounding labels:

• Another team might need to be tapped to investigate and fix it.
• This other team might not share your sense of urgency.
• There may be other pressing tasks (or vulnerabilities) being mitigated.
• Your team (and others) may be swimming in critical bugs.
• Other teams disagree about criticality.

Now there’s a need to step into this vulnerability and communicate it more specifically. With analysis, we will tease out and communicate the intricacies of this vulnerability that are causing us, as experts, to find this vulnerability undesireable.

First, this bug is internet facing. Literally anyone can find this vulnerabilty. Plus, there’s plenty of tooling available to find it efficiently. So, we want to communicate the simplicity of which this can be found. Exploitation is also simple - it’s literally designed to be used as scriptable access to the underlying system.

Let’s think of this in terms of time to exploitation and we can model a scenario as needed to communicate it. What are the odds this will be exploited within 30 days? The timeframe is arbitrary and we can pick any term. We’re looking to communicate a short term urgency. So, maybe we choose something like 30 days.

Now we have a scenario and can forecast against it properly as we have learned. Let’s say the forecast comes in at 45%.

Second, the server is a build system that might be a dumpsterfire of ACL exceptions, credentials, intellectual property (source code). The compromise of the host itself is not a disclosable incident. Notably, user data is just a stone’s throw away. Lateral movement towards protected data would be trivial for an attacker.

We will create a new forecast, preceded with a condition that an adversary has already exploited this vulnerability on build001. There’s nuance to possible outcomes:

An adversary might not be entirely concerned about your data - especially one that discovers this vulnerability from broad scanning. Maybe they’ll install a cryptominer and move on… or not. So, this is probabilistic as well. Since we’re working with examples, we’ll suggest the forecast comes in at 60%.

Lastly, and most concerning… it’s probably compromised already! It’s vulnerable now, not in the future. Let’s pretend that this vulnerability has existed for a year or more. Yikes! We will still create a scenario for a current state, so long as it’s not yet confirmed.

Exploitation has a 45% chance with a 60% the resulting incident would be disclosable in 30 days. This works out to a 45% x 60% = 27% chance that a disclosable incident will occur within 30 days (if it hasn’t already).

Hopefully the parties who review these measurements will be convinced about the nature of the risk involved and will help with a fix. Now, we prepare for the event that they are not fixed.