There has been some recent discussion of nCircle's vulnerability SLA - eEye's Ross Brown fired the first salvo, Alan Shimel jumped in,
and then TK from nCircle answered back. (Update: TK's post was from a different time period - he wasn't part of this debate.)
Before I start this, I want to say that I respect these guys immensely and I'm not writing to throw stones - the real issues of the discussion are being ignored because, while these guys are all great executives and marketers, I would argue that there are nuances that they're missing.
And, since vulnerability assessment is what I've spent most of my life doing, I can help shed some light. Especially since (even though I don't work there anymore and haven't in a long time) I was involved in writing the SLA.
Before I jump in on the discussion, let me stop short here and get remedial for a second so we're on the same page. I need to explain the difference between unauthenticated and authenticated checks. Authenticated checks use things like SSH, SNMP and SMB and other protocols to log in to the device and check as though the scanner was checking from the keyboard. These are incredibly easy checks to write, and take no time at all. Unauthenticated checks work only for some vulnerabilities (the ones hackers can get at remotely on servers, not things like web-browsers and mail clients). And, in most cases, they are incredibly hard to write.
All vendors are able to put out authenticated checks in under an hour. Heck, there are teams of monkies in the deepest parts of the jungle that are putting out authenticated checks in under an hour. As well as a few pre-school classes that I'm aware of.
The SLAs are interesting only in the case of unauthenticated checks.
The first thing that I have to say: in some ways, Ross is right. Today, with advanced tools like BinDiff (and, actually, everything Halvar makes), Ollydbg, and innumerable others, vulnerability reverse engineering is a lot easier than it used to be. Most companies can release remote checks in less than 24 hours pretty reliably.
But most vendors still don't. And even fewer have gone back and written the unauthenticated checks for the ones they missed. Because it's resource intensive and, for any given less-than-CNN-worthy vulnerability, the ROI on doing it just isn't there.
In fact, I know of vulnerabilities that nCircle wrote unauthenticated checks for under their SLA that are still only covered by authenticated checks in most competitive products.
I'm not here to advocate for either side - the business decision clearly favors not doing it because of the resources involved, though there are customers out there who definitely appreciate it - when I was at nCircle, I talked with them daily.
Beyond that, as Ross and Alan point out, the SLA itself is mostly useful as a marketing tool, not as a statement either of quality or actual service given to customers.
But, Ross, you should have asked your R&D team this question before you posted:
"For every vulnerability since 2004 in a Microsoft remotely available service, do we have a check that doesn't require authentication?"
Knowing your product, I'm 99.9% sure that the answer is no. nCircle's SLA requires theirs to be yes. That's the only real value that the SLA provides, beyond the marketing b.s.