Two Different Studies Find Thousands of Bugs In Pacemakers, Insulin Pumps and Other Medical Devices 47
Two studies are warning of thousands of vulnerabilities found in pacemakers, insulin pumps and other medical devices. "One study solely on pacemakers found more than 8,000 known vulnerabilities in code inside the cardiac devices," reports BBC. "The other study of the broader device market found only 17% of manufacturers had taken steps to secure gadgets." From the report: The report on pacemakers looked at a range of implantable devices from four manufacturers as well as the "ecosystem" of other equipment used to monitor and manage them. Researcher Billy Rios and Dr Jonathan Butts from security company Whitescope said their study showed the "serious challenges" pacemaker manufacturers faced in trying to keep devices patched and free from bugs that attackers could exploit. They found that few of the manufacturers encrypted or otherwise protected data on a device or when it was being transferred to monitoring systems. Also, none was protected with the most basic login name and password systems or checked that devices they were connecting to were authentic. Often, wrote Mr Rios, the small size and low computing power of internal devices made it hard to apply security standards that helped keep other devices safe. In a longer paper, the pair said device makers had work to do more to "protect against potential system compromises that may have implications to patient care." The separate study that quizzed manufacturers, hospitals and health organizations about the equipment they used when treating patients found that 80% said devices were hard to secure. Bugs in code, lack of knowledge about how to write secure code and time pressures made many devices vulnerable to attack, suggested the study.
This is a surprise how? (Score:5, Insightful)
Love to hear from one of the programmers who programmed one of these things, hear what they have to say.
Re: (Score:1)
The cost of the software development is probably negligible compared to the cost of regulations.
Re: (Score:2)
Which in turn is probably negligible when compared to the 5,000% markup imposed by the medical device manufacturer...
Re: (Score:2)
They don't find software/firmware fun. But companies want universal geniuses that do medical device HW design (not an easy task) and, well, write the FW as well, because they don't want to pay additional people to do it.
Re:This is a surprise how? (Score:5, Informative)
I used to program pacemakers. You are wrong that these are the cheapest programmers they could find, and in general about your assumptions as to how the industry works.
The medical industry doesn't work that way, at least for life-critical, highest-risk medical devices like pacemakers and implantable defibrillators. If a company operated as you describe, the FDA would shut it down very quickly. The pacemaker company I worked for hired highly skilled people, and used an internal software and hardware development process that makes the other software companies that I have worked for look like a bunch of amateurs by comparison. ISO 9001 compliance and FDA certification is no joke. There were detailed reviews at every level of the software development process: proposal reviews, system design reviews, detailed design reviews, code standards, code reviews, detailed regression tests, near-100% branch coverage (not just statement coverage) by regression tests, static analysis tools, simulation, animal testing, and so forth. It is quite focusing to realize that a coding mistake on your part may very well lead to someone's death.
Also, the industry is incredibly conservative, since every change, no matter how trivial, has to be justified to the FDA as to why it won't make a device unsafe. At the time I left, about 15 years ago, they were still using a DOS clone in their pacemaker programmers (basically a device that allows a doctor to download a set of configuration parameters into a pacemaker using something that looks like a mouse placed on the patient's chest) because Windows was too poorly understood as to its runtime characteristics (especially with regards to reliable real-time behavior, memory allocation, and interrupt behavior), and too poorly controllable to be trusted, especially as we couldn't get source code for it. (Note: something like Linux has most of the same problems. We were looking into the possibility of using QNX in the future, which looked more promising.) Still, while in that industry, I rarely worked with technology that was less that 10 years old, because it was assumed that in 10 years time, most of the bugs in the technology would have been known and documented, and understood as to their impact. This applied to hardware, operating systems, and development tools. Having tools be reliable (or at least unreliable in well-understood ways) was considered more important than having them be cutting-edge.
However, that elaborate software process was geared towards patient safety in the face of ordinary threats such as misconfiguring by physicians, low battery brownout scenarios, bits being twiddled by cosmic rays (Yes, really! We took precautions for this!), stray magnetic or electrical fields, unexpected patient heart behavior patterns, and so forth. Many, many precautions ("risk mitigations") were taken for events such as these. Deliberate hacking by outsiders was not really a concern on anyone's mind, particularly since to do so would have required close physical contact (due to one of the aforementioned risk mitigations, which I am not going to go into the details of), and so the data transmission protocols were geared towards detecting errors due to mistransmission or data corruption, rather than ones due to deliberately constructed valid-but-evil data.
Still, the close physical contact requirement would make it fairly difficult for someone to hack one of these devices in most practical scenarios. I don't see it as much of a threat. If someone is close enough to download a bad configuration into a pacemaker, they are close enough to do much more simple and direct harm to that person, which would be vastly easier to do. I can imagine very convoluted scenarios in which someone could try to perform murder-by-pacemaker, but realistically, there would usually be much more simple and reliable ways that wouldn't require stealthily breaking into a company to steal their specifications, or reverse-engineering their hardware and software. It's just too much effort for even a nation-state
Re: This is a surprise how? (Score:4, Informative)
Sorry to quibble... but medical devices are normally developed using a process that conforms to ISO 13485, not 9001. Pretty similar, though.
Re: (Score:1)
I used to program pacemakers. You are wrong that these are the cheapest programmers they could find, and in general about your assumptions as to how the industry works.
The medical industry doesn't work that way, at least for life-critical, highest-risk medical devices like pacemakers and implantable defibrillators. If a company operated as you describe, the FDA would shut it down very quickly. The pacemaker company I worked for hired highly skilled people, and used an internal software and hardware developm
Re: (Score:2)
Re: (Score:2)
That's an issue with your creativity
How do you even connect to it?
The same way the doctor connects to it for things like status queries, configuration changes, etc.
And you're right, not wifi.
Re: (Score:3)
This isn't how it works.
Firstly, they discovered microcontrollers about thirty years ago, so that's not really new.
Secondly, they just make the same mistake many other companies do - they want one person that does hardware and firmware development (check some job postings), because that saves money (haha). Which is bad. Someone who's excellent at analog an
Re: (Score:2)
The really small implants surely use an ASIC with embedded microcontroller, rather than an off the shelf discrete microcontroller and all the other stuff in the ASIC. In which case, the power consumption excuse for not running encryption (it needs too much processing horsepower) doesn't cut the mustard. Intel designed instructions to speed AES processing (AES-NI) https://en.wikipedia.org/wiki/AES_instruction_set/ [wikipedia.org]. It's a design time, design cost issue, and sheer arseholiness for companies to claim that it
Re: (Score:2)
Using encryption uses more power than not using encryption. And the more power the device uses, the more often you need to cut holes in the patient to replace it. Most patients don't like that part. And encryption doesn't just use power through CPU usage, it also requires more RAM and possibly flash than no encryption, and both memories also draw power.
Also, consider
Re: (Score:2)
Please keep your sexual fantasies to yourself. We're not interested in hearing about them.
Re: What OS do they run? (Score:2)
is there a Darwin Award here? (Score:2)
Overly complex (Score:4, Insightful)
Honestly, if you have 8000 bugs in your system then you haven't just done a bad job of securing your code, you have done a bad job of architecting your software and hardware. Bottom line, they should fire the people in charge of designing this shit and everyone in management who pushed these devices out before they were ready. Alternatively, start holding individuals inside corporations personally liable for things like criminal negligence and you'll find devices will get properly secured instead of being pushed out the door.
Re:Overly complex (Score:5, Informative)
May I suggest you read the paper first before heading off on a rant?
Basically all of the 8000 vulnerabilities (not bugs) are due to third-party libraries used in one of the components examined, which include "home monitoring devices" and "physician programmers", both systems that probably run Linux/Windows and hence inherit a lot of vulnerabilities from there.
The eeee-vil free market at work (Score:3)
If the FDA had to approve all these devices, even at the cost of making the price of everything exorbitant, their rigorous testing would ensure that the firmware wouldn't be riddled with all these bugs.
Oh, wait --
Re: (Score:2)
Re: The eeee-vil free market at work (Score:2)
The FDA doesn't actually do testing. The device maker supplies evidence that development followed a process that includes testing, the types and amounts of testing being based on the risks posted by the device.
A company can potentially lie, and claim they did testing that they didn't - but Goddess help you if FDA figures that out: you're in deep, deep trouble. And they can definitely figure it out during a regular inspection, or if people get injured by your product, etc.
Re: (Score:2)
Certainly, but the FDA is supposed to manage a testing process that assures, in a case like this, that ISIS wouldn't be able to pull a trick like setting off all the stimulating pacemakers (the kind that can actually reboot a failing heart) in Hollywood right in the middle of Academy Awards night.
Money, its all about making money! (Score:3)
Re: (Score:2)
Assassination Vector (Score:2)
No question the CIA knows all about these bugs, this vector is an ideal assassination technique. Just think if they had this tech in the 60's and Fidel had had a pacemaker or other medical device like one of these. The bar for political assassinations for Western nations has risen (a little), but the Russians would be all over this as well.
As it happens... (Score:2)
I'm working with some other folks to start a company to develop, manufacture, and market open-source medical devices. We all have extensive experience in developing commercial medical devices - defibrillators, radiation therapy for tumors, etc - and we're convinced that getting more eyeballs to review software and hardware will substantially increase safety and reduce costs.
Yes, we know how to work with the FDA and so forth.
Stay tuned...
Open source? (Score:2)
You say open-source, but will your organisation commit explicitly and non-retractably that ALL the code and hardware (including any ASIC HDL) will be published in a way that any individual can duplicate any design independently without agreeing to any contract, such as NDA?
In which case, how does your business model work?
I find the questions at the end of the study funny (Score:4, Interesting)
So how is the manufacturer supposed to diagnose devices that malfunctioned out in the field? If you lock the debugging interfaces, they can usually only be reactivated by completely clearing the devices flash memory - or even not at all.
Are third-party libraries used in software development?
What kind of question is that?
Ok, I've seen code without any third party libraries. It was all assembly, only available in hardcopy, written for an 8051 and about 30 years old.
Is the firmware image for the implantable cardiac device mapped into protected memory to prevent arbitrary writing to memory addresses?
I would guess the implantable device doesn't use a microcontroller beefy enough to have an MPU. That would reduce battery lifetime.