Ransomware and Medical Devices: How Behavior Analytics Can Protect Patients

Medical devices must be managed from a security perspective, but also from an operational perspective. Using analytics to establish behavior baselines helps support risk assessments, find malfunctions and enhance staff productivity.

By William Scandrett | Healthcare IT News

From a cybersecurity perspective, I believe the healthcare industry is in a growing medical device crisis. The emerging trend of ransomware attacks on medical devices has created serious vulnerabilities in healthcare security.

Ransomware threats, and their implications for medical devices, center around the wide adoption of easily compromised operating systems on these devices, creating a growing vulnerability with potentially life-threatening ramifications. And what many people may not know is that ransomware attacks on medical devices have already occurred.

Medical devices and easily compromised operating systems

Previously in healthcare, there was a degree of insulation in that medical devices were highly specific. They were traditionally built with some version of proprietary firmware or other exclusive features. That meant the ROI for compromising early-generation medical devices wasn’t lucrative. Developing specific ransomware or malware for these specialized devices, on an attack surface which is comparatively small, simply did not scale.

But now, it’s a different story. The trend in medical device manufacturing is changing. Manufacturers are building cheaper and more scalable medical devices running Windows (and the like). The benefit of using a standard operating system is that it’s generally easy for the IT group to apply the latest patches, whereas before, they couldn’t really do that. This was not only because the operating systems of earlier generation medical devices was often proprietary. There were also risks that installing antivirus software, or a product agent on a medical device, would break the device and/or void its warranty.

While the ability to apply patches is a clear benefit to using common OSs for medical devices, there are drawbacks as well. With the proliferation of standard OSs, the healthcare industry has begun to observe ransomware attacks on medical devices that were previously only seen on servers and desktops.

In 2017, one of the first cases of ransomware on medical devices was reported. It occurred on a precision appliance that improves the quality of images for an MRI. In this case, the WannaCry ransomware screen popped up on the LCD readouts, demanding a ransom to unlock the apparatus.

Protecting patients by securing medical devices

The ransomware situation exacerbates IT professionals’ challenges when it comes to managing medical devices. Do we treat them like desktop devices now? If so, how do we mitigate the risks? This is especially critical, because with medical device security, the stakes are much higher. In ransomware attacks, an organization might risk losing valuable data. But medical devices are connected to patients, putting human lives at stake.

To keep these devices secure it’s necessary to profile the behavior of medical devices and to understand their standard behavior patterns. For example, medical devices generally have a specific purpose. While they may be multi-functional in some ways, they’re mostly designed for one reason — such as an infusion pump or an imaging device. Their usage patterns don’t change a great deal.

Once you know these standard behaviors, it’s possible to identify unusual trends that could indicate the device has been compromised and the IT group needs to intervene to prevent damage.

At Allina Health, we use technology from Gurucul to establish baseline behavior profiles. With these baselines we can detect activities that are outside the normal patterns. When a medical device starts to act irregularly, there are only a couple of possible causes: Either the device is malfunctioning and needs to go in for service, or it has been compromised in some way.

From a threat perspective, this anomalous behavior triggers risk-based alerts from our user and entity behavior analytics, or UEBA, platform that could mean, for example, someone has accessed the device and changed its configuration.

In other words, it’s been hacked. Identifying malfunctioning devices and threat detection, or subsets of these two fundamental cause scenarios, are critical in healthcare. The key performance indicators that our analytics deliver represent bottom line information for any clinical group and the IT group supporting them.

Beyond security – the operational benefits of behavior analytics for medical devices

It’s not uncommon to see instances where medical devices show up on the hospital network that are unforeseen additions to planned inventory. In these situations, the apparatus is usually procured by a physician or a hospital organization that might have their own budgets for discretionary purchases.

These unplanned medical devices must be managed, certainly from a security perspective, but also from an operational perspective. Using UEBA to establish behavior baselines with medical devices not only supports risk assessments, but also provides the ability to determine malfunctions in medical device maintenance, which helps avert clinical risk and enhances productivity of medical personnel (doctors, nurses, technicians, etc.).

In many ways the medical device situation resembles the general IoT use case that any enterprise might deal with. However, the medical device use case has additional degrees of complexity. Medical devices are generally managed by the third-party company that installs them. There is usually a service contract where a device may digitally report out through the hospital network that it’s malfunctioning and possibly requires being swapped out for a new unit.

From the IT perspective, that’s a device leaving and a new device entering the network. With UEBA, even though that device might exhibit the same behavior pattern as another appliance of the same model, we now know its unique identity.

Because of this ability to determine the entity’s individual identity, we can use this technology almost as a network access controller and learn when a replacement device is performing a function with a different profile. We can also potentially use this technology to identify what the various kinds of devices are, and to use behavior patterning to understand where they should live and how they should operate on the network.

We have also begun to utilize UEBA technology as an early warning system to provide us with important indicators that a device is not behaving normally. Clearly, if a device is malfunctioning, it cannot be allowed to connect to a patient. Being aware of this issue and being able to take immediate action is essential. It is also beneficial to understand when a device might be out of rotation.

One of the major issues we have in this space is determining when we can safely patch medical devices. There’s always a small risk when we patch a medical device that the patching process might take the device down or might even disable it. As well, it might cause some form of operational issue for the device. There is a need to be extremely careful with medical device patching procedures. That’s generally why we scan at night or off hours, so we don’t disrupt normal patient care or business operations.

With medical devices, we must always maintain a primary focus on patient care. The IT team can’t just go scan a device, because the device may be performing a clinical service at that time and be connected to a patient. We can use UEBA to understand when a device is out of rotation, and when is a safe time to perform maintenance.

For example, with UEBA, we may know that between the hours of 8 p.m. and 6 a.m., a particular device is not being used. With this knowledge, we can perform regular maintenance activities during those known ‘off hours’ so as not to interfere with patient care. This contrasts with what we would normally do with the rest of our IT environment, like servers and workstations, independent of the patient care factor.

This also enables us to notify members of our clinical engineering team, for example, with a report on the results of a device that was scanned the previous evening. These reports might indicate the scan didn’t go well, that the device is behaving abnormally. That determination would result in the device being pulled out of rotation and replaced with another device until the cause of abnormality can be identified. Remember, patient care and safety always comes first.

The prospect of a patient being placed in harm’s way due to a medical device’s faulty behavior is not as far-fetched as it may seem. The assurance we gain with the ability to establish baseline behavior risk profiles for medical device types holds great value for healthcare organizations, such as ours. Depending on how good we get at this, it’s not unreasonable to consider this type of technology as providing a framework for facilitating the device maintenance process.

In the healthcare industry the patients must always come first. If a patient is connected to a medical device that is compromised, and that device ends up delivering a lethal dose of a drug, you can’t make the afflicted parties right again. You can’t recover that patient, or the loss to his family. A healthcare CISO must understand the tremendous responsibility he has – far beyond other industries.

William Scandrett is the CISO of Allina Health, responsible for security, governance, identity and cybersecurity programs, as well as technology compliance and risk management.


External Link: Ransomware and Medical Devices: How Behavior Analytics Can Protect Patients


Share this page:

Related Posts