This article is based on a talk that Karen Sandler of the Software Freedom Law Center gave at LinuxCon 2010.
Our software must be safe. It's in cars, voting machines, financial markets. And now it's in medical devices, which our very lives depend on.
Karen Sandler is a lawyer at the Software Freedom Law Center. She's also an activist, and--as almost all of us are at some time or another--a patient. More specifically, she discovered about a year ago that her heart is much larger than usual, a condition that may lead to sudden cardiac death. The recommended, life-critical treatment was a pacemaker/defibrillator.
The next thing she wondered about this technology seemed simple: What runs it? She asked three companies involved whether she could see the source code. Each was surprised at the request and sent her to technical support. In every case, she eventually reached a block. The dreaded, "No. It's proprietary." She offered to sign an NDA to simply see the code that was supposed to keeping her alive. The companies questioned why she would be concerned. Of course they're making software that won't fail. Of course.
Pacemakers can be maliciously hacked. The Medical Device Security Center conducted a study, resulting in the paper "Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses." From the study's FAQ:
Using our own equipment (an antenna, radio hardware, and a PC), we found that someone could violate the privacy of patient information and medical telemetry. The ICD wirelessly transmits patient information and telemetry without observable encryption. The adversary's computer could intercept wireless signals from the ICD and learn information including: the patient's name, the patient's medical history, the patient's date of birth, and so on.
Using our own equipment (an antenna, radio hardware, and a PC), we found that someone could also turn off or modify therapy settings stored on the ICD. Such a person could render the ICD incapable of responding to dangerous cardiac events. A malicious person could also make the ICD deliver a shock that could induce ventricular fibrillation, a potentially lethal arrhythmia.
In 2008, 350,000 pacemakers and 140,000 ICDs were implanted in the United States alone. Auditable software for medical devices is critical. And not business-critical. Life-critical.
Anyone who's written software understands that software has bugs. Developers try to get rid of as many as they can, but it's an inevitability. SEI estimates on average 1 defect for every 100 lines of code. Further, one study showed that 98% of software failures analyzed in device recalls would have been detected with all-pairs testing or basic multiple-condition testing.
Security through obscurity just does not work. We know this. But the medical device industry hasn't yet learned it. They need to understand that free and open code gives users the ability to independently assess the system and its risks. Bugs would be patched more easily and quickly, and it would remove the dependence on a single party.
But the FDA doesn't typically review source code. They don't even have a clear set of mandatory requirements for software, much less keep a repository of source code.
And because they don't review it, the FDA generally doesn't even ask for source code unless they have reason to think that something is wrong. That means that in large part, it's left up to the device manufacturer to choose what to report to the FDA, giving them a lot of leeway about what testing needs to be done. Moreover, because of Riegel vs. Medtronic, patients are pre-empted from challenging the effectiveness or safety of a medical device approved by the FDA.
The FDA's answer is that they don't have the resources to review every bit of every device, which is exactly the problem that opening the source could solve.
You probably know someone who relies on a medical device. And it's not unlikely that you will someday yourself need one. It's not just important. It's a life-saving project for the open source community to encourage the FDA to implement standards that protect the users of these devices from harm or death due to preventable software malfunctions.
Learn more in Karen's paper "Killed by Code: Software Transparency in Implantable Medical Devices"
Comments are closed.