Friday, June 24, 2022

No good deed goes unpunished


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