?

Log in

No account? Create an account
Ramblings Journals I Read Calendar The Dirt MegaZone's Waste of Time Older Older Newer Newer
My tweets - MegaZone's Safety Valve
The Ramblings of a Damaged Mind
zonereyrie
zonereyrie
My tweets

Tags:

6 STDOUT || STDIN
Comments
ninjarat From: ninjarat Date: October 18th, 2012 06:57 pm (UTC) (Direct Link)
Would you trust your health to a computer system that hasn't been tested and vetted by the manufacturer and FDA? Because that's what aftermarket patching means: the device is no longer compliant with the standards and specifications that got it accepted in the first place.
zonereyrie From: zonereyrie Date: October 18th, 2012 07:37 pm (UTC) (Direct Link)
Actually, yes. I'd trust a patched system that was no longer what was originally certified a hell of alot more than an unpatched Windows box. Patching is a controlled process. They can patch a device and then run a test suite to verify the behavior. Or, really, the damn manufacturer can get on the ball and issue the patches as a tested platform.

It is a lot more deterministic and can be done in a controlled situation (change windows), rather than just dealing with infections with unknown consequences.

When someone died because of an infected machine, and that's going to happen eventually if this doesn't change, maybe then the resulting lawsuit will force the industry to change.

Of course, the real answer is not to use Windows in the devices in the first place. You don't need a full desktop-ish OS. Use an embedded OS. If you need to process data and do pretty displays, etc., then you export the data to a desktop machine - but it has no control over the function of the device.
ninjarat From: ninjarat Date: October 18th, 2012 08:20 pm (UTC) (Direct Link)
How often have you updated a system -- any system -- only to find one or more applications no longer work the same as they did before the upgrade? Or that they don't work at all? Or that the system doesn't boot? Imagine if you can the application that runs a CT scanner or a life support system or LASIK laser not working precisely the way it should because someone updated the operating system. The OS doesn't matter. Windows, Linux, Macintosh, something custom for the equipment, whatever. Hospitals can't patch the systems that operate medical devices. It isn't an option. I've had this explained to me by people who helped draft some of the regulations regarding the certification of these devices.

The real problem is that they're being connected to networks where they can be targeted remotely. If a device isn't on a network then it cannot be targeted by network-based attacks. Devices like the ones I listed are kept isolated, or they were when I worked at the Dana Farber, and are therefore not vulnerable to these attacks. The ones that are connected? All I have to say about that is, "whoever did that was a moron."
zonereyrie From: zonereyrie Date: October 18th, 2012 09:07 pm (UTC) (Direct Link)
That's why you do the update during a change window. Ideally you test the update in a staging environment first. Then you apply them to the production systems during a change window. Then you test.

If anything doesn't perform as is should, and you can't resolve it during the change window, you roll back the update. Then you go figure out why it didn't work before you try again.

That's all basic IT.

More and more devices are being connected to networks now to allow for remote monitoring. So a nurse in a central station can keep an eye on the stats from the devices in multiple rooms. It doesn't have to be the Internet, just a local LAN - all it takes is someone connecting an infected USB drive to transfer some files.

It is extremely common for laptops or USB drives to be connected directly to these devices to gather data so doctors can analyze it, it gets into the medical records, etc. Nancy (my wife) talks about having to do this all the time. Most of the people doing this aren't that computer savvy, to hear her tell it. They just know they stick tab A into slot B and push button C.

She's received infected files from other people in the hospital. And all it takes is someone opening an infected file and infecting their laptop, then connecting a USB drive to upload data, then taking that USB drive to other devices to collect more data.

The OS absolutely matters. Not all OSes are created equal. Windows not only has vulnerabilities, but it is the number one target platform. If the devices ran a different OS than most desktops, it would also be less likely for any infection to jump platforms. Most malware targets one platform - like Windows. So if you have an infected Windows laptop and take the USB drive to a device, but it is running Linux, it is unlikely to be infected.

Even if they use Windows, there are embedded versions of Windows which can be extensively locked down and hardened. You don't include any functionality that isn't needed for the device. You disallow any executable updates. Other industries do this - Windows runs the majority of ATMs and most of them are fairly well hardened.

Using a dedicated embedded OS with minimal features would greatly limit the vulnerability. There are embedded OSes certified for use in avionics and military applications, which are *highly* trusted and reliable - and almost impossible to infect by design.

I really blame the vendor.
- They picked the OS.
- They failed the properly harden the OS, no matter what it is.
- They failed to provide timely updates that comply with regulations.

Maybe if they were required to provide updates, including certifying them, on a timely basis they'd decide to design more secure products to start with and make better design choices. But as long as there are no consequences to building things on a desktop OS without designing security in from the start, and no penalties to leaving hospitals hanging out exposed due to lack of patching, there is little incentive to change. Designing secure platforms is harder than taking the easy route, and therefore it costs more - in design, development, and test. Vendors don't want to spend the money and do the right thing as long as they can avoid it and make more.
ninjarat From: ninjarat Date: October 18th, 2012 11:07 pm (UTC) (Direct Link)
Here's something that will bake your noodle: Windows 2000 SP3 and every released version of Windows since have EAL level 4+ certification. This is the same certification level that RHEL v5 and Trusted Solaris have. If you implement the target profile for a given OS -- and these device vendors usually do -- then you can reference that certification as part of your own certification process. Saves a lot of money since you don't have to certify the OS; that's already been done. The device is just as reliable as military applications because it's the same standards underneath (Common Criteria is a superset of DoD standards).

If even one line of code is changed then the whole thing needs to be resubmitted for testing. No OS vendor does this for weekly updates. Not Microsoft, not Sun, not Oracle, not Red Hat, not SuSE. None of 'em. Your RHEL server installed straight from DVD is EAL 4, but install even one updated RPM and it isn't EAL anything any more. It doesn't matter that the RPM fixes a bug. What matters is that you don't have the assurance that the system as a whole will work as described by the target profile.

This is where hospital IT departments find themselves in a bind. If they do patch then they modify the device outside of what is specified by the vendor which means no warranty support and no legal recourse if it fails. If they don't patch and connect it to foreign networks or peripherals....

So the answer still is "don't connect it".
mackys From: mackys Date: October 23rd, 2012 09:20 pm (UTC) (Direct Link)
I wouldn't trust my health to ANY machine running Windows, patched or not! ;]
6 STDOUT || STDIN