Thursday, November 19, 2020

An opportunity – part I


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