Like it or not, the organization you've been charged with securing is constantly working against you by deploying insecure software, code or systems. And the problem is getting worse, as we're set to surpass 2021's record-breaking pace of nearly 54 published common vulnerabilities and exposures (CVE) per day.
These vulnerabilities are more than mere annoyances. By some estimates, around 60% of all cybersecurity breaches are the result of an exploited vulnerability, for which a patch or mitigation was available but not yet applied. So all the other work done to secure your environment—firewall management, access controls, and various endpoint protections—is only mitigating a small portion of your business risk.
To put it another way, upping your security vulnerability remediation game, including patching and other mitigations is quickly becoming an imperative.
To help you achieve that goal, ask yourself the following five questions:
Question #1: Can you automatically identify every potentially vulnerable asset?
This can be tougher than it sounds. Sure, maybe you have an accurate current inventory of every operating system running on every on-premise machine. But can you instantly pinpoint all outdated software or injectable Web apps used everywhere across your organization?
Are you sure? Because searching for vulnerable assets extends your window of exposure—and if you miss a vulnerable asset altogether, you'll remain exposed even after you think you've protected yourself.
Question #2: What logistical obstacles can stand between you identifying a vulnerable asset and you implementing a remediation?
SecOps teams are not always empowered to immediately execute responses on every identified vulnerability. Often, they must work with other groups in the organization that "own" the asset in question—such as IT and/or the department that uses the asset—thereby delaying deployment of the remediation.
Also, if the vulnerable asset is highly critical for the organization operationally, patching may have to be put on hold for several days until the asset can safely be taken offline.
Question #3: Can you prioritize your vulnerability remediation based on business risk?
Assuming for the moment that you can't possibly acquire sufficient resources to instantly remediate every vulnerability everywhere across your environment, it obviously makes sense to address your biggest risks first.
Conversely, it doesn't make sense to spend two weeks patching 1,000 relatively unimportant assets exposed to a single "popular" CVE. In that time, there may be a single vulnerability with more serious consequences for your organization gone unaddressed.
So how exactly do you prioritize your vulnerability management activities today? And is there a way you can prioritize them more intelligently, automating context gathering to identify valuable assets?
Question #4: What's the maximum amount of time that can pass from the publication of a CVE to the moment you remediate your last affected asset?
Organizations often judge their security vulnerability remediation aptitude by comparing their average time-to-remediate with what they perceive as the broader average—which, depending on who you ask, is about two weeks.
This is a terrible mistake for several reasons. First and foremost, your risk isn't determined by your average time-to-remediate. It's determined by your longest time-to-remediate on "high likelihood of exploitation" vulnerabilities, for assets that potentially pose the greatest financial threat to your business: Risk = Likelihood x Impact.
Second, remediation-time statistics are often misleading because they tend to be selectively self-reported. The fact is that many organizations will report an average time-to-remediate of a few weeks even though they have an existing backlog of vulnerabilities that reaches back for months, if not years. They simply discount those vulnerabilities, because they perceive them as low priority. What are you doing to automate that mean-remediation-time computation as part of your prioritization efforts, to ensure that it does not get skewed by confirmation bias?
Third and lastly, the broader average is a bad benchmark because it's still a low bar. More than a quarter of organizations report being breached due to a known vulnerability that was present for more than two weeks, if not months or years in their network. So being "average" is not very good at all.
Question #5: Can you obtain the resources necessary to accelerate your remediation activities and ensure that it's more thorough?
It would be nice if there were a magic wand that enabled you to instantly respond to every CVE (remember there are 50+ every day) or other vulnerability by identifying every single affected asset and deploying the appropriate remediation everywhere. But there isn't. Balancing operational IT risk with information security risk is a complex problem. What we know for sure though, is that faster remediation requires additional budget and a measurable and repeatable approach to risk-based prioritization. So if you want to drive down the risk these security vulnerabilities represent, you must get additional resources and/or make better use of the ones you have.
The five questions boil down to the same issue: the cybersecurity risk associated with your organization's security vulnerability remediation process. It's an issue that you want to reconsider after asking yourself the questions above.
And if after asking yourself these questions you think you might need some help making your remediation less patchy, feel free to give us a call. We have some answers you may find useful.