As devices age, their software becomes increasingly vulnerable to cybersecurity threats. Patching these vulnerabilities is critical, but it isn’t always easy. For example, smaller and lower-power medical devices are often not compatible with conventional IT strategies.

HealthCare Business News sat down with Sagar Patel, cybersecurity software engineer at Battelle Memorial Institute, to discuss these challenges and what HTM departments can do to keep themselves protected.

HCB News: It seems that every year we see a greater emphasis on medical technology software cybersecurity. In what ways does an aging technology fleet create vulnerabilities?
Sagar Patel: There are multiple factors that come into play when considering vulnerabilities associated with an aging technology fleet.

One is legacy software. A major chunk of devices that have been in market for more than 5 to 10 years do not have software update capabilities, and if they do, the updates are rarely made. These devices have been running old and vulnerable code, which may include both proprietary code and third-party dependency code.

Another is lack of end-of-life guidance. Traditionally, medical device manufacturers have not dictated an end of life for their specific products. In such scenarios, the customers keep on using the devices many years beyond when they should have been retired due to lack of updates or security issues. The landscape here is changing, and more and more manufacturers are providing end of life guidance with their devices when they are sold.

Proprietary protocols / security by obscurity are additional factors. Historically, a lot of medical device manufacturers relied heavily on proprietary communication protocols or proprietary authentication schemas, which hadn’t been verified to be secure. This sort of security can be relatively easily reverse engineered to find security vulnerabilities within them.

A major chunk of software running within any medical device relies on third-party libraries. Oftentimes these libraries become deprecated or aren’t updated to protect against emerging security vulnerabilities. Hence the medical devices inherit the vulnerabilities from the third-party code they are using. Lack of regular software patches adds to this issue and exacerbates it.

Finally, lack of regular updatability has been a security weak spot. Until now, a lot of medical devices have been designed without keeping regular updatability in consideration. This has led to irregular updates, if any, and allows for medical devices to become hotbeds for security vulnerabilities, and could be misused as a pivot to target the network they are connected to.

Usually it is a combination of these factors that causes the security issues to exacerbate and become difficult to manage.

HCB News: When we think of software patches, major capital equipment often comes to mind, but do security issues also exist with smaller medical devices?
SP: A great deal of capital equipment relies on widely used operating systems like Windows or Linux, which have software update capability built in, so the issues caused by lack of updatability are less prevalent in those systems. Whereas a lot of smaller medical devices either rely on custom RTOS (real time operating system) or have a proprietary embedded application running on them, which does not have built-in software updating capability. This has caused the majority of older, smaller medical devices to have vulnerabilities in them that remain unpatched.

On the other hand, a lot of these devices used to be non-networked. Hence the security attack vectors impacting large capital equipment didn’t affect those non-networked devices. In other words, they couldn’t be remotely attacked easily due to lack of connectivity, so large-scale attacks were practically impossible. But as more of these smaller devices get networked and have connectivity, it has become important to have software updating capability.

HCB News: How do smaller devices present unique challenges? Can you share an example?
SP: Smaller devices have different risk posture depending upon their use case scenario. Implantable devices, for example, can have a high risk profile but if they are not connected then the probability of an exploitable vulnerability diminishes. Furthermore, smaller devices face unique challenges in terms of technical capabilities to support security controls; lower processing power, lower memory availability and lower battery capacity.

An example where these issues come into play is cryptographic algorithms being used for encryption-decryption and authentication since these algorithms are mathematically expensive, hence, resulting in greater battery and processing power usage than some of the smaller devices could sustainably handle.

Another facet where the difference between large equipment and smaller devices is highlighted is their prevalent use case scenarios. Typically larger devices are used for diagnostics, whereas smaller devices like an insulin pump or a pacemaker, are used for delivering treatments. Hence, the impact of a security issue in larger devices may cause false diagnosis, whereas in smaller devices like a pacemaker it could severely harm the patient. So the cause and effect are delayed in large equipment versus immediate in smaller devices when it comes to exploitable security issues.

HCB News: At what point do software patches become a facility's concern rather than the concern of the device manufacturer?
SP: Patching of software is a shared responsibility, where the manufacturer’s task is to create the patch, validate it, and effectively communicate it to the devices/healthcare delivery organizations (HDO). The demarcation in responsibility can be made when HDOs have stricter controls over the software update being delivered to the devices on their network, (i.e., a manufacturer may produce and validate a patch, but HDO may allow it to get to the device during specific time periods only).

It is recommended that HDOs create and maintain a standard operating procedure (SOP) for when patches are made available from the manufacturers. Such an SOP should ensure that the manufacturer has validated the patch, ensure that the patch only gets delivered to devices when they are not actively being used, and ensure that if a subsequent issue emerges due to an update, it can be escalated to the appropriate team within HDO and the manufacturer organization, and they will work toward fixing it.

HCB News: Are there any first steps or key resources for HTM teams setting out to secure a software patch for legacy technology?
SP: Communication with medical device manufacturers is paramount when it comes to patching a legacy device/software that has a vulnerability. Additionally, the HTM teams should plan for end of life scenarios when software updates are no longer supported or available from a manufacturer for a specific device. In scenarios where a software patch is available from the manufacturer, the HTM teams should ensure that the manufacturer has validated the patch before rolling it out to the devices.