5 ms·

This is completely unacceptable. There really should be more pentesting of medical gear and industrial control systems in general.

by xooxies 11y ago

blueintegral 11y ago
It's surprising that the FDA doesn't require that as part of their certification procedure.
- asuffield 11y ago
  I can think of many words to describe my reaction to this, but "surprise" is not one of them. I have never seen a regulatory body impose any meaningful security testing. Even supposedly "secure" standards are often self-certified, not tested.
TheLoneWolfling 11y ago
I'd argue that the very fact that it's physically possible to hack these sort of devices is a huge red flag. There shouldn't be pentesting, because there shouldn't be anything to pentest. Something like a medical device, you keep the outside communication part airgapped from anything that could cause harm. If that means you have to duplicate things, then it means you have to duplicate things.
- moyix 11y ago
  Implantable devices typically have to have a wireless interface of some sort. The alternative is to put a physical port on someone's body, which is a great way to cause infections.
  - amyjess 11y ago
    But... but... I want a datajack at the base of my skull!
    - jessaustin 11y ago
      Me too, I've been searching for an excuse to get the Motoko haircut...
  - TheLoneWolfling 11y ago
    So you have a wireless interface for the non-able-to-kill-you stuff. But if you're having to change the code of something that's been implanted, you've already done something horribly wrong.
    - mkehrt 11y ago
      For example, I think pacemakers can set the range of acceptable heart rates by radio. So now, you have to have logic checking that it doesn't get set to 0. But what happens if there's a buffer overflow in that checking? Edit: here's a paper demonstrating similar attacks: http://www.secure-medicine.org/public/publications/icd-study.pdf http://www.secure-medicine.org/public/publications/icd-study...
      - TheLoneWolfling 11y ago
        See, that's an example of something that I do not think should be settable via radio. Maybe inductive or sonic communication. Alternatively, you have the software check the set range, but the hardware (or a second non-connected processor) also checks it separately to make sure it's sane anyways.
    - DasIch 11y ago
      Pacemakers and defibrilators are configured to match an individual patient. Part of that configuration includes what parts of the heart to stimulate. This configuration may need to change as the patient's condition changes. You also need to be able to turn of the pacemaker entirely to monitor how the heart operates without stimulation. You may need to turn of the defibrilator during certain medical procedures...
- mkehrt 11y ago
  Things like pacemakers often have radio interfaces, because the alternative is to cut someone open.
  - TheLoneWolfling 11y ago
    I didn't say "don't have a radio interface". I said, "don't have a radio interface to the able-to-kill-you parts". There is a distinction. Also, how does that work? Water is a pretty good attenuator of radio waves.
    - fabulist 11y ago
      They also need to be "able to kill you" so that the patient can be defibrilated if their heart stops beating. If you do that when their heart is functioning it tends to have the opposite effect.
      - TheLoneWolfling 11y ago
        Right. But that functionality can be airgapped from the readout parts.
        fabulist 11y ago
        Some sandboxing could be done, but if an attacker roots a pacemaker or an insulin pump it will be extremely difficult if not impossible to prevent them from convincing the device to perform its intended function at an unintended time.
        TheLoneWolfling 11y ago
        Airgapped. Not just sandboxed. As in two separate processors, with no overlapping RAM / etc. You can't do your example, because there's no way to get at the internal clock from the radio.
    - msandford 11y ago
- fabulist 11y ago
  > 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.
- spydum 11y ago
  the problem here is the medical community (especially hospitals) are increasingly pressured to increase productivity to offset cost increases. one way is to automate some of the dreary stuff like monitoring of medical devices in a hospital ward. if youve been in a relatively modern hospital lately, youll find they have wall mounted dashboards which can monitor all the vitals and devices for patients without the nurse needing to walk around and check rooms. this lets them respond to changes as they come up, as opposed to needing to wait till they make their rounds to the room. this sort of thing needs a network. I'm not familiar, but I thought in the US, HIPPA covered some of this stuff.. not sure how stringent it is, or if it covers scenarios like this.. perhaps it doesnt at all (I am thinking like PCI, where certain data must be encrypted, etc).
rodgerd 11y ago
Related: Karen Sandler's LC2012 keynote, which discusses the challenges of finding anything out about life-sustaining medical technology: https://www.youtube.com/watch?v=5XDTQLa3NjE https://www.youtube.com/watch?v=5XDTQLa3NjE
ars 11y ago
If you take that too far you end up with medical gear that is so locked down the owner can not make any changes themself, but must ask for permission to make any changes.
- MaulingMonkey 11y ago
  I was under the impression that medical devices were already locked down like that due to e.g. FDA regulations. Not having security either seems like a "worst of both worlds" situation.
  - ars 11y ago
    With no security people get access on their own......
    - MaulingMonkey 11y ago
      ...at the risk of bricking devices and legal threats? Sure. Both of which are concerns with some teeth for such mission critical devices as... your xbox. Jailbroken medical devices sounds like a great way for a doctor to loose their license, a developer to end up with manslaughter charges, and patients being unable to tell their doctors about their full medical situation, lest their doctors run screaming from the impending liability lawsuit. I think the correct answer to "let people modify their own devices" is "fix the regulations" not "intentionally weaken security in matters of potential life and death."

This is completely unacceptable. There really should be more pentesting of medical gear and industrial control systems in general.

by xooxies 11y ago

This is completely unacceptable. There really should be more pentesting of medical gear and industrial control systems in general.

blueintegral 11y ago

It's surprising that the FDA doesn't require that as part of their certification procedure.

asuffield 11y ago
I can think of many words to describe my reaction to this, but "surprise" is not one of them. I have never seen a regulatory body impose any meaningful security testing. Even supposedly "secure" standards are often self-certified, not tested.

TheLoneWolfling 11y ago

I'd argue that the very fact that it's physically possible to hack these sort of devices is a huge red flag. There shouldn't be pentesting, because there shouldn't be anything to pentest. Something like a medical device, you keep the outside communication part airgapped from anything that could cause harm. If that means you have to duplicate things, then it means you have to duplicate things.

moyix 11y ago
Implantable devices typically have to have a wireless interface of some sort. The alternative is to put a physical port on someone's body, which is a great way to cause infections.
- amyjess 11y ago
  But... but... I want a datajack at the base of my skull!
  - jessaustin 11y ago
    Me too, I've been searching for an excuse to get the Motoko haircut...
- TheLoneWolfling 11y ago
  So you have a wireless interface for the non-able-to-kill-you stuff. But if you're having to change the code of something that's been implanted, you've already done something horribly wrong.
  - mkehrt 11y ago
    For example, I think pacemakers can set the range of acceptable heart rates by radio. So now, you have to have logic checking that it doesn't get set to 0. But what happens if there's a buffer overflow in that checking? Edit: here's a paper demonstrating similar attacks: http://www.secure-medicine.org/public/publications/icd-study.pdf http://www.secure-medicine.org/public/publications/icd-study...
    - TheLoneWolfling 11y ago
      See, that's an example of something that I do not think should be settable via radio. Maybe inductive or sonic communication. Alternatively, you have the software check the set range, but the hardware (or a second non-connected processor) also checks it separately to make sure it's sane anyways.
  - DasIch 11y ago
    Pacemakers and defibrilators are configured to match an individual patient. Part of that configuration includes what parts of the heart to stimulate. This configuration may need to change as the patient's condition changes. You also need to be able to turn of the pacemaker entirely to monitor how the heart operates without stimulation. You may need to turn of the defibrilator during certain medical procedures...
mkehrt 11y ago
Things like pacemakers often have radio interfaces, because the alternative is to cut someone open.
- TheLoneWolfling 11y ago
  I didn't say "don't have a radio interface". I said, "don't have a radio interface to the able-to-kill-you parts". There is a distinction. Also, how does that work? Water is a pretty good attenuator of radio waves.
  - fabulist 11y ago
    They also need to be "able to kill you" so that the patient can be defibrilated if their heart stops beating. If you do that when their heart is functioning it tends to have the opposite effect.
    - TheLoneWolfling 11y ago
      Right. But that functionality can be airgapped from the readout parts.
      - fabulist 11y ago
        Some sandboxing could be done, but if an attacker roots a pacemaker or an insulin pump it will be extremely difficult if not impossible to prevent them from convincing the device to perform its intended function at an unintended time.
        TheLoneWolfling 11y ago
        Airgapped. Not just sandboxed. As in two separate processors, with no overlapping RAM / etc. You can't do your example, because there's no way to get at the internal clock from the radio.
  - msandford 11y ago
fabulist 11y ago
> 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.
spydum 11y ago
the problem here is the medical community (especially hospitals) are increasingly pressured to increase productivity to offset cost increases. one way is to automate some of the dreary stuff like monitoring of medical devices in a hospital ward. if youve been in a relatively modern hospital lately, youll find they have wall mounted dashboards which can monitor all the vitals and devices for patients without the nurse needing to walk around and check rooms. this lets them respond to changes as they come up, as opposed to needing to wait till they make their rounds to the room. this sort of thing needs a network. I'm not familiar, but I thought in the US, HIPPA covered some of this stuff.. not sure how stringent it is, or if it covers scenarios like this.. perhaps it doesnt at all (I am thinking like PCI, where certain data must be encrypted, etc).

rodgerd 11y ago

Related: Karen Sandler's LC2012 keynote, which discusses the challenges of finding anything out about life-sustaining medical technology: https://www.youtube.com/watch?v=5XDTQLa3NjE https://www.youtube.com/watch?v=5XDTQLa3NjE

ars 11y ago

If you take that too far you end up with medical gear that is so locked down the owner can not make any changes themself, but must ask for permission to make any changes.

MaulingMonkey 11y ago
I was under the impression that medical devices were already locked down like that due to e.g. FDA regulations. Not having security either seems like a "worst of both worlds" situation.
- ars 11y ago
  With no security people get access on their own......
  - MaulingMonkey 11y ago
    ...at the risk of bricking devices and legal threats? Sure. Both of which are concerns with some teeth for such mission critical devices as... your xbox. Jailbroken medical devices sounds like a great way for a doctor to loose their license, a developer to end up with manslaughter charges, and patients being unable to tell their doctors about their full medical situation, lest their doctors run screaming from the impending liability lawsuit. I think the correct answer to "let people modify their own devices" is "fix the regulations" not "intentionally weaken security in matters of potential life and death."