Skip to main content
June 1, 2015

Branded Vulnerabilities May Change Enterprise Security

Branded Vulnerabilities May Change Enterprise SecurityFor as long as malware, viruses and assorted vulnerabilities have existed, the most significant among them have been given names by the media. Lately, however, the practice of naming security flaws has evolved, building into a legitimate branding campaign for issues found in existing software. While seemingly benign, the practice of branding security issues may affect the way these flaws are fixed in the future, making them more impactful than they otherwise would have been.

Heartbleed and Vulnerability Branding

The era of branded vulnerabilities began with the Heartbleed bug, as detailed in this ZD Net article. Google discovered the bug in the OpenSSL library late in March 2014, patched it and immediately notified a number of well-connected insiders at other organizations. A little over a week later, Finnish security company Codenomicon also discovered the bug, dubbing it Heartbleed, as it bled out important information from the OpenSSL Heartbeat extension.

After notifying the appropriate government authorities, Codenomicon began formulating a marketing plan for Heartbleed, reserving a domain for the bug and creating a logo for it. Shortly thereafter Codenomicon launched its Heartbleed marketing campaign with a professionally made website, logo and official branding.

As the logo for the vulnerability (as well as the vulnerability itself) gained mainstream recognition, it became clear vulnerability branding was here to stay. Subsequent vulnerabilities, such as GHOST and Sandworm, would receive a similar branding effort, and the trend appears to only be in its nascent stages.

Beyond Simple Nomenclature

Detractors of the practice point out that when a security hole as serious as Heartbleed is discovered, the focus should be on fixing the hole and notifying the public, not creating a branding strategy for the company and hoping to gain recognition because of public curiosity surrounding the bug. It's true several weeks went by before the public was informed about the discovery of Heartbleed, while insiders, including businesses not directly involved in InfoSec, knew all about it. During this time, it's not unreasonable to believe information could leak from insiders into black-hat circles, essentially notifying nefarious actors before the public.

Defenders argue that proper branding drives public attention to the important issue of application security, ensuring all CISOs and IT managers properly patch and protect their systems. They can point to Shellshock as an example: Even though the so-called "Bash Bug" was considered worse than Heartbleed, without a branding strategy the public would not have latched on to it as much, making it less likely that enterprise IT personnel would ensure their systems were secure against it.

The truth is, for the companies that do properly brand a vulnerability, the potential recognition could be worth more than simply notifying the public first.

Changes CISOs Need to Know About

Both sides of this argument seem to have a point. On the one hand, a branding campaign can bring direly needed recognition to these issues and help ensure they get patched quickly. On the other, the delay that preparing a branding campaign causes can give nefarious actors time to exploit issues before the public, and most CISOs, know about them. But since branding appears to be the way of the future, it's the second point that should give CISOs pause.

Major vulnerabilities may now be in hackers' hands before the public is notified, so the days of relying on general awareness to know when patches are required are over. Enterprise CISOs have to find an established, well-connected security partner that will have the expertise and insight to fix these security issues as fast as possible — or prevent them altogether.

CISOs also have to look to their own application development and any third-party aspects of their system. While proper AppSec can't always prevent the issues that arise from these kinds of vulnerabilities, strong security can reduce the potential fallout until bugs get patched. If applications are built correctly, and manage the kinds of information they transmit to other applications, then hackers who exploit new vulnerabilities will be limited in the damage they can do.

The right security solution can also actively scan the binary code of third-party elements, providing insight into potential security issues before they are found through other means. Given the prevalence of open-source and outsourced code in most enterprises, these types of scans have to become mandatory before applications are allowed to interact with the rest of the network.

In a world where security flaws may exist for days or weeks while a branding campaign gets created, these types of precautions should be in the tool kit of every enterprise CISO. To build up your tool kit, check out Veracode's GHOST webinar and this whitepaper on creating a plan to respond to a vulnerability disclosure.

Photo Source: Flickr

Shawn Drew has spent the last five years helping businesses understand the difference that technology can make for their internal processes, external connections, and bottom line. He specializes in all things cloud computing and security, and hopes to impart some knowledge on how the two can be combined to enhance the inherent benefits of each. His work has been published on the websites and blogs of a number of technology industry leaders, such as IBM, Veracode and Boundary.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.