51–60 of 217 posts
Philosophy - She doesn't know the code that's running on machines inside her body. I don't even know the code that's running my heart. And yet, I trust it.
The latter has undergone far more testing than the former.
Earlier quoted context omitted.
Maybe in a complete vacuum, but in reality, having access to source certainly makes it easier to look for vulnerabilities, and if the same software is in many devices, the cost of finding vulnerabilities is amortized. Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
No. 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 f…
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.
Sure this is about pacemakers, but cant we say something similar about the rest of our body?
Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.
My understanding is that they don't review the code, but they do review all of the validation that goes into making sure the code does what it should.
[1]http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281...
Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.
With or without a warrant...? EDIT: Not sure what's up w/ the downvotes. There are well-established ways for regulatory agencies (whether FDA, FCC, etc) to obtain firmware for devices -- and it almost always involves a warrant under extraneous circumstances -vs- proactively receiving proprietary code.
Earlier quoted context omitted.
Maybe in a complete vacuum, but in reality, having access to source certainly makes it easier to look for vulnerabilities, and if the same software is in many devices, the cost of finding vulnerabilities is amortized. Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
Anyone you're likely to classify as a "script kiddy" is not going to be able to read the kind of code going into embedded devices like a pacemaker to a deep enough level to find any problems. And if they can the software is really problematic, most likely. 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…
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.
Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.
Earlier quoted context omitted.
Do you want to control the device, or do you want someone else to control your devices? If you're OK with someone else (who probably doesn't have your well-being anywhere in their list of priorities) controlling all of your devices, then the answer is no, you are not required to have access to the source code and output data. EDIT: I didn't realize this was such a controversial statement. I stand by it, though; even…
In theory, open sourcing pacemaker software make sense, but in practice, the pool of people qualified to review and edit that software may not be very large. Most people would still be depending on someone else to control their devices in any case.
I'm sure I'd lack a lot of the heart mechanics side of the equation, but I would be very highly incentivised to hunt out programming bugs.
Earlier quoted context omitted.
> If your company takes ~2 years to develop a pacemaker's software, it's not to your advantage to let your competitors catch up. 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.
Medical device software is subject to a level of rigor in development process that little else is. Exactly what patient need do you believe open source would meet that is not being met by the current closed-source development process?
Philosophy - She doesn't know the code that's running on machines inside her body. I don't even know the code that's running my heart. And yet, I trust it.