Just five years ago, the vulnerability landscape looked markedly different. There were fewer vulnerabilities to patch and risk was far lower - since most systems were still on-premise and the overall cyber-threat climate was calmer.
John Breeden II of CSO Magazine summarized this old-world vulnerability attitude nicely, "Think of vulnerabilities like holes in a suit of armor. The holes might not instantly pose a problem, but probably will cause trouble eventually. Ideally, patching those holes before someone exploits one, sending an arrow through it, for example, is a good idea."
But today, that world is gone. There are so many holes that the suit of armor is essentially nonexistent. There are far, far more known vulnerabilities and far more attackers willing to act on them.
The trend today is vulnerability risk management. And while management is an important first step in solving any problem – the next natural step is actually rolling up your sleeves and solving it. It is here that organizations are currently falling short.
Vulnerability risk management was more relevant to the old world of vulnerabilities; infrastructures were less flexible, and changes to them significantly harder than today. We need to change the conversation from management to remediation, knowing that we have the opportunity – due to the changes in the way we manage infrastructure – to allow us to stop compromising.
Let’s drill down and see how to make that happen.
What’s Wrong with Vulnerability Risk Management?
Currently, vulnerability risk management’s focus is on detecting vulnerabilities and determining the perceived greatest risk.These solutions collect a lot of interesting, technical data and delivering it to the user under many different titles — “vulnerability intelligence,” “network visibility,” “exposure insights.” The problem is, this paradigm falls short of actually protecting the network.
The reason? If data doesn’t drive users to action, it’s useless. Vulnerability risk management alone fails because it can’t translate insights into actions, and can’t scale to meet current vulnerability volumes.
In defining vulnerability risk management as “…systematically and continuously finding and eliminating vulnerabilities in your computer systems,” Qualys highlights the importance of at once identifying and remediating vulnerabilities.
The Three Steps
Given the above, we’ve come up with three steps enterprises should take to change the conversation from vulnerability management to vulnerability remediation:
STEP #1 - Prioritize Based on Impact
It’s not always readily apparent which vulnerabilities are the most important to fix and will have the most significant impact on an enterprise. In years past, when total numbers of vulnerabilities were few and far between, prioritization of vulnerabilities was based simply on technical severity. Today, however, prioritization needs to be based on the correctly-weighted fusion of the following factors that will allow organizations to move toward vulnerability remediation continuously:
- Overall Risk of Vulnerability - What is the overall risk that a given vulnerability is posing to an organization based on its exploitability, technical severity and overall importance of the asset? Are there known public exploits, like scripts that anyone can download to use the vulnerability? Are there active campaigns exploiting this vulnerability, and if so what type (ransomware, DDoS, malware, etc.)? In which vertical markets (financial enterprises, SaaS companies) are we seeing greater exploitation of the vulnerability?
- Impact of Solution - The ultimate business impact of every vulnerability – no matter how technically severe or exploitable – is measured by how it affects business. What is the overall impact of a given vulnerability on my own network, and how will:
- The solution impact my network negatively (downtime, interrupting business processes)
- The solution impact my network positively (how many bulbs one patch solution can solve, or how updating an OS version might solve hundreds of vulnerabilities).
STEP #2 – Define SLAs
Define formal and agreed-upon SLA’s (Service Level Agreements) for every vulnerability severity level and start addressing security patches as business-critical features competing for resources. Ideally, based on the SLA and criticality level, you should be able to prioritize between product feature vulnerabilities and security-critical changes.
Within these SLAs, define specific processes and steps that should be taken to complete remediation. Make sure to reduce manual aspects of remediation to a bare minimum and make effective use of existing organizational infrastructure like the CI/CD pipeline.
STEP #3 – Integrate Workflow
Make sure you apply changes as early as possible, and that you utilize the different automated process that every feature goes through before deployment. This is a way to save time and effort instead of relying on a manual process.
Moreover, make sure to continuously validate – don’t just patch and forget. Sometimes patches don’t “stick” due to dependencies or human error – and vulnerable images are still deployed post-patching. You need to continuously validate remediation, and constantly act on unmediated vulnerabilities.