Security Vendor Vulnerabilities: It's All About Reaction Time

Friday, June 03, 2011

Rafal Los


As I sat here reading the disclosure of the new persistent XSS vulnerability in the Imperva GUI, I keep thinking of how interesting the attacks on the security devices and gadgets are.  

Yes, security bugs can happen to anybody big or small... and scary as it may seem - no matter how successful their software development program is!

Now, this isn't entirely new as security devices (think locks, card readers, software, etc) have been getting attacked for a while... but it hurts when a security vendor is successfully exploited against a platform that's supposed to be protecting you from attack.

OK... so what?  I tend to be in the camp which believes every device, software and widget out there has at least one security defect that can be exploited given enough effort and resources. So what does that mean, should we all dump all the vendors that get hacked?

Let's face it, when your vendor gets hacked you have a knee-jerk reaction to lose some trust in that vendor, and rightfully so... but ask yourself if you should be that person casting stones.

I get that holding a vendor accountable is different, since that is their primary business - so in some sense there's really no excuse when a vendor of security products gets exploited or has a publicly disclosed exploit... well, sort of right? I mean to say that - in the final analysis, what is it really all about?

I think I have the answer - it's all about (or aboot for those of you northern neighbors... just seeing if you're paying attention) the reaction time. I'm fairly sure I've seen this talked about and mentioned a few times already, and I'm certain many of my peers, and many of you reading this will agree too.  Reaction time is key.

As an organization who's primary business is not security, you get the luxury of a laggy reaction, which may be a matter of hours in certain business models like finance or government, but as a vendor of security stuff you get the luxury of a few minutes... tops.  

You have to have a public-facing and accessible receptacle for found security defects, a team to reproduce, triage and identify a fix, and a tactical dev team to drop in, fix the issue, test and get out on a moment's notice. I bet you've accounted for that in your "Secure SDLC" right?

The moral of this story is this... if you're a vendor of security things, you don't have the luxury of time and obscurity. You will be immediately attacked by the piranha and your competition.

So you have to have a reaction plan, and a tactical team in place months or years before it's needed.  This is a cost most organizations don't account for - but I'm seeing it more and more.  Congratulations if you're doing it... start thinking about it if you aren't yet.

Good luck, and I hope you never have to use your tactical fix team.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Enterprise Security
Service Provider
XSS SDLC Vulnerabilities Cross Site Scripting vendor GUI
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.