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, @02:11PM (9 children)
TFA's a repost, but since we're here again now, I can offer to answer questions. I've spent half of my whole, and almost all of my professional life, on medical devices. Mostly in the diagnostics sector, with everything from simple handheld stuff over robotics, embedded controllers and their software, embedded computers and their software, front end computers and their UI software to networking with customer IT for automated workflow.
So if there's anything you always wanted to know about the sector, ask away.
(Score: 3, Interesting) by takyon on Tuesday February 25 2020, @02:41PM (1 child)
Where are some good sources for purchasing discounted medical and lab equipment?
Are ~$100 3D-printed prosthetics or robot parts going to replace the $10,000 ones? Maybe by sneaking around FDA regulations, selling on Etsy, etc.?
What is the best/cheapest path to acquiring a robotic exoskeleton for someone who doesn't have a medical or employment need for it? One answer would be to go it alone [hackaday.com].
Is anyone talking about the "chemputer" [twitter.com]? That concept has been around since at least 2012 [theguardian.com] but seems to be getting close to reality.
What do you think of the "tricorder" [wikipedia.org] idea? Ideally, a device could scan and diagnose somebody using information from as many minimally invasive sensors as possible. This might be useful for preventative medicine since people would be willing to scan themselves daily but not go to a doctor very often.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 4, Informative) by Rich on Tuesday February 25 2020, @06:45PM
Well, I see a lot of the stuff before it even goes into proper production and hardly get to deal with used stuff in the field. Every now and then I have looked around the net what actually happens there, and search results popped up with stuff for sale. I just did a search, found a site "dotmed.com" and indeed, there's one of the devices I just work on on offer. Not sure if this is a reliable channel, though. For all lesser stuff, I'd probably try ebay. Face masks might be in short supply these days, though.
I think prices for individual things have to be seen in context. I was recently suprised how relatively cheap dental drills can be. By the time an orthopedic part for a patient has to be paid, a lot of people, doctors, orthopedics, the supply chain, already were paid, and easily so in the order of the ten grand. I don't think the grand scheme of things will change here without the whole system changing. I wrote in the pre-duplicate article that verification overhead over development is somewhere around factor 20, you get an idea where the prices come from. You'll get a milled-to-spec titanium strut for way less than the $10k from any English countryside cottage motorsport shop. So, cheap prosthetics will be DIY for the time to come. If you want it powered, it is indeed your best choice to DIY, with a bit of help from the maker scene. Some Japanese hardcore mecha cosplay otaku probably has more advanced stuff today than western industry.
Reagents and their chemistry are really far away from device developers in the industry. As a device developer you have a basic knowledge that something chemical/biological reacts in some way and the hardware can pick that up (e.g. darkens, tinges, or scatters a light beam, changes electrical resistance, or even mechanical resistance when stirred). You work from there. I know more about biochemistry from my high school days than I picked up in my professional life.
What gets talked about is specialized microchemistry, so the whole functionality of that badass quarter-ton, hundred grand, 240 samples per hour cellar lab analyzer gets reduced into a little throwaway chip with print-head technology. A simple handheld device can then do an assay profile anywhere in the world, with instant results, from just a drop of blood instead of a full tube. Given that the cost is more in the process than the materials anyway, and the advantages of speed and ease-of-use, I see this becoming important.
Initially I was thinking about such microtechnology for synthesis. I think that's a pie-in-the-sky thing, and even if it worked, would not yield the amounts of product usually required (unless you're doing stuff that works in micrograms: lsd? novichok?). On a larger scale, a lot could be done on the foundation of today's in-vitro-diagnosis technology: Storage for racks full of reagent tubes, pipettor arms, colour sensitive photometers, it's all there. You'd just have to add what misses from a human chemists lab, and you'd have your fully automatic mini-lab. Concerning efficiency and throughput, it couldn't compete in any way with specialized processes, so the main commercial market would probably be for illicit substances.
I like the thought a lot and have had my own ideas. Particularly, after I saw a video of the sensitivity of an atomic magnetometer, I've been pestering a physicist at a customer to run the numbers if a portable fixed-antenna phase-array MRT would be feasible in any way. Unfortunately he retired and now dedicates his life to the fine arts.
It's a good thing that Star Trek created a goal to aim for, and I think that over the time we will see more and more, mostly integrated with or connectable to the smartphones we have, contactless temperature bolometers, gas sensors, whatever stuff modern fitness watches have built in, and maybe even an interface for microchemical profiling as described above (look at the blood glucose over-the-counter diagnosis market to see where it heads). Machine Learning might yield good results from a spectrum of seemingly unrelated inputs; I think that will account for a good bit of tricorder magic in the future.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @05:05PM (1 child)
Whether intranetted or otherwise, is TCP/IP still the common method for telemetry to be transmitted? What about UDP?
How much extra testing, if any, do medical devices go through for security assurance?
(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.
(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]