Security of Medical Devices – A Changing Regulatory Landscape

Over the past two decades, medical devices have been increasingly likely to be connected to the outside world using Wi-Fi, wired Ethernet, Cellular, and other methodologies. With this increasing connectivity, connected medical devices become more and more susceptible to the same kinds of attacks that other connected devices face, leaving patient and provider personal data, hospital networks, and other sensitive information vulnerable. For many years, the FDA in the US, the NMDA in China, and other medical device regulators worldwide have required manufacturers of connected medical devices to consider security as part of their overall design and processes, but there has been some extensions of the state of the art that these agencies are expecting in new submissions that were not as codified in the past.

Looking at the United States, the overriding guidance hasn’t changed; as part of the overall 510k regulatory submission, a device manufacturer is expected to conform to security guidance from the FDA:

1. The pre-market considerations (“Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”; this document is currently in DRAFT state, but is the best guidance the FDA supplies) require manufacturers to consider a security vulnerability and management approach as part of the overall risk assessment. They also suggest looking towards standards such as NIST 800-53 (“Security and Privacy Controls for Federal Information Systems and Organizations”) to address potential security vulnerabilities that might be in the device.
2. The post-market considerations (“Postmarket Management of Cybersecurity in Medical Devices”) require manufacturers to consider cybersecurity vulnerabilities and that might come up after their product is released. It mentions concepts such as the National Vulnerability Database (NVD) and Common Vulnerabilities and Exploits (CVEs), and encourages remediation of vulnerabilities found after release.

There is significant other guidance, but adherence to these are required to achieve approval of a device by the FDA, and other countries have similar requirements. These documents are useful, and they specify what must be achieved in the realm of cybersecurity but are not as clear on how those achievements are to be made. Since these were published, there have been several advancements of the state of the art, and the FDA is taking notice. A couple of those advancements are the adoption of new cybersecurity standards and expectations of more methodical management of CVEs

In 2017, Underwriters Laboratories (UL) published the UL 2900-1 standard (“Standard for Software Cybersecurity for Network Connectable Products”), which was later adopted by ANSI (American National Standards Institute) and the Standards Council of Canada. This release was closely followed by the release of UL 2900-2-1 (“Particular Requirements for Network Connectable Components of Healthcare Systems”). These standards have taken a leading position on how medical device manufactures need to think about cybersecurity in their devices and has been recognized by the FDA; essentially showing conformance to this standard will make it likely that the device has fulfilled the FDA’s expectations for the premarket submission for management of cybersecurity.

UL 2900-1 requires a risk-management approach for the identification of security risks, with a special emphasis on several areas including:

• Access Control, User Authentication and User Authorization – methodologies that make sure that only authorized users have access to the device, and that they only can access those device functions that are needed by the user (for example, a patient might have access to certain functions, a care provider might have access to others, etc.). This includes application of the Concept of Least Privilege, which basically states that a user should only have access to the functions and data they require for their role, which is a foundational element of security.
• Protecting remote communication, using standard encryption, key and other protocols based on the risk analysis (for example, status information that does not include personally identifiable information may not need to be encrypted, but needs to be considered as part of the risk analysis).
• Sensitive data shall be documented and protected at rest (i.e., while stored on the device) as well as in transit.

UL 2900-1 requires other process and implementation steps, but the key here is that device manufacturers have been given an outline on how to implement the kinds of security that the regulators believe to be necessary, and it is best to follow it.

Alongside this kind of cybersecurity emphasis, there has been a large uptake in the use of open-source software (OSS) in medical devices, including Linux. The benefits of doing so are many; the use of a largely deployed, high quality capabilities, with support for any kind of communication protocols and I/O, and security features that have been hardened over many years. The fact that there are a large number of known security issues with open-source should be considered a feature, not a bug; the ubiquity of OSS means that it has the eyes of hundreds or thousands of domain experts trying to improve it every day, which makes it both difficult to exploit and when serious exploits are found, they are quickly resolved and patched by the community. At this point, most new exploits in the major OSS packages like Linux or OpenSSL are actually found by researchers rather than by the “bad guys”, but once an exploit is known, it can be used by the bad guys to access personally identifiable information leading to possible HIPAA and other violations.

In the past, the regulators would accept a vague plan to monitor and address vulnerabilities as they were found in a connected medical device, but now they want to know the particulars of these plans; how the issues will be found, assessed, and how and when will the device be updated if needed. This requires a great deal of knowledge to be able to monitor the incoming stream of CVEs (somewhere around 2000 new vulnerabilities are discovered every month, in February 2022 there were 1953 published vulnerabilities just in those 28 days), determine which might impact your device, determine how severe the impact might be, and address the ones that bring substantial risk. Of course, the great majority of these are edge cases that have no impact on your device, but you don’t know until you take a look.

Siemens Embedded can help customers get through these and other issues around the use of OSS on connected medical devices. Our expertise, professional services and post-release support, including specialized support for CVE management can make the job of the device manufacturer easier and can help them through regulatory approval and to get their devices on the market.

Medical device security: achieving regulatory approval white paper