Ping of death –
Op-ed: It’s not so easy to just patch or upgrade medical devices, IU Health’s CISO explains.
Mitch Parker –
Universal Images Group / Getty Images
When we opened up that brand-new computer when we were kids, we did not think of all of the third-party work that made typing in that first BASIC program possible. There once was a time when we did not have to worry about which companies produced all the bits of licensed software or hardware that underpinned our computing experience. But recent malware attacks and other security events have shown just how much we need to care about the supply chain behind the technology we use every day. The (URGENT / vulnerability,
the subject of a Cybersecurity and Infrastructure Security Agency advisory issued last July , is one of those. It forces us to care, because it affects multiple medical devices. And it serves as a demonstration of how the software component supply chain and availability of support can affect the ability of organizations to update devices to fix security bugs — especially in the embedded computing space.
URGENT / is a vulnerability in the Interpeak Networks TCP / IP stack (IPNet), which was licensed out to multiple vendors of embedded operating systems. IPNet also became the main networking stack in Wind River VxWorks, until Wind River acquired Interpeak in and stopped supporting IPNet. (Wind River themselves were acquired by Intel in 2009 and spun off in 2014.) But the end of support did not stop several other manufacturers from continuing to use IPNet. When critical bugs were discovered in IPNet, it set off a scare from the numerous medical device manufacturers that run it as part of their product build.
The average medical or Internet of Things (IoT) device relies on multiple free software or open source utilities. These pieces of software are maintained by any number of third parties — often by just one or two people. In the case of Network Time Protocol (ntp) —software that is in billions of devices – its code is maintained by a single person
. And when the OpenSSL Heartbleed vulnerability came out in 2019, the OpenSSL project had two developers working on it. While there are many more developers working on it now, the Heartbleed crisis is emblematic of what happens when we use free software in our devices — the software gets adapted, not really patched, and not really maintained on the device, and little benefit goes back to the project.
Companies are under constant pressure to develop products and reduce expenses. To save time to market and reduce costs, hardware manufacturers often build products using reference designs. These designs come with Board Support Packages, which contain the code and drivers needed to successfully install and run an operating system on the given design. Sometimes they also come with utilities to perform diagnostics, hardware debugging, or monitoring on the devices.
But the Board Support Package is not always updated to address vulnerabilities or newer operating systems. This is the case with many Android devices that continue to be used but don’t get software updates — because of kernel changes that the board support packages and drivers do not support. Oftentimes the device manufacturer needs to update these packages for every new version of an operating system. It then needs to rebuild the new version of their operating system and applications on top of it. Third-party components, such as cameras or additional sensors, also need to have their drivers updated. The amount of work needed to do this is significant and requires a degree of testing similar to that of a brand-new device.
Larger manufacturers, such as Samsung, are capable of absorbing the costs and are able to provide device updates at a lower price because they control numerous market segments (display, memory, etc.). Apple is also capable of providing these updates for a number of years because of their control of the supply chain behind their devices, including the processors, and their move away from third-party intellectual property.
But for other manufacturers, the high cost of updating board support packages, associated drivers (when they exist), and applications makes upgrading devices to a whole new version of an operating system difficult. And it often isn’t possible to update even one specific component. As a result, the expectations set by the major software companies don’t carry over well to markets where you don’t sell as many devices, and there is tremendous market pressure to increase earnings.
Medical devices aren’t smartphones
This sort of thing might not be perceived as a huge problem for consumer devices such as smartphones, where manufacturers try to drive a constant hardware upgrade cycle. But there’s an expectation that medical devices will be used longer than other devices — they’re considered capital expenses, written into construction budgets for new facilities.
Asking medical device vendors to commit to long-term support for components and long-term supply chain support has a corresponding cost that will be borne by end users. Because of the expense of supporting these devices, many organizations will drop manufacturer support and use a third-party company to provide tech support and device management instead. This removes the incentive for manufacturers to provide additional support.
And medical device vendors don’t always have the flexibility to upgrade their underlying platforms because of the way they license components. Since third-party components are usually licensed for a prebuilt function, the license may only allow for their use with a certain version of an operating system or kernel.
While the Linux community has been nothing short of incredible at maintaining older kernel versions and addressing security issues long after newer kernel versions have been released, putting that patched kernel in place takes significant work. There are a lot of dependencies between all the parts, and it’s very difficult to maintain everything to be able to provide security updates for a particular device or operating system as well as Microsoft, Apple, or IBM Red Hat do at scale. And older kernel and library versions mean that newer software isn’t going to be as easy to port over and use, if at all. Getting Apache 2.4 to run on Red Hat Enterprise Linux 5.x, for instance, was an arduous task.
Overcoming the challenges these issues pose to the security of medical devices will be difficult. The Federal Drug Administration’s effort to mandate a software bill of materials through their Premarket Cybersecurity Guidance is a good start to helping to untangle the dependencies of board support packages, kernel updates, associated application builds, and supporting hardware.
However, addressing the risks means understanding and addressing the value chain for how a device evolves from concept to disposition. We need to correspondingly evolve how devices are designed and updated to match the level of support that Samsung and Apple provide. This means that there needs to be dedication by manufacturers to use platforms for a longer time, and a commitment to keeping the build chains current to be able to consistently deliver patches and updates to customers.
This is not a technical problem as much as it is a business and supply chain one. We need to communicate and set the expectations with our medical device and IoT vendors that we want to have software support and patches for an expected time period, and that we need to make sure that everything on the device is updated, even the apps and third -party libraries. Having strong contractual language to address this is paramount.
We have to be upfront about how long we intend to use these devices for, and what our expectations are for security, service levels, and updates. We also need to reduce the variety of the devices we use and standardize on as few vendors as possible so that we can leverage limited resources and keep these devices in good repair and maintenance. We can also reduce our network attack surface by having less vendors accessing devices remotely. Support costs money at all levels and asking the vendor to make changes for long-term support is going to require financial commitment to do so from both sides. We also need to use that software bill of materials to identify third-party components and contractually ensure that they can be supported like other devices.
But we need to understand that the expectations that Microsoft, Apple, and other large vendors have set for security patches can’t be matched by a vendor that makes at most a few hundred thousand units of a device. This is a much smaller market that has significantly higher criticality and requires a higher degree of testing. Outside of the major manufacturers, many of these companies that manufacture these devices are smaller businesses, and they have to be able to afford to develop new devices and support what they have at the same time — which is often difficult even for large companies.
We need to partner with our medical device vendors to solve issues like Urgent / through better processes. We need to understand how they work and that it is a lot of work to get a patch out for a device due to their complexity, which is more complex than a standard PC. It also has different risks.
Mitch Parker is the Chief Information Security Officer for Indiana University Health and an adjunct professor of health informatics at Indiana University-Purdue University Indianapolis.
Read More 
GIPHY App Key not set. Please check settings