Medical devices increasingly represent a weakness in security for most healthcare organizations, which typically use hundreds of diverse devices from dozens of manufacturers. Equipment ranging from infusion pumps to hospital beds to Bluetooth-enabled devices can be 10 or more years old, working on old, vulnerable operating or application systems, and they’re often in close proximity to patients and essential in providing life-saving treatment.
Because an increasing number of these devices are connected to the cloud, it’s time to take a structured approach to ensuring that security risks are managed closely, said James L. Angle, an information security architect at Trinity Health, a Livonia, Michigan-based Catholic healthcare system. Angle detailed the growing risk of cloud-linked devices’ security risks, as well as an approach for tightening up defenses based on their proximity to patients during his recent HIMSS20 Digital presentation, Managing the Risk for Medical Devices Connected to the Cloud.
Mitigating device security risks should begin before they’re purchased, Angle said. He outlined five “degrees of separation” medical devices can have from patients, and security professionals’ strategy for strengthening security varies among the different categories. They are:
Devices implanted in the patient
1: Devices that touch the patient, such as a blood-gas monitor in an ICU
2: Devices that don’t touch the patient, but take vital measurements, such as a blood pressure monitor
3: Devices that don’t touch the patient, but still provide data vital to proper patient diagnosis
4: Devices that are separate and are more of an operational tool vs. one that’s diagnostic or clinical
Before any devices are purchased, security professionals need to be involved, collecting documents such as the manufacturer’s disclosure statement on medical device security, augmenting those formal statements with additional security questions, Angle said. Based on that information, it’s crucial to conduct a risk assessment and threat assessment.
“Pay special attention to [security] controls that the manufacturers say are in place,” Angle noted. “Look at all the related software, both for the device’s operating system and application system. Some of these devices have database software connected to it. Identify all the connections for the data; know where the data is being processed and where the patient data is being stored – in multiple devices on site, network storage media or in the cloud. Each one of those has different security requirements.”
Various organizations provide a technical framework outlining security postures for devices that handle health information – these include the National Institute of Standards Technology, HITRUST and the International Organization for Standardization. “When you’re doing a control assessment, it’s important to use a recognized framework,” he said.
Contracts for device purchases should ensure that all threats and vulnerabilities are addressed, even though not all of them can be corrected or remediated. For example, contracts should specify how quickly patches are applied to resolve security issues, ranging from two weeks for high-priority patches to four weeks for low-priority fixes.
“A lot of times, vendors will not let you apply the patch to their devices – they want to do it themselves. If it takes them a year to come out and apply the patch, that’s a problem.” Once devices are purchased and in use, it falls to operations management to manage security protection, which is crucial for devices that are managed via cloud services or upload data to the cloud. Different levels of attention are necessary the closer devices are to patients.
For example, implanted devices “present a unique set of issues,” Angle said. “The device on its own typically does not connect directly to the Internet or the cloud – a pacemaker usually does so through another device, for example, like a handheld device that you hold up next to the patient, which then reads information off the pacemaker, which then connects to a base station or a smart device. In that case, you have multiple points to check for security.”
With implanted devices, typical concerns include how the devices accomplish identity and access management, and how the health organization ensures that new vulnerabilities are remediated. IAM is critical on implanted devices because patients can be in settings where devices might be easily accessed and hacked.
Depending on their proximity to patients, medical devices can be difficult to patch, Angle said in outlining challenges for the various degrees of separation from patients. IAM issues are common to almost all types of devices, and it can be difficult to run antivirus programs and apply necessary patches while they are in service.
Manufacturers of some devices don’t allow antivirus software to be installed on them, and they may have weak or no IAM, which makes it difficult to layer on essential security for devices that connect to the cloud. In these cases, devices can be somewhat insulated by segmenting them on the network and controlling the data flow to and from the device, Angle said.
For devices that connect to the cloud, healthcare organizations should collect log files wherever possible and implement a cloud access security broker solution. “What this does is identify all the PHI data going into the cloud and also encrypts the data. Providers also need to assess cloud security, and the Cloud Security Alliance IoT control matrix is a good place to start,” he said.
