What's in a connected medical device? Cybersecurity regulators want to know

Friday, January 3, 2020

Source: MedTech Dive

FDA is mulling a requirement that device makers draw up a list of internal hardware and software components, key information which could help providers more quickly respond to cyberattacks.

With connected medical devices becoming ubiquitous, hospitals face risk of cyberattacks that could disrupt services and cause widespread patient harm. Device makers, though, say such a list raises big questions — from what the controls are around sharing and maintenance of these lists, to how detailed they should be and the impact on time to market.

Imaging devices, insulin pumps and other IoT medical devices are especially vulnerable to attack. Products connected to legacy systems communicate telemetry and test results back to centralized servers, and when malware or ransomware hit, results can be frozen in time, leaving doctors without data on which to base clinical decisions. 

In a recent analysis, McAfee Labs' Advanced Threat Research team found cybercriminals could mimic and alter patient vital signs in real time on a medical network using a patient monitor and central monitoring system, causing patients to get the wrong medication or unnecessary tests.

The concept of a "cybersecurity bill of materials" in product labeling, first floated in the agency's Medical Device Safety Action Plan, would give providers a first line of defense in identifying assets, threats and liabilities and help manufacturers of connected medical devices head off software fixes and recalls due to compromised or vulnerable components.

FDA says it is considering a requirement that companies "develop a 'Software Bill of Materials' 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. In addition, availability of a "Software Bill of Materials" will enable streamlining of timely postmarket mitigations."

AdvaMed, in comments on the safety plan, warned that storing the documents in a publicly available central database could allow cybercriminals to learn which software is operating within a device, exposing patients to potential harm. The agency needs protections around the issuance and maintenance of CBOMs to ensure only authorized users are able to access it, the group said. 

The proposed guidance defines CBOM as "a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities."

When is enough, enough?

One of the biggest challenges for companies is deciding how far down in the supply chain they need to go to understand if the bill of materials is accurate, says Bryan McGowan, director of Burwood Group's security practice. "It's kind of the Russian doll aspect," he tells MedTech Dive. "Your first vendor that you ask for a bill of materials is going to have to turn around and ask for a bill of materials from their downstream entities that make up their solution and etc., etc., etc. It can be a nested search to find the real root components of your solution."

There's also the logistical challenge of how tracking the bill of materials will impact production costs and speed of market delivery. Companies can track it as they build the product, ensuring all components and subcomponents are entered into the CBOM as they are introduced and that due diligence has been done. Or they can wait until the product is mostly complete and then do a scan to identify third-party components. 

"The first option, where we're tracking as we add pieces, can be complex because it's going to slow down the development process," he says. Waiting until the end to create a manifest of components carries risks as well. If a component is found not to comply, companies may have to "back up the train" and replace it with something different or modify the source code to update outdated components.

Empowering buyers

In addition to providing validation of a product's disparate parts, the proposed guidance calls for labeling to communicate relevant security information to end-users, including features that protect critical functionality if the device is compromised, a description of backup and restore features and a list of network ports and interfaces expected to send or receive data.

The bill of materials would provide a first set of rules of sorts for what is contained in device, and the labeling then communicates that to whoever is using it, McGowan notes, helping buyers assess a product's safety and security.

Gary Davis, McAfee's chief consumer security evangelist likens it to an Energy Star rating. All things being equal, hospitals and other customers will likely buy the product that has the better cybersecurity score.

"The main advantage is they're going to have a device that is less likely to be compromised or exploited," he tells MedTech Dive.

McAfee has been advocating for industries across the spectrum — not just in medical — to include bills of materials in basic security controls. So far, there's been little action. "We find that very frustrating in our space," Davis says, noting power plants and transportation also pose devastating outcomes if critical infrastructure is breached.

Getting there

When it comes to incorporating a bill of materials into the medical device development process, working in an agile environment helps, McGowan says. There are tools that plug into software development pipelines and allow teams to scan for third-party components and validate that they're up to date. If an older version or one with known vulnerabilities pops up, it can be addressed then and there. There are also tools that let software developers validate as they are introducing new components. 

Hardware can be even more complex. "You start to get even more into that nested solution problem," McGowan notes, with hardware that has software on it and likely third-party components in the software. Managing this area will require more manual due diligence.

The proposed guidance also requires that the CBOM be electronically generated and machine readable.

Davis suggests manufacturers use the National Institute of Standards and Technology cybersecurity framework, noting it's been around for a while and is fairly straightforward. The FDA also recommends using the NIST framework.

Supply chain diligence is also key. According to a recent Sonatype report, the average application has about 106 components, of which 80-90% come from a third-party source code. As many as one in 16 of those components will have a software defect.

"This is a broader issue than just the medical industry, and I hope the FDA is able to implement this and make it a requirement, because I think that will kind of kick start other industries to follow with the pattern," Davis said.

View All News »