Virta Blabs

bac.jpg

Should I 510(k) or Should I Go? What New FDA Guidance Means and Why it Matters

Posted by Ben Ransford on Oct 27, 2017 7:30:00 AM
Find me on:

TRF_Schematic.jpg

This week FDA released several crucial guidance documents that are strongly relevant to cybersecurity. In regulatory fashion, the documents have very different names and are easy to tell apart, making it easy to talk about them at the same time.

Deciding When to Submit a 510(k) for a Software Change to an Existing Device is important because there's absolutely no longer any excuse for manufacturers to claim that they're not issuing security updates to medical devices because doing so would require jumping through additional regulatory hoops. If you're a healthcare provider and a vendor tells you that: print this guidance, roll it up tightly, and shoo them out the door. We've been saying this in different forms for years and we're not going to say it again here. The guidance says it for us!

Deciding When to Submit a 510(k) for a Change to an Existing Device is just what the title suggests: more general guidance that goes beyond software.  We'll focus on the part that caught our eye as being especially relevant to security: new and important guidance on what to do when adding wireless communication. Lots of manufacturers are going wireless, so this is a big deal.

Security implications of wireless for medical devices has been our founders' hobbyhorse for literally a decade and we're tremendously pleased to see this guidance finalized. So pleased that the rest of this post is about wireless!

Wireless Communication: Great Advances for Patients, Headaches for Manufacturers

The whole point of wireless communication is to improve usability by removing obstacles like wires from typical use scenarios. In some cases manufacturers are finding that adding wireless also opens up new use cases that they haven't had to consider before. There are design tradeoffs. You can give a patient much greater freedom (of movement, of location, etc.) by adding wireless communication, resulting in greater adoption and more sales, but you also get a whole new set of failure modes that you didn't have to worry about when you could rely on good old wires. FDA knows that patients want to move around and is absolutely correct to make sure manufacturers have considered the tradeoffs closely.

... BECAUSE, in addition to usability and failure-mode tradeoffs, wireless can bring new cybersecurity challenges too. Our founders' 2011 paper "They Can Hear Your Heartbeats: Non-Invasive Security for Implanted Medical Devices," written with MIT collaborators, and some of our earlier work like "Pacemakers and implantable cardiac defibrillators: Software radio attacks and zero-power defenses," written with another cross-disciplinary team, explore these challenges in detail. Wireless is never just a drop-in replacement for a wire. When you add wireless to a device, you have to imagine scenarios in which an attacker might try to disrupt or intercept communications — or even generate communications of their own. You can't safely send unencrypted information anymore, and you have to deal with the fact that the communication channel can stop working or start corrupting bits at any moment.

In our own peer-reviewed research, we've managed to:

  • Sniff (planted) patient information out of the air;
  • Make a medical device misbehave by replaying radio commands;
  • Turn off a device's therapeutic functions with a few well-placed transmissions;
  • Drown out legitimate communications with noise, garbage, or seemingly legitimate commands;
  • Make a medical implant shut its communications off to save battery;
  • and shorten an implant's battery life just by talking to it.
  • (We've also designed protective mechanisms using novel hardware, because we think the best security research is constructive.)

And that was without even trying to attack device firmware. That little radio system-on-chip component that you included in your design to "outsource" communications is actually a complex beast of its own; it runs its own beastly software. Remember those recent attacks on phones via Broadcom wifi components that could allow a wily hacker to get "root" without bothering to compromise the operating system? That was possible because the Wi-Fi module had privileged access to the device hardware so that it could be fast and well integrated. A foothold in a wireless component is an incredibly clever place to hide in order to meaningfully affect device behavior. If you're a manufacturer, you must carefully consider your "trusted computing base." And you must remember that every subsystem contributes its own bit of area to the attack surface.

This stuff is hard to get right, and part of getting it right is acknowledging the nuances and making sure they're accounted for. In this regard, FDA's guidance on the introduction of wireless hits the mark. Adding wireless communication requires extra verification and oversight because it can increase the attack surface of a device, and there can be real and insidious consequences for patient safety.

In short, the game is up. Manufacturers should expect scrutiny when introducing wireless functionality, no matter how innocuous the changes may seem. Don't try to pass off your wireless interface as merely an incremental upgrade that replaces a wire with an absence-of-wire. Show that you've done your homework and that you understand the security implications.

(Image credit: Wikipedia.)

510(mmmmmmmkay)?

mmmkay

 

Topics: Medical Device Security, IoT, Connected Medical Devices