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

9/16/2014
04:05 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

New CVE Naming Convention Could Break Vulnerability Management

MITRE sets deadline for releasing new CVEs with different ID format syntax, regardless of how many vulnerabilities we see in 2014.

The growing number of vulnerabilities found by IT manufacturers has created the need for a revamp of the way the security industry identifies them, and if practitioners and vendors don't get ready soon they could be in for some trouble. With so many security products and other IT systems dependent on Common Vulnerabilities and Exposures (CVE) identifiers, an impending change in the syntax of CVE numbers could cause products and vulnerability management processes to break unless accommodations are made.

As the volume of vulnerabilities recorded and categorized by the security industry continues to creep up year-over-year, it was only a matter of time before the old way of naming vulnerabilities using the conventional CVE ID system ran into a snag. With only four identifying numbers per year in the old CVE ID format, the system in place was only able to accommodate under 10,000 vulnerabilities. That is the reason why MITRE, which runs the CVE project, began the process over a year ago to change the syntax of CVEs to accommodate an arbitrary number of digits. After all, last year we reached 7400 vulnerabilities and this year we are nearly up to 6400, and it is only September.

While the syntax change became official at the beginning of the year, until the industry reached the 10,000 vulnerability mark it didn't really need to account for any differences. But today Mitre announced that product manufacturers and practitioners all need to be ready for a hard-and-fast deadline of January 2015, when Mitre plans to roll out some CVEs with the new naming format, regardless of whether the number of vulnerabilities hits the 10,000 mark in 2014.

MITRE officials are trying to get the word out, as they believe there's still not enough awareness in the industry that a change is coming.

"Many vendors and consumers are still unaware that this change has happened," says Steve Christey Coley, principal information security engineer at MITRE. "We're producing CVEs at such a fast rate that we could cross into needing the new syntax in just a few months. But even so, the time has come and people have had enough notice. This is our last widespread pitch to get people on-board because the change is coming."

Many within the vendor community agree that the shift by MITRE is the right one given the circumstances and are confident that the name change and the impending deadline won't be too disruptive.

"It's certainly a sign of the times when Mitre has determined that ten thousand entries simply won't suffice for a given year and has instead moved to a more flexible scheme which allows for an unlimited number of vulnerabilities to be tracked," says Michael Sutton, vice president of security research for Zscaler. "While this will require some relatively minor coding changes for applications that digest CVEs, the pain shouldn't be too great. Mitre has given vendors sufficient warning, providing a full year to make the necessary changes."

However, Coley says that practitioners and vendors need to prepare themselves for system breakages due to the changeover.

"We know that this will cause breakage because we've already spoken to some vendors and CVE providers who have encountered breakage, and in fact we've found difficulties even within our own code that manages CVE IDs," he says.

Coley explains that problems could come in a number of ways. For example, if a system for reporting vulnerabilities assumes the old syntax, it could potentially chop off additional numbers from a CVE and report a four-digit ID that might point to a completely different vulnerability than the one intended.

"So an incoming vulnerability might have one ID, but they're making decisions based on the wrong vulnerability number and therefor the wrong vulnerability," he says.

The devil will be in the details, says Morey Haber, senior director of program management for BeyondTrust, who says the way his firm's code was developed makes it such that it won't be impacted by the change.

"If any vendor coded specifically to the current length, it could be a problem," he says. "BeyondTrust will not have an issue but some vendors may experience great pain in parsing these values if the CVE is stored and coded by length."

As such, practitioners are strongly encouraged to take a deep dive to look at everything that could possibly be impacted by the change.

"It is absolutely worth verifying with your vendors that they will support the new format, from vulnerability scanners, managers, GRC systems, patch management, and security intelligence platforms that all use CVE-ID¹s in one way or another," says Jody Brazil, CEO of Firemon. Additionally, organizations need to think about home-grown systems that could be dependent on CVE identifiers.

"I expect all of the big vendors will have this implemented before it becomes an issue if they haven't already, but many security teams who've written their own tools for tracking and parsing CVE identifiers will probably experience some issues," says Ryan Olson, Unit 42 intelligence director for Palo Alto Networks.

Coley says that as organizations prepare for the change they are advised to check out MITRE's technical guidance on the matter. That guidance and more background on the change can be found here.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/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
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25596
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. T...
CVE-2020-25597
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. Howeve...
CVE-2020-25598
PUBLISHED: 2020-09-23
An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar...
CVE-2020-25599
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory a...
CVE-2020-25600
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains...