Slashdot Mirror
FDA Releases New Cybersecurity Guidelines For Medical Devices (theverge.com)
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.
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.
"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."
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...
Is this the same federal government that still hasn't released full security guidelines for Hippa? And how much older is the Hippa issue?
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
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.
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.
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.
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.
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.
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.
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?