‘If the public knew:’ Ripple20 shows medical device software cyber weakness
A dearth of details on third-party software widely used in medical devices is making patients vulnerable to cybersecurity threats, a long-running concern now more urgent amid the pandemic.
As the COVID-19 crisis drives exponential use of telehealth and remote patient monitoring, the risks are rising. Without knowing the underlying components in devices, hospitals and other healthcare providers cannot effectively protect them from attacks, regulators and experts warn.
“Neither the manufacturer nor the user typically has any idea whether the devices they have in their facility are subject to newly discovered vulnerabilities,” according to Chris Gates, principal security architect at Houston-based medical device engineering firm Velentium.
The stakes are high. Last month, researchers discovered vulnerabilities in a popular TCP/IP library from a third-party software vendor Treck used by Baxter and B. Braun infusion pumps, potentially allowing hackers to take control of the devices remotely and alter medication dosages. Baxter downplayed the threat calling it low-risk or “controlled,” as defined by the FDA’s cybersecurity guidance, while B. Braun said it is working to patch the vulnerable source code.
The security holes, found by Israeli firm JSOF and dubbed Ripple20, are the latest example of cyber vulnerabilities in third-party software impacting the medtech industry.
“If the public knew how insecure so much of the equipment is out there, they would lose their faith in the medical industry,” Gates told MedTech Dive. “There [are] a lot of issues that need to be corrected.”
While the majority of device software, which includes modules and libraries, do not have known vulnerabilities, some products ship with vulnerable or out-of-date components that may never be updated, according to the Department of Commerce’s National Telecommunications and Information Administration.
To address the problem, NTIA in July 2018 launched a multi-stakeholder initiative to improve software component transparency across myriad industries, including medtech, by standardizing the process for sharing the data so users can better understand what exactly is running on their networks.
Allan Friedman, NTIA’s director of cybersecurity initiatives, told MedTech Dive “software is built out of smaller pieces of software” but there is very little visibility into the supply chain, which is problematic from a security perspective.
With input from the medtech industry, NTIA in November 2019 published the first set of stakeholder-drafted documents to offer initial guidance on a proposed Software Bill of Materials (SBOM), an electronically readable format meant to provide an inventory or “list of ingredients” that detail the third-party components in devices.
“The hard part, the expensive part of security research is trying to figure out what devices are affected, whatever the new vulnerability is,” Friedman contends. “For Ripple20, if everyone had an SBOM this would be a couple of key strokes to figure out the risks. Once we have that, folks can start to make decisions based on their risk and exposure.”
An industry awakening?
Although healthcare traditionally has “not been at the forefront of cybersecurity,” Friedman said the medical device community as of late has been a leader when it comes to NTIA’s SBOM initiative. Medtech has had a “real awakening” about the importance of security, Friedman observed, though he acknowledged the industry had “skepticism” initially about the viability of SBOMs.
“This idea has not always been as popular or as obvious as it is today,” said Friedman.
Friedman pointed to a 2019 healthcare proof-of-concept that partnered medtechs such as Abbott, Medtronic, Phillips, and Siemens Healthineers — with hospitals like Cedars-Sinai, Mayo Clinic, and NewYork-Presbyterian — which found that SBOMs can play a key role in managing the operational and cyber risks associated with medical devices.
Specifically, the device manufacturers and healthcare providers successfully demonstrated the feasibility of SBOMs by generating, sharing, and using data to improve security practices in pre-defined use cases.
“That first exercise was successful but it also highlighted some of the obstacles for doing this at scale,” Friedman said. Among the findings of the resulting proof-of-concept report was that standard SBOM formats should be industry-agnostic.
Ultimately, Friedman said NTIA’s vision for SBOM is to help create an ecosystem-wide solution not specific to healthcare. “In reality, we all use the same underlying software,” he noted. As part of the NTIA-led initiative, a stakeholder working group in 2020 is continuing to refine the SBOM specification.
And a second healthcare proof-of-concept involving additional medtechs including Thermo Fisher and health systems like Cleveland Clinic and Mass General is planned for this year. The emphasis will be on third-party services to support the device manufacturers and hospitals, as well as the need to conduct the exercise “at scale in an automated fashion,” according to Friedman.
Industry has not always been on board with regulators’ vision for a SBOM.
FDA’s 2018 Medical Device Safety Action Plan said medtechs would be required on the front end to develop an SBOM “that must be provided to FDA as part of a premarket submission and made available to medical device customers and users, so that they can better manage their networked assets and be aware of which devices in their inventory or use may be subject to vulnerabilities.”
Friedman said that “what the FDA also did was they said they won’t define the standard themselves but rather wanted the medical device community to participate in this broad multi-sector initiative that NTIA has convened.”
AdvaMed took aim at the FDA proposal in comments last year. The lobbyist group argued the agency is getting ahead of its statutory authority, noting FDA’s own admission it would seek new authority from Congress to implement the idea.
“Under the statutory ‘substantial equivalence’ standard for Class II medical devices we do not believe FDA can impose these requirements on new devices that have demonstrated substantial equivalence to a predicate device,” wrote Zach Rothstein, AdvaMed vice president of technology and regulatory affairs, in the group’s comment.
GE Healthcare commented at the time to echo AdvaMed’s concern hardware requirements may be too onerous.
AdvaMed declined to detail its latest thinking to MedTech Dive.
Nonetheless, Velentium’s Gates, an SBOM working group member, believes the FDA’s support will go a long way to providing software transparency for new medical devices in the future, “making it much easier to know exactly which devices are affected by vulnerabilities like Ripple20 as well as what actions need to be taken in response.”