Two days ago, Politico published a really chilling article about how BlackBerry - which is now a software company, after earlier being a pioneer (in fact, the pioneer, in my opinion) in internet-connected personal devices - gravely mishandled reports of serious flaws in its QNX operating system. QNX is found in all sorts of devices like cars (200 million of them, according to the article) and the International Space Station. This was called to my attention by Eric Byres of aDolus, who wrote an excellent blog post that elaborated on Politico’s point about how having SBOMs could have made this a much easier problem to deal with, whether or not BlackBerry had cooperated.
But the fact is that they didn’t
cooperate. Microsoft first discovered this vulnerability in April in a whole
host of device operating systems, not just QNX. The article continues, “In May,
many of those companies worked with the Department of Homeland Security's
Cybersecurity and Infrastructure Security Agency to publicly reveal the flaws
and urge users to patch their devices. BlackBerry wasn’t among them.”
At first, BlackBerry denied that
QNX even had the problem, even though CISA showed them it did (in some versions).
Finally, they admitted the problem but said they weren’t going to publicly
announce the vulnerability. Rather, they were going to work with their customers
privately to fix the problem.
Of course, on the surface, BlackBerry’s
desire to limit disclosure to their customers was reasonable. Software
companies do that all the time, especially if they haven’t yet distributed a
patch for a vulnerability. After all, if they announce an important
vulnerability to the whole world before their customers have been able to patch
it, they’re inviting ruin on those customers.
But it turns out that BlackBerry
doesn’t have any idea who are all the customers of QNX. BlackBerry sells it to
large organizations that incorporate it into products that they sell to other organizations,
who embed those products into their own products, etc. Once you get down below at
least the second tier of this, users of devices that run QNX almost certainly
have no idea that they have it – since it doesn’t appear on any invoice they’ve
ever received.
Just as in the case of the Ripple
20 vulnerabilities, the right course of action in this case was to first prepare
the patch, then let the whole world know about it. That way, in principle
all users would be able to figure out if they have a product that contains QNX,
and if they do, get a patch from whoever
sold them that product. The good news is BlackBerry finally took this course of
action. The bad news is they took it two days ago, after Microsoft had revealed
the vulnerability in April.
Of course, Microsoft deliberately
didn’t name names in their April announcement, in order to give the O/S vendors
a chance to patch their systems and then announce the vulnerability and the
patch at the same time. It seems that BlackBerry missed that memo.
You may have noticed that I
italicized “in principle” two paragraphs above. When you hear that X is true in
principle, what do you normally think? I normally think, “There isn’t a
snowball’s chance in hell that X is actually true in real life.” Indeed that’s
the case here. In principle, every company could take an inventory of all the
devices they operate, check the current software bill of materials (SBOM) for each
device type, and instantly know which ones are running QNX.
And even if the device they own
doesn’t run QNX, the O/S might be running inside a component within that device
(take your car. Even if it’s one of the 200 million cars running QNX, in most
cases QNX is probably running inside some device that’s a component of another
device, etc). But in principle that’s not a problem either, since you’ll
not only have an SBOM for your car, but you’ll have an SBOM for the
entertainment system, the transmission system, the passive safety system, etc. So
if one of those systems is running QNX, you’ll learn that.
Now, I won’t say that principles
are worthless. But I will say that all these “in principles” aren’t going to
get you very far, because without a doubt you don’t now have SBOMs for all of
these devices – in fact, it’s very unlikely you have a single SBOM for anything
in your car, let alone the car itself. Or just about any other software or
device that you operate.
But this is changing, of course. Federal
agencies are going to be required to get SBOMs from their software (and device)
suppliers as of around August 12, 2021 – according to an OMB memo
that came out last week, based of course on the May 12 Executive
Order on software security. And it’s highly unlikely that this will end
with the Feds – it will spread to the private sector, even though it’s not
mandatory for them (and besides, the federal government buys lots of cars!).
If you’d like to learn more about
SBOMs, I believe I’ve mentioned them once or twice in previous posts (he says while
smirking). You can find some of them by searching on SBOM in the search bar
that you see when you go to the main page of my blog, https://tomalrichblog.blogspot.com/.
And you might want to join the Energy SBOM Proof of Concept meetings that I
help coordinate. We’ll meet next Wednesday from noon to 1 ET. To get the URL,
drop an email to SBOMenergyPOC@inl.gov.
I do wish to point out that we have strict criteria for attending these meetings. You must be a user of electric
energy. If you’re an off-the-grid kind of guy and you’re reading this in a
dark cabin in the mountains of East Nowhere, you probably won’t find the
meeting appropriate. In fact, I don’t think you’ll be able to attend it anyway
(plus I don’t know how you’re reading this post in the first place).
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. Nor
are they shared by the National Technology and Information Administration’s
Software Component Transparency Initiative, for which I volunteer as co-leader
of the Energy SBOM Proof of Concept. 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