Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:00 AM
Tal Morgenstern
Tal Morgenstern
Connect Directly
E-Mail vvv

Vulnerability Management Has a Data Problem

Security teams have an abundance of data, but most of it lacks the context necessary to improve remediation outcomes.

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.

Related Content:

Quarterbacking Vulnerability Remediation

How Data Breaches Affect the Enterprise

New From The Edge: Homomorphic Encryption: The 'Golden Age' of Cryptography

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?

Tal Morgenstern brings almost 20 years of experience in cybersecurity products development and design to Vulcan Cyber – experience he gained in the Israeli army, building cutting-edge Elbit systems, Israel's largest defense contractor, and during his tenure in various ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Jim McNeill
Jim McNeill,
User Rank: Apprentice
1/14/2021 | 11:31:34 AM
Data Classification and Time To Fix
A very prescient article, thank you. A data classification program can aid considerably in targeting remediaiton efforts, and Time To Fix is absolutely essential to planning remediation work.
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-23
Vulnerability in OpenGrok (component: Web App). Versions that are affected are 1.6.7 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise OpenGrok. Successful attacks of this vulnerability can result in takeover of OpenGrok. CVSS 3.1 ...
PUBLISHED: 2021-06-23
A vulnerability in SonicOS where the HTTP server response leaks partial memory by sending a crafted HTTP request, this can potentially lead to an internal sensitive data disclosure vulnerability.
PUBLISHED: 2021-06-23
A command execution vulnerability exists in the default legacy spellchecker plugin in Moodle 3.10. A specially crafted series of HTTP requests can lead to command execution. An attacker must have administrator privileges to exploit this vulnerabilities.
PUBLISHED: 2021-06-23
Heap based buffer overflow in tsMuxer 2.6.16 allows attackers to cause a Denial of Service (DoS) by running the application with a crafted file.
PUBLISHED: 2021-06-23
Heap based buffer overflow in tsMuxer 2.6.16 allows attackers to cause a Denial of Service (DoS) by running the application with a crafted file.