Safety and Security for Medical Devices with New U.S. House of Representatives Legislation
Inspired by an article from Jim Dempsey, lecturer at the UC Berkeley Law School and a senior policy advisor at the Stanford Cyber Policy Center, I decided to write about the recent legislation approved by the U.S. House of Representatives to address cybersecurity for medical devices and how it relates to open source software security, secure code standards, and static analysis.
The bill H.R. 7667, sponsored by Rep. Anna Eshoo, D-California amends the Federal Food, Drug, and Cosmetic Act, revising and extending the user-fee programs for prescription drugs, medical devices, generic drugs, and biosimilar biological products.
While this bill covers many items, I want to focus on one important piece of this legislation that is specific to ensuring the cybersecurity of medical devices. This section of the bill indicates that manufacturers of medical devices will have to meet the following three minimum requirements:
- The manufacturer shall have a plan to monitor, identify, and address cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and procedures.
- The manufacturer shall design, develop, and maintain processes and procedures to ensure the device and related systems are secure. The manufacturer shall make available updates and patches to the medical device and related systems throughout the lifecycle to address known unacceptable and critical vulnerabilities.
- The manufacturer shall provide in the labeling of the medical device a software bill of material (SBoM), including commercial, open-source, and off-the-shelf software components.
The Real Impact of Attacks on Medical Devices
It’s undisputed that medical devices provide critical functionality for medical care. Safety and security must be a top priority not only for patients and doctors but for manufacturers as well. There are documented cases of cyberattacks on medical devices, for example, pacemakers, drug infusion pumps, and imaging equipment. The risks may be understated, as serious health issues and lives are at risk.
Additionally, there have been lawsuits alleging deaths during ransomware attacks in hospitals: one in Alabama, United Stateswhere offline medical devices could have caused the death of a newborn, and another in Cologne, Germany, involving a negligent homicide investigation of a case in which an ailing woman was turned away from a hospital under a ransomware attack, whom later died on the way to another hospital.
Finally, it has been more than five years since the famous WannaCry ransomware attack hit hundreds of thousands of Windows devices around the world and affected medical devices in hospitals in the U.S. and U.K.
Medical Device Security Best Practices
This recent legislation is a positive step as software professionals in regulated industries, including, of course, the healthcare industry, are used to compliance and regulations. The bill is currently in the U.S. Senate, and if it becomes law, this legislation will provide guidance on practices that are not completely new to software and hardware manufacturers; compliance will be required for everyone, including laggards.
Manufacturers of medical devices have to address the safety and security of the embedded systems that are part of medical devices. From every line of code on every component of a medical device to functional and security testing, it’s essential to address quality, safety, and security with the necessary tools and expertise.
As a first step, coding standards guide software developers while writing code, and by following various standards, they can address bugs and security vulnerabilities while improving the quality of the code.
Global organizations have focused on safety and security standards across all programming languages, especially for C and C++, which are predominant in key components of medical device embedded systems. Coding standards have been created and improved over time, acting as a set of rules, techniques, and best practices to help increase the level of security, reliability, and maintainability of the code.
While there are no coding standards specific to the medical space, it’s highly recommended to follow the guidance of common coding standards such as MISRA and CERT, which can go a long way in terms of producing better quality and more secure software in medical devices.
Key Medical Device Functionality and Regulatory Standards
Recommended standards increase the chances of producing safer and more secured medical devices. Here is a list of the key medical device functionality and regulatory standards:
- IEC 62304 is a functional safety standard used for medical devices that covers software lifecycle processes.
- ISO 14971 is a risk management regulatory standard for medical devices.
- ISO 13485 is a regulatory standard that specifies the quality management requirements for medical devices.
- IEC 61508 is an umbrella functional safety standard that provides a framework for safety lifecycle activities, titled “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems” (E/E/PE, or E/E/PES).
Medical device manufacturers complying with the above standards also have a commercial advantage when publicizing their safety credentials.
Complementary to this new U.S. Legislation is existing guidance by the U.S. Food and Drug Administration (FDA) that is specific to medical devices. The FDA published a document, a draft of guidelines that expects security throughout the total product life cycle from design to manufacturing practices.
In Europe, the European Commission with the Medical Device Coordination Group (MDCG) issued Guidance on Cybersecurity for medical devices. MDCG guidance also refers to secure design and manufacturing as well as the means of security verification and validation in testing. Methods can include security feature testing, fuzz testing, static analysis, and penetration testing.
Also known as static application security testing, or SAST, static analysis scans applications’ source code and looks for specific flaws based on the corresponding programming language and framework used. Static Analysis ensures that first-party source code does not have flaws that may lead to vulnerabilities and exploits. These kinds of tools enable development and security teams to analyze thousands or even millions of lines of code rapidly.
Static analysis, in addition to searching for flaws and vulnerabilities in the source code, applies rules and recommendations stated in coding standards. This could go a long way in ensuring safety and security in the source code of medical devices.
Open Source Security
Today, all software uses open-source software, from the programming language and framework used to critical functionality available in open source libraries and technology stacks. Open source security refers to identifying all the open source components and libraries in the software. Software composition analysis (SCA) tools provide visibility of third-party software and identify open source license-related risks. SCA tools correlate known security vulnerabilities with the corresponding open source libraries in use.
With SCA, medical device manufacturers can identify security risks and produce SBoMs as required in the new U.S. legislation for cybersecurity in medical devices.
📘 Related Resource: Learn more about Open Source Security
Medical Device Security and the New U.S. Legislation
All of the above are important factors in complying with the new legislation requirements. Applying coding and safety standards with the use of static analysis tools and identifying vulnerabilities in open source software with SCA tools allow organizations to produce safer medical devices. Implementing security best practices, vulnerability remediation practices, software patches, and vulnerability disclosure procedures will benefit consumers and the industry as a whole.
Today, cyberattacks are common, and news about ransomware and protecting consumers is frequent. In the case of medical devices, patient safety is the objective of this new legislation.