Slashdot Mirror
Two Different Studies Find Thousands of Bugs In Pacemakers, Insulin Pumps and Other Medical Devices
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.
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
Sorry to quibble... but medical devices are normally developed using a process that conforms to ISO 13485, not 9001. Pretty similar, though.
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.