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.
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. The salt-api's ssh client is vulnerable to a shell injection by including ProxyCommand in an argument, or via ssh_options provided in an API request.