In my most recent post,
I pointed out that it’s literally counterproductive to buy only software products
for which no vulnerabilities have ever been reported – especially if the
product doesn’t have a CPE name, so it’s not listed in the NVD at all. This is because
not reporting any vulnerabilities is almost certainly not a sign that
the product is perfect, but that the supplier doesn’t think it’s worthwhile to
even look for vulnerabilities. After all, if you’re sure your software is
perfect, why even bother to look? I provided a vivid example of a device that’s
not even listed in the NVD, but probably has about 40,000 vulnerabilities
(2,000 of which are probably exploitable) in its software and firmware,
according to Tom Pace of NetRise.
However, I also pointed out that Steve
Springett had mentioned that, in his day job, they not only don’t get fooled by
products with zero vulnerabilities, but they literally favor products for which
a lot of vulnerabilities have been reported. The reasoning is simple: There are
a ___-load (excuse me, “a large quantity”) of vulnerabilities in just about any
software or firmware product. Since most vulnerabilities are reported by the
supplier of the vulnerable product, they can exercise discretion in the ones
they report and the ones they don’t report.
In the post, I did point to one type
of vulnerability that probably doesn’t need to be reported: vulnerabilities
that the supplier discovers and immediately fixes. Since these vulnerabilities
never even have the chance to be found in a shipped product from the supplier,
I don’t see why they would need to be reported. The whole reason for reporting
is to inform software-using organizations of vulnerabilities in software they
use, not as a form of public flagellation of the supplier for not being perfect
in all circumstances, even if there’s no possibility of harm to anyone.
On the other hand, a supplier
definitely should report any vulnerability that is found in a product they have
already shipped. And Steve is saying it’s inevitable there will be a lot of vulnerabilities
that meet this condition (of course, the biggest reason for this is that new
vulnerabilities are always being discovered, so a few lines of code that seemed
totally innocuous when the software was written suddenly are identified as a
vulnerability). So, if a product has a CPE name, but only a few vulnerabilities
have ever been reported for it, this is usually an indication that the supplier
isn’t looking very hard for vulnerabilities (the fact that there’s a CPE name
means they’ve at least looked once, but that’s not much better than never
having looked in the first place).
This brings me to an excellent blog
post I just read, by Walter Haydock. Walter is quite an interesting fellow.
I connected with him on LinkedIn last year, and a couple of months ago, he
mentioned me in a list of five people that his LinkedIn followers should
connect to. I was of course pleased with that, but I wasn’t expecting what came
next: within two days, about 300 people requested to be connected with me, all
due to Walter (whereas I’d probably never had more than two or three requests
in one day, and most days none at all). I found this almost scary; I asked
Walter what would happen if he told all of his followers to drink poisoned Kool-Aid™.
He didn’t know, but also added that he didn’t plan to try that. Good thing! With
great power comes great responsibility.
You get the point: This guy’s blog
is really good. I highly recommend you subscribe (although I don’t think my
recommendation will bring Walter 300 new subscribers in two days!). His latest
post makes a point something like my point in my previous post: that the number
of vulnerabilities itself isn’t a very meaningful metric (he writes both for suppliers
and end users, so you get both perspectives on this question).
What struck me most in Walter’s
post was this paragraph:
Some compliance regimes, such as
the federal government’s FedRAMP standard…(establish) clear perverse incentives
with respect to how organizations look at the total number of findings. For
example, after initial authorization, organizations that identify an increase
of 20% or more from the baseline, or 10 unique vulnerabilities, whichever is
greater, are subject to
a “Detailed Finding Review.” By punishing companies who identify more than an
arbitrary number of vulnerabilities - regardless of their severity - during a
given time frame, the government disincentivizes its vendors from looking too
closely for these vulnerabilities in the first place.
This was a real eye-opener to me: The
fact that, not only would a supplier not get credit for reporting a healthy
number of vulnerabilities, but they would get penalized for doing so. We clearly
need to re-think how we treat software vulnerabilities.
Any opinions expressed in this
blog post are strictly mine, and are not necessarily shared by any of the
clients of Tom Alrich LLC. If you would
like to comment on what you have read here, I would love to hear from you.
Please email me at tom@tomalrich.com.
No comments:
Post a Comment