Malware Is 'Rampant' On Medical Devices In Hospitals 234
Dupple sends this quote from MIT's Technology Review:
"Computerized hospital equipment is increasingly vulnerable to malware infections, according to participants in a recent government panel. These infections can clog patient-monitoring equipment and other software systems, at times rendering the devices temporarily inoperable. While no injuries have been reported, the malware problem at hospitals is clearly rising nationwide, says Kevin Fu, a leading expert on medical-device security and a computer scientist at the University of Michigan and the University of Massachusetts, Amherst, who took part in the panel discussion. [He said], 'Conventional malware is rampant in hospitals because of medical devices using unpatched operating systems. There's little recourse for hospitals when a manufacturer refuses to allow OS updates or security patches.' ... Despite FDA guidance issued in 2009 to hospitals and manufacturers—encouraging them to work together and stressing that eliminating security risks does not always require regulatory review—many manufacturers interpret the fine print in other ways and don't offer updates, Fu says. And such reporting is not required unless a patient is harmed."
Re:"easy" to remedy (Score:4, Informative)
Admin access is a red herring. If I'm after patient medical or billing data and that is readily accessible by the logged-in user account, why do I care about Admin rights?
Yes, it helps for propagation and hiding, but for data access it is superfluous.
Not so simple (Score:5, Informative)
Our solution, which seems simple enough, was that every type of medical equipment was located on a different physical network (for critical pt. monitoring equipment) or at a minimum a seperate VLAN on the main network. All network access to this equipment was blocked except for very specific exceptions that were allowed based on the absolute need of that piece of equipment. We had no issues with any of these infections or malware, although it did increase the man-hours overhead especially when working with the vendors that would sometimes wonder why they could not hit the internet from the X-Ray machine
Re:What about networks (Score:5, Informative)
Hospitals are notorious this this kind of IT stupidity.
Most institutions are, including the financial sector, government, schools as well as millions of homes.
Back when Windows 95 rolled out Microsoft was incredibly naive. Where for decades mainframe operating systems were hardened against attacks, Microsoft failed to learn from those experienced in the field and some clever lads found they could manipulate financial software remotely, thanks to a complete lack of security with ActiveX. Shocking. For over a decade Windows continued to be loaded with security holes and a lack of internal checks to ensure software should be allowed to do things it was. Where we had process monitoring applications on RSTS and *nix systems, there was no means to track what was going on, particularly with DLLs on your desktop or laptop Windows system. Yet Windows attempted to be able to do everything and uneducated users (for who is truly educated where a home computer is concerned?) trusted it to be a good steward of their data and other assets. Meanwhile good Bill Gates and Chair-tosser Steve Ballmer were plotting next conquests and becoming fabulously wealthy. Honestly, should anyone be surprised? A good bet would have been requiring a standard operating system, a good clean one, for medical systems as life depends upon them. Nope, everyone gets cheap - use Windows and commodity hardware.
They really should include a warning that the healthcare facility may have information of a personal nature about you on Windows or that the maching going 'Bing' which keeps you alive may also and you accept these risks and relieve them of responsibility when it all goes to pot.
This is extremely common. (Score:5, Informative)
The term medical device has a broad definition; it includes obvious things such as laboratory analysers, X-ray equipment, etc., but it also includes PCs running specific types of software, such as medical records software. Most of these things run general purpose OSs - some embedded; some desktop.
E.g. Windows XP is a common platform for things like ultrasound scanners, MRI scanners, etc. XP embedded is quite common on things like laboratory equipment. Variants of linux are also in widespread use - albeit, often old. E.g. I work with an MRI scanner that runs a 2.2 kernel.
Now, things like analysers and scanners are usually on their own VLAN (or should be) with connections only to their application servers, with the servers heavily firewalled from the general purpose VLANs; however, this often isn't the case, and I've seen a number of installations where you can just sit down at a random PC, and SSH into an MRI scanner (these things usually have generic root passwords which are written in the service manual - once you know what the passwords are, you can get into any device of that make and model).
The biggest problem, however, is that these machines never get updated. The manufacturers often won't support any updates to the OS, or even permit hotfix installation, nevermind a 3rd party security package (for more general purpose devices). For example, one hospital earlier this year, upgraded their PACS system (software for storing and displaying X-ray/MRI/CT images) and bought a new set of dedicated workstations (quad core, Xeon E5, 8GB RAM, Dual Quadro), but because the PACS client software had to interface with a number of other client software packages, and those vendors had strict requirements; these machines ended up being loaded with XP SP1 32-bit and Java 1.4. Unsurprisingly, these aren't regularly patched, and more importantly, they can no longer update their anti-virus software as the current version of their chosen AV software won't run on this configuration (so they're stuck using an obsolete, unsupported version).
I saw an extreme example of this a few years ago when the Confiker worm hit. There were a group of hospitals in a major city, which shared the same infrastructure, and they had a very large PACS system. The worm got onto the PACS VLAN, and essentially killed the servers. The system was completely down for days, because as soon as the servers we rebooted or re-imaged; the worm killed them again. The vendor stubbornly refused to apply the hotfix and refused permission to install the hospital's antivirus system on the servers/workstations. The only thing that got it moving was when the CEO of the hospitals made a conference call with the hospitals lawyers and the CEO of the PACS vendor, telling them that they were going to f**k them so hard with the SLA stick, that they wouldn't be able to sit down for a month. After that call, the vendor agreed to install the hotfix, and the system came back online.
Re:The fine print mentioned in TFA (Score:4, Informative)
Maintenance contracts and pay-per-incident support means that manufacturers make plenty of money on already-sold devices. In many cases the cost of the device is a rather minor part of the contracts.
Re:Meh... (Score:5, Informative)
If people are browsing the internet on them or sticking USB drives in them they are doing things very wrong.
Medical people should be familiar with the terms "quarantine" and "isolation".
Re:What about networks (Score:3, Informative)
I don't know about medical devices, but I do know that the last time I was in the emergency room I brought my laptop since I knew I would be there for a few hours. After getting tired of games and slashdot I decided to poke around the wifi network that I was on. I found an unsecured smb share on the network and downloaded a 17gb .bak file of patient records. Needless to say I deleted the file and sent an anonymous email to the administrator. 3 months later nothing had changed....
Deleting the file and sending an anonymous email to the hospital administrator is like deleting a tape and telling a car thief that he was videotaped and to be more careful next time. If their network is still unsecured, why not be awesome and protect other patients by filing a complaint and cc'ing lots of people at the hospital that you have reported their irresponsible negligence to the US Dept of Health & Human Services at http://www.hhs.gov/ocr/privacy/hipaa/complaints/index.html
And this is why the USA is in trouble (Score:2, Informative)
Why was he in the emergency room yet capable of deliberately bringing a laptop for the long wait?
Because he was using the ER for something he should have gone to the doctor paid through his insurance rather then the ER which is free if you don't have insurance.
And he wonders why hospitals have no money to spend on IT security.
Re:And this is why the USA is in trouble (Score:4, Informative)
I get your point but this a stupid example to use for it. Should he have gone to his GP for a severely twisted ankle or for a high fever on Saturday evening? For that matter, he could have been there with his significant other, child, or friend.
Re:What about networks (Score:5, Informative)
Probably more accurate to say that hospital administrators would rather rip their own arms off than fund IT adequately. Hospitals are *notorious* for under-funding IT departments.
Re:And this is why the USA is in trouble (Score:5, Informative)
... rather then the ER which is free if you don't have insurance.
No. While it is true that the ER cannot deny you care, they will bill you if you do not have insurance. Failure to pay will have all of the same implications of ignoring any other bill.
This "we don't have to insure the poor because they can just go to the ER" trope has got to stop.
Re:Meh... (Score:2, Informative)
Why would you use a "Windows Firewall" on your separate "Medical Device Network".
I would set it up as a physically separate network that only connects to the local network in one place and have my firewall there.
I can guarantee you that it will not be a windows server sitting on that hot seat.
Every bit of information entering the "Medical Device" network will be a known entity.
Only specific IPs will ever be able to send into that network and those IPs will still have the content of the information locked down.
You can do it. You can have your devices able to send and receive the information that they need and keep them safe.
Re:Meh... (Score:5, Informative)
I would set it up as a physically separate network that only connects to the local network in one place and have my firewall there.
Your whole reply can be summarized as, "I have never worked in anything like a hospital IT environment."
Moving many gigabypes of information around transparently and quickly between subtly incompatible devices (DICOM isn't so much a "standard" as a "suggestion" if you look at the way vendors actually implement) coupled to a bespoke PACS network is barely possible without any additional list of pie-in-the-sky requirements of the kind you list.
Add to that fun requirements such as that many hospitals are also teaching environments and so have to interface (again, transparently and at very high speed) to university networks, and then bring in external consulting scienctists (Hi) who may need access to some patient data AND who may be hooking up research devices to your pristine medical network for clinical trials (this is how progress gets made, you see) and your cartoon locked-down network becomes competely useless in the real world because you've only considered about 60% of the actual uses it has to support.
Re:Meh... (Score:5, Informative)
You're right about the network architecture, but things rapidly get complex.
Let's take the example of MRI/CT. How much data is in a CT or MRI study, or even an X-ray study? A single X-ray image (e.g. a Chest X-ray) taken with a modern digital machine, is about 60MB (30 megapixel image, 16 bits per pixel).
My new CT scanner, if I prescribe a "full neuro" protocol, generates 16000 files of 500 kB each. The reason I'm doing a "full neuro" it means that minutes count. I need to have that data set sent to not just a PACS (image repository and viewing software), but also to a PC with 3rd party software (which has the complex software capable of analysing the data) and I have to have it ready within 5 minutes. Not only do I need to have it in my office in 5 minutes, the doctor who is dealing with the patient in the ER, needs to have (some) of it in the ER within 5 minutes. Then, after everything is said and done, I need to send the data to my office at the university, so that I can run it through my research software.
If it was just PACS - no problem. You put the scanners and the PACS incoming-data server on a restricted VLAN. Have the incoming PACS server communicate with the main PACS application and data-store servers over a private VLAN, and have the PACS app servers face the hospital clients on the main hospital VLAN (or individual departmental VLANs).
However, at my hospital we also get several hundred CTs/MRIs sent in from outside per day, that need to get onto the PACS. Many come on CD/DVD. Some come via VPN tunnels. Some come via 3rd party proprietary transfer services. (The DICOM protocol used to transfer medical images doesn't support encryption, so must be tunnelled in some way). Now you have to somehow connect all these incoming points to your restricted VLAN (or you open your wallet to your PACS vendor for another software license at a cost that makes oracle enterprise look like chump change).
What if your PACS vendor has you buy the balls on your SAN contract, so that you are paying $10 per GB + $2 per GB per year? Do you really want to send that 8GB dataset to PACS (which can't actually do anything useful with it- and remember, as a medical-grade archiving device, you can't delete)? Or do you now need to start putting PCs with 3rd party software on your restricted VLAN so they can talk to the scanners?