By Micheal Gutman and Dema Assaf Helou
When faced with medical devices that cannot accept all the required security controls, as established by your organization, many healthcare technology managers turn to non-baselined device isolation. Isolation allows these devices to function as intended but mitigates the security risk posed by these devices by limiting their external and internal communication via firewall rulesets. While isolation is a valuable tool for managing the security of such devices connected to the network, non-baselined isolation (“isolation”) should not be the default network security option and should only be applied after individual evaluation of the device.
In contrast, a baseline is a set of security controls, group policies, and update standards that are applied to devices across the network. When a device is put on a baseline, it is forced to accept all security controls and group policies of the site. This allows for a uniform security posture and patch schedule regardless of the endpoint device or workstation that is being considered.
Because of this uniformity, internal network communication is typically not harshly restricted. Oftentimes, baseline devices can communicate freely with all other baseline devices on the network, so baseline devices use role-based or account-based security. This security is managed through an active directory where both devices and users will have accounts and role groups. These role groups control what level of access these devices and user accounts have to other baselined devices.
Isolated devices inherit a standard firewall or access control list (ACL) ruleset based on the type of device (e.g., a medical device) that is being isolated. Once the standard ruleset is applied, all specific communication needed by the device must be incorporated into the ruleset after a security review. Communication on an isolated system will only be allowed based on the technical and functional requirements of the device, particularly with external connections. This is done to mitigate the elevated risk posed by devices that cannot accept elements of the baseline.
Since there are typically very few, if any, universal group policies applied to isolated devices, the system owner is responsible for ensuring that all allowed security mitigations are in place. This includes ensuring the OS, anti-virus, and drivers are kept up to date as much as the medical device manufacturer (MDM) allows and ensuring that the group policies and registry (if applicable) of the device are tailored to mitigate any risks that cannot be addressed with updates. The ideal way to ensure that these updates are applied in a timely manner is to set up and connect to an offline update server that is configured to push all available and MDM-approved updates to each device. Without this, patches will need to be applied manually by technical staff or system owners. This opens the device to additional risk of human error when applying updates. To mitigate this, all isolated devices should be regularly scanned for vulnerabilities, and there should be a remediation plan in place for any that are found.
A common myth is that device isolation is the most secure network configuration and should be used for all medical devices. While device isolation makes these higher-risk devices easier to manage from a cybersecurity perspective, isolation presents its own set of risks. For one, device isolation does not remediate risks; it only mitigates them by hiding them behind firewall rules that limit device communication. If those mitigations fail, the risk remains. Additionally, since the communication of these devices are limited, access to the devices requires local accounts, which must be managed separately from enterprise accounts, creating another point of failure.
That said, there are instances that necessitate device isolation to ensure continued network security while also allowing these devices to function as intended. Many medical devices run proprietary embedded operating systems that must be managed differently than baseline devices. These devices can require a security configuration that violates baseline requirements (e.g., it contains software that cannot be scanned with antivirus, or the MDM does not allow installation of antivirus or other required software). Medical devices must adhere to the Food and Drug Administration (FDA) 510(k) clearance guidelines, which require MDM written approval prior to applying security patches. Automated patching is a standard requirement for baseline devices and would invalidate the medical device’s FDA 510(k) clearance.
While many medical devices need to be isolated for security reasons, non-baselined isolation should not be the default option. Devices should be evaluated on an individual basis to determine if non-baselined isolation is necessary. When evaluating medical devices to determine the appropriate security configuration (baseline vs. isolation), consider whether the medical device requires any special security considerations. Additionally, consider whether isolation will affect the normal function of the medical device software.
-Micheal Gutman and Dema Assaf Helou are biomedical engineering consultants with Blue Water Thinking, LLC, supporting the VA Electronic Health Record Modernization (EHRM) Integration Office (IO) Healthcare Technology Management (HTM) Program Office.
