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

1/14/2021
10:00 AM
Tal Morgenstern
Tal Morgenstern
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Jim McNeill
50%
50%
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.
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4931
PUBLISHED: 2021-02-24
IBM MQ 9.1 LTS, 9.2 LTS, and 9.1 CD AMQP Channels could allow an authenticated user to cause a denial of service due to an issue processing messages. IBM X-Force ID: 191747.
CVE-2020-11987
PUBLISHED: 2021-02-24
Apache Batik 1.13 is vulnerable to server-side request forgery, caused by improper input validation by the NodePickerPanel. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.
CVE-2020-11988
PUBLISHED: 2021-02-24
Apache XmlGraphics Commons 2.4 is vulnerable to server-side request forgery, caused by improper input validation by the XMPParser. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.
CVE-2021-21974
PUBLISHED: 2021-02-24
OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in...
CVE-2021-22667
PUBLISHED: 2021-02-24
BB-ESWGP506-2SFP-T versions 1.01.09 and prior is vulnerable due to the use of hard-coded credentials, which may allow an attacker to gain unauthorized access and permit the execution of arbitrary code on the BB-ESWGP506-2SFP-T (versions 1.01.01 and prior).