Slashdot Mirror
DHS Steps In As Regulator for Medical Device Security
mask.of.sanity writes "The Department of Homeland Security has taken charge of pushing medical device manufacturers to fix vulnerable medical software and devices after researchers popped yet another piece of hospital hardware. It comes after the agency pushed Philips to move to fix critical vulnerabilities found in its popular medical management platform that is used in a host of services including assisting surgeries and generating patient reports. To date, no agency has taken point on forcing the medical manufacturers to improve the information security profile of their products, with the FDA even dubbing such a risk unrealistic (PDF)."
It seems the DHS keeps expanding its mandate into ever broader areas.
And, quite frankly, that's a little creepy -- it's becoming this vast umbrella which has control over everything.
Lost at C:>. Found at C.
Technology in hospitals? Good.
Internet-connected technology in hospitals? Why?
Sure, people in hospitals need information, but surely something which is assisting in the physical process of a surgery (etc.) doesn't need to be in the cloud, does it?
The cloud can be cool, but be reasonable. Why not put the operations of the CIA into Salesforce.com while we're at it?
cause the DHS does such a fantastic job with all its other responsibilities so why not give em some more to do
After all, DHS must have _some_ use. This might turn out to be it.
manufacturers need to let os updates and AV software to be install on there systems if they want / need to be on the hospital network. also why do they need to phone home as well?
Or they could take the money assigned to DHS for medical device security and instead design a universal open-source electronic medical records system where security is maintained constant peer review and no one company has a monopoly on EMR's system.
I know, I know. You can stop laughing now.
I can't wait to get rid of him.
When an entire agency is tasked with finding bogeymen under beds they have to get creative to justify their funding.
Does this mean that DHS has access to source code and 0-day vulnerabilities for network attached medical equipment?
Could this knowledge be user offensively, in a situation where say Kim Jong Un is in hospital for a heart operation, and
DHS remotely pulls the plug on the life support machine?
Can this power be later extended to medical devices implanted in people, like defibrillators, insulin pumps etc.
Sorry to sound like Richard Stallman here for a second, but I would be very apprehensive having a device implanted in my
body that runs proprietary software, whose code development is overseen by a division of a shady foreign military agency.
Here is someone who got stonewalled when asked for the source code for the device she was to be implanted with...
http://www.youtube.com/watch?v=5XDTQLa3NjE
Thanks go to Homeland for giving them this brilliant idea
I'll bet this is just the DHS' attempt at getting a record with medical equipment, so they can rubber stamp the x-ray machines the TSA uses, to keep the FDA out of the loop.
Learn something new.
I dont think they need to be on the hospital network in the first place, there should be a way for them to update these machines from disk or usb thumb. Also if they do need to be on the network for updates or access to cloud information they should not have access to the web when not needed.
They will of course also want a backdoor installed in any security in case they want to turn off someone's pacemaker or insulin pump.
manufacturers need to let os updates and AV software to be install on there systems if they want / need to be on the hospital network.
Because running untested software is a bad idea. Heath care systems and medical device software should get the benefits of updates and patches, but only after those updates have been tested for those specific systems and software. Whatever the vendor does prior to release is insufficient.
When entire hospital processes come to a halt because the latest AV update mistakenly identifies a core OS file as a trojan, you'll come back and say, why are manufactures letting updates to be installed on their systems?
As with many things, the best path is in the middle. Critical systems should be updated as preventative maintenance, but administrators cannot rely on vendor testing alone.
Is this from the Australian equivalent of the Onion?
We've dropped exploits before on medical systems like Honeywell and Artridum...
Dropped? Is this serious security research or the latest mix tape?
- Pink Floyd
Yeah, there is nothing wrong with that. DHS, the government agency that believes it is alright to do anything in the name of protecting the population, now has control over the pacemakers and insulin pumps of anybody they suspect might threaten the nation or their own power structure. Nothing will go wrong with that.
manufacturers need to let os updates and AV software to be install on there systems if they want / need to be on the hospital network.
Because running untested software is a bad idea. Heath care systems and medical device software should get the benefits of updates and patches, but only after those updates have been tested for those specific systems and software. Whatever the vendor does prior to release is insufficient.
When entire hospital processes come to a halt because the latest AV update mistakenly identifies a core OS file as a trojan, you'll come back and say, why are manufactures letting updates to be installed on their systems?
As with many things, the best path is in the middle. Critical systems should be updated as preventative maintenance, but administrators cannot rely on vendor testing alone.
Why update the software? Pacemakers and insulin pumps were available long before you could wirelessly update them. If it is such a threat, then don't enable wireless updates. Plain and simple. My God, how did we exist before computers did everything for us!?
Cause they regulate their x-ray scanners so well?
Source? I couldn't find anything about it on DHS website.
All DHS hate aside, this is much needed change. We have FIPS and it made our crypto much stronger. We have other standards and procurement requirements (CC, PCI, etc) that made inroads on making sure vendors at least consider security. It is about time the same applied to medical devices.
Why DHS, NIAP or NIST would be more appropriate agency to handle this.
Most people think way too far into it. The goal of the DHS is not to turn the country into an oppressive police state. That's the rainbow, not the pot of gold. They want you to focus on that rainbow -- splitting hairs over which colors are good, which are bad, and which are ugly -- all the while ignoring the enormous pot of gold at the end.
The people who run the business of government are not power-hungry; they are money-hungry. Power is not the end goal in itself, but merely the stepping stone to riches. Yes, it's a despicable, immoral, and unjust attack on human rights. But they do not attack for the sake of sport. They attack for the sake of riches, and your rights are merely the "collateral damage".
AV and OS vulnerabilities is not top security concern. Something like letting unauthenticated user copy entire patient database that for some reason was stored on the device is much bigger threat.
Protecting all terminals is not a very effective strategy for preventing large data breaches. While undeniably required step, it isn't firth thing you do, and it isn't most important thing you do.
For example: Not storing session data locally would be the first step in securing this mess. Preventing access to any kind of stored data without authentication would be second step.
"Everything within the state, nothing outside the state, nothing against the state."
Looks like this is right up the DHS's alley.
When someone says, "Any fool can see
After initial bids to contact Philips failed, researchers Rios and colleague Terry McCorkle sought assistance from the DHS, the FDA and the country's Industrial Control Systems Cyber Emergency Response Team (ICS CERT).
DHS didn't step in as some grand plan. They were asked to intervene by Cylance, a security research company, when Philips wouldn't respond about the detected security holes.
Two days later, DHS control system director Marty Edwards told the researchers the agency would from then on handle all information security vulnerabilities found in medical devices and software.
In other words, "if you (the security research company) find a vulnerability, DHS is the proper channel to report it".
When our name is on the back of your car, we're behind you all the way!
Why update the software? Pacemakers and insulin pumps were available long before you could wirelessly update them. If it is such a threat, then don't enable wireless updates. Plain and simple. My God, how did we exist before computers did everything for us!?
This discussion isn't about having computers do anything for us. It's about how we use computers as tools to do things. How did we have conversations before computers? Well, we did, and yet here you are using a network of computers to have a conversation.
As for the ability to update the software in a medical device, it's about trade-offs and compromises. ObCarAnalogy: computers in cars have made maintenance more complicated, so why not take the computers out of cars? Sure, if you also want to remove the improvements in fuel efficiency, traction control, ABS, GPS, mp3-player interfaces, and all the other things those computers are doing.
Ability to wirelessly communicate with an implanted medical device is a risk? Well, so is having to perform surgery to update that devices configuration or to retrieve data. Maybe the risk (a product of the potential effects of a negative event and the likelihood of that event) of wireless communications is greater than the risk of the extra surgery. Maybe not.
My point is, it's not as simple as "all medical information systems should have updates as soon as they are available from the vendor" or "no implanted devices should have wireless communications."
I could be misinterpreting your message because I can read your words, but not the tone of your voice or body language. So rather than posting a message on /. why don't you come over to my office and tell me face to face? Plain and simple, right?
As with many things, the best path is in the middle. Critical systems should be updated as preventative maintenance, but administrators cannot rely on vendor testing alone.
Critical systems should also not be connected to the internet.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
My God, how did we exist before computers did everything for us!?
Stone knives and bear skins, my friend, stone knives and bear skins.
When our name is on the back of your car, we're behind you all the way!
We are still forced to run a system on windows NT 4.0 here because of lazy medical systems suppliers even thoug hwe are paying thru the roof for those half baked systems. It's about time someone get's the whip out!
They just want their hands into everyones pants dont they?!
Is there a link to a story somewhere? The links in the story don't talk about DHS at all.
You misunderstand my post. I am not saying that we shouldn't have these devices, but if the risk from the software, or somebody hacking the software is so great that homeland security has to take it over, then maybe the very benefits and tradeoffs you mention should be looked at again.
As for the car analogy, computers CAN make cars more fuel efficient, but in reality, they have a smaller impact on fuel efficiency than people think and are really used to keep pollution down and to keep from making the tough decisions that would truly improve fuel efficiency like smaller, lighter vehicles. A 1980 Honda Civic got better mileage than most "fuel efficient" vehicles today and it was computer controlled.
But in reality, the car analogy fails, because it is not the computer that is the problem but the need to be able to update the software remotely and securely. Is this a problem that really requires Homeland Security to solve or even be involved with? If so, then somebody has to ask the question as to whether the ability to do these updates outweighs the benefits. That's all.
It seems to me, that the market can easily fix this problem. Company A says "Buy my pacemaker, it is lower cost." Company B says "By mine, because, it might cost a little more, but then again, you don't have to worry about a stranger with an iPhone turning it off." Which company's pacemaker would you buy? The market is very good at deciding these things, if the market is told the truth.
So, yes, your pacemaker may be vulnerable to somebody hacking it and turning it off and you will die. Then again, without it, you would already be dead. The question is what is the likelihood of your individual pacemaker being hacked and turned off?
Again, the problem is not computers in and of them self. It is what we want to do with them and the trade-offs that must be made to accomplish that. Again, using the pacemaker as an example, it could be as simple as requiring some sort of password. Then again, if only the hospital that installed it knows the password, then what about the paramedics called to your house? What if they need to adjust it on the spot? Most likely, there will be a back door, for the rare situation where that might occur or the hospital simply loses the code. And, like any backdoor, it can be exploited.
I guess, what I am saying is that before turning all of this over to Homeland Security, I'd like to know how many pacemakers and insulin pumps have been hacked versus how many are out there? Is this a true threat or just bad movie plot from the ScyFy Channel that has taken hold in DHS? Or for the paranoid, does DHS want this so they can put their own back door in and turn off the pacemakers of those who are unfriendly to the US?
Again, if it is such a big risk, then go back to when pacemakers and insulin pumps couldn't communicate with the outside world. They might not be as convenient, but if there is such a risk, maybe that is the price to be paid.
As for coming over to your office to meet face to face, well, you'd have to give me the address first. (and please don't).
http://www.medical.siemens.com/webapp/wcs/stores/servlet/ProductDisplay~q_catalogId~e_-101~a_catTree~e_100001,1023065,1015817~a_langId~e_-101~a_productId~e_172960~a_storeId~e_10001.htm
This thing has:
You can bet that on a product of this complexity, there will be updates.
As with many things, the best path is in the middle. Critical systems should be updated as preventative maintenance, but administrators cannot rely on vendor testing alone.
Critical systems should also not be connected to the internet.
Or, to be more precise, should not be connected to the internet with unlimited IP address access in either direction. You can obtain (or at least you can if you're dealing with an important-enough Fed agency) nice little boxes that not only encrypt the crap out of your traffic but are set up only to send to specified addresses and only to receive from specified addresses. Aside from deliberate sabotage, this is a safe way to connect to a manufacturer's update-providing hub.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
The first issue that should be addressed is does anyone believe that 100% total bulletproof security is even possible today? Come on, do you think it is possible to have large, interlocking systems of computers communicating over a network with 100% security?
I think anyone reasonable will say "Heck no you can't!" There might be a few dreamers that think it is possible, but the amount of effort that would be required is beyond any reasonable standard. So sure, it might be possible to force all medical device manufacturers to use a single operating system designed from the ground up for security - but no such OS exists today, not even OpenBSD, and that puts a little crimp in such plans.
So what do we do? Well, there is the idea that access, all access, needs to be logged. Multiple ways with retention of the logs for nearly forever. Also, multiple verifications that you are who you say you are when logging in. Not just biometrics, but things like having to periodically log in with someone watching who then confirms that you are who you say you are. This would be a start, but just a start, for what would be required.
To go along with this there needs to be the kind of draconian penalties dreamed up in the 15th Century for hacking medical systems. You know, hacker gets caught, hacker gets executed by a crowd of nurses on the evening news. No appeals, no commutation of sentence, just swift death by horrible means. An example for the next person that even thinks of doing something similar. And sure, maybe a few good mistakes to ensure nobody wants to even get near to someone that might do something like that.
There is another solution. Something that Dune mentions in passing and the pseudo-Dune-sequel books describe in more detail. It's call removing computer systems from critical paths because you can't trust them. Face it, today we can rely on the fact that there are people out there with malicious intent to do harm by computer. Whether they get money from it or not doesn't really matter - they are out to make sure that people cannot trust their own computer. Open source doesn't fix the problem - unless everyone is a programmer. Anti-virus "solutions" don't fix anything, they just escalate the battle and cost users money. Even locked-down systems like iOS aren't 100% secure and it is assured that once there is a critical mass of important stuff secured by iOS there will be a really strong incentive to find holes and destroy people's trust.
So, if the choice is between having a machine regulate medications or a human doctor doing it, which is more trustworthy today? Twenty years ago the answer was "machine" but anyone that believes that today is an idiot or completely unfamiliar with current events.
The slow, Hooverite acquisition of power. Once they have enough dirt on current legislators and CEOs gleaned from their vile activities, they will be unstoppable.
Anyone doing that today should understand security. If they can't, then they can get help from NIST and/or NSA, or outsource it and make the device maker pay a specialist for an audit.
This was probably the real reason DICK Cheney switched back to a human heart.
That and the whole cool Kali-ma um, 'medical procedure'.
before turning all of this over to Homeland Security, I'd like to know how many pacemakers and insulin pumps have been hacked versus how many are out there? Is this a true threat or just bad movie plot from the ScyFy Channel that has taken hold in DHS?
That's one of the questions that the FDA answers a lot better than the DHS. The FDA has procedures to decide whether something is really a problem, so they can prioritize their efforts on the real threats. You could search the FDA's public device adverse events reporting database to see if any hacked pacemakers or insulin pumps have been reported.
DHS didn't step in as some grand plan. They were asked to intervene by Cylance, a security research company, when Philips wouldn't respond about the detected security holes.
Seriously, how many people could a terrorist kill if they took control of Philips systems?
Just because there is a theoretical security flaw that might be exploitable under some totally contrived test scenario is NOT a valid reason to involve an agency like DHS.
If the FDA didn't take it seriously, why should we hand the task to a bunch of airport friskers and coastguards men? (Apologies to Coasties everywhere).
And why do a couple of self appointed "securities researches" get to sic DHS on anybody?
Sig Battery depleted. Reverting to safe mode.
I feel safer already. Not.
They watched that episode of Homeland where the Vice President was killed remotely through his pace maker.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Medical software runs a wide gamut, and pace makers are at the very bottom end of the scale. Check this out:
http://www.medical.siemens.com/webapp/wcs/stores/servlet/ProductDisplay~q_catalogId~e_-101~a_catTree~e_100001,1023065,1015817~a_langId~e_-101~a_productId~e_172960~a_storeId~e_10001.htm
This thing has:
You can bet that on a product of this complexity, there will be updates.
There is no doubt that medical devices use all sort of operating systems and have all sorts of capabilities, but what they are talking about in the article is communications between patient devices like pacemakers, insulin pumps, etc. That is different than the equipment you show, or an MRI, CT scan, etc. Those, are true computer driven systems. The ones DHS are taking over are the kind that are embedded or worn on your body.
No need to worry they will just reclassify any security problems as "design issues" thus cutting the number of security bugs by up to 90%.
Time to offend someone
You misunderstand my post. I am not saying that we shouldn't have these devices, but if the risk from the software, or somebody hacking the software is so great that homeland security has to take it over, then maybe the very benefits and tradeoffs you mention should be looked at again.
We agree there.
Terrorists? Killing? You, my good chum, are a typical example of the rampant paranoia and cowardice that has gripped the US. The slightest hint of DHS involvement and it's "ZOMG! KILLER TERRORISTS! PANIC! PANIC! PANIC!"
Still, being able to root a hospital can have serious implications that could indeed lead to deaths.
When our name is on the back of your car, we're behind you all the way!
If they were competent in the slightest sense, maybe, but I haven't seen anything from the DHS that would have me putting my trust in them.
I'm from the government and I'm here to help.