5 Steps to Transforming Your Vulnerability Management
A snarky guide to improving Vulnerability Management
If you’re looking down an insurmountable pile of vulnerabilities from a vulnerability scanner, it may feel like you’ll never get the engineering time, manpower, or buy-in to even begin to scale up remediation efforts. Trying to become compliant to that accreditation/certification you need (ISO27001, PCI DSS, CyberEssentials+), or whatever policy someone mashed together 5 years ago must feel like an impossible task... How can you begin to resolve this?
Let’s first start with some hard truths:
There are on average 2,400 new vulnerabilities published every month, and in 2023, there were 29,066 vulnerabilities published. As of only Oct 2024, there are already 29,398 (VulnCheck, 2024).
In most large technical environments, there is not enough time/resource to patch everything consistently.
Effort patching the ‘wrong’ vulnerabilities damages security culture, rapport with engineering teams, and often doesn’t do anything to benefit organisational security.
So we have an ever-increasing influx of vulnerabilities, and apparently, sometimes we can patch and it might not even provide any benefits? ‘Fraid so. Of course, ignoring the potential update crashing your system or any other negative effects of applying a patch, your system won’t be any less secure, but you may be harming long-term performance in this area by not understanding how best to utilise your resources. If you’re wondering where to go from here, then here’s 5 of my essential tips to creating a rock-solid foundation for vulnerability management.
1 - Understand and prioritise your assets
Asset management. That’s right, it’s time to pull your socks up an- Wait, no, come back — I know it’s step 1 everywhere and you still don’t have a good solution for it, but hear me out. Asset management, from a vulnerability management perspective, doesn’t have to be the 100% perfect dream I know you wish it was. In fact, it’s our job to take a stab at fixing it. Utilise your subject matter experts internally and map whatever way you can. Take worksheets, CSVs, JSON files, notepad files if you have to. Start understanding what you have, what it does, and where it sits. Your goal here is to understand what’s important.
If you’ve got web servers, load balancers and other web apps that are tempting every BugBounty registered member and scriptkiddie with a Kali Linux install, put these in DEFCON 1. If it’s old, out of support, and the cornerstone of your entire business operation (see image), keep a real close eye on how someone might reach/break it. If your end user devices are in the hands of people you barely trust to button up their shirts correctly, consider what they’re allowed to install on their machines and the urgency at which it would need to be resolved to prevent disaster.
2 - Think inside of CVSS
If you haven’t heard it yet, prioritising vulnerability fixes solely by CVSS score is bad. That doesn’t mean CVSS itself is bad, but the way you interpret the data and use it to make decisions has to be able to respond to the needs of the business. For example, your business might be in providing essential utilities to customers. You don’t store anything of any incredibly high value, but your availability is what matters most. Any blip in service may impact customer’s lives. Now let’s compare two imaginary vulnerabilities:
Vulnerability 1
CVSS Score: 9.1 (Critical)
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Vulnerability 2
CVSS Score: 7.5 (High)
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
You’d think from just looking at the scores and criticality that the first one is obviously worse, I mean look at it, it’s precisely 1.6 worse! In fact, the only difference between the two is that I swapped the impact metrics. Vulnerability 1 affects confidentiality and integrity, whilst Vulnerability 2 affects only availability. Both are easily exploitable over the internet, with no user interaction or privileges required. Both are a PR nightmare, but the 2nd may (in this imaginary business’ context) genuinely put people’s lives at risk.
Understand the metrics that make up CVSS scores and apply the logic to your assets and your business functions.
3 - Think beyond CVSS scores — enrich your data
CVSS is not the only open standard for scoring and assessing vulnerabilities and CVSS is quite limited in the scope of what information it’s capable of giving you. Here’s two FREE ways to improve:
EPSS - Exploit Prediction Scoring System — EPSS assesses a probability score for each CVE between 0 and 1 - the higher the score, the greater the probability that a vulnerability will be exploited. If you set a threshold to only see vulnerabilities with an EPSS score over 10%, you’ve successfully deprioritised 98%~ of vulnerabilities. It’s definitely worth reading the detail about their model and understanding how it can be effectively used to prioritise your data.
CISA KEV — CISA ‘Known Exploited Vulnerabilities’ is the bible for checking whether or not a vulnerability has been exploited in the wild. This helps businesses’ to prioritise their focus on vulnerabilities that can materially manifest as a result of action taken by a malicious threat actor. As of writing, there are 1,137 entries in the Known Exploited catalogue which is a monumentally smaller number to manage than the total vulnerabilities reported. Only 43 of the 22,673 vulnerabilities released this year are ‘Known Exploited’. If you’re concerned about security rather than patch compliance, this data should not be ignored.
There are other paid solutions in this space that are offering heightened levels of analysis and proprietary scoring/prioritisation but these often are not cheap and will not typically have your environmental context in mind. There is value in these solutions, but you may find quicker and easier wins at low maturity levels by implementing the data feeds above into your vulnerability analysis.
4 - Get buy-in from the people that matter
Here’s where you’re going to have to put your laser sights on the people that are your ‘do-ers’ and ‘enablers’. Your ‘do-ers’ might not be quite as important if you’re responsible for both vulnerability management and patch deployment, but it’s still very hard to mature if you haven’t got the right people along for the ride.
You’ve first and foremost got to identify the people that get stuff done. People responsible for your Windows/Linux servers, the team that looks after your network equipment, the people managing your web servers, your VMWare engineers (if you can get them to stop cursing at Broadcom for 5 minutes)… All these people will help you to move your mountains, but you have to be willing to work with them and understand that their priorities will differ to yours. As much as some people may argue; security is a blocker. You can definitely make the process less painful, but any time spent on security is time not spent improving and iterating. That doesn’t mean it’s not essential, but often these team’s metrics are not ranking security patching as equal to their cost-benefiting deliverables.
Where you may face pushback from these teams that they simply can’t fit in the patching, that’s when you’ve got to get buy-in from your ‘enablers’. These are your senior leaders, your CISOs, directors, CTOs, CEOs etc. These stakeholders need to understand why we carve out development time to focus on security. If you aren’t getting the traction you need, then it’s your enablers who need to give that wheel some traction. Explain the risks, explain the potential ramifications, and arm them with as much information as is needed. They will ultimately have their own risk appetite for what they’re willing to tolerate - as long as you keep a log of the concerns raised and evidence that you have raised it, that’s then the business’ decision how they respond. Sleep easy knowing you’ve done all you can.
5 - Improve intelligence and reduce notification time
In the security world, we’re often assessed against how quickly we can detect, and how quickly we can respond. In vulnerability management, there isn’t always an event to detect, but there are constant shifts in the security world. Companies are getting breached, vulnerabilities are being identified, exploits are being written which are then mobilised by malicious threat actors. It’s imperative we are notified of these events as soon as possible so that we can assess the potential damage that may have already taken place, or may inevitably take place if not acted upon.
The main goal here is to bring down the notification time so that the response time can be reduced. The sooner something is in front of you to quantify the risk, the sooner the business can be informed of actions they should take. To reduce the notification time, consider:
Set up RSS feeds for good sources w/ instant notifications (Webhooks / email alerts)
Consider allinfosecnews.com, and platforms like Inoreader, Newsblur, or Feedly.
Subscribe to reputable security orgs that provide regular newsletters and notifications
Utilise social media monitoring tools
In conclusion…
If that was too much snark and not enough concise helpful info, I will never apologise, but I will deliver:
Categorise assets, assess their criticality, and prioritise their importance. Create your own asset database if you have to.
Understand CVSS vectors well, and consider which vectors are the biggest risk to which assets.
Enrich your vulnerability data with free and open sources, like EPSS and CISA KEV.
Get buy-in from your key stakeholders and become the driving force in fixing culture around patching and security.
Implement good security feeds that notify you quickly so that you can respond to threats imminently.
This is most useful for vulnerability managers just starting out in this area to ensure they have a strong foundation, but hopefully everyone can take something from this. Once the foundation is set, there’s lots of directions to go to further increase maturity, efficiency, and overall security.