Overcoming Security and Risk Management Challenges for Networked Medical Devices
As medical devices are becoming increasingly interconnected to provide the benefits of integrated and more efficient patient care delivery, healthcare providers are challenged to manage the risks of these connected devices. However, the increase in quality of care and gains through automation can only be realized if the resulting cybersecurity risks are managed to an acceptable low level.
Medical Device Management Challenges
As medical devices are becoming more connected, managing them from an IT and security perspective can be extremely challenging. Currently, around 30%-40% of hospital-based medical devices are connected to a network and that number is expected to increase at 15%-20% per year. Healthcare providers face multiple technical and administrative issues that make it difficult to reliably and predictably deal with the complexities of their medical device ecosystem. From an equipment, risk, and cyber security management perspective the following challenges need to be addressed:
Providers have thousands of devices like physiological monitors, infusion pumps, ultrasound machines, etc. connected to their network. These different types of devices are supplied by many different manufacturers and as a result, vary widely in their technology platform (e.g. operating systems) and have varying security maturity and software management capabilities. A typical mid-size healthcare provider may have several thousand devices from hundreds of different manufacturers within their environment which makes the problem of managing medical devices extremely challenging.
Old and new devices with varying security maturity and capabilities coexist on the same network. An old infusion pump might be running a stripped down customized Linux version that might not have the capabilities to be managed from a security and risk perspective. A new ultrasound machine, on the other hand, might have the latest Windows operating system with the ability to be remotely or centrally managed. In such scenarios it might be easier to protect the ultrasound machine than the infusion pump, but it doesn’t eliminate the need to find a solution for the pump.
Design and use case constraints make it difficult to use commonly deployed management techniques as they are used in the IT space, like device discovery or vulnerability scanning. For example: Scot Copeland in his presentation for ACCNet mentions how the Telemetry Monitoring system had failed as the result of a network vulnerability scan, which led to a temporary loss of equipment availability and diagnostic data.
There is no common architecture on how to build a secure medical device network and the data relevant to device and network properties is widely distributed across components. This means anyone attempting to understand a medical device has to look across a variety of distributed data sources which further adds to the complexity.
All of this means that healthcare providers have a variety of problems they must deal with and they need to think holistically about how they want to approach medical device management.
Building a Device Master Record
The first problem is getting a comprehensive view of all risk and security-relevant medical device data. Most providers have a list of biomedical devices and some of their parameters in a CMMS database. The database has some valuable information about the device but typically does not have any of the relevant IT or cyber-security parameters. Moreover, historically collected asset information has been known to be incomplete or inaccurate. Without knowing all the details about the device, providers find it challenging to develop a strategy around procurement, replacement planning, lifecycle management and device risk management. This could be addressed through a comprehensive device master record that allows the providers to optimize inventory, manage risks, focus resources, reduce costs and as a result improve their overall security posture and operational efficiency.
The second problem is understanding how the devices are integrated, how they interact with other devices in the network, and how the data is flowing. Understanding device relationships allows the provider to properly configure or segment the network. Understanding how medical data flows through their network is useful in understanding any potential existing configuration issues (e.g. observation data from a device flowing to the wrong servers) which can be a problem with the complexities of healthcare protocols and the large number of devices distributed across the network. Misconfigured devices can lead to devices not functioning and leading to device downtime. Also if the data cannot be tracked, it could lead to potential fines and costly debugging efforts.
Contextual Risk Management
The third problem is the ability to prioritize the mitigation tasks associated with different devices. Considering the wide variety of devices, use cases, and vendors, providers need to focus on their highest risk devices. Such an approach reduces the risks to care delivery, patient safety, security, privacy, and business operations. In a complex industry like healthcare though, risk does not just depend on number of vulnerabilities or anomalies but varies across many parameters. For example: a ventilator has a higher patient safety risk than an ultrasound imager. Or, a device with a Microsoft operating system might have a higher likelihood of being infected by malware than a device that runs a proprietary operating system. There are many more such examples across a variety of dimensions. Inability to prioritize appropriately and react swiftly can lead to costly misdirected efforts, constant fire-fighting and even with that, continuous stream of issues that could impact delivery and quality of care.
The fourth problem is getting a continuous view of the security and operational behavior of the device. Challenge is that medical devices might have differences in behavior depending on the device and the environment which might appear as a problem. For example: A potential deviation of behavior because of a patch which updates the device configuration might be normal whereas a change in behavior because of a security attack would be an anomaly. Differentiating between the two and providing an accurate view to the provider is important, without which providers could face time and effort debugging non-existent issues or letting problems proliferate in their network.
In its next blog, Asimily will lay out a solution approach and path forward on how to solve the challenges discussed above as well review some of the current trends in the industry. I would love to hear your comments and questions if any. Please feel free to also reach out to email@example.com