By Arleen Thukral, MS, CCE, CHTM
Not only do healthcare cyberattacks threaten our systems and information, they also jeopardize the safety of our patients. Fortunately, all hope is not lost. By following practices that align with the National Institute of Standards and TechnologyCybersecurity Framework—which are outlined below—you can provide a more secure environment for manufacturers to develop products and providers to deliver high-quality, uninterrupted patient care.
For medical devices that connect to larger information systems or applications, safeguards are not only important for the device itself, but also for the larger information system and connected endpoints. Case in point: An MRI machine may connect to a PACS with image-reading workstations. To protect these endpoints, the medical device manufacturer should directly support antivirus (AV) software. If AV cannot be implemented, the healthcare organization may consider a compensating control—for instance, enforcing an AV scan whenever equipment is serviced before it’s reconnected to the device network.
In addition, medical device data should be encrypted while at rest and during transport. If removable storage is not a necessary feature and encryption of removable storage is unsupported, consider disabling the use of removable storage media.
Identify and Access Management
If manufacturer-supported, the device should bind its authentication capabilities with systems enterprise authentication domains, which automates termination of device access. Moreover, passwords—especially those enabling privilege access—should be lengthened and changed into something more complex and specific to only the medical device. That way, passwords are more resistant to discovery (e.g., shoulder surfing attacks). It’s also judicious to limit the number of retries permitted without negative consequences.
All medical devices should be added to an inventory that can reflect their core components, as well as maintain preventative maintenance schedules. There is also a need for a software component inventory, or “Software Bill of Materials,” for medical devices—including operating systems and software application components developed by vendors or licensed from third parties—providing major version information. If possible, query this information automatically.
Futher, healthcare organizations are responsible for making risk-based decisions about devices nearing end of life or end of support. In most cases, when a device becomes unsupported, or legacy, it should be replaced as part of an established asset refresh cycle.
But in some cases, it’s not possible to replace legacy devices due to financial or other resource constraints. So the healthcare organization should implement compensating controls, with the understanding that the manufacturer will no longer support the devices—thus, planning their decommissioning. During the decommissioning process, it’s important to wipe all the data on the device.
Another best practice is to separate medical devices from hospital general access networks, with the former configured to communicate only with required systems. This control will significantly reduce the exploitability of the device. As part of the segmentation strategy, biomedical engineering should review data flows and interfaces between the medical device and the hospital’s connected systems. Still, manufacturers may require the organization to install their own physical network. In this case, access to the manufacturer’s physical network should be limited. After all, the ability to restrict access to the device is essential to its safe operation.
Healthcare organizations should have a program in place to review vulnerability disclosures, evaluate their exposure to such vulnerabilities, and work with manufacturers to remediate or mitigate each vulnerability according to its level of risk. If the risk is high, for instance, escalated actions should be taken to secure the device.
Moreover, uncontrolled risk should be communicated to healthcare organizations with the organization determining the interim mitigation step within 30 days. Within 60 days, the uncontrolled risk should be remediated. Healthcare organizations can also search the national vulnerability database at https://nvd.nist.gov/vuln/search. It’s important to note that vulnerability scans can only be conducted when the device is not connected to a patient. The most opportune time to conduct a vulnerability scan? When a device is first procured before deployment or when it’s taken offline for PM and routine patching.
Procurement and Security Evaluations
Healthcare organizations should establish a set of cybersecurity requirements when acquiring new medical devices, which should be embedded in their contracting processes. These requirements should include high-value items—such as supported and patchable operating systems, AV, or whitelisting—and no hardcoded or default passwords. When a security evaluation is undertaken, it should include all the other devices required for the device to perform its clinical functions. For example, evaluations should be completed for both the infusion pump and the server it connects to when updating the formulary.
Finally, healthcare organizations should insist on receiving a Manufacturer Disclosure Statement for Medical Device Security (MDS2). Developed collaboratively by the Health Information Management and Systems Society (HIMSS) and the American College of Clinical Engineering, the MDS2 is a standardized form that most manufacturers use to assess cyber risks. In addition to providing a list of comprehensive cybersecurity questions for medical devices, the MDS2 allows healthcare facilities to easily compare security features across different devices and different manufacturers, HIMSS officials say.
Arleen Thukral, MS, CCE, is a VISN 20 biomedical engineer at VA NorthWest Healthcare Network in Seattle. Questions and comments can be directed to email@example.com.
Thanks for sharing this.
This article is the one of the best that I have read ever.
It is quite practical and can implement in the field right away.
Some thoughts regarding the opinion that Mfg should support AV patches. Do we realize how often AV patches come out? How does a Mfg guarantee that a patch sent out by a AV Company does not interfere in any way w/ the operation of the device? How long after a point of sale should the Mfg be held responsible for exploits that come out 4,5,6,7,15 years down the road.
Patches are a as needed, as discovered basis generally. Do we wait till a patient is injured to investigate the root cause? And then at that point add a new patch. Being proactive on some devices that are never off line to apply an AV patch and test for any issues is extremely difficult. And how much testing do we put in place to call it safe for patient use?
Placing this monotonous responsibility and risk onto a MFG is the exact reason we suggest segregation/access-control/and limited traffic over our Real Time Patient Monitoring network.
I’m not a Cyber security expert nor am I a medical equipment designer, I do have my opinion from years of dealing w/ Real time Medical devices/networks and Healthcare networks. I totally agree that the logical approach that you mention in the Network Management section is to provide a level of separation/isolation from these networks and limit functionality that is only specific to the medical devices to traverse the network. Unfortunately, the trend is going in the opposite direction. Yes, in the segregation scenario we need additional equipment to provide medical staff a means to surf the web. Or we wait till someone opens a giff/applet/re-director and see what happens on a medical network. My2. #connectedworldtroubles#