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

12:00 PM
Bill Brenner
Bill Brenner
Connect Directly
E-Mail vvv

FUD Watch: The Marketing Of Security Vulnerabilities

I'm all for raising awareness, but making designer vulnerabilities, catchy logos and content part of the disclosure process is a step in the wrong direction.

If I’ve learned anything about vulnerability management as part of a large security operation, it’s that these things are serious business. Vulnerabilities are a threat to companies using the affected technology and – more importantly – a threat to their customers. Customers’ personal data is at stake. Trust in the affected company is on the line. We need to figure out where our systems are affected, if at all, and move fast but carefully to keep users secure.

That means investigating disclosures in a calm, cool manner. But in this age of so-called “designer vulnerabilities” – in which catchy logos and other content are used as part of the disclosure process – it’s getting more difficult to maintain one’s perspective.

In IBM’s Security Intelligence blog, writer Pamela Cobb asks, “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?”

It’s an important question.

The idea of attaching marketing campaigns to vulnerabilities may seem like a golden opportunity, but in my opinion they are misguided attempts to boost the fear factor in a situation where fear is the last thing we need.

We saw the lack of calm with Heartbleed, Shellshock, Poodle, and now Venom.

Each were disclosed the way promoters announce a boxing match or unveil a dramatic movie poster. The vulnerability is portrayed as a monster – a Godzilla-like beast intent on incinerating everything in sight with its fiery breath. Blood and explosives are worked into the theme, because if it bleeds or goes boom, it gets the headlines.

Marketers gave us a heart with blood dripping from it for Heartbleed. For Shellshock they gave us two images – one that looks like a grenade, the other a sinister take on the Shell Gasoline logo. With Venom, we have the head of a cobra, venom dripping from its fangs. Each new vulnerability is compared to the last one, usually with claims that it’s “worse than Heartbleed” or “worse than Shellshock.” Company executives see it and panic. Fire drills ensue.

I don’t think marketers behind these images are slimy or sinister. They’re doing what marketing professionals are paid to do, drawing attention to something big their company’s research teams have discovered. I can even respect the argument that marketing vulnerabilities this way raises the awareness necessary to force people into action. The researchers involved are well-respected and good at what they do. They see cracks and want them fixed, and it’s impossible to find fault with that.

In his /dev/random blog, infosec consultant and hacker Xavier Mertens notes the potential benefits of designer vulnerabilities, writing that “Such vulnerabilities are critical and affect millions of devices and, thanks to the help of their marketing presence … were also relayed by regular mass media to the general public.” Sometimes, he wrote, that mass communication was for the good. But it was also for the bad, because overplaying of FUD led to some lousy press coverage. His final point: “Speaking about major vulnerabilities to a broader audience is of course a good initiative, (but) it must be performed in the right way. “

So far, my impression is that more is going wrong with the marketing approach than right.

When a security shop gets reports of a new vulnerability and initiates an investigation, cool heads are necessary. Raise the emotional noise with an image and you affect a person’s ability to look over the issue thoroughly and completely. Too much emotion leads to mistakes. There can be an overreaction to the flaw, causing companies to tweak systems in a way that can make matters worse. And there can be an underreaction, where practitioners who have been around the block a few times see the media attention and dismiss something important as FUD.

I’m all for raising awareness. I just think there are more responsible ways to do it. We’ve seen examples of that for years. As a journalist watching for new vulnerabilities each day, I found various sites that helped me keep track of everything without the bells and whistles. If a vulnerability was severe, it was simply labeled a high risk. You got the cold facts and could swing into action.

The process worked fine before the days of scary images.

I consider myself a forward-looking guy. I like when we try new things to raise awareness.

But in this case, it doesn’t work.

Put away the fancy artwork and get serious.


Writer. Father. Husband. Blogger. History buff. Heavy Metal fanatic. Rebellious Catholic. Frequent traveler. In his day job, Brenner writes about threats to Internet security as seen from his vantage point as Senior Security Tech Writer at Akamai Technologies research center. ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Sara Peters
Sara Peters,
User Rank: Author
5/29/2015 | 11:05:36 AM
mixed feelings
I've got mixed feelings about the catchy names and the cool graphics. I suppose they could contribute to FUD. But, then again, it does seem to increase awareness...and yet there are plenty of organizations that are STILL vulnerable to Heartbleed, so there's still a need for even more awareness.

Ultimately, I think the responsibility is on us, the journalists. We're the ones who write the headlines. We're the ones who decide when to cover something and when not to. They might send us the press releases, but we have to decide what to do with them.
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
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
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-03
A GET-based XSS reflected vulnerability in Plesk Obsidian 18.0.17 allows remote unauthenticated users to inject arbitrary JavaScript, HTML, or CSS via a GET parameter.
PUBLISHED: 2020-08-03
A GET-based XSS reflected vulnerability in Plesk Onyx 17.8.11 allows remote unauthenticated users to inject arbitrary JavaScript, HTML, or CSS via a GET parameter.
PUBLISHED: 2020-08-03
Cross-site request forgery in Teltonika firmware TRB2_R_00.02.04.01 allows a remote attacker to perform sensitive application actions by tricking legitimate users into clicking a crafted link.
PUBLISHED: 2020-08-03
Improper Input Validation in Teltonika firmware TRB2_R_00.02.04.01 allows a remote, authenticated attacker to gain root privileges by uploading a malicious backup archive.
PUBLISHED: 2020-08-03
Improper Input Validation in Teltonika firmware TRB2_R_00.02.04.01 allows a remote, authenticated attacker to gain root privileges by uploading a malicious package file.