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 //

Vulnerability Management

10:00 AM
David Habusha
David Habusha

Vulnerability Prioritization: Are You Getting It Right?

Developers must find a way to zero in on the security vulns that present the most risk and quickly address them without slowing down the pace of development.

The past few years have seen an exponential rise in the volume of reported security vulnerabilities. Combined with the increase in headline-grabbing security breaches, it's no surprise that organizations are upping their application-security game. This includes a heightened focus on the detection and remediation of security vulnerabilities as early as possible in their DevOps pipeline — leaving developers with the added task of handling an increasingly high number of security alerts.

But they can't remediate everything. This is why they must find a way to zero in on the security vulnerabilities that present the most risk and quickly address them without slowing down the pace of development.

The prioritization of vulnerabilities has become a burning issue for software development outfits that want to stay ahead of security while not falling behind on AppSec release dates. Unfortunately, there is currently no set standard or practice for how to prioritize them. Different teams prioritize security alerts based on a variety of parameters and considerations — not necessarily the most effective ones, either. As a result, they are spending a lot of valuable time figuring out what to tackle first, to varying degrees of success.

To understand which prioritization methods are currently most common, we surveyed 300 of our customers and asked them how they prioritize vulnerability alerts. The top five considerations that arose were vulnerability severity, application type, the popularity of the vulnerable open source component, vulnerability disclosure date, and ease of remediation.

To learn more, we added a new perspective: the hacker community. We took the 100 most common open source vulnerabilities reported in 2019 based on the WhiteSource vulnerabilities database and compared characteristics, such as popularity, disclosure date, and severity score, to the level of discussion in the hacker community based on data from CYR3CON, which predicts cyberattacks based on artificial intelligence gathered from hacker communities.

In doing so, were able to gain insights about the effectiveness of common prioritization methods are and how they measure up when it comes to the hacker community's preferences.

Vulnerability Severity
Many organizations consider the Common Vulnerability Scoring System (CVSS) vulnerability score first when prioritizing remediation since it's so easily accessible and seemingly straightforward. Unfortunately, this parameter does little to shorten the long list of security vulnerabilities that teams need to address since data shows over 55% of the top open source security vulnerabilities were rated as high or critical.

This doesn't mean organizations should disregard a vulnerability's severity score, but it's important to remember that this score doesn't indicate risk. Risk is the impact times the likelihood, but severity only indicates the impact. Organizations need to add additional parameters in order to ensure they are addressing the right issues and not wasting time on security vulnerabilities that pose less of a threat just because they got a high severity score.

Application Type and System Architecture
Many businesses prioritize remediation on vulnerabilities that threaten critical applications related to business data, confidential data, intellectual property, or financial transactions. 

This is an extremely important consideration, but it's challenging to create a one-size-fits-all methodology based on application type when there are so many subjective variables, such as user audience and mobile or web application.

The Popularity of the Vulnerable Open Source Component
Naturally, the more popular an open source component, the more exploit opportunities it provides to hackers.

While we found that 85 out of the 100 most common open source security vulnerabilities in 2019 came up in hacker communities, there wasn't a direct correlation between popularity and the level of discussion.

Clearly, a popular open source component will get the hacker community's attention, but other characteristics also attract hackers to a vulnerability.

Vulnerability Disclosure Date
Many organizations, understanding they can't address the backlog of alerts in their systems, create a cut-off point and decide to only address alerts from a chosen date.

While this is a quick way to lighten the load, CYR3CON data shows many vulnerabilities featured in hacker community discussions occur over six months following disclosure.

Ease of Remediation
As previously mentioned, time constraints and the industry's increasingly competitive release cycles drive development teams to try to address security tasks as quickly as possible. This consideration also factors into prioritization, and the security issues that are attended to first are the easiest, quickest, and cheapest to fix.

While this is another way to cross items off a seemingly never-ending list of alerts, it often leaves critical issues unattended.

How to Prioritize the Security Issues That Matter
One of the most important insights we learned from our study is that when considering which security issues to prioritize, most teams tend to look to the most easily accessible data, which isn't the most indicative of the risk that a security vulnerability poses to an organization.

The research didn't cancel the validity of the five parameters we studied. Rather, it reinforces the understanding that prioritizing security vulnerabilities remediation is complex work. When assessing security alerts in order to fix the most critical issues first, it's important to create a methodology that focuses on the data that matters, going beyond the data that is the easiest or cheapest to access or resolve. 

Related Content:

David Habusha is the VP of product at WhiteSource. He frequently writes articles and speaks about open source, DevOps, and security. Previously,  Habusha led product management teams in large ISVs (Symantec, Veritas, and others) and startups. He is the co-founder of ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Vulnerability Management Has a Data Problem
Tal Morgenstern, Co-Founder & Chief Product Officer, Vulcan Cyber,  1/14/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This is not what I meant by "I would like to share some desk space"
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-20
OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.6, there is a vulnerability which enables remote code execution. In affected versions an administrator with permission to update product data to be able to store an executable file on the server ...
PUBLISHED: 2021-01-20
Weave Net is open source software which creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. Weave Net before version 2.8.0 has a vulnerability in which can allow an attacker to take over any host in the cluster. Weave Net is suppli...
PUBLISHED: 2021-01-20
A vulnerability in the CLI of Cisco SD-WAN vManage Software could allow an authenticated, local attacker to read sensitive database files on an affected system. The vulnerability is due to insufficient user authorization. An attacker could exploit this vulnerability by accessing the vshell of an af...
PUBLISHED: 2021-01-20
Multiple vulnerabilities in Cisco SD-WAN products could allow an unauthenticated, remote attacker to execute denial of service (DoS) attacks against an affected device. For more information about these vulnerabilities, see the Details section of this advisory.
PUBLISHED: 2021-01-20
Multiple vulnerabilities in certain REST API endpoints of Cisco Data Center Network Manager (DCNM) could allow an authenticated, remote attacker to execute arbitrary SQL commands on an affected device. For more information about these vulnerabilities, see the Details section of this advisory.