Medical Device Cybersecurity
Recommended Practices for Software-Contained Device Manufacturer
Why Cybersecurity for Medical Devices?
As more medical device software is released to the market, information exchange and integration between devices become more feasible and vigorous. Furthermore, the popularity of cloud computing makes remote healthcare realized more quickly and prevents the need for hospital IT infrastructure from being continuously updated due to the adoption of new AI-based devices. However, with that comes growing cybersecurity concerns in medical devices, hospitals, and sensitive patient information. In addition to the manufacturers who design and develop the devices, hospitals, healthcare providers, and patients must also take steps to ensure the security of the medical device.
The FDA & Medical Device Cybersecurity
Although the FDA issued cyber security guidelines on off-the-shelf software, premarket and postmarket, as early as 2005, 2014, and 2016, they may not be able to respond to rapidly changing security threats and new types of security vulnerabilities. Therefore, the FDA draft guidance released in April 2022 emphasizes mitigation throughout the total product lifecycle warrants an updated, iterative approach to device cybersecurity. In this draft guidance, FDA proposed the concept of the Medical Device System, that is, any individual connected devices will be operating as single elements of a larger medical device system, and the system can include healthcare facility networks, other devices, and software update servers.
For devices connected to the Internet, integrated with other devices, or transmitted through different media (e.g., USB or CD), how the manufacturers design, develop and maintain them in response to cybersecurity issues. The FDA guidance proposes several aspects throughout the total product lifecycle (TPLC) to ensure the security of devices, including risk management from the earliest stages of development; secure design, architecture, and management of third-party software components during development; cybersecurity testing and risk assessment for unresolved anomalies during the testing phase; and information provided in the postmarket management plan and labeling as it prepares for marketing. Let’s talk about each topic in the following sections.
Risk Management
The concepts of security risk management and safety risk management are similar. Both should be part of the manufacturer’s quality management system, especially in design and development, verification and validation (V&V), process validation (deployment in software fields), and corrective action preventive action (CAPA) procedures pre- and post-market.
However, Security risk assessment differs from safety risk management, which cares about physical injury or property or environmental damage, the security risk management focuses on the risk related to assets of the organization, manufacturer, and patient, and any vulnerabilities that might lead to the threat. Threat modeling analyzes identifying assets, vulnerabilities, threats, and impacts, then, as with security risk management, assesses the risk level of each risk and performs risk mitigation. According to the conventional risk management process, once the security risk control is completed, it is still necessary to evaluate whether it will cause other safety risks or vice versa. AAMI TIR57:2016 illustrates how these two risk management interfaces ensure that all risks are mitigated appropriately.
As mentioned above, security risk management must cover any activity of TPLC. For instance, during the development, the developer commonly adopts third-party software components (also known as Software of Unknown Provenance, the SOUP) or off-the-shelf (OTS) software as part of the medical device system. Or the defects or bugs are found during the development or testing but may not be able to reproduce the same scenario that generated the bug or just has not been resolved yet. The manufacturer should perform a safety and security risk assessment on the SOUP/OTS and unresolved anomalies to ensure that the device is safe, effective, and secure.
The document preparation of security risk management is the same as that of general risk management. Besides the risk management plan and risk assessment, the risk management review (or report) summarizes the method and procedure of risk management, details of security risk assessment and mitigation, and traces the risk and its corresponding control and test results.
Security Design and Architecture
The risk control identified through risk assessment should be taken as design input and implemented in the design process. The design considerations can be roughly divided into two measures: prevention and recovery when it is attacked by a cyber-attack. Preventive measures include authentication, authorization, cryptography, integrity, confidentiality, and event detection, while recovery-related measures include event logging, resiliency and recovery, updatability, and patchability. The detailed description and recommendation for implementing security control are included in Appendix 1 of the FDA guidance (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions).
Vulnerabilities may come from hospital networks, cloud infrastructure, or other non-device functions (as defined in FDA’s guidance “Multiple Function Device Products: Policy and Considerations”). Therefore, through the security architecture diagram, developers or regulatory reviewers can logically and easily follow data, code, and commands from any asset (server) to any other associated asset (medical device) while possibly crossing intermediate assets (application). Furthermore, it is also possible to delineate the system’s security context and trust boundaries in terms of the interfaces, interconnections, and interactions with external entities.
The FDA recommends device manufacturers provide at least four types of security architecture in the premarket submission, including Global System View, Multi-Patient Harm View, Updatability/Patchability View, and Security Use Case View. The detailed information has outlined in Appendix 2 of the FDA guidance (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions).
The Global System View describes the overall system, including the device itself and all internally and externally connected devices or other facilities, such as software update infrastructure, health care facility network, intermediary connections or cloud connections, etc.
The Multi-Patient Harm View will address how to defend against and/or respond to attacks with the potential to harm multiple patients. When the devices can be connected to other devices or the network, it may cause various devices to be compromised simultaneously, leading to the patient’s safety risk. In addition, non-device functionalities failures or being hacked may also lead to security issues. Therefore, through the multi-patient harm view, the security risk can be identified, and then risk management should be performed.
The Updatability and Patchability View describe the process by which the manufacturer provides software updates or patches, including technologies in the software update path that the manufacturer does not control and related protection measures. Software updates and patches should be considered any additional cybersecurity risk created or posed by those non-manufactured-controlled technologies.
The Security Use Case View will define “actors” and functionalities. Actors are the person or a thing that invokes the functionality of a system, and they may be a user, system, or private entity. This view should cover various operational states of elements in the system (e.g., power on, standby, transition state, etc.) and assess clinical functionality states of the system (e.g., programming, alarming, delivering therapy, sending/receiving data, reporting diagnostic results, etc.) which a security compromise could impact the safety or effectiveness of the device.
Third-Party Software Component
FDA’s guidance documents “Off-The-Shelf (OTS) Software Use in Medical Devices” and “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” discuss recommendations regarding the adoption of third-party software components, due to the manufacturer is impossible to control and determine whether the software is developed under the Software Development Life Cycle (SDLC) process that complies with IEC62304, so security risk of the software components become factors of the overall medical device system risk management processes and documentation. The manufacturer needs to provide a plan of how the software component could be updated or replaced and provide users with the necessary information for users to manage device-related risks.
The Software Bill of Material (SBOM) is a helpful tool to track manufacturers’ adoption of OTS/SOUP updates and changes and to help manage security risk by providing a mechanism to identify devices that might be affected by vulnerabilities in the software components throughout TPLC.
The FDA recommends that manufacturers include at least the purpose and the asset where the software component resides, the level of support provided through monitoring and maintenance from the third-party manufacturer, any known vulnerabilities, and the name, version, manufacturer, and end-of-support date of the software component in the SBOM and premarket submission.
Cybersecurity Testing
Security requirements such as Security risk control and other security design considerations will be taken as design input and become design output through implementation. During verification and validation, it can be confirmed that all design outputs have met all design input requirements. The difference between cybersecurity design testing and standard software verification and validation is that security testing is focused on finding all possible loopholes and weaknesses of the system which might result in the loss of sensitive information or harm to the patient, including vulnerability testing and penetration testing.
The Vulnerability Testing conducts attack surface analysis, vulnerability chaining, closed box testing, software composition analysis, static and dynamic code analysis, and robustness and fuzz testing by abuse case, malformed, and unexpected input for known vulnerabilities.
Penetration Testing is a simulated cyber attack against the medical device system to check for exploitable vulnerabilities, which will first plan the scope of testing and discuss how a target works and its potential vulnerabilities—then scan the system of how it will respond to various attacks by static and dynamic analysis. The testers will try and exploit the vulnerabilities, typically by escalating privileges, stealing data, intercepting traffic, etc., and then maintaining access to see if the vulnerability can be used long enough for an intrusion to gain advanced access. The penetration testing results might include specific vulnerabilities that were exploited, sensitive data that was accessed, and the amount of time the tester could remain in the system undetected. The FDA also recommends including the independence and technical expertise of testers, scope of testing, duration of testing, and test methods employed in the penetration testing report.
As identified above, vulnerabilities and anomalies identified during testing should be assessed for their security impacts as part of the security risk management process.
Unresolved Anomalies
An anomaly is any condition that deviates from the expected behavior based on requirement specifications, design specifications, industrial standards, or from different stakeholders’ perceptions or experiences. The FDA recommends that each anomaly be documented with a detailed description of the problem, its impact on device performance or the user, and any plans or timeframes for resolving the problem. The manufacturer should provide a list of unresolved anomalies in a product at the time of premarket submission and already assess the anomaly’s impact on safety and effectiveness. Some anomalies discovered during development or testing may have security implications and be considered vulnerabilities.
In standard software testing, a benefit-risk analysis of the unresolved anomalies may conclude that the defect does not need to be fixed, as its impact on the system or user may be minor or unlikely to happen. Conversely, in security testing, the exploitability of an anomaly may require mitigation because of the significant and different types of harm that it could facilitate. The FDA recommends that for those bugs that will be addressed in the following releases (e.g., remediation deferred for a future release because current risk was assessed to be acceptable), the plans for those releases should be detailed in the premarket submission to include the vulnerabilities that future version will address, anticipated timelines for update, whether devices released in the interim will receive those updates/patches, and how long it will take the update to the device on the market.
Cybersecurity Transparency
Medical device security is a shared responsibility among stakeholders throughout the use environment of the system, and cybersecurity transparency is critical to ensure the safe and effective use and integration of devices and systems, which can be conveyed via both labeling and the establishment of post-release management plans. Due to different types of users and stakeholders having different abilities to take on a mitigation role, the information provided to ensure continued cybersecurity should be appropriate to the kind of target audience.
For medical device systems with cybersecurity risks, the Instruction for Use (IFU) will be an effective way to comply with the FDA’s labeling requirements and help mitigate cybersecurity risks to ensure the continued safety and effectiveness of the device. The FDA recommends that any risk transferred to the user should be detailed, documented and considered for inclusion as tasks during usability testing to ensure that the type of user has the capability to take appropriate actions to manage those risks. The instructions for users should be understandable to the intended audience, such as patients, healthcare providers, or caregivers with different technical knowledge levels. The specific information should be available only to particular users to prevent unauthorized users from gaining access. FDA’s guidance document “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” and the Health Sector Coordinating Council (HSCC) Joint Security Plan outline the information that should be included in labeling to communicate relevant cybersecurity control to users.
The FDA recommends that the manufacturers include the vulnerability communication plans as part of the premarket submission to demonstrate their ability to address how to maintain the cybersecurity of the medical device system after marketing. The plans should include the following elements: personnel responsible such as the chief information security officer, quality assurance, and development and operations engineer; sources, methods, and frequency for monitoring for and identifying unknown vulnerabilities; periodic security testing to test the impact of the identified vulnerability; timeline to develop and release patches; update processes; patching capability (e.g., the rate at which update can be delivered to the user); and description of the coordinated vulnerability disclosure process.
Summary
The cybersecurity issues revolve around the Total Product Life Cycle (TPLC), so the Secure Product Development Framework (SPDF) proposed by the FDA is to blend cybersecurity-related activities into every development stage to ensure that the medical device system has been thoroughly implemented and tested before it goes on the market, and sustain its safety and effectiveness after releasing to the market.
Rook Quality Systems has helped many Software as Medical Device (SaMD) manufacturers plan cybersecurity projects and implement security risk assessments to provide development teams with mitigation and testing. If you have cybersecurity-related questions, please feel free to contact us.