Note from Tom 12/8/2021: I am currently reconsidering my opinions on VEX. I'm not going to withdraw any of my posts on the subject, but frankly I don't recommend that you spend much - if any - time reading this or my other posts that addressed VEX. I expect to update this notice within at most a month.
I am pleased to announce that members
of the electric power cybersecurity community are invited to participate in an
important upcoming event: A Proof of Concept for software bills of materials
(SBoMs) in the power industry. I will describe the PoC in part
II of this post. In part I, I want to make the case (better than I have before)
for why this is important.
I recently wrote
that I have lately fallen in with a bad crowd: the Software Transparency
Initiative of the National Telecommunications and Information
Administration (NTIA). The NTIA’s job is to promote usage of important new
technologies, without trying to regulate them in any way. They do this by
convening “multistakeholder processes” that gather the different stakeholders
in the technology, to figure out what are the barriers to adopting the technology
and how they can be overcome.
The Software Transparency
Initiative is focused on an important problem in cybersecurity: The average
software product contains a large number of components; one recent study by
Sonatype said that number is 135, but some software products have thousands of
components – and 90% of these are open source. In fact, believe it or not, a
different recent study by Synopsys found that 70% of the average
software product consists of open source code. This means that, rather than
speak of components as isolated “islands” of code in a sea of code written by
the supplier of the product, it is almost more accurate to speak of a
software product as consisting of a large number of components, with some “glue”
provided by the product supplier to hold the components together.
Of course, this in itself doesn’t
constitute a problem. The problem arises because, just as the code written by the
supplier itself has vulnerabilities, each of the components can have
vulnerabilities as well. Let’s say the product itself has a 1% likelihood of
having a serious vulnerability at a given time, and that each of its 135 components
has that same likelihood[i]. If you don’t consider the
components, you would say that the software product has a 1% likelihood of
having a serious vulnerability. But if each of the components also has a 1% likelihood,
this means the likelihood there is a serious vulnerability in the product is 136%
- i.e. it’s a certainty.
Fortunately, as discussed in this
post, probably only about one in 20 of those component vulnerabilities is
actually exploitable. This means the likelihood that there will be a serious
vulnerability in this product or one of its components is about 8%. This is
still eight times more than the likelihood that the product itself will have a
serious vulnerability, if you don’t take the components into account at all.
But even this increased likelihood
doesn’t itself constitute a problem, as long as you can count on your supplier to
identify and patch all of these component vulnerabilities. And as long as you’re
sure that, if there ever is a vulnerability that the supplier can’t immediately
patch for some reason, you can count on their letting you know about it and at
least providing you with some workarounds to mitigate the vulnerability.
However, the problem is that you
can’t count on your supplier to a) quickly learn about new vulnerabilities in
any one of the 135 components in their product, and b) take quick action to mitigate
it, through a patch or other means. Here are some reasons why that is the case:
1.
Sometimes (hopefully not
too often), the supplier doesn’t even know all of the components in their
software.
2.
If they do know all of
the components, they don’t receive prompt notice of a vulnerability in each
component. Remember, 90% of components are open source, so there is no company
that sends them a notice (and especially not a patch) whenever there’s a new
vulnerability in the component. It’s up to the software developer to regularly
visit the site of the community that developed the product to determine if there
are any new vulnerabilities identified, as well as any new patches available (although
sometimes they may get an automatic notice).
3.
In theory, all of
these vulnerabilities in open source and third party components should appear
in the National Vulnerability Database (NVD), meaning that the supplier should
easily be able to find at any time if a component has a vulnerability, right? Wrong.
One of the biggest problems with components is the naming problem, which I
wrote about in this
post. The name that a supplier uses for a component is almost never the CPE
name that is used in the NVD. Since that name requires knowledge of the exact
version number and the exact string of words that describes the product, you
will get a null result if you’re just one or two characters off. Say that you
know you’re looking for version 2.3.4 and you entered “vsn. 2.3.4”. But the CPE
name actually reads “v. 2.3.4”. You won’t
find anything in your search.
4.
And suppose the supplier
does find the right component name and finds there is a serious vulnerability
(CVE) for that component. Will they immediately develop a patch and send it to
you? Some suppliers might and some suppliers might not. A 2017 study by
Veracode found that “A mere 52 percent of companies reported they provide
security fixes to components when new security vulnerabilities are discovered.”
In other words, there’s just as much chance that a supplier won’t provide a fix
for a vulnerability in a component as that they will, even if they know about
the vulnerability.
5.
Now, why would a
supplier treat vulnerabilities in components differently from vulnerabilities
in their own code? After all, most software suppliers nowadays do a good job of
patching vulnerabilities in their code soon after they are identified. Could it
perhaps be that their customers can quickly learn about any vulnerability in
their own code by looking up the product in the NVD? But how is the customer
going to learn about a vulnerability in a component if they don’t know what
components are in the software they use? Until customers know about the
components of their software, and are able to quickly learn about
vulnerabilities in them, they will be left in the dark about what might be the
biggest source of cyber risk on their networks: the components of the software
they use.
This is
where SBoMs come in. An SboM tells you the components of your software, just
like the label on a candy bar tells you its ingredients (OK, there are some
differences between an SboM and an ingredients label, I’ll admit). If you can
identify the CPE names of the components, you can look up vulnerabilities that
apply to them in the NVD. This can make your organization more secure in several
ways:
1.
When purchasing
software, you can learn about vulnerabilities that apply to each component of a
software package you’re interested in, not just the vulnerabilities that apply
to the software itself. This information might help you make a better-informed
choice of one package over another. And it can definitely give you important
knowledge that will help your negotiations with the supplier. If for example
you know there are five serious vulnerabilities in components of the package,
you can require that all five be remediated before you will sign the contract.
2.
Once you own the
software, you can track vulnerabilities in components like you currently track
them in the software itself. If you learn of an important component
vulnerability and the supplier doesn’t issue a patch or a notice about that
quickly, you can contact the supplier to find out when they will patch the
vulnerability. Of course, it’s very possible the supplier will tell you that
the vulnerability isn’t exploitable in their product, because of the way the
component has been implemented (e.g. the component is a library with three
modules, but the supplier only implemented two of those modules. The vulnerability
is in the third module). That’s fine, but at least you will be able to cross
this off of your list of things to worry about. And quite frankly, the supplier
is much more likely to patch component vulnerabilities quickly if they know
their customers are tracking them and will be on the phone soon if they don’t
do something about a new serious vulnerability, than if the customers are
totally in the dark, as they are now.
3.
The supplier will also
benefit from widespread availability of SBoMs. After all, the supplier needs to
know about the components of the components they have included in their software,
since serious vulnerabilities in those second-level components might very well
be exploitable in their software. They can track vulnerabilities in the second-level
components, and – just like their customers do with them – they can put
pressure on the suppliers of their first-level components, including open
source communities, to patch those second-level component vulnerabilities.
4.
And what happens when
the next Ripple
20 comes along? This is a set of serious vulnerabilities that have been in
a particular component – the Treck IP stack – since the late 1990s. The
vulnerabilities are estimated to be found in hundreds of millions of devices
worldwide. The vulnerabilities might be found four or five component layers
down. Software suppliers worldwide have struggled even to tell their customers
whether or not their products are susceptible to the Ripple20 vulnerabilities,
since the suppliers generally have no idea of what their second-level
components are, let alone their fifth- and sixth-level components. I heard that
Jsoft, the Israeli company that discovered these vulnerabilities, resorted to
combing through LinkedIn to find references to Treck, for example in resumes of
developers, in order to find companies to warn about this. They knew of no
other way to find what products might be affected by Ripple 20. Of course, were
SBoMs widely available and multiple layers deep, this wouldn’t have been hard
to do. But right now the idea of widely-available multilevel SBoMs is pretty
much a pipe dream. Hopefully, in a few years one-level SBoMs will be at least
somewhat widely available. That alone would be a huge help.
It’s
getting late, and I’ll close this post with a quote from Gartner[ii]: “By 2024, the provision
of a detailed, regularly updated software bill of materials by software vendors
will be a non-negotiable requirement for at least half of enterprise software
buyers, up from less than 5% in 2019.” They’re coming!
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.
[i] With open source software, the chance that there will be vulnerabilities is higher. In fact, the Sonatype study found that on average 11% of the open source components in any given software product have at least one serious vulnerability. And a 2020 study of developers found that 21% of them had experienced a breach due to a vulnerability in an open source component in the past 12 months. This was down from the 31% figure in 2018.
[ii] From
their “2020 Market Guide for Software Composition Analysis”, available at https://www.synopsys.com/software-integrity/resources/analyst-reports/software-composition-analysis-market-guide.html
No comments:
Post a Comment