Risks without impacts: attack path analysis

A little while ago, I was presented with a familiar problem statement from a Cydea client who was a cyber security manager at a large organisation: “There’s a new cyber vulnerability in the Operating System we use on the handheld devices used by our engineers out in the field; how do I communicate the resultant change in risk profile to the organisation?”.

Despite having flaws, as we will explore here, there is a standard approach to this: the humble risk register. We scroll down past the other 100 or so previous entries that are already checked into our digital equivalent of Hotel California, and we enter it as a new ‘risk’ to the organisation. The problem with this approach becomes apparent when we get to the inevitable ‘likelihood/probability’ and ‘impact’ columns in our spreadsheet. We’re moments away from multiplying together two ordinal scales (shudder!) to get our made-up risk rating.

We can assess the likelihood of the handheld device being compromised using this new vulnerability, as we likely have known data points around how easy it is to exploit technically e.g. a CVSS (Common Vulnerability Scoring System) rating. But we also need to take into account the wider context, looking at how an attacker would get the necessary access to the device in the first place. This type of analysis is starting to move us away from just assessing the vulnerability; we are starting to do attack path analysis to justify our ‘likelihood’ assessment.

What could they even do if they did gain access?

This question leads us to another bit of attack path analysis to determine the actual impact of this risk occurring. It may be that exploitation of the vulnerability leads to an immediate impact because it enables the attacker to wipe the device, causing an immediate impact on the availability of the device, leading to some business disruption. It might be that the device itself is not business critical, but because it is docked back into the corporate network when the engineer is back in the office, it provides an entry point for the attacker to gain access to the corporate network and do some more damage.

You probably get the picture now:

A single vulnerability isn’t necessarily something we can risk assess by itself, but by using attack path analysis, we can start to understand how it changes the risk profile for the organisation.

I think it is fair to say that a lot of risk practitioners do this subconsciously when they arrive at their probability and impact ratings.

But what about our impact rating?

Is it a 1 because it will cause half a day of inconvenience whilst the handheld device is rebuilt/replaced or is it a 5 because the lateral movement onto the corporate network brings down the entire organisation?

The risk register is going to force us to make the choice, and invariably we go for option B, or rather 5: the compromised handheld device brings down the entire organisation. Why? Because no-one wants to be the person who downplayed the risk. Sounds silly, but looking back at our careers, most seasoned risk practitioners will be nodding with a wry smile right now.

So is there another way?

Yes. To start with, we could move our entire risk assessment approach from a restrictive qualitative approach to quantitative risk analysis. We’re then free to describe any risk as multiple different probabilities of different losses on a Loss Exceedance Curve. I’m not here to sell you the benefits of quantifying your cyber risk, but we still have the unanswered question from the cyber security manager: how do I explain this single vulnerability in the context of an entire enterprise?

Just as I wrote in a previous blog post about linking risk scenarios to detection use cases, my answer is similar: link low level vulnerabilities with high level risk scenarios.

Some recent risk assessment work with a client in the autonomous vehicle space got me thinking again about this. The client is sensibly aligning themselves with ISO/SAE 21434, the international standard for cyber security engineering in road vehicles, and one of the things I think this standard does well is to include attack path analysis as part of its suggested approach to threat analysis and risk assessment.

As we worked through the threat & risk assessment with the client following the suggested approach, we came up with a set of risk scenarios (or threat scenarios as the standard refers to them) that were then directly mapped onto one or more attack paths.

With these attack paths fully mapped out (possibly onto the MITRE ATT&CK framework as we did when mapping out our detection use cases in my previous blog), we’re in a position to start assessing individual vulnerabilities that might be exploited at each stage of an attack path. If the identified vulnerability maps to more than one attack path, then great, we map it back to multiple risk scenarios. Using our example earlier, I might find a compromised hand-held device already featured in two previously mapped out attack paths, and it makes me think about the feasibility of a new third one, so I review my attack feasibility ratings to account for this new vulnerability and this feeds up into a modified risk value for one or more risk scenarios.

By following through all these attack paths and mapping them against potential new vulnerabilities, we’ve used attack path analysis to understand and demonstrate the changes in risk profile to the organisation while also giving everyone involved a clear view of said paths and potential risks.

Photo by Deva Darshan from Unsplash