Why fixing security vulnerabilities in medical devices, IoT is so hard

[Karlston]

Ping of death —

Why fixing security vulnerabilities in medical devices, IoT is so hard

Op-ed: It's not so easy to just patch or upgrade medical devices, IU Health's CISO explains.

Enlarge / The complex web of software and hardware components and their licensing schemes makes it difficult for healthcare organizations to upgrade or patch systems that prove to be vulnerable.

Universal Images Group / Getty Images

When your family opened up that brand-new computer when you were a kid, you didn’t think of all of the third-party work that made typing in that first BASIC program possible. There once was a time when we didn't 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/11 vulnerability, the subject of a Cybersecurity and Infrastructure Security Agency advisory issued last July, is one of those events. 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/11 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 2006 and stopped supporting IPNet. (Wind River itself was acquired by Intel in 2009 and spun off in 2018.) But the end of support didn’t stop several other manufacturers from continuing to use IPNet. When critical bugs were discovered in IPNet, it set off a scare among 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 2014, 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.

Patch economics

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 its 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 its control of the supply chain behind its devices, including the processors, and its 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 in a consumer device market, 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 the device's 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.

No easy fix

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 its Premarket Cybersecurity Guidance is a good start. It should help 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 also evolve how devices are designed and updated to match the level of support that Samsung and Apple provide. This means 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 fewer 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 the 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/11 through better processes. We need to understand how the devices work, and we need to understand that it takes a lot of work to get a patch out for devices that are more complex than a standard PC. Deploying patches to these devices also carries 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.

 

 

Source: Why fixing security vulnerabilities in medical devices, IoT is so hard (Ars Technica)  

[halvgris]

"Larger manufacturers, such as Samsung, are capable of absorbing the costs and are able to provide device updates at a lower price"

 

this is cut you need to read the post above.

 

samsung and other companies aren't able to provide support for

their devices. even on so called flag ship phones updates are only

2-3 years. it took 1 whole year longer for a european update. while

japan and usa had it allready.

 

this is google androids biggest flaw.

this is why open source benefits everyone in the long run. any of

the open source community can keep anything alive for years.

 

even if independent developers upgrade / tweak newer android

versions for unsupported mobiles it's better / cheaper for companies

to give xda devs access to company content to provide a official android

release.

 

this problem is not just mobiles and IoT it's all routers, webcams etc.