Invite to discuss

Customize your feed and connect with your peers.

Sign Up

How does the infosec community get vendors to use facts and reason

At the Usenix Enigma 2017‍ conference, the chief technical director of the UK NCSC used words that are very similar to what we've seen repeatedly here on Peerlyst. He called out cybersecurity‍ vendors for using FUD.

He said that they use FUD and criminal hacker steoretyping such a using graphics with hoodies and the usual misconceptions.


(insert small artificial break here to enjoy the lovely cat meme)


This is well-known to have been a problem, although many security vendors do seem to have toned down on the too obviously misleading steoretyping.

He also said that when cybersecurity vendors push "APT" threats, it's really just "“adequate pernicious toe-rags” doing the actual criminal work - and not advanced persistent attackers. Skidz with metasploit abusing SQL-i was mentioned, I believe.

The vendors use marketing terms and misconceptions to boost sales in whichever market they are in, a market often containing "useless next-gen cyber security solutions" according to Daniel Shapira‍ (link).

So the big question becomes:

Is the profitability of cybersecurity vendors more important than openly facing what the real problem is and dealing with it in transparent fashion?

If we could require of cybersecurity vendors to openly state what the problem space is that they're trying to tackle, how they're approaching tackling it technicaly, and what the insufficiencies of their solutions are, would this improve the current state of things?

Sales would probably drop for a lot of big vendors, while the infosec community in general - and especially blue teamers everywhere, would start having a fighting chance at identifying and discerning between lemons a real security solutions.

Requiring vendors to openly state how their own Application Securityprogram is implemented could help as well, perhaps? Then CISOs and other decision makers in purchasing would be able to at least get a chance to evaluate what they're buying:

- Option 1: Fuzzes all internal releases, uses static analysis‍ plus dynamic analysis‍ testing techniques

- Option 2: Has a nondescript statement about a "SDLC‍" that they've implemented but no details

Which would you choose?

It's often about trust, but verify. When we do not have the option to verify, then trust is not possible. Without trust, there should be no purchasing, but there still is, because CISOs are left without any other option - it's all FUD and security by obscurity‍. No one knows how anyone works their magic. And if everyone knew, it would no longer be magic and the solution would add no value at all, potentially, instead of a marginal theoretical value.

That brings me to the Bill of contents‍. I've seen this idea proposed here and there, and if indeed vendors were obliged to document which third party and open source libraries they use in their code, plus which versions they're currently using in which releases, this would also help CISOs make more informed decisions.

So I very much thank the NCSC chief technical director for lambasting the vendor community. We can get better, but only together, and only by being open and transparent about what's what and how it works.


Security Management‍ , vendors

Join the discussion...
Gwen Betts

As the Director of marketing and product design lead for a security company, I hear you on ALL of this. FUD style sales and marketing is the bane of my existence, and when we started building the Komand brand, a main goal was to never market or sell in that fashion. Trust and reputation is crucial. We want to empower people, not scare them into buying a product they may not even need.

And similarly to what you've mentioned, the heart of a product should come from solving a REAL problem and providing real value. Which is why it's vitally important for companies -- security or other industry -- to be truly customer-centric. It also helps to have security practitioners on the product team, too.

I don't believe in security through obscurity (for the most part). And I don't believe that by sharing the way you do things necessarily takes away the magic. If your product is solving a REAL problem, sharing the magic shouldn't matter all that much.

A few things I'll end on: at my company, we do truly believe in sharing our knowledge. We have a tech blog to share what we've learned while working with our tech stack (, and we've started an article depot to share actual security knowledge (

And plugging us one more time, but super relevant... we also put together a slideshare on the benefits of an "open" mentality in the security community: