Malware Is 'Rampant' On Medical Devices In Hospitals
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."
When someone does get hurt, it will be a very clear case of negligence on the part of the manufacturer, and the lawsuit will bring everyone else in line.
Sad that this is the way it works in America though.
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....
Windows is not intended to be used in life-critical situations such as medical hardware or nuclear reactor control. It's right there in capital letters in the EULA.
Someone's being a cheapskate here and decided to use windows instead of paying to develop a custom medical OS.
Dad has owned an ultrasound service business since the late 70s. My brothers and I all worked for him in varying capacities, before becoming engineers ourselves.
In my experience: the amount of willful ignorance towards all manner of IT in the medical field is nothing short of astounding.
I hate to say it, because I love alot of these people- but I chalk it up to the arrogance of the doctors and administrators. They treat anything IT related on the same level as an issue regarding say, HVAC or sanitation. That is to say, beneath them.
Which is fine, except in this case the "HVAC" can be programmed by a remote intruder to emit Zyklon B.
Ok, I'm only a student. So I don't know anything. But I sorta THOUGHT that the standard for a mission critical system (aka something like a heart monitor, blood gas analyzer, etc etc etc) would be to NOT use any software in your system that you don't have 100% control over.
You know, rather than picking some version of windows, use an embedded linux. Add the bare minimum graphics libraries you need in order to draw a gui. Isolate the threads that actually do the mission critical stuff (say, reading the sensor and displaying the output) from the ones that do other tasks (like handling all the complex menus and the network connectivity and so on). Heck, use a separate physical CPU for the mission critical stuff, and give it it's own dedicated display so that no matter what, it keeps displaying the important data. The hardware to do this is cheap.
And firewalls should be integrated into the devices themselves - even Linux can theoretically catch a worm, and so it should apply strict filtering rules on any communications with the network.
I can fully understand the reluctance of the manufacturers to issue software patches. Building the system so that it's practical to not ever patch it (well, maybe patch it a couple times to eliminate any bugs found after release) is a good thing. Everyone here must know that the best way to break a working machine is to shut it down and change something.
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.
Validated. That costs a bunch of money. And this basically is saying that if the manufacturer DOESN'T validate the changes to the FDA's satisfaction (meaning do a heck of a lot more testing than just applying the patch real quick and booting it up and making sure it's still working) then they are totally vulnerable to lawsuits.
Also, just as importantly : the manufacturer does not receive money from medical devices already sold. Their new ones (with new hardware which is why they can't back-port the software) are where the revenue is. In fact, it's sort of beneficial if the hospital's old equipment starts running slowly and badly because they can push their new gear (now with enhanced cybersecurity!)
You don't allow people to use the instrument to have administrator access
I guess you've never heard of a privilege escalation exploit. If you're not performing updates then you're vulnerable, end of story. It's a good argument for eliminating the full-fledged computers inside of general-purpose medical devices, and making them instead some kind of peripherals used with computers of some sort when an interface is needed.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
A little sooner than we should, but that's them bones !!
Need a sign out front - Caution: This Hospital Uses Microsoft Windows.
A feeling of having made the same mistake before: Deja Foobar
I worked as an IT Manager in a hospital for a few years, and know a little bit about this... The first issue is that these systems typically CAN NOT be upgraded, and this is not due to the MFG not wanting to upgrade, this is a FDA compliance issue... If they upgrade the software, they have to do some very expensive certifications with the FDA, these same certifications delay the release of medical equipment to the point that much of the technology is already close to being outdated when it hits the market.
... but we managed just fine.
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
+++ATH0 NO CARRIER
I work in hospital IT and we have an entire separate department for working with any clinical equipment. In most cases they can't do anything either because the vendors do not allow us any admin level access and none of them are part of our regular domain/AD. The lab/pharmacy techs quite literally have more access to those systems than we do. It's extremely aggravating.
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.
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....
Usually anyone who dares tell the Emperor that he's actually naked and not wearing any "new clothes" gets his head chopped off for pointing out the truth.
Lemme tell you what would've happened at one particular hospital I know of: The IT administrator would've contacted law enforcement and provided them with all the video footage from the multitudes of security cameras around the place, along with the patient and visitor lists, as well as all the the wifi access and activity logs containing your mac address and anything else logged and/or identifiable about your laptop, to try to find out your real identity for criminal prosecution purposes.
Despite the fact that they are extremely weak in securing their network resources in the first place nor do they have any realtime alerting mechanisms to detect any kind of unauthorized access while in progress.... they do go to ridiculous lengths to log and record everything necessary to try to identify you so they can come and get you long after the fact.
Caution: This Hospital Uses Microsoft Windows 98
Ahahahahahahah I totally understand why you would think these things, but, you need a little history.
I worked in Healthcare IT for about 6 years, until a few short months ago. Before that, I actually started my career as a service tech. The thing to realise is...the group I worked in moved out of the office they were in while I was there.... the original office had a room full of chest high benches, with a built in shelf above, and lots of plugs. If this sounds like the kind of setup that would have soldering stations, then you are getting very warm...because that what they used to do!
In fact, some of the same guys I worked with...had been there since core memory that was tacked to the wall was decommed.
That sort of attitude makes perfect sense if you are building a new network, in the total absence of road blocks. A hospital environment however... well.... we are talking about an environment thats been in CONTINUOUS operation since the early 1800s. (not all hospitals are that old, of course) all new equipment, all upgrades, all troubleshooting, all goes on, while operations continue. There is no weekend downtime. There is no middle of the night downtime.... thats just to START.
Add to that the federated 'academic' model that most hospitals use for their budgeting (ask your professors to explain how departments are budgeted and why money gets suddenly spent before the end of the fiscal year, and thats very much like how hospitals work). They started bringing in all this equipment before they even had central IT. They have their own budgets and egos, sometimes bigger departments will have their own mini-IT staff even! It is utter chaos.
Now the departments decide what they want, get most of the way down the path of purchasing it, then bring in IT late in the game. IT fights with them and the vendor about their standards, but can't fight too hard or else they will tell IT to go fuck themselves and just go do it with their own money, since IT can't actually say no. (or they make a stink up to a level where IT gets the smack down)
Then patching and OS upgrades.... often you can't patch or upgrade because the vendor claims they wont support it. Occasionally they blame the FDA saying they certified it on the OS version its on (we often questioned whether that held water).
In short, the vendor and department often act like they are on the same team and IT is the roadblock, rather than the department and IT working as a team. The department, especially if they are clinical, but sometimes research too, has more clout than IT, because the trustees are from the medical professions and they are the final say.
Very early on in my career I got a stack of work orders. First I was told "they can't have windows 95 because their department hasn't been upgraded yet" (and there were internal reasons involving training and federation that meant each dept needed one or two people trained before it could be upgraded).
A week later the hardware arrived and I was told "they are getting Windows 95, OEM build, not ours" (which was a HUGE exception for them)....from that point on, every day I showed up to do something for them based on what we were doing yesterday, and every day they had already had a meeting that I wasn't privy too, and my department had made new concessions to them, totally changing what I was supposed to do ..... the ego maniac who was making them do all this, of course, just got mad at me for constantly doing the wrong thing, even though, nobody had told me the plans changed.
Eventually I heard, through more connected people than me, that he had a huge and prestegious grant and was threatening to take his grant and go to another institutiuon if they didn't give him everything he wanted....and he got it.
Now.... tell me how you control what you are using when the final say on policy comes from people who don't understand IT, and are willing to see it as a roadblock rather than part of their team? Believe me when I say there are a lot of people (not everyone of course) who know what they should be doing, and want to do things right, but, they lose a lot of battles.
"I opened my eyes, and everything went dark again"
... 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.
-