Slashdot Mirror
Should the FDA Assess Medical Device Defenses Against Hackers?
gManZboy writes "The vulnerability of wireless medical devices to hacking has now attracted attention in Washington. Although there has not yet been a high-profile case of such an attack, a proposal has surfaced that the Food and Drug Administration or another federal agency assess the security of medical devices before they're sold. A Department of Veterans Affairs study showed that between January 2009 and spring 2011, there were 173 incidents of medical devices being infected with malware. The VA has taken the threat seriously enough to use virtual local area networks to isolate some 50,000 devices. Recently, researchers from Purdue and Princeton Universities announced that they had built a prototype firewall known as MedMon to protect wireless medical devices from outside interference."
More money down the shitter. I can't think of anything a hacker would gain from a medical device. What would be the point? Are hackers just evil and nefarious and out to hurt people in the hospital for the lulz? I doubt it.
Yes, they should. It should be a separate certification that allows doctors and consumers to chose medical devices with confidence.
Because assassination via pacemaker, like in the book Rain Fall (http://goo.gl/IwVPC), can happen to anyone.
If magnets can be used to reset or interfere with a pacemaker, should ownership of magnets be considered a terrorist offense?
My refrigerator can take more lives on an airplane than your bottle of shampoo.
Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
1) Can't abbreviate VLAN properly
2) A firewall for wireless devices
3) attracted attention in Washington = some politically connected consultant is making bank
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Quick, TSA enact law forbidding laptops onboard airplanes, so the evil terrorist don't kill implanted people in flight!
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Yes, but devices as important as medical hardware should be ROM only operation with the ability to be flashed for updates only by vetted, qualified licensed personnel.
Anyone caught intentionally cracking anything should get, at a minimum, 20 years of hard labor. Intentionally trying to harm or kill someone attached to a medical device should be a hanging sentence. Full stop.
Embed the device in concrete and sink to the bottom of the ocean. Virtually hack proof.
It's also great for annoying servers that won't patch and people who send meeting invites with no description...
crazy dynamite monkey
Before worrying about security of the software, how about worrying about the correctness and fault-tolerance of the software and hardware?
Most famous is the Therac-25 incident, but it's not the only one.
Stop making the goddamn things wireless!!! WTF are you thinking??!!
If you have a pacemaker, then you're already 'zipper-chested,' so the addition of a firmware update port would be a non-issue.
Or hey,here's an even better idea: Make the goddamn things right in the first place, so they don't need software updates! I mean, fuck, we're not talking about a SOHO router here, we're talking about a device people rely on to not fucking die; One would think they would be better engineered.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
Yes, they should. It should be a separate certification that allows doctors and consumers to chose medical devices with confidence.
Personally I don't trust the FDA with something like this nor do I think it would help to give them funding to expand their expertise in a field like security. I don't even trust the best in the private world with something like this: Microsoft, Apple, Google, IBM, I don't care they all have failed at security at some point. I have to imagine that our government's security agencies already have a generalized form of protection testing and certification within their own systems, why not reuse that process and actually get some use and protection for citizens out of said government money vacuums?
My work here is dung.
Whichever federal agency takes charge could offer a large reward for security holes/bugs found in applicable systems. The agency would validate claims, pay an applicable reward to those who reported the issue, then bill the offending company for the reward.
The idea is to make the reward large enough that it is more profitable for people to report a flaw then to abuse it. Government involvement would be the review of claimed flaws, not to access the security of every device. Private companies would then have a financial incentive to ensure their code is secure.
No, becuase they will just use it as an excuse to raise prices on everything, and to grab more personal information.
absolutely.
The Kruger Dunning explains most post on
If a medical device can be made available to heads-of-state, why not task the NSA with proving that it won't be a vector for carrying out a political assassination?
More money down the shitter. I can't think of anything a hacker would gain from a medical device. What would be the point? Are hackers just evil and nefarious and out to hurt people in the hospital for the lulz? I doubt it.
Some just do it to see if it can be done, some of them *are* out to extort money and will hurt people in the process.
And the hackers, if caught, should be charged with attempted murder. And if someone acutually dies, then charged with murder.
to have the entire Medical Insurance industry restrained from having anything to do with this?
Let's stop their meddling before this even gets started!
More ridiculous government nonsense.
There are already a million and one law about unauthorised computer access and there are already a million and one law about causing harm to people, and this situation falls under all of those provisions already.
This is just another way to raise the costs, increase government apparatus, increase government spending, lower the economic activity and probably this is going to end up costing a number of lives, as products are prevented from entering the market at all or soon enough at lower costs.
You can't handle the truth.
to hack someones medical device.. I mean seriously. There are certainly some jerk offs, but it's a bit alarmist to need to spend all sorts of money to protect medical devices against hackers.. They've been reading the interent too long they think everyone really is that big of an ass hat in real life..
Single pad encryption has been proven to be unbreakable. Each device can be assigned a specific key, kept in a safe, that a doctor could use to communicate with a device.
So some rich assholes can feel safe? Really?
How about just making "hacker proof" hospitals for assholes.
This is so far outside any reasonable scope of the FDA's mission as to appear absurd on its face, either in terms of cost or benefit. The 'safety' of medical devices and treatments as regulated by FDA has been compromised by the machinations of industry and politics to the point that it's efficacy is already questionable, and I can see no 'reasonable' excuse for expanding this mission to encompass the question of security at the level inherent to this proposition. If crimical hackers, governments or corporate industry becomes so corrupt that this line of attack is used, then it's encumbent upon the security industry to provide coverage for the few individuals who might fall prey to such an attack.
And if it can be shown in court that a company is negligent in providing an insecure device vulnerable to some known and defensible means of attack, then it's up to industry to correct the oversight or suffer the consequences.
Good Luck to all you private citizen/corporations and indviduals possessing any reasonable fear. (Oh, and you too Mr. Cheney.)
They already have to certify medical devices that are essentially Windows boxes with medical software. Often times, these vendors get quite snippy if you ask about security software on said devices. These boxes will never be updated in all likelihood. During the course of certification, security definitely needs to be considered.
If you don't protect a computer (whatever shape that computer comes in), some hacker somewhere will hack it just because they can. The fact that the computer controls a piece of factory equipment, city sewer system, a person's pacemaker or any other thing is irrelevant. Someone will hack it because they can, that's just the way the hacker works.
Companies have a habit of saying something can't be hacked, would be impractical to hack, or no one would want to hack our /whatever/ for decades. Hackers than have a habit of exposing the exploit when said company ignores their work. Why does the form factor make a difference?
Something definitely needs to be done because I can vouch that very few programmers even consider security, especially embedded software developers. It is worse than average in the medical industry since the idea of putting a medical device on a network is totally new to them. To put it in perspective, many new medical devices being built today use 9600 baud serial ports for communication.
Alternatively, you could change the law so that if someone hacks a medical device the hacker is not liable - the designer is. That way, when someone remotely sets off a defibrillator or stops a heart pump the companies will pay attention to security. The way things are today they will just hire extra lawyers to avoid liability and marketing to cover it up.
I worked in the industry for 20 years, in all that time, I never encountered a single medical device that employed even the most basic notions of security adequately to withstand anything resembling an "attack." Many of them were vulnerable to random noise.
We're already years behind the curve where I work (hospital) because FDA certification costs so much. Yay, because the vendor won't spend another $50K or so, our brand new IV pumps are stuck for eternity with 2.4GHz radios (802.11b/g). Also, because the older model that could manage 4 IV's at a time was so buggy, we're replacing them with the wireless ones that only do 1 IV. Wireless because the drug database updates can be pushed, saving a ton of time putting hands on each device. Now we add a bunch of extra access points on low power to avoid cross-channel interference and spread the load around.
Then there's bedside meds administration. There are some devices with 5GHz radios, but our people don't like them. Great. More load on the shitty 2.4GHz spectrum. Seems like every week there's a new project that "has to have wireless to work".
Dick Cheney had an LVAD, or a Left Ventricular Assist Device, implanted in 2010. Hmmmm.
Some days it's just not worth
chewing through my restraints.
If they don't protect medical devices, including implants against 'hackers', then the politicians who run the FDA won't get the bribes they need for reelection from McAffe, Symantec and Kapersky. This is important stuff, people. Now we just need a paid 'security analyst' to go on TV and frighten grandma "Yes, it's technically possible a person could die" during her mid morning 'news'. That's right after the story about the baby with 3 heads, but after the inspiring story of a dog who saved its friend...a chicken, from a house fire. AWWW.
While a competent security assessment is a very good idea, I highly doubt the FDA is capable of doing it. More likely this would result in another basically worthless "security" certification.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
...The FDA pulls their head out of Monsanto's ass first before they ask for any more money to goof with technologies they clearly don't understand.
~Just as a thing fails if it lacks a kernel, so too it fails if it lacks a skin. ~ Rumi, Discourses
I'm not sure if the FDA should set computer security policies. That seems well outside their wheelhouse. That said, security policy on devices should be too dumb to fail.
I can see the virtue of a wireless programmable pacemaker. But the security system should be something that can't be tampered with... not because the security is good but because it LITERALLY cannot be tampered with... at all.
For example, instead of using bluetooth (just an example) or something that is a radio signal, maybe use a different sort of signal that requires body contact but not partially close contact. I'm sure you could send a very weak electrical signal into someone through a finger or hand that a device could pick up. And it would be very hard for a hacker to touch someone, send a signal to their pacer through that contact, and potentially kill them. Especially when compared to a more remote signal that someone might be able to send from across the room.
So I guess I'd suggest they avoid certain types of technology for transmitting commands. And even then I'd strongly suggest some decent encryption but I wouldn't have the FDA regulating it. I'd sooner put the NSA in charge of setting those standards. They'd at least know what they were talking about.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
we have hacking laws now. Just the fact that they are medical in nature doesn't change the laws.
Sure, it's worse if the products are in people. We have laws for that too -- Attempted Murder, for example.
Is not some lame "hacker" (should be cracker...) but instead the everyday crappy bread-and-butter code. See e.g. http://www.softwarefreedom.org/news/2010/jul/21/software-defects-cardiac-medical-devices-are-life-/
But I guess spouting silly buzzwords like Terrorism and "SOMEONE THINK OF THE CHILDREN" gets more funds and makes more striking headlines than cool headed reasoning... Oh boy.
Magnets are used to disable or suspend operation of the device (therapy). The devices can malfunction where an inappropriate shock is repeatedly delivered. There are also times when they need to be disabled. When a magnet is placed on the device there is a rather loud alarm. Magnetic fields can also pose a problem as the lead(s) that transmit the minute electrical impulses from the heart muscle to the ICD can also act as an antenna. They tell you 'don't lean / don't linger' around certain electrical devices and things that generate a strong magnetic field - security posts leaving a store (I am aware of one documented 'event'), working on a running engine, and the like. There a times that I do not want to be 'surprised' because of something I'm doing at the time.
Some devices are capable of transmitting their data to a 'base station' that later transmits the data to a server for examination by a physician. I did not RTFA yet, but am curious to know if the malware infection is in the actual device or the base station / server network. My device is not one of them. It requires an antenna to be placed over the device and after some handshaking, the data is transmitted to the controller / monitor. I have been playing with it and have been able to communicate with it up to a distance of 10m. With a better antenna design on my rig I think I can get it up to 30m.
Yes, I am 'zippered' - three on the left leg to remove the spare 'plumbing', large vertical n the chest - where they installed the now spare plumbing parts to reroute blood flow in three places, three little zips below the rib cage for temporary drainage, and don't forget just below the left collarbone to implant the ICD. Even with all of these zippers, I would not allow an constant open wound for a firmware port. That is an idea waiting for an infection. Also, they don't stitch anymore so there is no zipper. It is more like the 'ZipLock Club' now with the use of superglue and packing tape - you know - the stuff with the threads imbedded...
BTW - they don't replace the battery on these devices, they replace the device..
In other words, a literal "solution in search of a problem." And an excuse to give an already corrupt and counterproductive government agency more power.
Liberty in your lifetime
We leave security up to the customers. Generally because they already have their own corporate security technology stack and also because we're built on top of windows. We're mostly running java so it wouldn't be completely out of the realm of possibility to run a more secure OS.
That being said, working with the VA has been a genuine pain in the butt. Mostly because they purchased a product without realizing that the data analysis took place on a web based cloud platform. Because of them we re-engineered our product into a new product where they could buy a standalone server to do the processing.
Medical devices don't just include things like implantable equipment (such as implantable defibrillators, pacemakers, pumps, etc.) but analysis equipment, and more recently computer software running on regular PCs (such as electronic patient records, order management systems, digital X-ray system/picture archiving and communications systems), etc.
Implantable devices have been in the public eye recently because they don't use very secure protocols. Typically, the wireless controller transmits a command prefixed by the serial-number of the implanted device. The device then ignores commands which are not prefixed by the appropriate serial number. This is OK for preventing programming the wrong device in a clinic situation, but a hacker could easily perform a replay type attack to cause the device to administer an inappropriate treatment or dose. One reason that manufacturers have given for this is an extremely limited power budget - strong cryptography simply burns too much energy for a device which cannot be recharged.
One problem that has concerned me as a user of medical software is just how poor the security is on a surprising number of products. One product that I use at the moment is part of an electronic patient record system. This system doesn't quite store user passwords as cleartext in the database. However, instead, it encrypts them with a Vigenere cipher (using the username as key). However, because of excess load on the database server, the software very concienciously caches the entire "Users" table as a CSV file on the client computer. Yes, when I discovered the file, it didn't take long for the Mk I eyeball and my recollection of my password history (which was also documented in great detail in encrypted format) to determine the cipher and what was being used as the key. This was subsequently confirmed by running the binary through a decompiler, which revealed a number of other wonders such as potential SQL injection vulns. Of course, none of that really mattered - there was an interesting file called "C:\epr.ini" which contained such lines as:
[ClientDatabaseConnectionString]
Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=EPRORA)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)));User Id=SYSTEM;Password=pyramid1;
However, even leaving aside such extraordinarily bad software from small IT contractors, even the big-boys in the healthcare arena seem to have problems with basic testing, and anything even vaguely corner-case will often result in strange behavior - and that's just routine use, I can imagine all sorts of vulnerabilities appearing if these software packages were subjected to serious attack.
In fact, even in healthcare systems which are supposed to be paradigms of good design, implementation is often very poor. Professor Ross Anderson in his book "Security Engineering" mentions a national security system used in the UK for securing health records, where an individual user's smartcard contains an individual certificate and permitted user roles, which interact with the software to release the appropriate records. On the face of it, an excellent system - and one that Anderson mentions as an example in his book. For a user, however, the implementation is a disaster area; it's unreliable (depending on a national authentication server - local caching was broken in the first 11 6-monthly releases) and vulnerable to DOS attacks. Authentication with the national server was hopelessly slow (taking up to 5 minutes) so was useless for doctors in a busy environment such as the ER. The Roles are administered on a national level, with no way to override errors in role allocation before the next 6-month release (e.g. the first few releases did not permit doctors to change the brightness/contrast of an X-ray that they were examining - this function was restricted to sysadmins only) - the user role administrators acknowledged that this was a serious problem, but refused to push out a hotfix, instead it had to wait for the next role release. In reality, the nurse in A
I don't understand why this problem is so hard. It's not something like a browser, which has a huge attack surface. You just need the device to refuse to communicate until you've gone through an authentication handshake, and make that handshake protocol secure. How are the medical companies screwing this up?
Yes because it has been proven with our medical records that nothing is safe. However thats where the VA and DOD should start as all of our records can be read with a wand now.
87,000$ Windows 2000 computers with a nice acquisition card in a custom box connected to the internet so all the doctors can look smart video conferencing in a dark room filled with LCD screens.
force them to let the hospital IT team to do windows updates / install there AV software / there firewall software.
Also they can't force the device to go connect to a 3rd party out site sever. If they need some kind of sever to talk to it must be open to being run in house with full admin the sever OS to the IT team so they can install the windows updates / AV software.
I'm pretty sure that regulation currently prohibits hospital IT and others to change the medical device software (yes, AV, drivers, OS also belongs to that) to some configuration which has not gone through validation testing.
My experience is that the fda currently has no concerns about cyber security. Case in point, the FDA was notified (several times) that a certain drug alluding stent manufacturer (chicago based) has very lax security in several critical engineering and production database systems that control, track and audit their manufacturing processes of all their vascular products. These Oracle database systems used passwords that matched their user names for dba privileged accounts. These accounts have been in place with these same passwords for over ten years. one of these systems even handles the patients interactions with the products. The FDA was anonymously notified of this over a year ago, the fda even conducted an audit - they found some paper work dependencies in the IT department - but today the usernames still match the passwords in the production systems and no attempt has been made to determine if any data was ever modified outside of the normal audit trails required of these sensitive systems.
Should they get involved assessing medical devices against hackers? Maybe. But first how about getting them involved in assessing medical devices in general? Ok, so medical devices from the FDA's standpoint encompass everything from simple mechanical gizmos all the way up to complex microprocessor based devices. So, specifically in regard to the "computer" type devices, you know the FDA doesn't really "asses" them at all in general. Their requirements are for the manufacturers to "use industry best practice" in their development process and to have a QA system that shows they're adhering to whatever process they've settled on.
The FDA doesn't exactly assess any code or designs. In fact most devices get approved via a 510(k). In theory this is a process to show that the device is safe. However there's a huge get-out : if you submit your device as a "substantial equivalent" of a device that is currently legally marketed then you bypass onerous testing... In fact you don't really need to prove much if there's already something similar for sale. This has a daisy chain possibility too - if you can prove a chain of equivalency back to a device that was legally on sale in the 70's when the act came in to being that was never proven to be safe in the first place, yes you can use a 510(k) to sell one today... This sort of made sense back in the 70's, and for mechanical devices where there's not so much variation but for the complexity of software and hardware, personally it scares the crap out of me.
A slight diversion but in summary : Worry about the basic functionality being verifiable safe in normal operation before getting excited about people causing problems outside of normal operation...
Some light reading for the interested. The IOM brief about the 510(k) process :
http://iom.edu/~/media/Files/Report%20Files/2011/Medical-Devices-and-the-Publics-Health-The-FDA-510k-Clearance-Process-at-35- Years/510k%20Clearance%20Process%202011%20Report%20Brief.pdf
IEEE reporting on how FDA approved defibrillators can be useless yet not made any safer by the FDA's procedures :
http://spectrum.ieee.org/biomedical/devices/the-shocking-truth-about-defibrillators/0
The FDA is a millstone around the neck of freedom. It should not have the power to prohibit anything, only to certify some things as "approved". If everyone at the FDA were unemployed tomorrow it would only be what they deserve.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
As someone who works in the industry (I develop software for radiotherapy treatment systems), I would welcome this. Far too many devices developed and engineered (including some of our own) have incredibly lax security sadly:
- They run as administrator under Windows (XP), because of the lack of inertia in the industry, tracking state of the art OSes is very slow (some devices still run NT4!), rather than Win 7 etc. They've often been badly designed that way (in spite of engineers protesting!) e.g. writing to HKLM, \Program files etc, which makes it hard to run otherwise.
- They do use firewalls BUT often have internet/hospital LAN access often for tech support purposes- which as I've shown my boss numerous times means you are as strong as your weakest link - that malware loaded on the hospital network can get to the systems.
We're slowly moving in the right direction but it's very slow and putting such potentially vulnerable software systems in charge of potentially dangerous hardware is certainly unwise - while it's unlikely that machine movements/xrays could be invoked remotely (we use dual channel control - i.e. dead mens handles etc), it is entirely possible that patient data could be corrupted, held to ransom by ransomware that encrypts etc.
then what about when crapware gets on a unpatched system and starts spamming the network and you can't block the system on the firewall as it needs to talk to outside systems?
As of 2005, there wasn't. Below is a link to a transcript from a presentation given by John F. Murray Jr., the Software Compliance Expert from the FDA. In it he says directly "Well there’s no regulation that prohibits a user from modifying a medical device." Even so, device manufacturers bear the ultimate responsibility for ensuring their device is safe and effective.
http://www.fda.gov/MedicalDevices/Safety/MedSunMedicalProductSafetyNetwork/ucm127922.htm
then what about when crapware gets on a unpatched system and starts spamming the network and you can't block the system on the firewall as it needs to talk to outside systems?
Hospital IT can put a firewall between the medical device and the hospital network and configure it accordingly. Or detach the system from the network and call service.
FDA states on this topic pretty clearly (http://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm189111.htm):
"All software changes that address cybersecurity threats should be validated before installation to ensure they do not affect the safety and effectiveness of the medical devices."
This pretty much means that the medical device manufacturer has to validate OS and AV signature updates before allowing their own service or hospital IT to install to systems. This also implies that auto-update of OS and AV must be disabled.