xIoT Tom Pace’s Second-Biggest Problem (Missing CPEs) (Part 2/3)

A recent post described a presentation I saw last Friday by Tom Pace of NetRise, describing what seems to be a huge security problem. To summarize it:

1. Do you think products with a lot of open vulnerabilities - as indicated by CVE’s listed for the product in the National Vulnerability Database (NVD) - are dangerous and should be avoided? If so, you’re right.
2. By the same token, do you think a product with no open vulnerabilities – and which has never even reported a vulnerability – is one you ought to buy? After all, what could be safer?
3. It turns out that you’re probably better off with a product with lots of open vulnerabilities than with a product that’s never reported a vulnerability. Seriously.
4. Why? As Tom pointed out, nobody can report a vulnerability (CVE) for a software product or intelligent device, unless the product has a CPE name. So, if the product doesn’t have a CPE name, no vulnerability has ever been reported for it.
5. There are two reasons why a vulnerability might never have been reported for a product: A) The coders who created the product – as well as the third party coders who wrote each of the 135 components (on average) included in the product – never make mistakes; and B) The supplier of the product has never even bothered to look for vulnerabilities in it, perhaps because they believe A) is true. Of course, if this is their reasoning, it’s hard to argue with it: If you’re perfect, you don’t need to worry that you’ll ever make a mistake – after all, you wouldn’t be perfect if you made mistakes! Pretty compelling logic, no?  
6. Tom came to realize that probably the majority of software products and intelligent devices sold in the US don’t have CPE names, meaning they don’t have any CVEs reported against them. So if your organization is comparing five different vendors in advance of procuring a particular type of software, and you decide to compare the vendors based in part on how many open vulnerabilities their product has, what will you do if you find that four of those vendors have some moderate number of open vulnerabilities, but the fifth doesn’t have any at all – in fact, they don’t even have a CPE number? Will you stop the evaluation and declare the fifth vendor the winner? After all, they’re not only good…They’re perfect…
7. It turns out that Tom Pace doesn’t believe there’s such a thing as perfect software developers, so he decided to test this idea. He identified the supplier of a widely used line of devices found in many ICS environments and started looking for their devices in the NVD. He didn’t check on them all, but none of the ones he checked on had CPE names – and therefore they didn’t have any reported vulnerabilities. In fact, the supplier’s web site doesn’t mention anything about vulnerabilities or patches – or even security in general. It seems the subject never came up for them…
8. So either this supplier is so perfect that they don’t even have to think about security, or they made the decision early on not even to look for vulnerabilities in their products, since that’s probably the best way to ensure that nobody will ever learn of vulnerabilities. They won’t have to report vulnerabilities to the NVD, post notices on their website, etc. Sounds good, right?
9. Tom decided to test just one of this supplier’s products, by first creating an SBOM for it and then identifying all of the open vulnerabilities that apply to those components; if he found anyway, that would constitute proof that the supplier isn’t perfect.
10. I regret to inform you that this supplier isn’t perfect, after all. How many vulnerabilities did Tom identify? 5? 10? He actually found…drumroll, please…1,237 vulnerabilities. And he could have found more if he’d had more time. Moreover, that was 1,237 vulnerabilities in just one of about 50 products sold by this supplier – and probably none of those other products have CPE names, either.

Of course, this strategy is pure genius: Since the   supplier never reports any vulnerabilities, they don’t have to worry about patching log4j, Ripple20, OpenSSL, or any other serious bugs that keep people up at night and ruin holidays. After all, this supplier is perfect.

But for those of us who live in the real world and realize there’s no perfection (especially in software), we need to take other steps to protect ourselves. Here are some suggestions:

1. When you’re sending out an RFP for software, first check the website of each supplier you’re considering inviting to the RFP: What do they say about security and vulnerabilities? More importantly, do they say anything at all about those topics? If they don’t, drop them off your list.
2. Ask the salesperson for each supplier you’re considering to give you the CPE name of their product. If they can’t give you anything (meaning there is none for the product), drop that supplier off your list.
3. If the product has a CPE name, but the NVD doesn’t seem to list any vulnerabilities for any version of the product, ask the salesperson to tell you if they’ve ever reported any vulnerability for it (and if so, verify the CPE name. It’s possible they entered the CPE name wrong and reported vulnerabilities against that name. The NVD doesn’t validate CPE names, as far as I know).
4. But, if they tell you, “We’re so dang good that we’ve never have a vulnerability!”, thank them for their time and drop them off your list. What they’re really saying is, “We’ve gone to great lengths to make sure we don’t know about any vulnerabilities in our products, so we can tell you truthfully that we know of no vulnerabilities. You can be sure that when a big vulnerability appears in one of our products, we’ll be the last to know about it! Are you ready to sign the contract?”

Again, thank them for their time and remove them from your list. By the time you’re done with this, I hope you’ll still have at least one supplier on your list. But even if you don’t, you’re much better off staying away from any supplier that’s so convinced of their perfection that they don’t want to take the chance that they’ll be proved wrong, by…you know, trying to find out if they actually might have some vulnerabilities.

At the end of my previous post, I noted that this problem was only the second most serious problem Tom has identified, having to do with CPE names. Coming soon to a blog near you: Tom Pace’s most serious problem.

This blog is part of a 3-part series, View Part 1 or Part 3 here.

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.