Sunday, November 22, 2020

An opportunity to be part of the solution


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