When the WannaCry malware outbreak hit in May 2017, some of the first reports came out of the United Kingdom, where hospitals were impacted and some medical devices were implicated. Analysis of the malware quickly focused on a vulnerability in an early version of a Windows file sharing service that had been recently patched by Microsoft. As hospitals around the world reacted, the first question for many was “which of my systems has this vulnerability in it?”
With only two months passing since the official patch, many traditional IT systems had been patched. But many others, such as medical devices and building control systems, had not been.
This event highlighted the challenges of managing a set of “black box” systems, where the software content in them is relatively unknown. While one might infer the basic operating system during startup, most modern software systems incorporate libraries, frameworks and other third-party and open-source software that may have their own vulnerabilities identified.
Responding to a malware outbreak is just one (though perhaps the most extreme) example of when an end user wants to know what software is contained in a medical device. It starts at the time of purchase, when knowing the software content of a device can help in assessment of the security risk it may bring. Organizations also do periodic assessments of security risk so they can focus resources on areas requiring attention. Information on the software within, and configuration of all the systems on a network are needed to make such periodic assessment.
What Is a Software Bill of Materials (SBoM)?
The term “bill of materials” has long been associated with a list of hardware elements that make up a manufactured product, commonly defined as “a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product.”
As a result, a list of software components contained within a product is called a “software bill-of-materials” (SBoM, pronounced “ess-bahm”). There has been some confusion whether this would list the proprietary software built by the device manufacturer, or only the third-party software contained within. Some have worried that including the custom code would expose intellectual property (IP). However, an SBoM would only list a version number and perhaps release date, which should not be a considered IP.
The physical form an SBoM takes is also under discussion. It could be part of the device documentation, in the form of a PDF file, or a spreadsheet. A structured dataset could be defined that would allow electronic transfer and import which would improve the searchability over a broad set of SBoMs.
What Are the Challenges of a SBoM?
First, there is the presence of SBoMs within SBoMs. Third-party software chosen by a manufacturer may contain software from someone other than that software supplier. Open-source software may incorporate other open-source elements. The nesting behavior of such software complicates the discovery of all contained elements (it may be difficult to obtain what is in the dependent software), the communication of that contents, and the maintenance of that data. For example, two different packages in a product may utilize different versions of yet another package. Should that hierarchy be communicated, or just the multiple versions of a common package being present?
Device configuration also matters. Software such as Windows or Linux operating systems are “Swiss Army knives” with all sorts of capabilities present because of their wide application across many domains. Many of those services are not needed in a medical device and may be disabled or completely removed. So, an SBoM that only contains a list of the larger software entities may overstate the risk a device presents if many services and features are not exploitable due to configuration. For example, the WannaCry malware exploited a Windows service that might not be enabled in most devices. Clearly expressing software configuration requires a nomenclature that specifies exclusions.
Additionally, patching of devices is not an instantaneous function. Within any hospital of moderate complexity will be devices at different patch levels while the patches are being distributed. This is not an issue if the SBoM is used for purchasing or overall risk assessment, but its use during an emergent malware event will require the ability to map versions to specific device instances. Indeed, if patching takes a long time and patches come out too frequently, more than two versions might be in the inventory at the same time.
Lastly, the production of an SBoM as a separate document separates it from the distribution process for the software itself. This creates the potential for the inventory database and the devices in the inventory to be out of sync. Ideally, in the future, a protocol will exist that will allow a device to tell you it’s software configuration through its network interface in response to a standard query. This would allow inventory management systems to maintain a precise representation of what is actually on the network.
Of course, the downside to that would be that such messages would also allow an attacker to quickly identify devices on the network with unpatched vulnerabilities that a piece of malware has been designed to exploit. Security of this information must also be considered in the design of protocols to support it.
What Is Next?
While a perfect solution to all the challenges is daunting, there are efforts to begin the process of building and communicating SBoM information. The National Telecommunications and Information Administration (NTIA) has convened a working group on “software transparency” that is working on initial definitions for a set of use cases. Several subgroups have been formed, and a healthcare “proof of concept” is being planned. Members of multiple industries, including automotive and industrial controls, are participating, as this issue is not limited to hospitals and medical devices. You can get involved on the NTIA website.
Much work remains to make SBoMs a useful and effective part of the manufacturer to end-user communications. Seeing industry/government/academic partnerships—as is found in AAMI and at NTIA—are important vehicles to the creation of solutions that can be leveraged across healthcare and across other industries.
Ken Hoyme is director of product security at Boston Scientific in Maple Grove, MN, and a member of the BI&T Editorial Board.