SoylentNews is people
SoylentNews
from the don't-add-them-to-begin-with dept.
Why fixing security vulnerabilities in medical devices, IoT is so hard:
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.
The S in IoT stands for Security
(Score: 2) by Immerman on Tuesday February 25 2020, @04:29PM (2 children)
>For a device that requires either periodic log monitoring or needs to be reprogrammed, using the Internet is going to be nearly inevitable simply on cost/benefit grounds.
Fine, but again, why is the device connected to the internet?
Use a second, external device as an intermediary that connects to the internet, and communicates with the medical device via a simple, easily auditable wired or short-range single channel serial communication protocol with the absolute minimum of functionality necessary. Any software or setting updates must be cryptographically signed, with the signature checked immediately after the data has been transferred to the device, before the data is even looked at.
You're talking medical devices with multi-thousand dollar price tags. Even a full-fledged Raspberry Pi based intermediary is barely going to nudge the price tag.
(Score: 1, Informative) by Anonymous Coward on Tuesday February 25 2020, @05:01PM (1 child)
Why? Because using the internet as the transport via VPN is much more economical than requiring modems and land lines. It means not having to re-invent the wheel to figure out how the data gets from A to B. It might be nice to develop a separate network but not necessary to.
OK. So the device is separated from the reporting mechanism. Most intra-body devices have to be anyway. But having any intermediary then adds the risk of all the potential compromises that the intermediary may encounter as well. While "only" having your device data compromised is a lot less destructive than allowing an attack on the actual therapeutic modality, it's still an unacceptable risk as well.
And yes, "minimum functionality necessary," sure. But what are the minimum functions? Do they include changing parameters on the device? If not, fine, but very few medical devices are created without the need to change settings. And not requiring the person to take the device somewhere is part of the risk-benefit analysis in terms of healthcare cost as well. (Not to mention the times when it may be determined that a device firmware does contain a flaw. Being able to reflash a device without having to cut it out of the person is certainly more preferable from an infection control standpoint).
(Score: 3, Interesting) by Immerman on Tuesday February 25 2020, @08:33PM
I won't address the first part, since my previous post already accepted that the internet will be involved at some level.
> But what are the minimum functions?
Primarily, receive a file and verify that the digital signature is valid.
Once you've done that, then you can do whatever you want with the contents of that file - Is it a settings file? Apply the settings. An update? Apply the update. (Though really, updating the software on a medical device should be done in a medical setting where correct functioning can be confirmed, and the patient can get emergency care in case of any malfunctions)
So long as the patient don't have to adjust the settings themselves (as is generally the case for medical devices), you've just made sure that the *only* way to compromise the device, is to compromise the digital signature. It's not perfect, but nothing is, and it dramatically reduces the attack surface. A simple serial interface is several orders of magnitude easier to audit to ensure there are no exploitable I/O flaws than an internal TCP/IP stack, hardware drivers, etc.