Vulnerability Management Has a Data Problem

Today, vulnerability management teams have so much data on hand that processing and analyzing it takes as much time as remediation efforts. This occurs in great part because each of the many tools used for remediating vulnerabilities provides only fragments of the data needed to resolve vulnerabilities. As security teams look to double down on cloud IT, vulnerability management teams are under pressure to streamline and scale remediation processes, which can't happen if they are manually parsing siloed data across dozens of tools. Remediation teams — from the chief information security officer (CISO) on down — need better data, not more of it.

The Problem With Data
Today's vulnerability management tools collect basic data, such as the number of vulnerabilities detected, assets impacted, or technical severity. This allows security teams to monitor only the most remedial elements of a remediation campaign; these tools rarely provide the level of correlated detail needed to drive better remediation outcomes. More mature teams might use spreadsheets or business intelligence (BI) tools to track metrics such as the number of previous vulnerabilities that have been fixed, those that still exist, and the number of new vulnerabilities identified since the last scan.

While that data is helpful, it lacks context and rarely provides a holistic view of the remediation program. For example, it doesn't align a vulnerability's location with the impacted business unit, report the true time required to fix a vulnerability, or provide insight into vulnerability prioritization decisions. This type of granular information is foundational in improving remediation outcomes.

The Data We Really Need
Security teams need data that helps them prioritize remediation based on business risk as well as information that guides and drives process improvement. Data should help them identify weak spots and refocus remediation efforts for the most at-risk technology impacting the most critical business areas. 

For example, if a scanner identifies a SQL injection in line 7 or a patch needed on the Red Hat box, that information doesn't convey the specific product impacted, the owner, or the business criticality for the organization. Does one of those vulnerabilities pose more of a risk to keeping the lights on than the other? Which needs immediate attention if the team can't fix both concurrently?

Another consideration is the fluctuating criticality of impacted technology depending on the enterprise's business cycle. For example, many retailers see increased risk during holiday shopping seasons, while grocery chains introduce new products on a monthly basis that can cause priorities to shift across multiple IT and business units. For these situations, teams need better data to facilitate making decisions based on business expectations in real time.

Next, the remediation team needs an understanding of how a particular fix could impact operations. While vulnerability management tools track the mean time to remediation, they do so based on weekly scans, which, again, lack important context. Which vulnerabilities reported last week have been fixed? How much effort did each require? Did it take a day? Five minutes? Five days?

This data would also be invaluable to CISOs. Historical data showing which platforms take more time to patch than others — and why — can help them identify process inefficiencies, product fallibility, and personnel issues and how best to address them.

Why Is This So Hard to Fix?
The biggest barrier to improving vulnerability remediation is that the data is siloed in many different systems: vulnerability data in the scanner, business context data in the configuration management database or asset repository, or, worse yet, in people's heads. Additionally, the security team may deploy several vulnerability management tools siloed across different teams — to those who scan for vulnerabilities, threat intelligence teams, IT operations technicians, etc.

Compounding the issue is the fact that many data points aren't stored by existing tools. For example, few organizations track the amount of time it takes the DevOps team to find the vulnerability, install the patch, and check that it worked. When they do, it's even rarer that they funnel that information back to the vulnerability management program.

Further, some vulnerability management tools ignore the data points that are not stored. So, if a CISO asks how many vulnerabilities were fixed in the last six months, corresponding data is not available in most vulnerability management tools.

What Can We Do About It?
Now comes the hard part — creating the workflows and processes needed to improve remediation outcomes. First, the vulnerability remediation team must get the business unit owners involved, asking them to identify critical business functions and the relationships between assets. Align the business function with the supporting technology products, then assess the criticality of each asset and tie it back to the vulnerability management program. 

Next, security teams should recruit partners from the DevOps and IT operations teams to help coordinate and collaborate on remediation efforts. Those relationships will be key to security's ability to improve remediation processes, as needed, over time. 

This kind of collaboration isn't easy, intuitive, or historically mandated, so security team leads must seek ways to bring these players to the table through cross-function strike teams, training, and other hands-on efforts. Discuss what data is needed to move forward, then plan how to collect and utilize that information to develop efficient and proactive vulnerability remediation campaigns.

Finally, efficiently collecting, parsing, and analyzing that data is key to maturing vulnerability remediation programs. Whether you use spreadsheets or BI tools, remediation teams must then decide which metrics to track and set reasonable key performance indicators (KPIs). Executing against data-driven goals makes it much easier to stay on track. 

This is a heavy lift — believe me, I know. But pain is a great motivator, and for security teams, few things are more painful than a breach that could have been avoided had they patched the exploited system when the patch first came out. 

Sound familiar?