March 25, 2015 By Pamela Cobb 3 min read

We have come to a precarious place in security research where the volume of vulnerability disclosures is making it difficult to prioritize not just what to patch first, but also what to prepare for that nerve-wracking five-minute elevator trip with the CEO, who undoubtedly heard about the latest Heartbleed over his or her morning coffee. In the age of designer vulnerabilities that come with catchy names, branded websites and custom logos, how can the security industry stop itself from falling into a trap where the marketing of security vulnerabilities is just as important, if not more so, than the risk they actually represent?

A Vulnerability by Any Other CVE Number

Allow me to put on my Captain Obvious hat when I say that naming things makes them easy to identify. How easy is it to reference a “blue pen” versus a “000F55-colored ink-based writing instrument?” Perhaps I have 10 pens in my desk drawer. If all of them have the same blue color, I need a secondary indicator. If I number the pens in my drawer in order of discovery, I’d get PEN-2015-0001 and so on. These schemata are very handy.

Naming or numbering something, however, doesn’t necessarily brand it. Branding implies the development of surrounding assets, such as websites, pictures, blogs, tweets and webinars. The creation of these assets can help provide additional information and context, which is helpful to have in one place when you’re talking about it.

In the past, the industry has given threats names such as “Melissa” and “I Love You,” or given worms names like “Conficker” and “Blaster.” These names helped raise awareness at a time when Internet threats were in their infancy, and the public was unaware of the potential dangers of opening email attachments. Threats have evolved, and the recent change in naming vulnerabilities seems to be that we are now seeing bundled packages of accessories at the moment of disclosure, not just a suggested name.

The naming trend for malware waned for a while, likely in response to a customer revolt over these slickly named bits of code. Malware naming fatigue set in, in the same way the massive number of personally identifiable information records breached today has dulled consumers’ response to a ho-hum sigh of resentment. Security analysts are beginning to note a new vulnerability marketing release by just adding it to the pile of things they need to address in their networks.

The Perils of Marketing

Security is a competitive market, and technologies rapidly change. The ability to claim discovery of a critical vulnerability is a feather in the cap of any security researcher. With the decline of bug bounty programs, notoriety is one of the benefits a researcher can claim these days, along with the satisfaction of foiling the attackers. Coordinating disclosures between researchers and software vendors is tricky and requires careful planning to maximize protection for the end user. There is an intricate dance of discussion, patch development, testing, rollout and public disclosure that finds equilibrium in the need to raise awareness for end users without raising too much awareness about potential bad actors.

However, the industry needs to balance the desire for media opportunities with potential delays in disclosure if the marketing materials for the vulnerability aren’t ready. Several detailed accounts of the timeline around Heartbleed indicate there was a rush to create marketing materials for the vulnerability. The fear, of course, is that security researchers will focus more on bragging rights than actually protecting end users, which could lead to delays in disclosure if resources are diverted from responsible disclosure to marketing activities.

Naming Vulnerabilities Doesn’t Fix the System

Designer vulnerabilities do nothing to offer better protection for the customer’s ecosystem than one marked only with a CVE number. IBM X-Force reported that three months after the Apache Cordova vulnerability disclosure and associated patches were made available, 59 percent of banking apps were still unpatched. Knowing the name “Heartbleed” didn’t increase the patch rate, either — those were only slightly different than the Cordova instance, with just over half of affected servers patched two months after disclosure.

While naming and branding can smooth the lines of print and digital communication, it can distract from truly fixing problems in the network if resources are directed toward the biggest brands versus the biggest holes in the infrastructure.

By perusing message boards where security analysts and researchers talk, there is clearly a growing distaste for overmarketed designer vulnerability disclosures. The highest recommendation X-Force can provide is to have current and accurate asset inventory for your ecosystem and prioritize patching based on risk impact to critical systems, not on which vulnerabilities have the most attractive logo.

Learn more about Designer Vulns: Download the 2015 Q1 IBM X-Force Report

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today