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."
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.
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.
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
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.
Really? How about a hacker selling malware to the highest bidder that could be used to assassinate someone with a medical implant, or while they are recovering in the hospital after surgery? That's just two I can think of off the top of my head, I'm sure there are more.
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.
The problem with that is every time you want to update the device you have to physically get to it.
Taking updates wirelessly makes things much easier and safer.
As far as (EEP)ROM-only, that's good for the code, but many devices log data (and dump it out wirelessly).
You have to protect against attacks that try to make the device do bad things as well as attacks designed to get or overwrite that data.
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.
There are a ton of other implanted devices, not just pacemakers. A lot of these devices might need to be adjusted to make a patient "not fucking die" - it isn't about system patches, it's about making medical adjustments to things like the dosage/voltage/rate/etc that the device is pumping out. You can't tear someone open every month when you need to adjust their insulin pump.
Things like record keeping blood bank software is regarded as a medical device by the FDA. Such software can contain sensitive information like you Social Security Number or drivers license number. In Sort, a hacker can gain plenty from breaking into a medical device.
Speaking as someone who has worked in the software side of the medical industry I just want to say that this is long overdue and the FDA has their work cut out for them. The systems I worked on are laughable in their "security" as they typically rely on how secure the local intranet is. Software vendors rarely put in any kind of serious authentication methods.
absolutely.
The Kruger Dunning explains most post on
I see two major areas of concern with, arguably, quite different requirements:
1. Implants/embedded systems with some measure of field-programmability: On the plus side, these are much more likely to be running something fairly esoteric, possibly not even an OS at all, possibly some RTOS or embedded OS. They are also likely(for the moment) to have only short-range connection capabilities, quite possibly over a somewhat obscure protocol. This makes them low risk devices in terms of untargeted worm/phishing/etc. attacks, by virtue of limited connection and oddity of software. On the minus side, being directly connected to the patient, these offer a handy target for personally-directed sabotage, possibly from a surprising distance, depending on the whims of the RF gods(surely, the first person to reinact the classic 'sniper on the roof, suit with bodyguards crossing the parking lot toward the armored limo' scene; but with a rifle-stocked Yagi and lethal exploit code for the suit's pacemaker will be awarded a signed copy of every cyberpunk book of note).
2. Systems that have much more in common with the PLCs and management console computer systems that we are always complaining about in factory scenarios. That box running WinNT SP2 connected to a monstrously expensive diagnostic science machine, etc. etc. These are much more prosaic, just badly patched and outdated WinSomething boxes that really ought to be air-gapped properly, which makes them much more likely to suffer lots, and lots, and lots of expensive downtime when they eventually cave to the demand for electronic transmission of radiology data to another hospital for a consult and hook the sucker to the internet....
'Type 1' stuff seems like it would be best off with a "When in doubt, don't" approach: Don't interpret unsigned inputs, use very short range(inductive rather than RF, say) interfaces. It won't be perfect; but it'll at least confine the universe of potential hackers to people who could have just shived you anyway.
'Type 2' is where the mess really hits. Like industrial stuff, the economics of ripping out expensive capital investments are Deeply Unexciting; but persuading the vendor to deliver a service contract that doesn't read "Fuck you. Buy a Model N+1" is going to be a challenge. Also the (by no means necessarily false) promises of various 'telemedicine' applications are going to be constantly tugging at the people who run that stuff, urging them to connect it up. That isn't go to go well at all...
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?
Yes, safer, in the sense that you don't have to go in for surgery every time the settings on your implant need to be adjusted.
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.
You haven't been on the internet long I see.
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.
You can't tear someone open every month when you need to adjust their insulin pump.
I understand your point, but... As a user of an insulin pump myself, I'd like to clarify that it is an external device, usually carried on the belt or in a pocket, as it needs to be refilled every few days and adjusted quite often. There are implantable insulin pumps in existence, but these are primarily for research purposes, and are not commercial devices to treat diabetes.
>> Standing on head makes smile of frown, but rest of face also upside down.
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?
How likely do you rate it that a random malware author will put special safeguards into his spam botnet worm to ensure it does not interfere with the operation of a medical device should it happen to infect one? Right now, this cross-infection is unlikely due to incompatibility - in the future, the platform running on a specialized medical device could be susceptible to the same viruses as a desktop computer.
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.
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".
I would rather they try to patch the security holes *before* we start charging people with attempted murder and murder, personally.
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.
Glad to see you've fallen in love with the DMCA friend! Anything that could lead to crime should be a crime aye? Never mind how close that comes to dangerously impeding our legitimate rights to freedom of speech including research that includes circumvention of various controls.
On the Oregon Cost born and raised, On the beach is where I spent most of my days
Are hackers just evil and nefarious and out to hurt people in the hospital for the lulz? I doubt it.
Well, two issues, here. First, you seem to be assuming "hacker" roughly equates to "guy who messes with computer-stuff for the heck of it". There most certainly are hackers/crackers (depending on your preferred use of the term) who harm people and systems, sometimes for money, sometimes for fame, sometimes for fun.
Aside from that, a hacked medical device makes for a really easy way to kill someone from a moderate distance and leave very little trace of whodunit. And I'm not even going to begin to consider all the reasons a person may have for wanting to kill, or even simply extort via credible death threats.
It's not limited to hospitals, either. I have Type I Diabetes (the autoimmune strikes-randomly and needs-insulin-to-survive type) and so I always wear an insulin pump jacked into my abdomen. In the pump, there is an insulin cartridge which contains a large reservoir of insulin -- injecting 1/20th of the reservoir could kill me if I'm not treated quite quickly. Injecting the whole thing is a death sentence if I'm not already in a hospital bed and hooked up to an IV. The kicker is that the device has RF access, and is likely hackable. I have turned off the RF from day one (partially due to the battery drain, partially due to my worries of a possible hack or mis-delivery) and sacrificed some of the pump's features, but most pump users will not do this.
It's a glaring vulnerability in a life-or-death system.
>> Standing on head makes smile of frown, but rest of face also upside down.
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.
A lot of these devices might need to be adjusted to make a patient "not fucking die" - it isn't about system patches, it's about making medical adjustments to things like the dosage/voltage/rate/etc that the device is pumping out.
OK, so use a physical connection; as I said, if you have a pacemaker then you're already scarred all to hell, what difference will an 1/8" serial plug make?
Someone below mentioned magnetic communications, which sounds just plain awesome.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
"Rich asshole"? Seriously, a pacemaker isn't just for the rich asshole. Failing to assess these devices for security controls would be ridiculous negligence. Malicious software has a tendency to spread where it can, it doesn't need a reason to compromise a pacemaker if its able to. I guarantee that if proper security controls aren't implemented in medical devices you will see deaths related to failed or compromised devices. It doesn't even have to be intended malice, if a piece of malware compromises a device and decides a reboot is necessary, guess what happens to the heart behind the pacemaker...
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.
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
My area of concern revolves around the VA stating they have "isolated some 50k devices with vlans." This implies two things: 1) They're already networked such that they can be placed on their own vlan (or, at least the controllers, or whatever connects to that RF int) and 2) the VA is under the impression that a vlan is a legitimate security measure worth promoting. I do not want something controlling my insulin pump, which is capable of killing me, hooked up to the network. AT ALL.
"Sorry, your daughter died because our network had a brownout and the switches stopped switching, so it interpreted the input from your TV remote which you pointed the wrong way as "PURGE INSULIN." Ugh.
It's unlikely that a would-be assassin will learning the art of medical implant hacking in assassin school on the off chance that he'll one day have a target who just happens to have such an implant. As with today's black-hats, who focus on Windows over Linux (well, until the recent Mac headlines), their efforts will concentrate where they get the most leverage -- on cars. Even people who don't drive almost surely step into a car fairly regularly. The high-tech hacker-assassin may eschew the "old bomb under the chassis" bit, but why not a drive-by reprogramming of the ABS computer to disable the brakes when the car hits highway speed?
Great TED talk on this topic here
There are much easier, and explainable, ways to kill someone. What assassin leaves a paper trail?
This whole thing stinks of a bunch of people selling a service no one needs. Symantec, McAfee, and friends used to make good money pushing out anti-virus software; then worms where the big problem, so they adapted; then mal-ware was the new problem, so they adapted; MS got bitched at left and right about the security issues with their platform, then they released Microsoft Security Essentials; Windows XP is being phased out, Windows Vista is as well, and Windows 7 is slowly taking over, with many of the old exploits being patched. These companies, if they are going to survive, need a new schtick. Seeing the writing on the wall, they converted themselves to 'security consultants,' and began lobbying Congress for contracts to fight 'zee evil Hackers, unt!'
You've noticed the sudden influx of articles focused on finding some 31337 h@xors. They can't find any, but the money is too good to give up. Sooner or later, they're going to need to invent some, if they want to stay on that gravy train.
I am John Hurt.
No matter where you set the bar, sooner or later the universe will deliver you a bigger asshat.
The would-be assassin doesn't learn how to hack medical implants. The assassin goes onto an underground forum and looks for vulns that match a specific target device that the assassin's mark is using.
:(){
It's unlikely that a would-be assassin will learning the art of medical implant hacking in assassin school on the off chance that he'll one day have a target who just happens to have such an implant.
many implants are expensive, and I suspect there is a strong correlation, at least in some countries, between "has more money/power than average" and "more likely to have implants". Therefore, you are learning an attack against a group that self-selects to be a more tempting target, for either extortion or assassination.
Define "enough". Of course if you set off an EMP, most electronics will be fried. Is it practical to apply enough EMI to a device to cause a failure? Keep in mind that FDA and FCC tests are pretty stringent and there are a ton of certifications you need in order to sell an implant.
:(){
I would rather they try to patch the security holes *before* we start charging people with attempted murder and murder, personally.
You can never really be certain that every security hole has been patched though, after all programming is the art of adding bugs to software.
"To prevent this day from getting any worse, I'll just read ERROR as GOOD THING" 1GJU8xLuDKDxEs4KLf8fAGyptoDsqvEsBT
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
All surgery carries risk, so easier AND safer.
Actually, the socket would add a great deal of ongoing risk of infection.
The thing is, it's not just for firmware updates. More commonly it's to alter the parameters of it's operation or even to adjust on the fly. For example, an implantable insulin pump may respond to the result of a glucose meter reading.
A better answer is to require a magnetic switch to be activated for the entire time communication occurs.
I can see this happening mandatory medical devices with mandatory health care. When you don't pay your taxes or pirate a movie or something the secret code to break the hidden cyanide capsule is transmitted.
Or the government can get rid of crazies like you simply by tightening up the straps on your tinfoil hat until your eyes bug out.
Faster! Faster! Faster would be better!
Quite. A lot of our "medical devices" are actually software programs running on PCs. Many of them require a specific environment to run.
I can think of one package that will only run on: Windows XP32-bit (No service pack) and Java 1.4. It simply won't run on anything more recent (no idea why), and the developer of this (very expensive) package has gone bust, and the product is no-longer supported (but the finance department budgeted on a 10 year usable life-span, so it's not getting replaced for 10 years following installation).
I've no idea of the total number of vulnerabilities on the combination of unpatched XP and Java 1.4- but I suspect, the number is substantial.
The guys with inflatable penis implants are going to be very nervous, very soon... UpDownUpDownUpDownUpDown
Up and down aren't a problem for a penis, nor are left or right, but how is the poor fella supposed to manage B and A?
If God forks the Universe every time you roll a die, he'd better have a damned good memory.
Why not install a 1/8 serial plug? It would become a focus for all sorts of horrible fungal and bacterial infections.
Not to mention that somebody would try to plug their iPhone into it.
Faster! Faster! Faster would be better!
For semi or permanently patient-connected devices, I'd really want to see some good, old-fashioned, physical interlocks where possible.
If, say, a device needs some sort of adjustment from time to time, it wouldn't be terribly taxing to have normally-open reed switch that physically disconnnects the external programming interface unless 'activated' by shoving a magnetic key into the programming slot. It doesn't stop a truly malicious actor, subtly planting malware to strike during planned program/sync periods; but it does mean that the entire world isn't fuzzing your security 24/7...
It would also be nice if (analogous to devices that have contact with patient tissue/fluids) any programmer/interface device used to manipulate implants and near-implants could be 'cleaned' by verifiably flashing a manufacturer approved memory state onto the unit before use.
The more complex(and, to look at history so far, probably not solvable) problem are the bigger devices, almost all built around embedded computers running obsolete OSes that you aren't allowed to change; but which you want to be able to communicate with other devices so as to swap diagnostic data, schedules, and who knows what else about. These are also the ones where massively expensive downtime, massive data breaches, or lingering infections requiring something little short of burning everything would be most likely to crop up.
Having somebody write an assembler virus for your specific brand of pacemaker and somehow sneak it in to your programming session is so much effort that it's practically a complement. The fact that millions of dollars of fancy medical gear will be good for little more than spewing the Klez worm the moment somebody's precious 'airgap' is compromised by a cleaner replugging a wire is simply a sad inevitability...
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.
That's a little like saying it's up to the victim to secure their safety. If that same person walked into a patient's room and started fiddling with their heart pump or dialysis machine, I could see charging them with attempted murder. We don't say 'gee, we'd better not charge him because the hospital didn't put a lockable steel cage over the panel to the dialysis machine to keep people out.' Just because the network is the means of intrusion, as opposed to going into the room, doesn't give someone a pass if there are security holes in the software. You're still f**king with someone's life. That being said, it is *is* incumbent upon the hospital to ensure your safety, especially when you cannot react (i.e. unconscious). It is up to the device manufacturer to make a safe product. In both those instances I think you should be able to take the manufacturer or hospital to court. From that standpoint, fear of losing their shorts in a law-suit and subsequent bad press, I think that they may pay more attention to security.
Leave the gun, take the cannoli -- Clemenza, The Godfather
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.
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.'"
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?
Seriously, look if I go onto Google and try that right now..
Hold on, there's someone at the door, brb.
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.