> 1> Loss of competitive advantage
Patient safety trumps business considerations. Skipping clinical trials would be a major competitive advantage (lower costs, quicker to market etc.), but we don't allow that for the same reason
> 2> Open source is not necessarily any safer (heartbleed bug ... )
I'll agree, in so far as saying making it open source doesn't necessarily make it safer. However, it should, at worst, be no less safe - the requirements on the manufacturer (testing etc.) should be the same regardless
> 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects.
You can open the code but, for example, required a signed binary before a device can be updated. The openness of the code and the openness of the device itself are linked but separate issues.
About that ...
Have you seen http://www.fdareview.org/05_harm.php and http://www.fdareview.org/07_market_failure.php?
There's a competitive advantage in keeping pacemakers' source code proprietary?
Open source is not necessarily any safer (heartbleed bug ... )
It's a hell lot more amendable to inspection than proprietary software.
There definitely is. If your company takes ~2 years to develop a pacemaker's software, it's not to your advantage to let your competitors catch up. I'm not saying it's a good thing that it's closed source, but there is definitely incentive to keep your research to yourself.
Why should the patient who has the pacemaker implanted care? This seems like a clear situation in which the patient's interests trump everybody else's. Pacemaker manufacturers should be competing in how well their devices meet patient needs. Closed source doesn't meet a key patient need.
I mean, I get the business incentives involved, but I also think it's high time to realize they're getting insane and should be altered.
Exactly what patient need do you believe open source would meet that is not being met by the current closed-source development process?
How do you know this?
For starters, without access to the hardware and understanding what it's supposed to be doing, how do you know if the code is right or not?
Let me clarify that I'm not opposed to open sourcing the code, once issues around Trade Secrets are handle. But I don't think it would have even remotely the impact this group believes. The vast majority of device problems I've seen were system issues, not just a coding error.
I also don't need to know much about the intended function of the device to find coding styles that cause problems in an embedded environments.
The need to know, and be able to control if necessary, what a device that affects your life and health is doing.
I'll give an example from my own experience. I have sleep apnea and have to use a CPAP machine. There is a nice little SD card in the machine that records detailed data from every use--which means it records how long I sleep, how soundly I sleep, how many (if any) apnea episodes I have, etc. This would be very useful information to me, but I have no way of getting it, because the software and data inside the device is proprietary. The only way for me to have anyone look at this data is to pull the SD card out and take it to a sleep therapy doctor, and even then I won't see the actual raw data; the best I'll get is some proprietary analysis report designed by the device manufacturer.
Furthermore, the ostensible use for the data is to be able to adjust the pressure the CPAP machine is set at in order to improve the therapy. If I had access to the data and the settings inside the machine, I could easily do this myself. Instead, if I want any adjustment made, again, I have to go see a sleep therapy doctor--which means I need to make an appointment, which usually means waiting weeks or months, and I need to take off from work to go to the appointment, etc., etc.
It should be obvious how open source would greatly improve this situation.
Put another way: If you had to explain Marie Moe's death to one of her relatives, which of your three points would make the relative understand your position?
We do not allow food companies to hide the ingredients of their products, because we know that companies (in the interest of profit) will fail to inform consumers about the dangers of eating unhealthily. Similarly, we do not allow meat producers to leave their meat ungraded because it endangers their "competitive advantage" - we understand (empirically) that doing so leads to food contamination and otherwise preventable disease.
Your choice of proprietary medicine as a counterexample is an interesting one. The pharmaceutical industry in the United States has a long history of "protecting its competitive advantage" at the cost of individual welfare - consider how frequently "reformulations" of the same base chemical are patented to continue milking a lucrative product that could improve the lives of thousands if genericized.
Perhaps even more pointedly, consider the fact that we deem it acceptable (and necessary) that the FDA step in and regulate the release of new drugs. Is there a valuable distinction to be drawn between the sort of regulation and evaluation that the FDA does and the sort that would be possible if programmers could openly evaluate medical devices?
You're attempting to justify the release of a (potentially fatally) flawed product on the grounds of lost "competitive advantage".
If you lost a family member to a faulty (yet certified!) medical device, would you feel that their death is justified by a marginal improvement to some company's bottom line? What if it wasn't a medical device with closed code, but a miracle pill whose manufacturer refused to release the formula to the government for analysis?
The argument I made in my original comment does not rely on the (un)soundness of your original claims - it is a moral argument about the value we place on human life. I'd be willing to bet that, even if you think that closed source is superior in every fashion, you would never be satisfied by your own justifications in the case of a personal tragedy. This contradiction suggests that, at the very least, we must draw a distinction between justifiably and unjustifiably closed source code.
2) Open and closed are equally vulnerable. Closed may be even more vulnerable, since security researches have to attack a black box and can't run ordinary code linting tools.
3) Liability after update is a good question, but one which can be (and is) solved with traditional contract agreements. See cpap machines.
Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
Tell me, how many vulnerabilities are running wild on Linux, the software that powers... well, pretty much anything (including the servers through which you read this content)? Even if you find a vulnerability, it gets patched within hours and it may take a day or two for it to be distributed to everyone.
> Security by obscurity [...] does raise the barrier to entry for script kiddies.
Which script can help you find a vulnerability inside of the source code? You'll need a script that can understand the code it's looking at. I'm not aware of any such script.
I'm not advocating for security by obscurity in the slightest because on balance I think it's bad, but we should acknowledge that publishing your source does change the potential cost of mounting an attack in various scenarios, and some of them might actually favor obscurity.
Nobody except the most determined attacker will attack a device with some custom, unpublished code. On the other hand, popular software have a variety of exploits in the wild because their popularity makes them more attractive targets, one consequence of which is enabling script kiddies (since the hard work can be outsourced).
> it gets patched within hours and it may take a day or two for it to be distributed to everyone
This doesn't work for embedded devices. Hence why it might not be a great idea to publish their vulnerabilities, or tell the whole world that you're running on old vulnerable source.
This is patently incorrect. Even the underpowered Z80-clone micros with 18kB RAM I was writing firmware for 15 years ago had trivially updated firmware; modern devices are even easier.
The article even mentions that wireless firmware updates is a feature:
Then she bought a pacemaker programmer online,
and she and other hackers figured out that it
could be used to update the code on her implant.
Relying on the laziness and ignorance of the attacker is a terrible idea.
> Hence why it might not be a great idea to publish their vulnerabilities
This is why any it's important to practice responsible disclosure. The manufacturer should have a reasonable time to make their patch before telling the internet.
We live in a world where even phones don't get patched as frequently as they should; you expect end users to patch their pacemakers?
Putting them online and allowing auto-patching would probably be worse since it also increases their attack surface drastically.
> This is why any it's important to practice responsible disclosure.
Right, and fact is that 'responsible disclosure' ends up looking a lot like obscurity in a world where you can't guarantee that devices will be patched before an attacker would be interested in exploitation.
I have no idea what the current patch rate is for pacemakers, but they do happen. The use of radio was a feature specifically to allow updating and management of the pacemakers while avoiding the serious risks of surgery. The pacemakers would be patched when the patient shows up for their next checkup appointment, which is probably every 1-2 months. They already connect to the devices for regular diagnostic purposes at those times.
If the problem was severe enough, calls would be made to the patients to come in right away. Medical services already handle problems on a priority basis ("triage"). This already happens for other types of problems.
> 'responsible disclosure' ends up looking a lot like obscurity
That's a circular argument. You're implying that the manufacturer wouldn't want to fix their product, which is highly unlikely. The only reason they are resistant to the idea at present is because the source is closed. The entire point is that by opening up the source the community can work with the manufacturers to fix these problems.
You're arguing that because the current system currently doesn't patch bugs that often, we shouldn't allow more debugging. Pretending that either bugs don't exist or that malicious actors won't find them without the source code is dangerous. "Pride goes before the fall"; do you really want to bet - potentially with your life - that all malicious actors are too stupid to find security problems? Hint: many medical devices have already been hacked (without the source). Or do you want to let the community at least attempt to find the bugs first?
In other words, it's a ready-made vector for potential attacks, as long as an attacker can get close to a pacemaker with a radio. You could probably even put a powerful device near a hospital and pick up random people coming and going.
> Or do you want to let the community at least _attempt_ to find the bugs first?
The promise of open-source security has always been that you let many eyes look for problems, then you patch ahead of potential attackers.
Logistically, that's extremely problematic for embedded devices. Every time a vulnerability is found, you ask the patient to go back to the doctor to get it updated? That doesn't scale at all.
The idea that device manufacturers will change their entire engineering and security philosophy is somewhere between idealistic and naive. I sincerely hope it's the former and not the latter.
Now there is an argument that there is a trivial way to find vulnerabilities in Open Source code - just diff the commits to look for fixed bugs, and attack those who didn't manage to update their software yet. That's part of the reason why e.g. Wordpress blogs and PHPBB forums get spammed so heavily.
Whether or not the benefits of Open Source are greater than those problems is another topic, but let's not pretend opensourcing doesn't lower the entry bar for attackers.
Security by obscurity is never a good idea, but especially not when it might prevent a white hat from finding a bug that would allow a malicious actor to remotely STOP MY HEART.
1) White hat finds a vulnerability in the source code which applies to a large number of devices. 2) Source is patched but vulnerable devices exist in wild
Now all an attacker needs to do is find a vulnerable device; because the source code is public like OP suggests, figuring out which devices are vulnerable is trivial.
Unless I'm missing something drastic, this is actually a problem in the embedded space where obscurity seems to help.