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 JoeMerchant on Tuesday February 25 2020, @05:06PM (4 children)
How much "hands on" integration is required when you sell networked products into a new customer site? We're just starting to develop for that (EMR/HL7/FHIR) market and the intel we've gotten back so far is: "a lot, every site is different, it's hopeless to try to automate it, one configuration never fits more than a few..."
🌻🌻 [google.com]
(Score: 3, Informative) by Rich on Tuesday February 25 2020, @07:40PM (3 children)
That's pretty much it. Every customer is doing their own stuff and there are peculiarities with how the devices understand things. If a customer has no in-house software development and just the usual admin crew, I'd estimate an effort of anything between 2 to 20 work days to get an interfacing going - if the devices claim to speak the same protocol. If not, all bets are open.
That said, I haven't developed anything against HL7 so far, only ASTM and legacy protocols, and internal communications of a local sample handling system. I often hear HL7 being a requirement for this or that, but always because it's the "in" thing, never because "it finally gets rid of all the connectivity issues for good".
(Score: 2) by JoeMerchant on Tuesday February 25 2020, @08:17PM (2 children)
I've been bouncing off of HL7 since 1991, this is _finally_ starting to look like a commercial development and rollout of something that uses it. It reminds me a lot of DICOM, the non-standard standard - more like the "Pirate Code" guidelines really. Sort of state of the art for the early 90s when "compatible" meant 90%+ compatible, some tweaking required.
If you ever do wander into serious HL7 implementation across multiple vendors, we've found https://www.iheusa.org/ihe-connectathon-overview [iheusa.org] to be a good way to develop some level of internal confidence that "our stuff works." Too bad it's still going to need massaging in the field.
🌻🌻 [google.com]
(Score: 2) by Rich on Tuesday February 25 2020, @09:08PM (1 child)
Thanks for the lead. I wouldn't be surprised if some of my customers show up there with their stuff.
I don't like the networking and connectivity things much and generally try to avoid them - alas, coming up in two months or so I've got a set of host drivers to work on as part of a general software overhaul. I can do all that, if I need to, but it's a bit of a chore to me. I feel more at home in the lower layers. :)
(Score: 2) by JoeMerchant on Tuesday February 25 2020, @09:57PM
For family reasons I don't travel unless absolutely necessary - so, the younger staff get "experience" doing the Connectathon field work. Years ago I might have wanted to go to the European one, but I don't think I'd ever be wanting to go to Cleveland in January...
🌻🌻 [google.com]