Report: Evidence of Healthcare Breaches Lurks On Infected Medical Devices 42
chicksdaddy writes: Evidence that serious and widespread breaches of hospital- and healthcare networks is likely to be hiding on compromised and infect medical devices in clinical settings, including medical imaging machines, blood gas analyzers and more, according to a report by the firm TrapX. In the report, which will be released this week, the company details incidents of medical devices and management stations infected with malicious software at three, separate customer engagements. According to the report, medical devices – in particular so-called picture archive and communications systems (PACS) radiologic imaging systems – are all but invisible to security monitoring systems and provide a ready platform for malware infections to lurk on hospital networks, and for malicious actors to launch attacks on other, high value IT assets.
Malware at a TrapX customer site spread from a unmonitored PACS system to a key nurse's workstation. The result: confidential hospital data was secreted off the network to a server hosted in Guiyang, China. Communications went out encrypted using port 443 (SSL), resulting in the leak of an unknown number of patient records. "The medical devices themselves create far broader exposure to the healthcare institutions than standard information technology assets," the report concludes. One contributing factor to the breaches: Windows 2000 is the OS of choice for "many medical devices." The version that TrapX obtained "did not seem to have been updated or patched in a long time," the company writes.
Malware at a TrapX customer site spread from a unmonitored PACS system to a key nurse's workstation. The result: confidential hospital data was secreted off the network to a server hosted in Guiyang, China. Communications went out encrypted using port 443 (SSL), resulting in the leak of an unknown number of patient records. "The medical devices themselves create far broader exposure to the healthcare institutions than standard information technology assets," the report concludes. One contributing factor to the breaches: Windows 2000 is the OS of choice for "many medical devices." The version that TrapX obtained "did not seem to have been updated or patched in a long time," the company writes.
Not Just That Machine (Score:3)
It's not just the outdated OS that is the problem. One must wonder why a medical image storage server is allowed by the network to make outbound network requests all the way to China.
Re: (Score:2, Informative)
If I'm understanding the story right, it didn't. The medical image server got infected somehow but didn't have outbound network access. From that server, they then infected a work station, that DID have outside network access. From there, they sent data to China.
The root issue is ultimately government regulations, which prevent these devices from being patched. You can't simply patch a medical device because then it loses its FDA certification. And it's only going to get worse, since part of Obamacare is re
Re:Not Just That Machine (Score:4, Informative)
> The root issue is ultimately government regulations, which prevent these devices from being patched.
> You can't simply patch a medical device because then it loses its FDA certification.
No. The issues are far deeper than that and have ALOT to do with the overall fragmentation of the entire medical industry and the culture of vulchers that fly around the clinical medical industry looking for ways to get their feet in the door to steady profits.
Here is what i saw from spending too long on thos front lines:
They are all trying to build an embeded solution they can charge for support on, they will generally work directly with the clinics, bypassing central IT as much as possible, and bring them in only at the end, and try to position them as the road blocks on the project because.... they want to keep all the support to themselves.
Then when IT patches all their systems and sees "hey this is an out of date linux box" the vendors sit on their thumbs and cry about FDA certification, as if the responsible thing to do wasn't to immediately contact the FDA about re-certifying. Oh no but that would cut into their profits!
Hell if they really cared, they would fix it, and tell the FDA that if they even try to levy a fine, they are going public with exactly what level of risk and vulnerabilities the FDA is effectively forcing people to accept. Who do you think would look bad after that exchange? "We fixed this problem to protect our patients in spite of the FDA trying to make us not" you think that isn't the kind of issue that would get an FDA head called before congress?
It is, but it never happens, because the profiteering industry likes the regulations the way they are because they don't like having to patch, its a bother.
Re: (Score:2)
So it is ok to let them die because some script kiddie owned the box, because in that case you are not liable.
Makes perfect business sense.
Yes, testing patches is part of the fucking process, maybe they should have figured that into the business plan up front.
Re: (Score:1)
That is an easy one. Because that would require have competent IT and especially network staff to make sure that there are working vlans.
One of the challenges that hospitals face is that their benefits packages suck, really really suck. They tend to work with other hospitals and providers in a region to make sure that salary and benefits are similar between institutions. This is to minimize clinical personnel to move between places.
This is tolerated because medical instutions are us
Re: (Score:2)
something like 10 years ago i would joke that we should block all traffic at work from china and eastern europe. doesn't take a genius to do that
Re: Not Just That Machine (Score:2)
Not only that, but I have to wonder why any hospital or scada network doesn't have some sort of ip block whitelist. In fact, dare I say, any ip connected network that isn't intended for its users to access Facebook should have some kind of autonomous system number whitelist in its bgp tables.
Meanwhile, HIPAA fines will skyrocket (Score:5, Informative)
HIPAA imposes fines for each patient's record lost through security breaches, even if the medical provider "did not know (and by exercising reasonable diligence would not have known)" https://kb.iu.edu/d/ayzf [iu.edu] that there was a breach. These kinds of punitive rules have scared the entire industry to death, and yet the open secret is that nobody is safe from breaches, or these fines. This story illustrates how the law has done little, if anything, to actually protect privacy.
Most providers react to HIPAA in one of two ways:
1) They over-react, creating stupid policies like refusing to tell even a patient's own spouse the details of a patient's medical condition, unless the proper paperwork has been filed, or
2) They under-react, blissfully ignoring any privacy concerns.
If we're going to try to regulate privacy in the medical industry, how about let's focus on the device and software makers with certification programs, and let hospitals and physicians get back to doing what they do best: treating illnesses.
Re: (Score:3)
No, we don't do that. At least not any more. Most places have figured out the ins and outs of HIPAA by now. And no, your spouse cannot access your records without permission - that is by design. You can give your spouse permission but you can also block it. Think about it - that's the way you would like the default.
This isn't a HIPAA issue at all. It's a technology problem and, FWIW, I'm not so sure it's as big a problem as TFA would have you believe. I've yet to see a PACS run on WIndows 2000 (cert
Re:Dude! You got a Dell (Score:4, Insightful)
Infected by Dell is more like it. Notice all the health (sick) companies use Dell. Notice that.
Seriously? If you don't load your own image on the corporate computer you purchased from Dell, you've got a problem, not Dell. I don't know of *any* corporate customer of any reasonable size that doesn't have their own commissioning process that involves wiping the disk and starting over so they can be sure that the system is 100% what they want, and nothing else.
Heck, one of the first things I do even with retail equipment is re-install everything to get rid of all the vender supplied bloat and "free" offers and get to a minimum install set. I do it for two reasons.. Clean out the junk and verify I have everything I need to recover the system in the future.
Re: (Score:2)
Heck, one of the first things I do even with retail equipment is re-install everything to get rid of all the vender supplied bloat and "free" offers and get to a minimum install set. I do it for two reasons.. Clean out the junk and verify I have everything I need to recover the system in the future.
I do the same thing, and for the same two reasons. I once returned a server because I could not get it to work from the CDs they sent with it, after wiping the hard drive. When the vendor returned the server, the set of CDs was complete.
FDA Certification Part of the Problem (Score:5, Informative)
The reason a lot of these devices use outdated OSes is that it has to be FDA approved. I used to work on some hospital networks, and not only were some of these systems running out-dated operating systems, they couldn't have any security updates applied without losing their FDA approval. We kept these systems locked in solitary confinement behind firewalls (with no Internet access), but you still have to be able to get to them over the network to actually use them (and worse, occasionally by remote radiologists coming in over a VPN from who knows where).
Re: (Score:1)
I used to work for several hospital and the vendors used to tell me I could not patch systems until they got FDA approval.. I asked the FDA about this and they said that was untrue. The FDA unofficial statement is the vendors do not what to go though the process of testing things and there for blame it on the FDA.
Re: (Score:2)
The reason a lot of these devices use outdated OSes is that it has to be FDA approved. I used to work on some hospital networks, and not only were some of these systems running out-dated operating systems, they couldn't have any security updates applied without losing their FDA approval. We kept these systems locked in solitary confinement behind firewalls (with no Internet access), but you still have to be able to get to them over the network to actually use them (and worse, occasionally by remote radiologists coming in over a VPN from who knows where).
Yup. I've seen the same sort of thing firsthand. The mountain of paperwork needed to make changes means that fixes of any kind are only made if they're absolutely critical (and sometimes not even then). On the other hand, I doubt the virus propagating over the network bothers to file a change control form and get 3 pre-approvals.
Even in non-regulated areas vendors get touchy about installing software like antivirus on systems. At my workplace we ended up coming up with a standardized windows image for v
Re: (Score:3)
Re: (Score:2)
So, it's exactly like he said and no updates are allowed to be installed.
ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.
Honestly, I hope s
Re: (Score:3, Insightful)
So, it's exactly like he said and no updates are allowed to be installed.
ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.
Honestly, I hope some hospital gets the balls to sue an ISV for failing to act in a timely manner for perpetually ignoring security like we all know they do. It's not going to change until someone holds them accountable. They'll just hide behind their EULAs until then, and hospitals will get the bill for letting people die because of security holes.
From the linked FDA page:
4. Who is responsible for ensuring the safety and effectiveness of medical devices that incorporate OTS software?
You (the device manufacturer who uses OTS software in your medical device) bear the responsibility for the continued safe and effective performance of the medical device, including the performance of OTS software that is part of the device.1
If the device manufacturers are forcing hospitals to run without OS patches, the manufacturers are not doing what the FDA says they should do. Maybe the FDA should change should to required. Even so, I have to wonder if there's anything preventing the manufacturers from simply maintaining a patch compatibility web page and telling the hospitals that they're responsible for the OS patches... I seriously doubt either party is innocent, but have to wonder if the hospitals are the
Re: (Score:2)
In practice I've yet to hear the FDA go after anybody for failing to patch security problems on their devices.
If somebody actually reported an adverse event with a device caused by a virus, I'm sure the device vendor would issue a tested update that closed that particular hole. However, beyond that I've yet to hear of the FDA cracking down on this, despite whatever might happen to be on their website.
The fact that malware is being found in hospital equipment in the wild just seems to support that.
Re: (Score:2)
The problem is that the FDA is requiring that the patches/updates be 'tested the update for any effect on clinical function'--knowing how FDA testing can and often runs, this probably in practice translates to 'not at all.'
If the tests are limited purely to the ones relevant and necessary, it'd be one thing, but the FDA has a well-earned rep for requiring tests that are antique and/or irrelevant. This is approximately like having somebody in upper management decide that any change whatsoever to the computers can only be done after huge, time-consuming & expensive battery of tests, and that you cannot skip any step under any circumstances whatsoever, even if you would like to know exactly how 'applying humorous sticker to monitor stand' could possibly result in software issues.
It is not nearly that clear cut. Testing requirements vary depending on the risk classification level. Things like a pacemaker or insulin pump are Class III devices, and the requirements for that are indeed very strict. But PACS systems are Class II, which is not nearly as onerous. And both the FDA and the IEC-62304 standard are starting to acknowledge that not taking software updates is likely more risky than taking them, precisely because of the huge numbers of bugs and vulnerabilities found.
But vendo
Re: (Score:1)
What were the names of these 'out-dated operating systems' and what terms of the FDA prevented them applying security updates?
Vendors lie about FDA certification (Score:2)
The main reason they put it out is that it helps reduce their costs.
If you read the FDA advice at http://www.fda.gov/RegulatoryI... [fda.gov] and at http://www.fda.gov/MedicalDevi... [fda.gov]
The key piece of advice is If manufacturers chose to use OTS software in their devices and vulnerabilities in OTS software can affect the safety and effectiveness of their networked devices, they have to act to keep their devices safe and ef
There's an app for that (Score:4, Interesting)
Win2k (Score:2)
"One contributing factor to the breaches: Windows 2000 is the OS of choice for "many medical devices." The version that TrapX obtained "did not seem to have been updated or patched in a long time," the company writes."
Well DUH. I'd have been rather surprised if they had since Win2k was EOL'd 5 years ago.
Malware lurks on infected medical devices? (Score:1)
Wouldn't it be safer to run these medical devices on a dedicated Real Time Operating System (RTOS [wikipedia.org]). That isn't susceptible to acquiring malware through normal operation ref [windriver.com].
Windows XP is also prevalent in medical devices (Score:2)
What's needed is an industry standard on how to partition and isolate these devices, while allowing appropriate inter-system communications to occur. Then at least there is something that people can hold vendors to and drive the level of technical maturity in the right direction. The sad thing is that these companies are locked in the 1990's mindset, and unless there us a blowtorch applied to their feet they will keep on selling eq
Re: (Score:2)
Re: (Score:2)
Yes, they do. [microsoft.com] There are several versions of Windows Embedded 7, Windows Embedded 8 and Windows Embedded 8.1 available depending on the needs/requirements.
If I remember correctly there was an embedded version based around the Vista kernel as well although I never saw it used on any actual devices.
Re: (Score:2)