Using security metrics to prioritise vulnerabilities

This article is written in collaboration with an information security executive at a Fortune 500 financial services firm. We discuss an approach to vulnerability prioritisation that goes beyond the typical severity index of critical, high, medium, low to create a multi-dimensional model that prioritises systems using various factors such as business context.

The challenge of vulnerability prioritisation

‘Security leaders are in the business of finding, tracking, and mitigating risk. If you do anything as a CISO, it’s to scan your network for vulnerabilities as much as possible, continuously and relentlessly, and then prioritise your highest risk systems for remediation.’

Many organisations just run their vulnerability scanners and treat their vulnerabilities in a silo.

Vulnerability prioritisation is a big challenge for security teams. Scanners pick up thousands of vulnerabilities in the environment. Your team has limited resources in terms of time, personnel and technology. What do you remediate first?

‘Many organisations just run their vulnerability scanners and treat their vulnerabilities in a silo,’ said our security expert. They put them in buckets based on criticality – critical as a first priority, high as a second priority, maybe medium as a third priority, and probably ignore the lows.

Not all vulnerabilities are created equal.

This doesn’t necessarily prioritise the highest risks though, because it doesn’t consider any context about those vulnerable systems.

‘Not all vulnerabilities are created equal.’ Once when our collaborator was interviewing for a security leadership role, the interviewer gave him a one-pager of vulnerability metrics – pie charts, lows, mediums, highs, criticals. ‘But there were no dimensions. It didn’t mean anything. Yes, you have critical vulnerabilities. But for what? The cafeteria menu? Desktops? High-value assets? Internet-facing systems? Payment systems?’

‘The key to vulnerability prioritisation is to understand the context around your vulnerable systems and focus priority on the vulnerabilities that are running on systems that are directly or indirectly exposed to the internet.’

If a server has a critical vulnerability, and that server has ports open to the internet, that’s the priority. Things like the vanity website, portal for financial transactions, user login, shopping cart – whether cloud or on-prem.

‘But crucially, once you’ve identified these internet-facing systems with a critical vulnerability, don’t just patch the critical vuln. Patch them all.’

Normally, no-one would care about those non-critical vulnerabilities, but our collaborator thinks they are very important. A critical vulnerability on a system is an indicator of an especially risky system.

‘If you have critical vulnerabilities exposed and you have other things wrong with your system, you have to fix them all. Every vulnerability should be like a chain based on the most critical one. If a threat actor is able to exploit a critical vulnerability on a system, then they can also exploit all the other vulnerabilities on that system that nobody apparently cared about before.’

A multi-dimensional model for vulnerability prioritisation

There are several dimensions to take into account that point towards a level of prioritisation. Our collaborator has built a rather technical and academic model, which includes these dimensions and principles:

• Severity: We’ve mentioned already the severity of the vulnerability and whether the vulnerability is on an internet-facing system.
• Likelihood and impact: Threat intelligence tells us every day which vulnerabilities have the highest and lowest likelihood and impact.
• Exploitability: You should also look at exploitability, whether it’s network exploitable or locally exploitable. Can it be attacked by throwing a packet across the network? Or does the threat actor need to get a user to click on something, exploit a vulnerability, and move laterally?
• Business context: You also have to look at the business context of the system in question. Is it part of a business-critical process or system for the organisation, such as the payments process and critical infrastructure?

These are the kind of dimensions to look at to prioritise vulnerabilities. And from this model, we can assign appropriate remediation thresholds.

An example dashboard

To create an example, we have mocked up a dashboard that gives some insight into our security expert’s vulnerability prioritisation suggestions. It breaks down a view of vulnerabilities by some of the key factors, such as criticality, whether they are internet-facing, or part of a business-critical process.

The second dashboard goes into slightly more detail, outlining not only the network location (ie whether they are internet-facing) and business process of vulnerabilities, but also highlighting the devices with those vulnerabilities, based on both network location and business-process.

What are your vulnerability prioritisation thresholds?

No critical vulnerability should have a threshold beyond 30 days. It doesn’t matter what other dimensions are in play. Firstly, this will look terrible to an auditor. You never want to be telling a stakeholder that you’re taking 90 days to remediate a risk you have labelled critical. Secondly, if that’s the case, why are you calling it critical?

Our security expert suggested setting thresholds within bands aligned to your risk appetite for remediation and compensating controls that may mitigate the risk of exploitation. This can be from the most urgent priority in 24 hours, to others mitigated with compensating controls allowing 6 months or longer.

The remediation threshold is determined by the above dimensions of the vulnerability in question. For example, if your threat intel says it’s highly likely, it’s a super-critical severity, it’s impacting the most critical assets of your organisation, and it’s network exploitable – this is the bullseye. That would be a 24-hour threshold.

But if there’s a low severity vulnerability, which is not likely to occur, affecting your cafeteria menu system, then that will probably be allowed 6 months or longer.

One principle he also suggests: ‘No critical vulnerability should have a threshold beyond 30 days. It doesn’t matter what other dimensions are in play. Firstly, this will look terrible to an auditor. You never want to be telling a stakeholder that you’re taking 90 days to remediate a risk you have labelled critical. Secondly, if that’s the case, why are you calling it critical?’

How do you work out the context for all systems?

To understand the business context around each system, you need to aggregate data across all the relevant tools your organisation is using that relate to vulnerability management – your vuln scanner, pen test data, app sec scanners, etc – and stitch it to your asset inventory. It can be very difficult to manually stitch together that many data sources, and keep them running continuously. That’s why our collaborator has introduced Continuous Controls Monitoring (CCM) to his current team.

With CCM you have a trustworthy dashboard of cyber posture metrics that shows you things you need to do, things that are broken, or things to remediate. When you double click down, you want to understand how to remediate or how to improve your scores in a prioritised, highest return on risk mitigation approach.. That’s where your CCM metrics need to be anchored to the principles of good asset classification, and how you gain the key context you need to prioritise effectively – whether around internet-facing assets, or the slightly harder to achieve, business criticality.

Once this priority is linked to an asset inventory, such as a CMDB or CCM platform itself, you can use it to drive not only vulnerability remediation, but various other initiatives, such as regulatory compliance and audit. Without a good priority classification, a regulator or auditor may consider everything in scope, which makes your job that much harder.

The final word…

When it comes to vulnerability prioritisation, you have to take into account the context of the vulnerable system. You can’t just look at severity and go from there. The three top tips from our collaborator are:

• Prioritise remediation on internet-facing systems.
• Prioritise remediation on systems that are part of business-critical processes.
• Remediate all the vulnerabilities on any system with a critical vulnerability.