Slashdot Mirror
Fed-Up Hospitals Defy Windows Patching Rules
bingbong writes "According to Network World: 'Amid growing worries that Windows-based medical systems will
endanger patients if Microsoft-issued
security patches are not applied, hospitals
are rebelling against restrictions from device manufacturers that have
delayed or prevented such updates. Device makers such as GE Medical Systems,
Philips Medical Systems and Agfa say it typically takes months to test Microsoft patches because they could break the medical systems to which they're applied. In some instances, vendors won't authorize patch updates at all.' This is the typical patch vs. crash problem. Unfortunately, the stakes here could be human lives."
Why is hospital equipment running windows? Anyone that knows anything about embedded systems with high quality requirements know that you stay away from large OSes. Even Linux is avoided unless you need tcp/ip and if you don't then its better to have a small maybe even off the shelf OS. The Key is to limit the testing requirements and limit changes, which are goofy to test a life support system just to have the latest and greatest IE 6 or 7 that you shouldn't even, have hooked to a wide-open Internet anyway.
Why are they even accessible on the internet? Seems like these should be in a secure private network unlikely to be attacked.
pshaw! what's a few human lives when network security is at stake?
...do they not just put these devices and systems behind something as simple as a $50 hardware NAT firewall, especially for a device that costs hundreds of thousands - or millions - of dollars? (Or better yet, why does the vendor not integrate such protection if they're relying on network-connected Windows systems for device control/interaction?)
The norm is that these devices may need to connect *out* to something else, but don't necessarily need any inbound connections, so a hardware firewall, or even a host-based software firewall, would work perfectly in most instances; those that do need externally initiated inbound communication can *still* set up the necessary rules to allow such communication to take place. And yes, it is just this simple. (I did RTFA, and noted that some vendors actually recommend this, but that, startlingly, "there have been several instances in which viruses originated from medical instruments straight from the vendors"!)
Medical machines responsible for human life should never need to be patched. The software was tested at one point and should be controlled to stay at that test point until it is to be retested. For machines running windows this means they should be segregated from other parts of yoru network and should be airgap firewalled from the rest of the world. Intenet worms and email trojans shouldn't be relevant.
I'm not a big fan of Microsoft, but I don't think the quality (or lack thereof) of their products is the issue here. I've read from their EULAs that their products are not suited towards critical applications (ie nuke facilities, life support). My point is that although a EULA is not a legally-binding contact, the fact that MS is stating in public Windows shouldn't be used in critical applications should tell you something. The bottom line is that if GE, Philips or Agfa build a medical system, they should be responsible for that product from the software up to the hardware. The fact that *they don't have control* over one of the components in their products (the underlying OS) is negligent, IMO.
I would get laughed out of court if I tried to blame a critical problem with a report I wrote on my secretary, and the same should happen with these companies if somebody's loved one dies from their irresponsibility.
Bill Clinton: Pimp we can believe in. - The Shirt!!!
Having spent 10 years working in the Medical Device/Biotech domain, I can tell you that the FDA really does govern these things. Unfortunately, their internal understanding of computer systems in general is frighteningly scarce. Essentially, the only body of legislation they have to go by is a small portion of a CFR (Code of Federal Regulations: 21CFR Part11) that was released in 1997, and the enforcement guidance documents that followed it. The Code is extremely ambiguous and realistically lumps "electronic documents" and "electronic signatures" together. The compliance issues resulting from the vague document and its (mis)interpretation and enforcement were enough for me to change industries. My heart goes out to all of the people still battling this.
I work with MRI scanners, so I know about these issues very well, and here's an example from my own experience:
An old colleague of mine got funding to start his own reasearch group, meaning he got his own MRI scanner. He asked me to consult on some software that would extract the data from the console of a Siemens scanner (at the time, the console was based on an OLD version SunOS, whose native compilers did not even conform to standard ANSI C) and send it directly to another computer running software that we use for data analysis. The dialect of C was a little strange, but within a week, I was able to get the software together, and my colleague was able to do the type of experiments he wanted to. And his scanner hummed along. This was back in 2001.
Fast-forward to the present. His console has since been "upgraded" to Windows XP system, and in the times I've spoken to him, he's had nothing but bad things to say about the stability of the "upgraded" system. And it's not that he had a choice, as support for his previous system was phased out. So now patients, doctors and reasearchers in his group are at the mercy of the moods of an XP system. And mind you - this system is not even on a publicly accessible network. It is on its own dedicated, private network, and its stability still can't be maintained, even by the support staff of the scanner manufacturer.
When it comes down to it, Windows still does not have the stability (never mind the security issues to cut it in really "mission-critical" situations). Maybe in cases where you need your e-commerce site up, running, and handling 1000s of transaction per second. But NOT when peoples' lives are involved.
Firewalls won't help. If it runs Windows, some idiot's going to bring in a CD full of pictures from his latest vacation and the CD's going to be infected with MyDoom or (heck, probably and...) Sobig or any number of other nasties. Or it's going to be something he wants to print on the nice laser printer at the office.... there's a hundred ways to get infected just by clueless users.
Pretty soon, the internal network's either too busy generating random traffic to do anything else-- and even if the Big Iron of the business, the dialysis machines and heart-lung devices and all those wonderful things that better damned well not break work fine, you've still got the terminal the nurse sits in front of that keeps track of when to issue you your shot that keeps you alive spending half its time rebooting because it's got Sasser.
This is not a problem a firewall can solve, and it's pretty darned big: You can't go throwing software around willy-nilly to solve this problem (even though the real problem is that the users _are_ throwing software around willy-nilly), so you can't just go "oooh! A next-day patch from Microsoft, let's hope their two hours worth of QA before it walked out the door was good enough!".
-JDF
Sorry, Ryan, but you're not correct. I worked for GEMS for 12 years, in software engineering. There _are_ Windows systems embedded into some of these scanners. Most of them do trivial things and are being phased out in favor of *nix systems, but there _are_ Windows-based medical devices.
It's quite a quandry. If you don't patch the 'doze boxes, (and if you don't have a firewall...) it's possible that someone could infect that system. The problem is, GE (and obviously the other device manufacturers) test the hell out of that specific OS build and patch set. When Windows Update breaks things (which happens more than never), the system is now in a state which GE didn't test, and may in fact break the functionality of the scanner. At this point, the FE has no choice but to re-load the PC from the GE-supplied media(which doesn't have the latest patch that the hospital just installed).
The solution? It's pretty simple, stop using Windows in critical situations. I was trying to make that point 10 through 5 years ago there, and was involved in some of the very first Linux tests, prototypes, and production implementations there. The current generation of scanners is mostly linux/intel based, although there is still a lot of SGI/Irix at the top-end where heavy image processing is done. The fix for this problem, is to avoid this problem, and that's really the only sensible approach.
So, yes, they do have 'doze systems embedded in some of these scanners, but it's getting better. The hospital gets to choose between complying with HIPPA and patching the systems, or installing an unsupported patch which might break the scanner. Not a good place to be in, but then again, people shouldn't be reading their email or surfing the web from the MRI scanner's console, and the hospital _should_ have a firewall blocking the slammer/whichever ports.
> Unfortunately, the stakes here could be human lives.
Soon to be made into a movie starring Uma Thurman.
It's called "Bill Kills".
assert(birth_date<time-86400)