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.
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