Slashdot Mirror

← Back to Stories (view on slashdot.org)

FDA Releases New Cybersecurity Guidelines For Medical Devices (theverge.com)

Posted by BeauHD on from the internet-connected dept.

An anonymous reader quotes a report from The Verge: The U.S. Food and Drug Administration released its recommendations for how medical device manufacturers should maintain the security of internet-connected devices, even after they've entered hospitals, patient homes, or patient bodies. Unsecured devices can allow hackers to tamper with how much medication is delivered by the device -- with potentially deadly results. First issued in draft form last January, this guidance is more than a year in the making. The 30-page document (PDF) encourages manufacturers to monitor their medical devices and associated software for bugs, and patch any problems that occur. But the recommendations are not legally enforceable -- so they're largely without teeth. The FDA issued an earlier set of recommendations in October 2014 (PDF), which recommended ways for manufacturers to build cybersecurity protections into medical devices as they're being designed and developed. Today's guidance focuses on how to maintain medical device cybersecurity after devices have left the factory. The guidelines lay out steps for recognizing and addressing ongoing vulnerabilities. And they recommend that manufacturers join together in an Information Sharing and Analysis Organization (ISAO) to share details about security risks and responses as they occur. Most patches and updates intended to address security vulnerabilities will be considered routine enhancements, which means manufacturers don't have to alert the FDA every time they issue one. That is, unless someone dies or is seriously harmed because of a bug -- then the manufacturer needs to report it. Dangerous bugs identified before they harm or kill anyone won't have to be reported to the FDA as long as the manufacturer tells customers and device users about the bug within 30 days, fixes it within 60 days, and shares information about the vulnerability with an ISAO.

28 of 40 comments (clear)

  1. What about makeing os updates happen? by Joe_Dragon · · Score: 3, Insightful

    What about makeing os updates happen? and letting the local IT staff lock down there network and not be forced to have some things wide open to the outside vendor.

    1. Re:What about makeing os updates happen? by invictusvoyd · · Score: 2

      Dangerous bugs identified before they harm or kill anyone won't have to be reported to the FDA as long as the manufacturer tells customers and device users about the bug within 30 days, fixes it within 60 days, and shares information about the vulnerability with an ISAO.

      What about the Windows family of OS's

    2. Re:What about makeing os updates happen? by Anonymous Coward · · Score: 2, Informative

      I develop firmware for medical devices. Windows and Linux are used in medical devices in critical care devices.

    3. Re: What about makeing os updates happen? by Zero__Kelvin · · Score: 1

      Then think that most medical devices are not implants, but rather large machines the size of an oscilloscope or larger, and absolutely do run on a Windows variant or Linux.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  2. Respect !! by invictusvoyd · · Score: 1

    But the recommendations are not legally enforceable -- so they're largely without teeth

    My authoritah !!

  3. Re:hail! government makes us safe! by grumling · · Score: 3, Insightful

    "But we followed all the guidelines as set forth by the FDA, so we're not liable."

    -Every medical device manufacturer after they've been hacked.

    --
    "Well, good luck finding a judge that doesn't run a bestiality site."
  4. Not enough by NotInHere · · Score: 4, Interesting

    Its not enough to just be reactive about computer security. This still means that sophisticated attackers can hoard security vulnerabilities and develop advanced tools that find vulnerabilities the moment they are introduced. Instead, you should already design the system in a way that frustrates attacks and hopefully prevents some attacks entirely. A good talk about this:

    https://www.youtube.com/watch?...

    Slides:

    http://outflux.net/slides/2016...

    1. Re:Not enough by Shane_Optima · · Score: 2

      A noble effort, but tools like ASLR have in practice shown themselves to be less than bulletproof. They're worth pursuing to an extent, but they aren't enough for a truly robust preemptive security strategy and shouldn't be our primary focus.

      The future of secure computing is obviously a ground-up microkernel affair that allows strong sandboxing. But that's going to take... a while to mature, in terms of native application support. In the meantime, a stopgap using paravirtualization and hardware assisted virtualization is the best that can be done. It's not as efficient, but it's a lot snappier than you'd expect and silicon is cheaper than programmers' time.

      The basic security idea of Qubes (putting aside its UI innovations, which obviously aren't important on embedded devices) is that Dom0[1] entirely lacks networking, including the networking driver. The networking driver is isolated in its own VM with its own separate kernel, and on a vt-d capable machine that VM's access to shared resources is controlled (meaning you can't use a DMA attack to access another VM's data from RAM.) After the networking VM comes a separate firewall VM, and other VMs can have connectivity through the firewall VM.

      This is pretty damn robust, but in this scenario you could and should do even better by modifying Dom0[2] to verify commands and/or update signatures for your mission-critical VM. Dom0 itself should never be accessed or updated over the network (and it doesn't need to be, since it isn't vulnerable to remote exploits and isn't directly involved in whatever the main functionality of the medical device is.)

      Assuming we can't rewrite everything from scratch to function in a pure microkernel universe (with no VMs), the best we can do right now is to have completely separate OSes with separate kernels, connected and coordinated by a hypervisor. There's still the very real possibility of a Xen exploit (which would need to be stacked with other severe Linux exploits to be useful), but Xen is less than 150,000 lines of code and should be easier for security folks to reason about than the Linux kernel.

      This all may not be viable for implanted devices due to the added power requirements but for external devices... why the hell not? The extra hardware required would surely be less than $100 wholesale, on a device that probably costs thousands.


      1. With Xen, this is roughly comparable to the "host OS" used with type II hypervisors like Virtualbox, VMware, KVM / QEMU, but there are important differences. Namely, it's possible for device drivers to be located in unprivileged domains instead of Dom0.

      2. Or perhaps another VM without network connectivity at all, using a more limited mechanism of data passing along the lines of Qubes' VM-to-VM copy mechanism.

  5. Security is not a state. . . by Salgak1 · · Score: 1

    . . . but an ongoing process, and this does not appear to recognize that. Especially with medical device certification: make a change, and generally the entire system must be re-certified.

    So if a flaw is found in $libfoo, and fixed, FIRST the med companies need to know about it (not sure they even LOOK. . . ), and THEN update. And yet all too many Medical systems I've seen are still running Windows XP. . . How do you remediate something that's out of support ???

    1. Re:Security is not a state. . . by Anonymous Coward · · Score: 2, Informative

      And yet all too many Medical systems I've seen are still running Windows XP. . . How do you remediate something that's out of support ???

      Two different ways.
      The first one is to go through certification with the entire operating system. If you have been proven that it is safe then you don't really need to do further updates.
      The other way is hardware separation between the critical and non-critical parts.
      Most likely the life critical function was done with a separate controller that either doesn't run an operating system at all or runs an operating system that has been certified for medical usage. The windows application you saw is just the GUI component and it doesn't matter if it crashes.

      I can't imagine someone actually attempting to use Windows or Linux for a life critical part of a medical appliance.

    2. Re:Security is not a state. . . by bluefoxlucid · · Score: 2

      They've progressed on that front: fix a flaw and you don't need recertification or even to alert the FDA.

      I'm more fond of a single-point-of-failure approach. To access a device, I'd want to connect to it in open mode first, and establish a two-way trust. The device would generate and install its own security key pair, and the device with which I connect would also generate a key pair. Then I could sign a new certificate with my device and use that as an authorized certificate: we just exchanged our keys as Certificate Authorities, and on each end we only trust each other as the CA.

      This means the doctor issuing the device (surgeon for internal devices) would have to activate it first (hopefully before putting it into your body). He would send the device a self-signed "Accessor" Public Key, and receive the device's self-signed "Device" Public Key--certificates. The Device private key is kept secret on the device; while the doctor prints out the Accessor private key as a page-sized string (OCR, keyboard entry) and matrix bar-code, to be filed with the medical record.

      Now it's possible to scan the paper print-out and use that Accessor private key to sign a certificate for an authorized key.

      All of this means you can write the communications interface such that you need to hack the network stack or the signature verification code path to exploit the device. The device only accepts communications (updates, other commands) if it can verify the signature on the communicated packet. That means the device's OS has to read data from an IO and pass it to software; the software has to perform a digital signature verification on that data before it's willing to do anything else about it.

      That's a tiny code path operating on end-user data, and it can be made absolutely-secure.

      Reading IO is a matter of identifying how much data to read and copying it into a kernel buffer, or mapping that IO to a userspace application--which means you can either identify the fixed length of data to read, or you can identify the risk of a buffer overrun and ensure that you always enlarge your buffer when you approach its capacity. In any case, you don't actually process the data; you're copying some length of bytes to some length of storage, which is impossible to manipulate. The only possible failure here is an egregious programming flaw that will be broken and buggy well enough on its own--like attempting to read the packet length from the wrong register, or using strcpy() instead of memcpy().

      Verifying a digital signature is tricky. It's a complex operation that involves iterating over the entire length of a specific body of data and performing a bunch of computations. If implemented correctly, it also doesn't process the data; instead, you have to worry about things like reading the packet in the first place. OpenSSL can verify a digital signature fine; it just occasionally has a bug where the packet says to do something incorrect and OpenSSL happily does it, and then reads data from a memory area bigger than the whole packet. That's what you need to code to avoid.

      Once you've gotten a way to pull the packet in and not accept commands like "Read 6,000 bytes from a 30-byte field", you don't have any possible exploits. At all.

      Then you're done. If signature verification fails, you refuse the packet--don't even process it. If signature verification succeeds, you've got someone who can do some dangerous shit and doesn't need to hack your device to fuck it up.

      It's called a key for a reason.

      --
      Support my political activism on Patreon.
    3. Re:Security is not a state. . . by Doke · · Score: 2

      The FDA may not require recertification after a supposedly minor software update. However, most companies would still want to go through QA again after a software change. This is because they're worried about medical liability. That's going to take time and money. It also creates a moving target for their developers. So they have an incentive to avoid OS upgrades of any kind.

      Since they're worried about liability, they will do anything they can to disclaim responsibility. Local hospital staff altering the control PC, in any way, is an excuse for the manufacturer to wiggle out of responsibility. This especially applies to large medical equipment, like CAT scanners, MRIs, etc.

      The rest of your comment is about cryptographically securing smaller devices, especially implanted ones, ie pacemakers. I agree with everything you say, but I'm concerned the medical staff will have trouble with it. Many of the doctors and nurses I've met are near-technophobes about computers.

    4. Re: Security is not a state. . . by Zero__Kelvin · · Score: 1

      In the end the data from one part needs to be interchanged. No matter how unhackable the one part is it can still display false data in the GUI that causes the patient to die because the instruments say he's fine when he's dying.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    5. Re:Security is not a state. . . by bluefoxlucid · · Score: 1

      QA doesn't take additional time and money; QA is an integrated part of the project management and, afterwards, the ongoing maintenance process. It's a critical component of the product development lifecycle required to minimize the time and money taken to produce and support a product.

      QA reduces costly support calls, costly lawsuits, and costly rework. Without QA, you send out products that eventually need bugfixes, and then have to be reworked. Units on shelves are now inadequate, and must be recalled. Customers with grievances now have the right to have you repair or replace their defective product. Customers who have experienced harm might have the right to force you to pay reparations, if it can be shown that harm was at your negligence--which is harder to do when you have good QA.

      QA makes the difference between 30% of your product's price being the cost of handling all this shit and 5% of your competitor's much-cheaper-and-better product being the cost of handling all this shit. It makes the difference between a failing business and the competitor who puts you out of business by simply selling a faster, better, cheaper product than you ever could. In the case of medical devices, it could make the difference between being a rich CEO and being an inmate.

      QA isn't a feature you pay extra for; it's a process whose output is a reduction in total costs. If QA didn't reduce the cost to supply an adequate product, we wouldn't do it.

      --
      Support my political activism on Patreon.
  6. Ok, Hippa please? by nefus · · Score: 2

    Is this the same federal government that still hasn't released full security guidelines for Hippa? And how much older is the Hippa issue?

  7. BlackBerry's new frontier by ArhcAngel · · Score: 5, Informative

    BlackBerry may have conceded the mobile handset business but they own the automotive market. (Both Android Auto and CarPlay run as plug-in modules for BlackBerry's QNX Car OS) And for the last four years they have been quietly buying up medical electronic companies left and right and integrating them into QNX.

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
  8. Re:hail! government makes us safe! by mean+pun · · Score: 4, Insightful

    A decent government tries to make their populace safe. Defining safety guidelines helps with this. Please try to appreciate the remnants of decent government that still have survived rather than score cheap talking points by playing the cynic. The flocks of horror clowns that, for example, the people in the US prefer to elect nowadays on all levels of their government will try to demolish these remnants soon enough.

  9. No Theeth, Eh? by Anonymous Coward · · Score: 2, Insightful

    But the recommendations are not legally enforceable

    Sure it is. Once a manufacturer is sued for negligence, the plaintiff can point out any failures to follow the FDA recommendations. It is a "soft" argument.

  10. Re:hail! government makes us safe! by Anonymous Coward · · Score: 1

    Following FDA guidelines does not shield you from negligence or errors in the design of a medical device.

    However, I do develop software for medical devices. I read through that document and found nothing useful in it.

    It seems to say:
    1) here is the problem (those of us in the field already know this).
    2) You should evaluate this risks(duh!).
    3) Think of ways to fix the problem.
    4) Cybersecurity risk management should be part of the development process.

    All of these are fairly obvious. For those of developing the firmware there are no useful guidelines. There is nothing ground breaking or even
    useful here.

  11. libability and air gap by Doke · · Score: 1

    The FDA's guidlines are not enforcable. So the hospitals will care a lot more about anything in the manufacturers' EULAs that let them disclaim liability.

    A lot of medical equipment, especially large scanners, are controlled by a PC. The embedded OS may be something real time, but the control PC almost always runs Windows. It does higher level functions like visualization, printing, etc. Since these devices are large capitol investments, they're kept for many years. Most doctor's offices don't have the technical skills to upgrade them. Even large hospitals can't maintain the expertise on every single device. Even if they did, they don't dare, because the manufacturer will try to disclaim any liability if the software installed on the PC has been altered in any way. Most places won't even allow IT to install virus scanners.

    The equipment vendors have a financial incentive not to change their platform. It requires repeating quality assurance tests for liability, and creates a moving target for their developers. They also have an incentive to forbid local changes, because it gives them an excuse to disclaim responsibility in court.

    In my opinion, all of these diagnostic systems should be air-gapped from the hospital intranet. Data should be shuttled in and out of them on removable hard drives. There should be an intermediate system that virus scans them before connecting them to either side. It would be a huge pain, but far less so than the ransomware.

  12. People don't understand regulations by MobyDisk · · Score: 2

    I see several posts that amount to "These guidelines are too vague." Understand how regulations work, and that they are a trade-off: governments are not going to give a specific detailed list of how to address, for example, security concerns in software and hardware. They will not say "All passwords must be length X" or "Passwords must be stored using PBKDF2 hashes with N number of rounds" or "All secure access doors must use a lock with at least 15 tumblers in it." While such guidelines would make liability a lot simpler, they would need to constantly change and no one could ever agree to them.

    Instead, the regulations say things like "Use industry-standard best practices when securing patient data." Now that sounds completely obvious to any professional, but understand that security breaches happen most often because these kinds of obvious things are missed!

    They then expect the industry to take those high-level requirements and use a bit of self-regulation to determine what exactly the regulations mean. And that naturally changes over time, which is the intent. For example, the industry has decided that this means web sites should follow the OWASP top 10. They seem to have coalesced on using only FIPS-compliant algorithms. And there is agreement that protected health information (PHI) must be encrypted "in transit and at rest." But take that last one for example: does that mean that PHI must be encrypted when transiting across the internet, or across PCs within a LAN, or within devices in an embedded machine, or across chips on a board? That might depend. As technology changes, so will the expectations for what is secure. And without a bunch of congress-people having to argue over it and pass a new law.

    Ultimately, companies that want to be in compliance must to prove that they thought about these things and made sensible decisions. Yeah, it sucks that this is vague, but there really is no perfect regulatory solution here. That work is delegated to other agencies and the industry itself.

    1. Re:People don't understand regulations by MobyDisk · · Score: 1

      Every change and fix is avoided until it becomes a life/death problem, or worse, until someone dies.

      Agreed, that does happen sometimes. But it usually isn't the regulatory process that keeps such fixes out, it is the companies themselves. Take a simple example: OS security patches. There seem to be a few basic arguments to not deploying them: One is that there is no funding to test the fixes. Two is that it is the customer's responsibility to secure it, or that the device shouldn't be networked at all. But the worst reason is that the companies might do the math and decide that it isn't worth the cost. They conclude that they are better off to accept the additional risk than to invest in testing the fixes. But whatever reason they choose, the regulatory paperwork for those kinds of changes is minimal by comparison to the 510k and PMA processes that are required to release the device initially. You don't have to rerun trials. But if your budget for sustaining efforts is zero, then any time spent is unacceptable. The mentality has to change from "get it out the door so I can make money" to "this is a living breathing project that will continue to require maintenance for the next 20 years."

      Ooh, another reason is that some labs decide that they need to re-test the devices after each patch. That's up to the labs, but it seems like they are adding quite a bit of onerous effort just because libasound.so was updated to fix a memory corruption when playing MP3 files.

      The whole regulatory charade makes businesses invest in being compliant. NOT in being secure or good or whatever.

      True. The trouble is that in the absence of regulations, they didn't invest in being secure or good or whatever. This is why industries need to be proactive about such things, lest the hand of government come down upon them.

      Non-AC disclaimer: I work for the industry.

  13. Re:hail! government makes us safe! by MobyDisk · · Score: 1

    Following FDA guidelines does not shield you from negligence or errors in the design of a medical device.

    While it is not a perfect shield, following those guidelines is a pretty darned good one. This applies to many industries. Suppose a commercial boat sank and killed people. The first thing that will come-up in court is coast-guard regulation. Did the captain have a captains license? Was the boat recently coast-guard inspected? Did they have the proper number of passengers and coast-guard approved life jackets? If so, they the operator of the boat is probably not liable. Seriously: If they followed all the rules, then it *probably* wasn't their fault. But there is always room for judgement.

    All of these are fairly obvious. For those of developing the firmware there are no useful guidelines. There is nothing ground breaking or even
    useful here.

    In my first example, having the coast-guard make specific regulations made the question easier to answer. With industries that are more self-regulated, a judge would have to decide what specific guidelines apply. Suppose your medical device had a web interface with a security flaw that exposed patient data. The judge might ask: Did the device follow OWASP guidelines? While the regulations don't specifically call for OWASP by name, the judge might see that this is what the industry has accepted the regulations to mean. In 10 years, maybe OWASP will be gone and some other organization's standards might apply. But compliance to those would be a very good shield at minimizing liability.

  14. Easy fix: Get the insurance companies involved by laurencetux · · Score: 1

    after making sure that the recommendations are useful the Regulators need to "suggest" that the insurance companies can use not following the guidelines would be a jolly way to give an out for the insurance companies (and depending on the scope lawyers love the words "Gross Negligence")

    so you don't include decent crypto in your CLOUD ENABLED drug pump or you have a backdoor in your Social Net Enabled Heart (with matching lack of safe default settings)

    NO CLAIM FOR YOU and hope that the next of kin does not have good lawyers because your malpractice insurance just got cancelled.

    (personally i think the CxOs of those companies need to go down on Murder charges)

  15. Re:computer security is like birth control by Shane_Optima · · Score: 1

    A security tool is never ignored for being not bulletproof.

    That's why I said "they're worth pursuing to an extent". ASLR is obviously useful even in the context of an isolated VM setup, but there have been multiple attacks against multiple implementations of it. I even recall reading once where one of the PaX/grsec guys was basically saying "yeah, you realize this is just a stopgap right? It's not a magical like a lot of people are pretending", but I can't find the link at the moment.

    You would only choose not to use it if the protection it adds is disproportionate to its cost. These days ASLR is inexpensive relative to the protection it adds so you'd be silly not to include it.

    If a given implementation is pretty much 'done' and robust then sure. If it's nowhere near bulletproof and this is an ongoing arms race, and/or if it's going to require a lot of code refactoring to enable it for something specific, I would question whether it's worth making the top priority. The Qubes team isn't huge, but they have already produced a surprisingly user friendly general purpose GUI desktop distro. I believe that security-by-isolation principles, using full OS (para)virtualization, are ideal for many other contexts, but this isn't widely talked about. (Partially because they've been overshadowed a bit by Docker/LXC, which is great for userspace but can't protect you from kernel or driver exploits.)

    But if using ASLR is a simple matter of setting a flag by all means, do that. I just think the conversation and manpower are better focused elsewhere. I think the conversation clearly needs to be shifted. There are no forks / "based on" / companion distros of Qubes that I'm aware of, and a sad lack of third party produced templates (though I did stumble on a MirageOS based replacement for the firewall VM the other day that sounded pretty neat.)

  16. Re:computer security is like birth control by Shane_Optima · · Score: 1

    To acknowledge my own limited research in this area, there are probably other Xen-based projects I'm not aware of that do security by isolation, but if they do exist I'm not sure why their codebase couldn't / wouldn't overlap a lot with Qubes'. The stuff Qubes does with templates, driver isolation and network isolation are useful just about anywhere.

  17. Politics guarantees ineffective measures by golodh · · Score: 2
    Fairly obvious it might be, but it's also fairly obvious that quite a lot of manufacturers simply chose to ignore the problem.

    And why?

    It costs money to think of the problem, it costs even more money to evaluate any risks, it costs still more money to think about fixing them, and it's downright expensive to actually implement any fixes.

    Incorporating cyber-security risk management will be part of the development process as soon as people are willing to pay for it. Which they aren't, because they can't see it so they can't even check it's there. Plus, it's probably a lot cheaper to just settle with any victims out of court than to bust a gut trying to turn medical devices into electronic fortresses. So don't count on the market to fix anything.

    This seems a typical case where "self-regulation" is dead on arrival and only statutory safety requirements will get results. But that's not happening because of politics. Conservative politics to be precise. Pussyfooting about where industry regulations are concerned is the reason we're seeing such a lot of unsafe devices.

    Expect that to continue for the next 4 years. Until and unless someone can whip up a juuuge scare story about ISIS sabotaging medical devices in the US. Oh wait ... what will happen then is that they'll shut down the Internet within half a mile of any hospital and start a fresh bombing campaign wherever. Ok, that won't work.

    Perhaps if some reality star is killed through a hacked medical device? Or a photogenic child?

  18. Re:hail! government makes us safe! by mean+pun · · Score: 1

    ... Or the people of the US finally realise they should elect people that can actually govern properly. I'm an optimist, but let's at least keep mentioning this option.