You Can’t Protect What You Can’t See.

On November 4, 2021, MedCrypt hosted a webinar with panelists Kyle Erickson, Senior Director of CRM Product Security at Medtronic, and Seth Carmody, Vice President of Regulatory Strategy at MedCrypt.

Read on to gain greater insight into SBOMs, regulatory guidances, pain points, and steps to improve transparency within the security community.

What is an SBOM and how is it used?

Today, software is made up of a number of commercial, open source, and custom components. Software Bill of Materials (SBOMs) are a list of components in that software, analogous to the ingredients list commonly found on food items.

Historically, MDMs have built software from scratch, but software nowadays increasingly relies on a complex supply chain of third party software components.

As Erickson points out, SBOMs are, “becoming necessary for us to understand what’s in our products… and if we’re able to understand what’s in our products we can do proper vulnerability management.”

“We can’t protect what we can’t see. Supply chain risks exist, and digging into components and dependencies will be necessary to prevent supply chain attacks before an adverse event occurs,” Erickson said.

Where does the market incentive for SBOMs come from?

Carmody, formerly Cybersecurity Program Manager, Medical Devices at the FDA, noted from the regulatory perspective that SBOMs are a fundamental part of risk management and are thus part of existing FDA guidance. Additionally, market incentives for software transparency come from guidance like the FDA, recent cybersecurity executive order and the NTIA SBOM initiatives.

Internal pressures within MDMs from governance and quality teams also drive the incentive for SBOMs. In the future, the software transparency gained from SBOMs will likely be a mandate from regulators, but also a requirement from customers Manufacturers are trying to get ahead of the demand for transparency by studying new and legacy products to determine what is needed to build SBOMs in a way that is mutually beneficial for their product and security teams as well as customers.

Where should device manufacturers start with SBOMs?

Erickson shared that one approach involves taking an old product still in the field and comparing it to new devices. It will be harder to generate SBOMs for an older product than something newer that uses traditional software development practices. Learning what these differences are is a good starting point.

Another approach is observing real world examples or models from other industries and adapting those models for SBOM generation for medical devices.

How is the medical device cybersecurity industry becoming more dynamic with SBOMs?

“What you don’t want is an SBOM that just creates information,” Erickson said. SBOMs should be the tool that helps drive risk management, vulnerability mitigation, or patches.

SBOM generation is more than just compliance, it drives security and enables vulnerability management. It’s a tool to help understand the weaknesses in a product design or weaknesses in the dependencies of a product.

If manufacturers are using a spreadsheet or PDF to comply with guidance, the overall benefits that could be derived from software transparency and proper vulnerability management are limited as the lack of automation hinders efficient exchange of information.

The medical device industry is not like Google or Amazon where multiple software releases are made every day. Devices that need to function continuously can’t be constantly updated.

SBOMs are the first step to figuring out to identify priorities and what needs patching or mitigating and making that information visible.

How do you create a win-win for different parts of your organization to get everyone on board with SBOMs?

Device manufacturers can make sure they are getting a proper bill of materials from components and dependencies vendors through the supply chain to help inform security design decisions. This could improve visibility when there is an issue and help point to how to fix it. Getting better at automating these processes with SBOMs can save resources for everyone.

Something that isn’t discussed as much is the total cost of design, development, and particularly, the maintenance of a device. SBOMs can drive transparency there by showing the cost of software supplier choices after a device is released.

There is also a value proposition for customers. Hospitals clinical engineering and IT security teams are asking for SBOMs to support their own security risk management programs, as well as inform procurement decisions.

Device manufacturers that have a program or plan to meet the requirements of customers in regards to transparency, while keeping operational security in mind (i.e., avoiding a “road map” to hack devices), will combine forces with customer IT security or clinical security teams to protect devices more effectively.

Carmody provided the regulatory perspective: it’s hard to assess the public health impact of vulnerabilities. That transparency helps regulators gauge the health risk of vulnerabilities impacting devices. Regulators want to trust that manufacturers can assess risk, have transparency in regard to what is in the system, and apply the right mitigations or patches if needed to effectively protect the public safety.

Knowing how to patch the right things starts with having the transparency needed to draw those conclusions.

What are the risks?

Erickson notes, “Just like with vulnerability disclosures, you want to have some kind of mitigation or patch ready. If the risk is shared, you want to make sure that’s in a forum that gives some level of protection.”

If there are adversaries with a certain intent and resources, they would be capable of finding this information whether or not it is disclosed. Protection involves making it more difficult for anyone looking to exploit a system or product, and this can be done with developing a specific strategy for software transparency and SBOMs sharing.

Finding the right level of transparency is also important to communicate intentionally with customers about the information they need.

When will we be ready to use SBOMs? Are we there yet?

While automation and reducing the amount of human decision making is the ideal state, the adoption of systems and processes for SBOMs are still in an early phase, but, as Erickson comments, “you have to start somewhere.” Finding the right people, processes, and technology to tackle this will help shift the culture around software transparency and move the industry forward to a place of protected medical devices that create a win-win scenario for manufacturers, clinicians, and patients.

The recording of this webinar is now available. Watch the full replay here.