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

8/10/2020
10:00 AM
David Habusha
David Habusha
Commentary
100%
0%

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
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Russian Military Officers Unmasked, Indicted for High-Profile Cyberattack Campaigns
Kelly Jackson Higgins, Executive Editor at Dark Reading,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24847
PUBLISHED: 2020-10-23
A Cross-Site Request Forgery (CSRF) vulnerability is identified in FruityWifi through 2.4. Due to a lack of CSRF protection in page_config_adv.php, an unauthenticated attacker can lure the victim to visit his website by social engineering or another attack vector. Due to this issue, an unauthenticat...
CVE-2020-24848
PUBLISHED: 2020-10-23
FruityWifi through 2.4 has an unsafe Sudo configuration [(ALL : ALL) NOPASSWD: ALL]. This allows an attacker to perform a system-level (root) local privilege escalation, allowing an attacker to gain complete persistent access to the local system.
CVE-2020-5990
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to 3.20.5.70, contains a vulnerability in the ShadowPlay component which may lead to local privilege escalation, code execution, denial of service or information disclosure.
CVE-2020-25483
PUBLISHED: 2020-10-23
An arbitrary command execution vulnerability exists in the fopen() function of file writes of UCMS v1.4.8, where an attacker can gain access to the server.
CVE-2020-5977
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to 3.20.5.70, contains a vulnerability in NVIDIA Web Helper NodeJS Web Server in which an uncontrolled search path is used to load a node module, which may lead to code execution, denial of service, escalation of privileges, and information disclosure.