Patching as a Panacea Operational Realities on Medical Device Patching from a Hospital Perspective

With the rise in cybersecurity events, remediation teams have become hyper focused on patching as the primary methodology to mitigate software vulnerabilities – the faster the better. In businesses where networks are composed of computers, laptops, and servers, pushing patches centrally using automation has become operationally orchestrated to such a level that events are almost as smooth as a master composed symphony.

Unfortunately, for those hospitals trying to patch their medical devices, there is no symphony. Instead, it looks much more like a fifth-grade band class with students who just picked up their first instruments –an off-key uncoordinated cacophony in need of much more practice.

Hospitals have thousands of devices from hundreds of different manufacturers that sit on hospital networks. In some hospitals, over 50 percent of those devices are no longer supported by the manufacturer and so patches aren’t even available. For devices where patching is available, the process to get that patch from the manufacturer and install it is almost as varied as the number of manufactures hospitals have. So, let’s deep dive into what it looks like.

The first question asked – is the device supported? If not, it’s nearly impossible to even determine if the vulnerability affects that device. The manufacturers generally don’t have a team or any individuals who know these devices well enough to know the impacts of vulnerabilities. These devices require other risk mitigation methodologies to mitigate any potential impact of the vulnerability.

If the device is supported, then next we wait. According to FDA guidance, medical device manufacturers are supposed to assess vulnerabilities and notify affected parties in 30 days. Almost no manufacturer meets that guideline. Manufacturers then produce a patch (if required), assess if it needs 510k approval, and get it cleared by the FDA (if applicable). 

This can take upwards of 2 years. Although progress has been made, there is a highly variable amount of time between the disclosure of a vulnerability and the release of a patch. In the interim, hospitals are required to determine whether they want to put a temporary mitigation in place while they wait. Hospitals also need to track where each manufacturer is in the process of developing patches or else the vulnerability can be forgotten.So now a patch is released (Yeah!). The next step is to acquire that patch. Some manufacturers push the notification of patch availability to hospitals via automated emails or physical mail. Other manufacturers require hospitals to check their webpage regularly to learn a patch is released (remember thousands of devices, hundreds of manufacturers). The prospect of even checking hundreds of websites a month is daunting because that requires manual resources that are limited, and this could be a task that is automated.

Finally, a patch is downloaded and now needs to be deployed. There are few medical devices where patches can be pushed remotely. For nearly all patches, each device needs to be physically handled to upload the patch. Some manufacturers allow hospital staff to complete this task, while other manufacturers require their staff (or a third party at the direction of the manufacturer) install the patches. In either instance, the physical reality of touching thousands of devices is significantly challenging. The removal of a device from patient care also causes operational issues, which is another strong deterrent from patching. Once install and testing on every single device is complete the patching process is now complete – onto the next vulnerability!

Once the entire process is understood, the operational reality of how hard patching medical devices is becomes understood. Just the tracking of each vulnerability and where in the process each device is makes one’s head spin.

Hospitals and health care systems that have started to tackle these challenges have implemented risk ranking criteria to prioritize a smaller pool of medical devices to focus on. Although these techniques can help focus teams to highrisk areas, it still leaves devices unmitigated and networks at risk. To truly streamline patching, standardized processes to develop and deploy patches using automated mechanisms need to be incorporated into the medical device lifecycle. Centralized repositories of disclosed vulnerabilities with vendor specific patching progress need to be established, with “map to the attacker” arguments failing to be stronger than the argument for streamlining and speeding up mitigation of risk to the healthcare delivery organization. Medical device manufacturers in collaboration with healthcare delivery organizations and public/private partnerships have begun to look at these processes. Hopefully these groups will continue to collaborate on ways to enhance patching and enable the ecosystem to move more towards that seemingly effortless symphony. Until then patient safety is placed at risk due to a cumbersome and poorly aligned ecosystem – it seems we are back to band practice.