Recent years have shown an alarming increase in cyber attacks geared towards the healthcare sector. Just last year alone, the FBI reported that 148 ransomware attacks successfully penetrated healthcare organizations– more than any other industry.
While there are many steps that can be taken, from securing the IT infrastructure to implementing better credential security practices, few are as important as securing the growing wave of connected devices accompanying medical professionals. Huge amounts of connected devices, operating with varying levels of network authorizations, and in a realm where cyber threats rapidly evolve is a lot to secure– and Suzanne Schwartz of the FDA and her team know it (listen to Dr. Schwartz’s interview on Left To Our Own Devices).
Medical Device Manufacturers (MDM) are heeding the call of the Biden administration’s push for companies to bolster cybersecurity practices across industries. In addition to the Decmeber 2022’s Omnibus bills impact on the FDA, another way to achieve this is with the International Medical Device Regulators Forum’s (IMDRF) Principles and Practices for Software Bill of Materials (SBOM). While still a draft, the IMDRF WG/N73 Draft: 2022: Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity, gives a fresh look for MDMs on how to create and manage living SBOMs.
For implementation, It gives both MDMs and health care facilities (HCF) suggestions on practices. Yet, it remains elusive when pinning down specific SBOM maintenance steps, encouraging companies to review internal practices and choose what works best for them. The concerns raised by the document was not about the documentation itself, but about ensuring the most relevant document for each device version was easily accessible.
We’ve put together a rundown of five key takeaways from the recent draft.
#1: Why are SBOMs necessary?
As industry insiders, we understand that much of the software that operates medical devices is from open source or third party vendors. While this reduces costs and boosts time to market, it leaves potential cybersecurity vulnerabilities out in the open.
The IMDRF views SBOMs as a critical component in not only understanding potential weaknesses in each device but also the threats they introduce to a facilities network. This is so critical that the IMDRF believes all SBOMs should consist of NTIA elements, including having MDMs share known vulnerabilities.
One part that was meant as a critical element of SBOMs is “Characterizing the relationship that an upstream component X is included in software Y.” It’s not enough for MDMs to make a long list of vulnerabilities. They must consider and report how it may be impacted in various environments today and into the future.
Ultimately, SBOMs are necessary since they create a single shared resource that clearly defines software component ownership should an attack or vulnerability be discovered.
#2: Why all medical devices need an SBOM according to IMDRF
Generating an SBOM should be as simple as asking a developer for all their sources, writing them in a list, and publishing.
In reality, creating an SBOM is never that simple.
Increasingly software-defined devices bring a heavier reliance on code. For various reasons, companies can choose to hire out all or portions of the devices code development. In addition, they likely rely on third-party software, open source libraries, and multi-source packets of software that make it impossible to track down the original author’s security knowledge. In short, developing an SBOM for existing devices potentially raises more questions than answers.
Since much of the foundational pieces for a device rely on outside sources, when exactly should a company begin creating the SBOM?
The simple answer is – start now.
Whether a device is still going through its Software Development Life Cycle (SDLC) or is already out in the field, companies need to start compiling whatever they have. The draft states “Standards and tools continue to evolve and mature; MDMs should not wait for these to be ‘finalized’; rather they should generate initial SBOM documents applying basic/foundational SBOM concepts.”
#3- SBOM cybersecurity risk reduction use cases
One of the most interesting parts of this draft is the dual perspective that is maintained throughout. Being aware of the continuously evolving landscape, the IMDRF demands that both manufacturer and health care provider (HCP) perspectives are taken into consideration.
This is seen when discussing risk management. Manufacturers are responsible for conducting:
-
- Hazard analysis- reviewing existing SBOMs to identify vulnerabilities within used software components.
- Risk evaluation- Identifying vulnerabilities, potential exploitability, and impact. At times this is unavoidable and it is crucial that HCPs are made aware.
- Risk Control- Continuously update existing SBOMs with newly discovered vulnerabilities.
- Assess and monitor- Update SBOMs with new software following updates.
- Lifecycle risk management- This describes the handover of information, which should be included in the product security documentation to HCPs at purchase, throughout the TPLC, and up until the product’s end of service (EOS).
Furthermore, this helps MDMs improve the timeliness and accuracy of vulnerability identification and remediation playbooks.
On the other side is the HCP’s responsibilities. This focuses on obtaining an SBOM as part of the pre-procurement process, allowing them to understand the risks and mitigations that must be applied to their networks. “This will enable the HCP to better understand the benefits and risks of a device as it progresses through its TPLC, and how to apply risk control measures and mitigation strategies more effectively across the device life cycle.“
#4 SBOM minimum requirements
Minimum requirements for modern devices still promote using the SBOM as an opportunity for total transparency between MDMs and HCPs. In contract, it gives true minimal requirements for legacy devices (see section #5), keeping it more as an internal starting point towards future devices.
For all non-legacy devices, existing NTIA requirements still apply here. Where this IMDRF draft expands is on Change Management, stating “…third-party component change management is a new area for most manufacturers.” To remain compliant, SBOMs must be reviewed and kept up to date with each product or version change. This can include the discovery of a vulnerability on a third-party component, patches, new functionality, and others. It also means teams will need to maintain this document regardless of planned events, such as end of life decisions or new version releases.
Acknowledging the current fluidity of SBOM standards, the IMDRF draft does not explicitly lay out the procedure for keeping documentation up to date, only that it is required. This leaves companies or individual teams to lay out a procedure each time a device has any kind of software update no matter the size.
#5 Future proofing and post production security for legacy devices
Legacy devices pose a unique challenge to SBOM development as components may be operational but no longer receive support. This may be a result of its age, software developers may no longer be in business, or finding original creation tools may send engineers on a wild goose chase.
The draft acknowledges this and puts the responsibility back on MDMs to protect their devices as best they can. The draft states “…it is still desirable to build an SBOM which may be of reduced scope and depth, that captures major software components such as the Operating System, COTS software, and OSS as possible.”
Not only does this help with identifying potential interoperability issues throughout the total product life cycle (TPLC), it also creates a foundation for future device versions.
How to implement the IMDRF SBOM Draft
Developing best cybersecurity practices and SBOM generation during pre-production is becoming standard which may be why WG/N73 goes on to address devices that are already operating in the field.
This draft discusses connected devices which may or may not be compliant with the latest medical device security standards and regulations, making them a prime target for hackers to penetrate an HCP’s network. To secure broader networks, each device requires an SBOM that gives basic information as well as security insight. Once an SBOM is in place and devices are understood, teams can shift to the full product life cycle including maintenance and updates.
Keeping this process orderly can be a challenge. To ensure nothing falls through the cracks, SBOM creation and SBOM management should be standardized and automated early on in the development process. This will benefit developers by automatically populating an SBOM as new software is introduced. Only then can HCPs be sure that their SBOMs are up to date and threats have been mitigated.
Want to learn how Cybellum’s Product Security Platform helps device security pros keep ensure devices are secure and compliant? Book a demo!
