Slashdot Mirror
FDA Wants Medical Devices To Have Mandatory Built-In Update Mechanisms (bleepingcomputer.com)
Catalin Cimpanu, writing for BleepingComputer: The US Food & Drug Administration plans to ask Congress for more funding and regulatory powers to improve its approach towards medical device safety, including on the cybersecurity front. An FDA document released this week reveals several of the FDA's plans, including the desire to force device makers to include mandatory update systems inside products for the purpose of delivering critical security patches.
In addition, the FDA also plans to force device makers to create a document called "Software Bill of Materials" that will be provided for each medical device and will include software-related details for each product. Hospitals, healthcare units, contractors, or users will be able to consult the medical device's bill of materials and determine how it functions, what software is needed for what feature, and what technologies are used in each device.
In addition, the FDA also plans to force device makers to create a document called "Software Bill of Materials" that will be provided for each medical device and will include software-related details for each product. Hospitals, healthcare units, contractors, or users will be able to consult the medical device's bill of materials and determine how it functions, what software is needed for what feature, and what technologies are used in each device.
Seems like a nice way to legislate backdoors into all devices with the added bonus of an increased attack surface... if I had a pacer maker than could get over the air updates, I'd not want to be worried that an attacker could push an update. I'd have to live my life inside of a Faraday cage to even feel somewhat safe.
All those medical device manufactor have so much know how on what to do (digital signatures, encrypted communications), let's add firmware update to the list. They can call it "secure firmware update" (because the protocol is secret, which makes it secure!). Well no, scrub that, simply make it illegal to hack devices, much cheaper than security...
The only thing that scares me worse than insecure proprietary bullshit that can kill people is people who don't understand technology trying to legislate insecure proprietary bullshit that can kill people.
I'd rather have a device with no external connectivity than one that has external connectivity because one is needed by the upgrade mechanism.
That just adds a vector for attack where there was none.
It's too bad that you need this to be up 20 hours an day as the max you can set active hours to is 18 or 12 (server 2016) too bad and read the EULA we don't have to do shit.
the desire to force device makers to include mandatory update systems inside products for the purpose of delivering critical security patches.
First of all, why does every damn thing have to be able to connect with your phone/internet. Unless there's a damn good reason, I don't know why you would want to introduce security holes in a device that is keeping you alive. I suppose it's convenient to have your pacemaker app on your phone giving you live updates about how well it's working so you can post it to Facebook or something. But not if it means that anyone within range can turn the thing off, or cause it to malfunction.
Any manufacturer that has released an device that a malfunction could cause a lethal event with wireless access with a hard coded password should be fined a lot. And pay for whatever surgery and device is needed to remedy this. Additionally, they should pay the patients for their time and recovery. Just how incompetent are people that make these things? Gee, WiFi and Bluetooth. No one would ever think to try to connect to something like that. I mean seriously, hard coding "1234" or "password" on an implanted defibrillator or and insulin pump?
and teach that poorly done copy/paste bot to get some better sources for his regurgitated press release "news"?
Say
in market (small area) $1/meg
out of market (In state) $5/meg
out of market (out of state) $10/meg
Canada / Mexico fringe roaming $11/meg
Canadian roaming $20/meg
Other $50/meg
Cell at sea $60/meg
----
In Lockup free to you
3rd party vendors must let hospital have full os update control and no forced open 24/7 links to the outside.
You hospitals think that the ransomware attacks you've been dealing with are bad now? Just wait until you've got criminal assholes hijacking all the OTA-updatable medical devices in your entire organization -- with a couple random people 'accidentally' dying of intravenous drug overdoses or their ventilators being bricked, just to show that they're serious and that their demands should be met promptly. Stupid, stupid, stupid! There is no possible way they can adequately secure such devices. They should require physical access to the device, NEVER wirelessly.
to this one, he'll be able to upgrade to a rat brain after?
1. My pacemaker BSOD'ed during a firmware update.
2. My insulin pump gained an attack vector.
3. I can now co-pay for software updates to my oxygen tank.
4. My GPS-assisted wheelchair didn't know there was construction on Main St. and now I'm stuck in 6" of concrete.
5. The same gov't that runs the DMV has the ability to decide what happens to my dialysis machine.
I'd rather have a device with no external connectivity than one that has external connectivity because one is needed by the upgrade mechanism.
That just adds a vector for attack where there was none.
And I just updated my Buffalo network drive with the latest firmware and now it's flaking out. Point: upgrades aren't so good all the time.
That'd be so great if a pacemaker were to be upgraded and start pounding hearts!
My worry is that vendors of devices update the software for equipment that requires training. An OTA update WILL change how a device works.
Hospital staff may or may not notice, and then even if they notice, who has time to figure out which devices have changed their behavior.
The article makes no mention of remote updates, let alone wireless ones. A physical port inside the device (perhaps behind a locked panel) makes sense for most devlces. If the device is already remotely accessible in any way (eg to allow a physician to plug into it and recover health data) then it potentially needs security updates. If not, then being able to apply a (suitably checked and signed) firmware update with a special cable may avoid the need for surgery and/or an expensive replacement device. Assuming they get the details right, this sounds sensible.
I wonder if the elite will get smart medical devices implanted into themselves.
I'm gonna guess no.
Experience shows that the Microsoft mandatory updates ALWAYS make things much better and NEVER cause problems! FDA, now bringing new meaning to the phrase "Blue screen of death"! Ack! They automatically updated my pacemaker! Will anybody with a computerized medical device now be forbidden from going out of WiFi range?
I've abandoned my search for truth; now I'm just looking for some useful delusions.
kids: dad what happened to grandma?
dad: well kids...shes gone to a better place
mom: dad flashed a rom to her pacemaker with the wrong binary architecture
dad: Its more complicated than that kids, Grandma was one SMA antenna away from being able to route our IPv6 traffic so we can use faster fortnight servers.
kids: is grandma in heaven?
Dad: more importantly, does daddys toolchain documentation cover the insulin pump in grandpa....
Good people go to bed earlier.
3rd party systems in an hospital with old oses that don't get updated is the real issue.
No F'n way I am letting my insulin pump be auto-updated. Period.
The medical industry doesn't need mandatory updates. It's the electrical grid's control systems with their SCADA controllers that are always connected to the internet (even though they shouldn't be) that need mandatory updates.
I worked at a medical company that "unlocked" premium features by cutting out a resistor that the software checks. Will that be on the BOM too?
That is the real question. Funny how spending money US Federal Government doesn't have isn't even a question anymore.
The IETF actually has a Working Group (WG) looking at this, Software Updates for Internet of Things (suit):
* https://tools.ietf.org/html/draft-moran-suit-architecture
* https://datatracker.ietf.org/wg/suit/documents/
I worked for a medical devices company for a couple of years, one of the big players on the global stage, and I can tell you that before we worry about including methods for updating critical software issues, we need to first focus on getting companies to put patient safety back before profits and share price.
These are just examples that I personally saw. Let's just say for example that to go from an idea in someone's head to a finished product, it will require $1m and take 1 year if you give the lead engineer everything they want. These numbers are representative and chosen because they are easy to work with. It's also assumed that these numbers are the bare minimum needed to do the job effectively, not padded in any way. So right out of the gate, the budget for the instrument might be set at say $800,000 and the release date is set for 10 months, plus the lead engineer might only get 90% of the manpower needed. As the project progresses, the budget will be steadily slashed, manpower diverted to newer projects, and the timetable moved up. So the engineer in charge is constantly scrambling to get everything done, and most of the time the initial product is being built with a number of "deviations" from what is reported to the FDA, and it's a crapshoot whether or not any of those deviations will be cleaned up.
I personally saw a case where an IVD (clinical use) instrument was released, then a near-identical RUO (research only) model was released. The very first units of the RUO model came back as DOA. Turns out they were using the blue laser in the device at a slightly different power level than the IVD model, and it was causing the lasers to blow out. You don't need to be an engineer to figure out that this is the sort of thing that would have been caught during testing... if the engineers had been given sufficient time to test units before shipping them out. I was speaking directly with the engineers involved as they were having a meltdown. They were counting on having a couple of weeks to be able to set up all the service and repair parts, then the very first units started coming back DOA almost immediately, so I had to help them triage the situation.
There was another case where the company launches what is supposed to be a new flagship product and allows people to carry the instrument with them into remote regions. My coworkers and I were still literally finishing up some of the FDA REQUIRED work when they started the launch party down the hall from us... and we weren't even on the invite list. A customer had threatened to cancel a large order if they didn't take possession of the units by a specific date, and the only way to meet that date was to push up the release date of the entire instrument by around two weeks. Since the company chose to ignore the fact that the WHO was phasing out the primary test this instrument did, it was almost immediately abandoned by the company.
I was also personally in a meeting where the lead engineer of a product was very nonchalantly talking about how they were going to build a couple of prototype units, and then they would ship those to customers who were complaining about how long their orders were taking. Not that they would bother telling the customers they were getting prototype units, which are intended to help find and work out any kinks in the manufacturing process. It was also against company policy to sell prototype units, and part of that is because all of the FDA mandated documentation hasn't been finalized at that point. Turns out the sales department had been making all kinds of wild promises about delivery dates to customers to make their quotas, and then the leadership expected the engineers to be able to meet these ridiculous dates so they didn't lose that revenue.
I know of an IVD instrument that was released over the objections of the lead engineer, who tried to tell local management that the instrument still had fundamental design flaws that needed to be worked out. I was in a meeting in a conference room near the production floo
I maintain medical equipment for a living.
The comments to this story are so full of head-up-tailpipe pontificating it makes my head spin.
Trust me, this would be a good thing.
The medical industrial complex has "other" ways of dealing with security vulnerabilities. Just ask Barnaby Jack.
Wow. Definitely don't want to be getting critical care in the hospital on the new medical device's equivalent of update Tuesday.
what could this hurt >>>update>>>
-Phone rings
IT: "IT how can I help you"
Doctor: "The medical devices are pushing all the medicine into the patients at once"
"Half are dead now"
IT: "have you tried disconnecting the intravenous tube from their skin"
Doctor: "your missing the point"
IT: "I'm sorry to hear that, Let me transfer you to level 2 support"
IT L2: "I have remote into the device and have turned down the dosage"
Doctor: "You do realize that patient has been dead for 15 min now"
IT L2: "I'm sorry let me quickly transfer you to Level 3 support"
IT L3: " have you turned the device off and on again?"
To be honest though, the day I've had taking calls because of a GPO update changed firewall settings (windows firewall on the laptops) and kicked a bunch of our users from having the ability to connect to networks remotely. Was not expecting that today.
thought mandatory hacking mechanisms immediately right?
Drive by heart attacks. Malware asking for payment by bitcoin within 24 hours or you will die.
Evil idea as government rarely does anything well.
Even at best mandatory Windows updates are making me lose productivity at critical time. Quite a few times they crash. I don't want any of these in a pacemaker. I also don't want to have to walk in a Faraday cage if government or hackers are out to get me. Actually, keep all the radios off unless activated by means like a magnet that can not be easily faked from a distance.
Windows is installing update 17/67. Please do not reboot your pacemaker or die during this process ...
of bricking your pacemaker. Your next of kin can rest easy in the knowledge that we've all learned something here.
Implantable medical devices require extremely near (centimeters) field communication and have extremely complicated encryption mechanisms. Moreover the FDA, AMA, and the courts have long ruled that once a medical device is implanted it becomes "legally" part of the persons body and is thus no longer anyone (or anything) else's property. Tangible or otherwise. Moreover, modifying a device once implanted is still considered a "surgical" procedure. Meaning, they know full well changing settings could "brick" the device and cause a problem that would cause risk to the patient. Doctors (well, surgeons anyway) are smarter than this.