Cybersecurity Practice #9: Medical Device Security (medium/large)

Health care systems use many diagnostic and therapeutic methods for patient treatment. These range from technological systems that capture, render, and provide detailed images of scans to devices that connect directly to the patient for diagnostic or therapeutic purposes. Such devices may have straightforward implementations, such as bedside monitors that monitor vital signs during an inpatient stay, or they may be more complicated, such as infusion pumps that deliver specialized therapies and require continual drug library updates. These complex and interconnected devices affect patient safety, well-being, and privacy, and they represent potential attack vectors in health delivery organizations’ (HDOs’) digital systems. As such, these devices should be robustly designed and properly secured.

This section focuses on the methods that HDOs can employ to protect connected medical devices. Specifically, it addresses the actions that HDOs are permitted to take, how to align with the Medical Device and Health IT Joint Security Plan, and how to best work with device manufacturers and the U.S. FDA.

Any device that connects directly to a patient for diagnosis or therapy should undergo extensive quality control to that it is safe for use. Rigorous stipulations, managed by the FDA, are in place for the development and release of such systems. The organizations that produce these devices, referred to as device manufacturers, should comply with regulations. Organizations that purchase devices and use them for the treatment of patients are the clinical providers. In the context of this relationship, they are the HDOs.

Given the highly regulated nature of medical devices and the specialized skills required to modify them, it is ill-advised for HDOs to make configuration changes without the support of the device manufacturer. Doing so may put the HDO at risk of voiding warranties, result in legal liabilities, and, at worst, harm the patient. Therefore, traditional security methods used to secure assets cannot necessarily be deployed in the case of medical devices. For example, one cannot simply apply a patch to a vulnerable component of the OS that runs a medical device.

In 2018, the Healthcare Sector Coordinating Council’s Joint Cybersecurity Working Group released a guidance document for device manufacturers on developing and releasing secure medical devices.³⁹

This Joint Security Plan (JSP) was the result of a public–private partnership between health care providers, device manufacturers, and the FDA. The JSP focuses on ensuring that vendors deliver secure products to HDOs and have concrete plans to maintain the security of these products. This section takes this context into account when addressing what HDOs should do upon receiving medical devices from manufacturers.

For a practical example of full lifecycle management, risk analysis, management, leading practices, and detailed configuration specifications to secure wireless pumps (one type of medical device), see the NIST/NCCOE report, Securing Wireless Infusion Pumps In Healthcare Delivery Organizations 2017.⁴⁰ Another common framework to leverage is the ISO 80001:2010 standard.⁴¹

Sub-Practices for Medium-Sized Organizations

Medical devices are a specialized type of IoT device, specific to providing clinical diagnosis or treatment within HDOs. Nevertheless, cybersecurity for medical devices follows many of the cybersecurity practices already discussed in this document:

• Cybersecurity Practice #2: Endpoint Protections
• Cybersecurity Practice #3: Identity and Access Management
• Cybersecurity Practice #5: Asset Management
• Cybersecurity Practice #6: Network Management
• Cybersecurity Practice #7: Vulnerability Management
• Cybersecurity Practice #8: Security Operations and Incident Response

Rather than recreating these cybersecurity practices, HDOs are encouraged to extend the relevant cybersecurity practice from each section, implementing it appropriately for medical device management. The following sections expand on how the broad practices listed above apply in the specialized case of medical devices.

Typically, medical devices connect to larger information systems or applications. For example, a CT scanner may connect to a picture archiving and communication system, which, in turn, is connected to specialized image-reading workstations. In such environments, the safeguards listed below are important, not only for the medical device itself (in this case the CT scanner), but also for the larger information systems and connected endpoints. Consider all these safeguards, as applicable.

Where feasible, medical devices should have the following controls enabled:

• AV software: Usually, the medical device manufacturer should directly support AV software, or it should be cleared for operation by the manufacturer. Ensure that a compliant AV technology is enabled. If AV cannot be implemented, compensating controls should enforce an AV scan whenever the device is serviced prior to reconnecting to the device network.
• Local firewalls: Medical devices should be configured to communicate only with required systems. Unused services and ports should be disabled if they are supported by the manufacturer.
• Encryption: If supported by the manufacturer, medical devices should have local encryption enabled in the case the device is stolen.
• Application whitelist: Configure medical devices, or implement software, to only allow known processes and executables to run on the devices. This control alone can significantly reduce the exploitability of devices.
• Default password changes: If supported by the manufacturer, default passwords, especially those enabling privileged access, should be changed to long, complex passwords used only for the medical device. Do not tie unique device credentials to any general systems management credential, because you do not want general credential compromises to affect the medical device.
• Routine patching: As part of preventative maintenance cycles, medical devices should be patched with supported cybersecurity patches released by the device manufacturers. Given the special sensitivity of the configuration and management of these devices, patching should not take place on these devices unless cleared by the manufacturer. This control, along with whitelisting, can significantly reduce the exploitability of the device.

As much as feasible, medical devices should have the following controls enabled:

• Authentication: If supported by the manufacturer, the device should bind its authentication capabilities with systems enterprise authentication domains. This automates termination of access to the device upon termination of employment for the user.
• Vendor support passwords: Passwords should be complex and not shared among the vendor team. A unique logon credential should be established for each vendor employee. Ensure the manufacturer does not use the same account and password to manage medical devices in your organization and others.
• Remote access: If remote access is required to manage medical devices, MFA capabilities should be deployed, with HDO acceptance of the system access mode to be used. Depending on the deployment scenario, the device manufacturer may be required to support remote access capabilities. Otherwise, such capabilities should be deployed on a separate component of your existing MFA system to limit exposure if the MFA system is compromised. 

As much as feasible, medical devices should have the following controls enabled:

• Inventory, hardware: All medical devices should be added to an inventory that is capable of reflecting the core components of the devices themselves. You may use your general ITAM inventory, as described in Cybersecurity Practice #5: IT Asset Management. Alternatively, you may have to employ specialized tools designed specifically for tracking the lifecycle of medical devices. Such systems can be useful for maintaining preventative maintenance schedules.
• Inventory, software: Implement a software component inventory for your medical devices. Manufacturers should be able to deliver to the HDO a full listing of software components (including operating systems and software application components developed by vendors, as well as components licensed from third parties), with at least major version information. Such lists are sometimes referred to as bills of materials. Information about software components should be maintained in a scalable database managed by the HDO, and updated as part of the standard device management practices.

• Wiping: When a medical device is slated for decommissioning, it is critical to ensure that all data on the device are wiped. Typically, these devices are returned to the vendor and potentially resold or delivered to other organizations for destruction. You do not want your organization’s data to be accessed by these other parties.

As much as feasible, medical devices should have the following controls enabled:

• Segmentation: Given the critical nature of medical devices and the organization’s general inability to configure them to reduce vulnerabilities, it is critical to segment these devices separately from general access or data center networks. The ability to restrict access to the device is essential to its safe operation.

Dedicated, highly restricted networks should be set up. The only traffic allowed on these networks should be profiled based on required operation of the devices connected to that network. Access to device management systems should be heavily restricted to limit its exposure. Lastly, it is important to ensure that these networks are segmented such that any vulnerability scanning systems are not permitted access in a clinical setting. Given the delicate nature of medical devices, execution of a rogue vulnerability scan could disrupt the devices.

As part of the segmentation strategy, review data flows and interfaces between the medical devices and their connected systems. Be sure not to limit the essential functionality of the medical device, including its ability to be patched remotely, if required. 

Device manufacturers may require installation of their own physical networks in the organization. In these cases, access to the manufacturer’s physical network should be limited with the same restrictions as if the HDO were implementing its own segmentation strategy.

Sub-Practices for Large Organizations

As much as feasible, medical devices should have the following controls enabled:

• Vulnerability and risk categorization: In 2016, the FDA issued the Postmarket Management of Cybersecurity in Medical Devices guidance.⁴² This guidance document presents components for the proper management of medical devices after they have been deployed in an HDO. Focusing on the risk to patient safety, this guidance stipulates that manufacturers should implement vulnerability and risk-management practices to categorize risks according to the device’s effectiveness and the potential to cause harm to the patient.

HDOs should work with device manufacturers to arrive at a common understanding of the framework for the risk categorizations. Upon disclosure of a high risk, HDOs should take escalated action to secure the device.

• Vulnerability disclosure programs: Each device manufacturer should have a program that informs HDOs of vulnerabilities that exist in their devices. These programs should have a communication channel to report information and inform parties. HDOs should work with the manufacturers so that all parties understand the respective points of contact between the manufacturer and the HDO.

In addition to direct communication channels, other channels exist for the disclosure of medical device vulnerabilities. These include the Department of Homeland Security National Cybersecurity and Communication Integration Center, the Health Sector Cybersecurity Coordination Center, and the Industrial Control Systems – Computer Emergency Response Team; manufacturers can include these as part of their vulnerability releases, as can ISACs or ISAOs with which the manufacturers participate.

The HDO should have a program in place to accept inbound vulnerability disclosures, evaluate the HDO’s exposure to these vulnerabilities, and identify, alongside the manufacturers, response actions to remediate or mitigate each vulnerability according to its level of risk.

With a well-established vulnerability disclosure program, medical device manufacturers and HDOs will have bidirectional communication for managing medical device vulnerabilities. Communication is key to maintaining patient safety. Table 12 provides a general rule for the response timeframes (including interim compensating controls) for medical device vulnerabilities; this general rule is in line with expectations in the Postmarket Management of Cybersecurity for Medical Devices guidance.

Table 12. Timeframes for Resolving Medical Device Vulnerabilities

• Software bill of materials (SBOM) and vulnerability lookups: Using SBOMs registered in the organization’s IT!M , the HDO can compare data from the NVD against data in the organization’s software libraries. This comparison provides the HDO with information on current potential vulnerability postures in the medical device space.

A simple search of the NVD can be conducted by using the web interface located at https:// nvd.nist.gov/vuln/search. This search tool allows HDOs to look up vulnerabilities in products that they currently have. It does not require SBOM material to be preregistered.

• Vulnerability scanning: The final action that an HDO can take to understand its vulnerability posture is to conduct vulnerability scans against the medical devices.

WARNING: UNLESS APPROVED BY THE DEVICE VENDORS, THIS ACTION SHOULD BE TAKEN WITH EXTREME CAUTION DUE TO THE POTENTIAL IMPACTS ON MEDICAL DEVICES WITHIN THE PRODUCTION ENVIRONMENT. HDOS SHOULD NOT ATTEMPT TO CONDUCT VULNERABILITY SCANS UNLESS ABSOLUTELY CERTAIN THAT THE MEDICAL DEVICE IS NOT IN PRODUCTION, IS NOT CURRENTLY IMPLEMENTED IN A CLINICAL SETTING, AND IS NOT CONNECTED TO PATIENT.

There are two opportune times to conduct vulnerability scans against medical devices:

• When the device is first procured and tested before deployment in the production environment
• When a device is taken offline for preventative maintenance and routine patching

In both scenarios, it is important for the device to be in a highly controlled setting and not connected to a patient. A vulnerability scan can be configured to profile the device and determine whether potential vulnerabilities exist, or to confirm that vulnerabilities have been mitigated as part of a remediation or patching plan. 

To conduct such an exercise, it is best for the cybersecurity team to work with the clinical engineering teams and establish a profiled scan template in the vulnerability management software. This template should allow the scan to be executed only against a specific nonproduction network and only by specific individuals. To provide further assurance that the vulnerability scan cannot cause harm to the medical device while it is connected, the scanners’ IP addresses scanners should be blocked as part of the segmentation strategy noted above.

When these preparations are complete, the clinical engineering teams can be granted access to the scanning software in a restricted manner that allows the scan to be run only against the network used for preventative maintenance. Vulnerabilities discovered can be shared with the information security office to determine the relative risks. Upon classification of these risks, the teams should contact the device manufacturer and work together to develop and implement a remediation plan.

Expanding on the SOC and IR processes found in Cybersecurity Practice #8: Security Operation Center and Incident Response, HDOs can provide better monitoring, detection, and response activities around their medical device ecosystems. Using the segmentation strategy outlined above, HDOs should monitor for malicious activity into and within the segment. To provide visibility into the daily operations of the medical device systems, the following sources should be configured to send logs to the HDO’s log management systems, SIEMs, or both:

• Firewalls providing segmentation to the medical device network segment
• Information systems that control the operation of the medical devices
• Netflow data from the medical device network segment
• Intrusion prevention systems in front of the medical device network segment
• Logs from any deception technology deployed in the medical device network segment

Using these logs as a source, plays can be enumerated and added into IR playbooks, as described in Table 13.

Table 13. Incident Response Plays for Attacks Against Medical Devices

If any HDO experiences a security incident and requires the assistance of the manufacturer, the HDO should leverage their contact information, which should have been established as part of the vulnerability disclosure program, outlined within section L.B above.

HDOs should establish a set of cybersecurity requirements during the acquisition of new medical devices. These requirements should be embedded in your contracting processes and shared with your supply chain and procurement offices. Ideally, cybersecurity requirements are included requests for information or requests for proposals. These requirements should include high-value items such as supported and patchable OS, AV or whitelisting, no hardcoded or default passwords, and minimal use of administrative privileges.

All technology acquisitions and integrations, including medical devices, require security evaluation as part of the HDO’s supply chain process. Implementing cybersecurity evaluation as part of the supply chain process provides an opportunity for the organization to understand, evaluate, and mitigate cyber risks prior to technology deployment. When a security evaluation is undertaken it should include all the other devices required for the device to perform its clinical functions. Examples include the need to both evaluate both the infusion pump and the server it connects to update the formulary, or to evaluate an MRI device that and all the specialized workstations to control it.

• Security evaluation: The first part of the medical device acquisition process should be a security evaluation of the device. This evaluation should uncover any risks or flaws in the current design of the medical device and establish transparent communications between stakeholders representing the supply chain, clinical engineering, and manufacturing. The HDO should insist on receiving a Manufacturer Disclosure Statement for Medical Device Security (MDS2). The MDS2 is a standardized form used by most manufacturers and developed by the Health Information Management and Systems Society and the American College of Clinical Engineering. It provides a list of comprehensive cybersecurity questions for medical devices, with responses from the manufacturer of the device in question. Questions in the MDS2 include the following:
  • “Can this device display, transmit, or maintain private data (including electronic Protected Health Information)?”
  • “Can the medical device create an audit trail?”
  • “Can users be assigned different privileged levels within an application based on ‘roles’ (e.g., guests, regular users, power users, administrators)?”
  • “Can the device owner/operator reconfigure product security capabilities?”

A copy of the latest MDS2 can be found on the Association of Electrical Equipment and Medical Imaging Manufacturers website.⁴³ Answers to these questions assist the HDO in completing a meaningful evaluation of the medical device.

1. Attacks against connected medical devices