3 ms·

> There shouldn't be pentesting, because there shouldn't be anything to pentest. At the face this seems like the right approach, but you end up with security-t

> There shouldn't be pentesting, because there shouldn't be anything to pentest. At the face this seems like the right approach, but you end up with security-through-obscurity protecting (yet another) critical system. If you don't hire pentesters, how can you be sure there is no way to maliciously interact with the device? Because you didn't intend for there to be? Its a good thing vulnerabilities are never unintentional right? Its also not very resilient to a change in the software's requirements; maybe its okay for a pacemaker not to have a password when you need to open up a patient's chest to connect to it. Maybe those extra microseconds you save mean less blood loss and pain for the patient undergoing surgery, an undeniable win. But this operation turns out to be expensive (by every conceivable measure), so the next model ships with bluetooth, now we have a problem. See also: http://blog.ioactive.com/2013/02/broken-hearts-how-plausible-was.html http://blog.ioactive.com/2013/02/broken-hearts-how-plausible...

TheLoneWolfling 11y ago
Perhaps I was overstating things. I'm not saying "don't hire pentesters". I'm saying "don't implement security in software when it can be done in hardware". If all interfaces that could cause damage are not physically connected to an external interface, the chances of anything being able to coerce them into doing something bad are... slim, at best. Not none, never none. But slim. Certainly slimmer than just stuffing everything in the same basket and calling it a day. And your second part is exactly why medical devices are not, or at the very least, should not, have changes done to them after-the-fact.
- fabulist 11y ago
  Security necessarily comes in layers. Some will fail; hopefully not all of them. Adding protections at the hardware part of the stack is a fantastic idea, but insufficient for something lives are literally, directly depending on. Medical devices do need to be accessed. Diagnostics need to be performed to make sure they're functioning. Sometimes batteries even need to be changed. Insulin pumps and the like need to be given more medicine, and the dosage may need to be adjusted. Et cetera.
  - TheLoneWolfling 11y ago
    Diagnostics are a good example of something that can be separated from the actual safety-critical stuff. Have a dumb output from the safety-critical processor that the radio interface can read. If you're changing batteries or medicine, you're going to be accessing the device physically anyways, and so can change settings / dosages then. Et cetera.
    - DasIch 11y ago
      A battery change of a pacemaker or an ICD is required every 6 years or so, if not later. You may need to change settings far earlier than that.
- joeyo 11y ago
  > And your second part is exactly why medical devices are not, or at > the very least, should not, have changes done to them after-the-fact. I don't think this is self-evident. There are already a number of devices on the market that basically require physician tuning post-implantation. Deep brain stimulators and cochlear implants spring immediately to mind, and there are likely many other examples. There are many reasons for this: there may be too many parameters for the physician to realistically adjust intraoperatively, assessing efficacy may require activities that are impossible to perform in the OR (ie observing gait), the parameters may be time-varying, it may not be possible to have the patient awake during surgery, the patient may be pre-lingual, etc. Even worse, both DBS and cochlear implants have relatively short loop-latencies between the physician "turning the knob" and observing the effect (seconds). There are emerging medical implants where the loop-latency may be in the hours-to-weeks range. That's pretty much going to require tuning post-surgery which in turn basically requires a wireless interface of some kind. Finally, while updating the firmware of a medical device (eg to give new capabilities) should certainly not be done lightly, but it is far and away preferable to going under the knife again to receive a new device. Bottom line, the right thing to do is get security right, not limit what physicians can do with the devices.

TheLoneWolfling 11y ago

Perhaps I was overstating things. I'm not saying "don't hire pentesters". I'm saying "don't implement security in software when it can be done in hardware". If all interfaces that could cause damage are not physically connected to an external interface, the chances of anything being able to coerce them into doing something bad are... slim, at best. Not none, never none. But slim. Certainly slimmer than just stuffing everything in the same basket and calling it a day. And your second part is exactly why medical devices are not, or at the very least, should not, have changes done to them after-the-fact.

fabulist 11y ago
Security necessarily comes in layers. Some will fail; hopefully not all of them. Adding protections at the hardware part of the stack is a fantastic idea, but insufficient for something lives are literally, directly depending on. Medical devices do need to be accessed. Diagnostics need to be performed to make sure they're functioning. Sometimes batteries even need to be changed. Insulin pumps and the like need to be given more medicine, and the dosage may need to be adjusted. Et cetera.
- TheLoneWolfling 11y ago
  Diagnostics are a good example of something that can be separated from the actual safety-critical stuff. Have a dumb output from the safety-critical processor that the radio interface can read. If you're changing batteries or medicine, you're going to be accessing the device physically anyways, and so can change settings / dosages then. Et cetera.
  - DasIch 11y ago
    A battery change of a pacemaker or an ICD is required every 6 years or so, if not later. You may need to change settings far earlier than that.
joeyo 11y ago
> And your second part is exactly why medical devices are not, or at > the very least, should not, have changes done to them after-the-fact. I don't think this is self-evident. There are already a number of devices on the market that basically require physician tuning post-implantation. Deep brain stimulators and cochlear implants spring immediately to mind, and there are likely many other examples. There are many reasons for this: there may be too many parameters for the physician to realistically adjust intraoperatively, assessing efficacy may require activities that are impossible to perform in the OR (ie observing gait), the parameters may be time-varying, it may not be possible to have the patient awake during surgery, the patient may be pre-lingual, etc. Even worse, both DBS and cochlear implants have relatively short loop-latencies between the physician "turning the knob" and observing the effect (seconds). There are emerging medical implants where the loop-latency may be in the hours-to-weeks range. That's pretty much going to require tuning post-surgery which in turn basically requires a wireless interface of some kind. Finally, while updating the firmware of a medical device (eg to give new capabilities) should certainly not be done lightly, but it is far and away preferable to going under the knife again to receive a new device. Bottom line, the right thing to do is get security right, not limit what physicians can do with the devices.