Medical Device Security: how leaders can secure medical devices to enhance patient safety
Medical devices are soft targets for threat actors.
They were built for a specific clinical use case. As a result, these devices have only the necessary components to do the job and keep the production cost low. As a result, typically, they do not have enough resources (e.g., CPU, disk, memory, networking) to implement modern cybersecurity and privacy best practices.
The Healthcare Industry Cybersecurity Practices (HICP) captured the best practices for securing medical devices. It extends the practices discussed in this HICP series to medical device management.
This article reviews the shared responsibilities aspect of this practice and how small/medium organizations can adopt it with what they have.
Medical device security is a shared responsibility.
Medical Device manufacturers (MDM), Health Delivery Organizations (HDO), and Food and Drug Administration (FDA) share responsibilities for Medical device security.
The FDA sets the standard that the MDM should follow. Accordingly, the HDOs should operate the device under the conditions prescribed by the MDM due to liability and regulatory concerns.
The HDOs can be proactive about medical device security from procurement to decommissioning. To help the HDOs with the procurement process, the HPH sector coordinating council recently published the Model Contract Language for Medical Technology Cybersecurity document [1].
This model also guides for the MDMs to improve their cybersecurity maturity level. For example, with a mature production process, their product should be secure by design and follow a “shift left” concept.
With the “shift left” approach, cybersecurity best practices are baked into the product. As a result, it emphasizes cybersecurity practices during development and before the security incident occurred, i.e., “left of boom.” This approach contrasts to reactive measures taken after an incident occurred, “right of boom.” The emergence of the DevSecOps job titles in MDM organizations indicates this shift.
With medical device security being a shared responsibility, we should hold each other accountable and reward those who take their share of responsibility seriously.
MDM vs. HDO Responsibilities
It is recommended to identify the responsibilities early and plan for them. Lacking clarity for boundaries of responsibilities often hampers and delays recovery efforts.
The MDM should be responsible for changes to the hardware and software components. In addition, configuration for the following functions is also under the MDM purview: endpoint protection, identity and access management, and vulnerability management.
On the other hand, the HDOs could focus on safely operating these devices. For example, having the following process in place: asset management, network management, security operation, procurement evaluation, and contacting FDA.
Unfortunately, the absence of explicitly identifying the risk means that the HDO silently accepts the risks. The HDO should avoid this silent acceptance to minimize the chance of encountering unpleasant surprises later.
Compensating controls that small HDO can use
From HDO’s perspective, the HDO could deploy compensating controls that cover the entire life cycle, from procurement to disposal.
For procurement, the HDO should follow the model contract language closely.
Before moving it to the operation phase, the HDO should record these devices in IT Asset Management (ITAM) system. Next, the network administrator should place these devices in a dedicated network. Furthermore, the admin should configure access lists that permit strictly necessary traffic.
Besides preventative measures described above, we should also look at detection and response. For example, the security operation team needs to closely monitor inbound/outbound traffic. In addition, they need to be alerted when certain activities are out of profile. The team also need to have a playbook for anticipated use cases and practice tabletop exercise.
Finally, when it comes the time to decommission, they need to wipe clean all the data on the device.
Leveraging existing tools to implement compensating controls
There are tools in the market that specifically address medical device security. However, those are more appropriate for enterprise-level health systems with hundreds (if not thousands) of medical devices.
In the absence of these highly-automated tools, we could compensate with processes and tools identified earlier in this HICP article series. This method is acceptable for small or medium organizations as the number of medical devices is still manageable.
For example, we can use the ITAM tool we identified in the previous article (LanSweeper) for asset management. We can scan the device to obtain the digital fingerprint and create records before putting them into the production environment.
For network segmentation, we can create a dedicated VLAN on our network switches to create proper segmentation, separate from other devices.
For network security and security operation, we can use the firewall and IPS discussed earlier (Cisco Meraki MX) to create firewall rules and monitor the traffic through its IPS capabilities.
For vulnerability management, we can perform a vulnerability scan using Nessus either before production or during the maintenance window using Nessus. When the HDO finds a vulnerability, the HDO can notify the MDM or engage the FDA when necessary.
Looking at the cost
As mentioned previously, small organizations may not need a specialized tool for this practice. The assumption is that we have a low number of medical devices, which makes it manageable, and we have existing generic tools that we have already identified previously.
With no additional cost anticipated, the projected cost for a small organization (1 FTE Physician + 3 staff) to adopt HICP practices so far is $7,792 (1st year) and $4,168 (subsequent years).
Conclusion
Medical device security is critical for patient safety, and it is a shared responsibility between the MDM, HDO, and FDA.
Small practices can use the tools identified in this series to adopt practices outlined in HICP for medical device security.
