In my post last Thursday, I
explained why one of the biggest cybersecurity risks worldwide today is the
risk posed by vulnerabilities in software components. It is very likely that
the majority of these risks aren’t being patched today because software
consumers – and very likely most suppliers – can’t easily track those
vulnerabilities. Thus, they simply don’t know they’re present. A good example
of this is the Ripple 20 vulnerabilities, which are estimated to have affected
hundreds of millions of devices worldwide – yet there was almost no way that a
supplier could learn whether the Treck IP stack component was included in a
given software package, since knowing that would require knowing all of the
components of the components of the components, etc…of their software.
But there is hope. As I’ve written
a lot lately, there is now recognition that the widespread availability and
acceptance of software bills of materials (SBoMs) will finally allow both
suppliers and consumers of software to understand what the software packages
they use are made of, then be able to learn about vulnerabilities found in the
components of the software packages. SBoMs are being used for some limited
purposes today, and there is agreement on their formats (there are three primary
SBoM formats now, with one or two more being developed. Each format can be
easily transformed to each of the others, so there is no need to standardize on
a single format for all uses).
So the good news is that there
aren’t any technical barriers to the widespread use of SBoMs. However, there
are definitely barriers, and they’re quite simple to describe:
1.
Producing and
continually updating SBoMs will require a sustained effort by all software
suppliers, of all sizes. The suppliers are reluctant to make that effort until
they are sure that their customers (both current and future) will see value in
having SBoMs.
2.
Organizations that use
software (i.e. just about every organization on the planet) aren’t sure how
they could use SBoMs if they were available.
It’s easy to see the solution
here: The software suppliers need to be convinced there’s demand for SBoMs, and
the organizations that use software need to be convinced that having SBoMs will
allow them to greatly increase the security of the software they use. That’s
the good news. The bad news is that this is a classic chicken-and-egg
situation: Suppliers won’t produce SBoMs in quantity until they know their customers
will use them, and customers are reluctant to invest the time required to learn
how to use SBoMs if they’re not sure their suppliers will in fact start
producing them regularly.
This is a rough description of the
problem facing the National Technology and Information Administration (NTIA) of
the US Department of Commerce. I described the important work that group is
doing in this
post. Specifically, Dr. Allan Friedman of the NTIA is leading a “multistakeholder
process” called the Software
Component Transparency Initiative, whose goal is to make the production and
use of SBoMs a normal process, not a rare occurrence like a sighting of
Bigfoot.
As I described in that post, this Initiative
will not issue regulations or even guidelines for production and consumption of
SBoMs. Rather their main tool is a Proof of Concept (PoC), in which a small
number of software suppliers and users within a particular industry develop and
test procedures for producing and using SBoMs, and share what they’ve learned
with all other parties involved in the NTIA initiative.
The primary use case for SBoMs so
far in the PoCs has been for an end user organization to learn about vulnerabilities
that have been identified in components of software packages used by the
organization. So far, there have been two successful PoCs in the healthcare industry
(focused on medical devices used in hospitals, like infusion pumps); a third (more
specifically, the second iteration of the second PoC, if you’re keeping score
at home) is now under way. A PoC for the automotive industry (led by the Auto-ISAC)
is just getting underway.
Why do the PoCs focus on
particular industries, rather than some other way of dividing up the problem –
e.g. having separate proofs of concept for organizations whose names begin with
the letters A, B, etc? The reason is that this allows NTIA to break through the
chicken-and-egg problem described above, by having software suppliers for a
particular industry sitting across a (virtual) table from software users from
the same industry. The suppliers will hopefully become convinced that their
customers want to see SBoMs; in other words, “If you build them, they will
come.” And the customers will see that they can use SBoMs when they’re widely
available.
I hinted in the post linked above
that a PoC would probably be coming soon for the electric power industry. Now I
don’t have to hint: A PoC is coming under the auspices of the NTIA (although
one or two other organizations may play a leadership/sponsorship role as well –
not that the PoC is in any way an expensive undertaking).
The PoC itself could start early
in 2021, but right now I believe that Dr. Friedman of NTIA is trying to identify organizations
that are interested in learning more about this (he’s certainly not asking for
commitments now, of course!). I see there to be the need and opportunity for four types of participants:
1.
Suppliers of software
used in the OT side of the power industry (including software used in BES Cyber
Systems, of course – but hardly limited to BCS software). This can include
suppliers of hardware devices that include software - relays, RTUs, etc.
2.
Power industry
organizations that use OT software. This includes electric utilities (of any
size) and independent power producers, as well as government-owned power
marketing organizations. It also includes associations of those organizations,
such as the E-ISAC, NATF, EEI, NRECA, APPA, and EPSA.[i]
3.
Service providers, who
may sit “in the middle” between suppliers and users of SBoMs. This group plays
an important role. As I described in two posts three weeks ago (found here
and here),
there are some important problems that need to be solved before SBoMs can be
widely used – and there are other problems besides these two. Rather than have
every electric utility solve these problems on its own, service providers can address
them for all of their customers at once. They will not “solve” them once and
for all, but they can at least provide a good enough workaround so that use of
SBoMs can move forward, at the same time as research continues on the ultimate
solutions.
4.
Observers. The above
three types of participants will all need to sign an NDA (to be worked out
among the participants at the beginning of the PoC). In return, they will be
the only organizations allowed to see the SBoMs produced for the PoC. However, the
results and lessons learned from the PoC will be shared with anybody who is
interested, with no restrictions other than that they must be a user of
electricity (and I assume that everyone who reads this post is in fact a user
of electricity, not living off the grid in some place like the Yukon). There will
be regular meetings of the PoC group to which all observers are invited (the
healthcare PoC conducts these meetings weekly), where issues and solutions will
be discussed. The PoC group will also draw up documents to inform the outside
world of what they’ve learned.
I want to point out that, while
the NTIA PoCs focus on particular industries, there is really nothing very
significant that’s unique to any industry, when it comes to production or use
of SBoMs, In fact, this was the conclusion of the first healthcare PoC, since when
they started working in 2018 it wasn’t clear that this would be the case.
The most important implication of
this is that the power industry PoC won’t start from ground zero, like the
first healthcare PoC did. The lessons learned in the healthcare PoCs were all
carefully documented; the power PoC can build on what they have done and go beyond
it. Moreover, the people participating in the healthcare PoC are more than
willing to coach subsequent PoCs on what they did and the mistakes they made (in
fact, they’re providing coaching sessions for the Autos PoC now. The first was
last week). In turn for receiving all of this help, the power PoC participants
will be expected to share what they learned with the other groups participating
in the NTIA initiative.
However, the primary goal of the power PoC won’t be to advance the frontiers of SboM practice in general: it will be to demonstrate a workable use case for SBoMs in the power industry, that can be implemented by the industry now. It will definitely not be a fully automated use case, so it won’t immediately scale to say hundreds of suppliers. But because the suppliers have to learn about this, too (in fact, they have much more learning to do than the users), this may be enough for the moment.
One
good thing is that it’s useful just to have some SboM information for some
software products; you don’t need complete information, and you don’t need it
for all products that you use (e.g. just knowing the names of ten components of
a software package you use regularly is better than not knowing any. The
average software product has 135 components, according to a 2020 study by
Sonatype). Just that will allow an organization to learn much more about the vulnerabilities
they face in software components than they know now (which is very little, of
course).
There’s another important reason
why you should consider joining the power PoC: You will be part of the group
defining the solution to the software transparency problem. SBoMs are coming,
without a doubt. I quoted Gartner in the first part of this post: “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..”
I suspect there will be a webinar
in December for interested parties. If you want to hear about that and any
other PoC information, please drop an email to Allan at afriedman@ntia.doc.gov. If you want to
cc me, you can do that, but you don’t have to. And if you’d like to have a
conversation about this now, let me know. I’d be glad to do that.
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] Note
I didn’t list NERC here because I’m assuming they may – mistakenly, IMHO –
convince themselves that their Rules of Procedure don’t allow them to
participate in the PoC. I am sure NTIA would love to see NERC participate
directly in the PoC if they can, but in any case, I hope they will at least be
observers.
No comments:
Post a Comment