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 Rich on Tuesday February 25 2020, @07:26PM
There are two "telemetries" to consider. One is the connectivity of a device to a host of its owner (e.g. a hospital's IT schedules assays over a number of available analyzers for different things). The other is phone-home logic to the vendor.
The first thing has mostly been a serial-interface connection with a de-facto standard called "ASTM Protocol" for ages. Then, there is a newer thing called "HL7", or the upcoming "FHIR", which I haven't worked with yet. These protcols don't really define their transport, but especially for HL7, TCP transport seems to be preferred.
Phone-Home over TCP is an entirely different thing and hasn't been in any devices I've been working on. If it was, I'd assume, there would be an encrpted VPN tunnel between the device and the vendor, and it would be used to read out troubleshooting data and transfer (signed and checked) updates onto the device. I've also heard from a vendor that they are setting up their kind-of-App-Store for such updates, so that may not be tunneled. YMMV.
UDP never was a deal. It doesn't fit with any of the text-stream protocols, and on lower layers it has no use because it is not guaranteed. CAN is used for packet messaging between device components.
It is part of the overall process. For legacy devices, security development may be separate from the functional (that might have gone on since the pre-internet age). There is a developer (or more) responsible for the hardening of the platform, and test cases get written and verified to make sure that all this works as intended. However, those test cases have clear expectations, so they won't cover what a good hacker can achieve. In the later course of development, an audit may (or may not) take place, where a "good hacker" (i.e. a corporate script kiddie) tries an attack, but unless he is successful, you'll never know how good he really was. Generally, the devices should be pretty safe on a system level, because they limit the attack surface, but I'm pretty sure a nation state actor could, after analyzing the applications, root many of them by exploiting flaws in the application protocols.
At the moment, the big issue in the "data protection" sector is implementing the GPDR limitations, though.