I can agree with this article.

I work in medical equipment R&D and understand criticality. I have personally used competitors systems and am freaked out by their security problems. "Want to see how to infect this system? Plug this thumb drive in. The OS is set to autorun. Or, lets just plug a keyboard in and hit CTRL-ALT-DEL open the task manager and lookie here, full access to the system as an admin user. Plug a network cord in... the C drive is fully shared all permissions. Well, at least the drive is RAIDed so that any malice that happens to this device has a failover backup. facepalm"

My devices run Windows Embedded and they are locked down hard so that no unauthorized access. You aren't getting into the bios. You aren't getting into a permanent part of the file system. You aren't getting access via the usb port unless it is exactly what we want. Something on the system changes and fails a checksum test, we will know and the system will not allow usage. Our service people are the only ones allowed to make those types changes.

There are replies on this post and the article seem to have a strong anti-Windows for the sake of being anti-Windows sentiment and shows an extreme lack of understanding on software and hardware configurations. "Herp-Derp Window$ BAD, use Linux". Windows itself is not inherently bad. I would make the same statement if someone just went with a full stock release of Ubuntu on a medical device.

Most medical devices use Windows Embedded, not a full Windows install, and developers should strip it down to the bare essentials that they need, set up the write filter protection and lock their system down tight and anyone that gives a care about their patients would overprotect above the FDA guidance.

I think your comment narrows down only to medical devices. While I have noticed this problem mostly in workstations used by hospital administration which are networked and more prone to viruses. In any hospital, communication between departments is as critical as life support systems.

Many times a malware infected system can cause minor but significant annoyances like sluggishness to random reboots. Thanks to a rich malware ecosystem, these systems are almost always based on Windows. So, I don't think that the anti-Windows sentiment is unwarranted. The visitors themselves see the ominous Blue Screen of Death on screens from time to time.

I don't think physical security is an issue. There's usually very little of value on the devices the clinicians use, so there's no reason to break into one.

If you want sensitive patient data you go after the servers that receive and store data from the devices, or data entry computers. Hell, most desktops in hospitals contain sensitive patient information and malware is already on all of those because people are clicking on the 'INSTALL A VIRUS SCANNER ON MY PC' banner ads and admins are too lazy to lock down desktops.

If anyone ever had the technical skill to sabotage medical device just to hurt or kill someone, it would be an extremely rare event.

The real danger comes from automated malware that trawls networks or is attached to media and overwhelms or disables medical devices by accident. Malware that's just trying to find a home for a botnet can spread like wildfire and cause all kinds of havoc and is much more likely to be on the device right now.

Alas, medical device manufacturers (like most 3rd-party vendors) design their product to the barest specifications of their customers. If the customer doesn't ask for security or a hardened OS, they aren't going to go out of their way to make it so.

Actually, the physical security is important as well. The reason for this is USB viruses. I have seen one that still boggles my mind. It basically autoran on insert without displaying any sort of autorun dialog and then any stick that is inserted gets infected.

With a medical device, you don't just worry about the intentionally malicious viruses that try to extort money via fake virus ads or steal record. You must make sure that the system operates as the system is supposed to operate. If in the middle of surgery, your system crashes because some virus tries to link in to a DLL load because the surgeon loaded their profile to the system with an infected usb stick, you have a problem. Imagine that you had a laser on to cut something and now it isn't getting a command to stop from the system. Guess what will happen?

It doesn't need to be an intentional sabotage, unintentional does damage quite well. If your product has security issues, you don't just lose customers, you injure people.

malware isn't just used by folks looking for financial gain, but also people that just want to be pricks. While they may not write their malware specifically to destroy a medical devices, it's not hard to see how a bit of malware might prevent system resources from being available at the right time. For example, in my previous career as a medical tech, I've seen multiple diagnoses of epileptic EEG hinge on the timing of a single frame of video.

I once was hospitalized and got an x-ray while on a trip. They gave me a CD with the images on it, which I took to a different doctor (not affiliated with the hospital that gave me the X-ray) in my home city later. When the doctor put the CD into his Windows machine, I was shocked to see that it used AutoRun to run an image viewing program stored on the CD! My doctor was not at all surprised to see a totally unfamiliar program running on the same machine that he uses to access all of his patients' medical records, create perscriptions, etc. He told me this was the normal way to share images in different formats across hospitals. (I actually helped him figure out how to figure out the clunky UI of the image viewer.)

Having seen that, I can't say I'm surprised that medical computers of all kinds are full of malware. For all I know, I might have carried a computer virus from the hospital onto the doctor's office computer myself! I saw no sign of that, and the viewing software looked legit (even if it was clunky and hard to use) but viruses that attach to legitimate programs and hide from the user are not new. I hope this changes soon.

Wow! That happened to me - I thought it was a fluke. When I thought I broke my foot, I had it x-rayed, and they gave me a burned CD. I put it in my mac and noticed it was autorun.exe, and the images themselves were not readily available. I wonder how much they have to pay the x-ray machine folks for that awesome software vs. exporting a bunch of PNGs?

Medical images are typically stored in DICOM files which transport the information used for taking the X-ray image (X-ray energy, pixel-size, patient name and birthday, type of exposure). DICOM is a huge standard that also includes 3D images, ECG or EEG waveforms, ...

While a PNG for sure is adequate for your doctor to see a fracture of your bone or joint, it might be completely unusable for someone who wants to do quantitative analysis: How big is a babies head in a ultrasound? How dense is some bone material for planning radiation therapy?

In these cases the correct metadata is very important. It might of course possible to add it to the PNG standard, but DICOM is already there, and it's established.

And: In theory your doctor would only need one compliant viewer program, but in practice the "export data" functionality of a certain device will burn a DVD that includes the vendor's recommended viewer program.

Why doesn't it include the DICOM files then, why is it bundled into an executable

It would be nice to work oneself up into a great big RMS huff about windows vulnerabilities etc but this isn't the problem. Hospitals don't care about IT. Period. I've worked IT in a lot of places including hospitals. The medical gigs stand out foremost in my mind as the most hostile and willfully ignorant places by far when it came to all things computerized.

In my experience, medical technology solutions tend to be geared toward desk workers and bureaucrats because no-one else has the time to champion their needs and 'default' enterprise assumptions map so poorly to the needs of doctors and nurses.

So you get doctors and nurses who hate computers and computer-based solutions reflexively because a few more clicks, or minor Windows-cruft-based annoyances are just irritants for an intake clerk, but often tip the scales of "what's faster and more effective" for nurses and doctors back toward pen-and-paper.

Those workers tend to have UX needs that run more toward mobile users [1] and medical software is very rarely designed to meet those needs.

And the general aversion to computers -- again, in my experience -- is an act. Honestly saying they hate a given system has political costs and asking for changes again takes time (they rarely have to spare) to define and follow-through. But saying they simply aren't proficient with computers often has no such costs and can be very effective in getting overhead tasks pushed off to other workers.

This is also why you see those same types of users take so quickly and eagerly to the new wave of stripped-down mobile companion apps. They don't necessarily want to carry a tablet instead of a clip-board. They just really want to use a focused-task, minimal, responsive interface instead of another windows enterprise UI.

All of that is to say: Hospitals do care about IT. They just have a not-altogether-unique situation where the people who would most benefit from computerization rarely make time to see the projects done to their specifications and the overhead in 'typical' enterprise solutions can make-or-break feasibility. [2]

[1] half-seconds count. size of click targets counts. data unrelated to the current task is wasteful noise. etc.

[2] law and cpa firms can be similar, due the inaccessibility of the partners, the political situations and the resistance to anything that introduces overhead they can't bill for. These places, not unlike hospitals, often only see successful technology projects when they're limited to improving the speed/accuracy of administrative groups.

That's not particularly surprising in a highly government-regulated industry. No one outside of IT is particularly interested in IT. The difference between the medical field and other non-IT fields that require IT is that those other fields are open to market pressures.

Simply put, most people are lazy until they get smacked by the invisible hand. In the medical field, the invisible hand has been tied up by the government.

I utterly agree. I've found hospital IT staff to be negative, extremely unskilled, and openly hostile to even the most benign questions or requests. And I can't remember any other context where staff feel it's acceptable to hang up the phone on their contractors and consultants.

Depends on the hospital, but when it's bad, it's bad. Where I worked, the typist's printer went down due to a network error. An urgent job ticket was raised (by phone, I believe) as this was a room of eight typists who typed up dictated reports - important function. I was fished out from between patients to try and fix the issue and was successful. Six months later, an IT tech fronts up to the desk to ask where the printer was that needed fixing.

Same department had a tech that would only come down to look at the computers if our pretty staffer was there. When she left, he refused to come down.

Two questions:

Why are these devices connected to a network, let alone the internet?

Why are these devices running windows? Don't get me wrong I run it too, but that doesn't mean it makes sense on something like this.

To answer number one:

- Increasingly health monitors are on a network so that all the stats of a ward can be displayed at a central nursing station. The alternative is to turn the beeper really loud so that nurses at the station can hear it go off. In the case of (as an example) children, these monitors go off regularly - especially at night. The warning beeps are usually not a big deal but they do wake up both child and parent (whom often sleep at the hospital with the child). Oxygen Sat monitoring in particular has a high false-positive during regular monitoring on children. To ease the burden of parent, child and nurse these monitors are connected to a network and remotely monitored by nursing staff. This allows nurses to weed out false positives without waking everyone up.

- These networks should not be on the internet, I agree. But I can see low budgets (why run so many wires when one will work?!) and less-than-competent IT (also related to budgets) causing these networks to be connected to the internet.

I've seen air-gapped computers infested with malware. Portable storage devices can easily host malware. Air-gapped machines are more likely to have old, exploitable vulnerabilities, since they're not able to receive updates over the network and some people erroneously believe that being air-gapped makes them more "secure".

Edit: External media connectivity is typically used for updates. It's much more convenient to have a USB port that will use an off-the-shelf mass storage device than a JTAG and a custom programmer.

For something like a fetal heart monitor, which has been certified to work in exactly one configuration, why would you allow external media? Have an internal network, and lock down every device. If nurses want to have a computer to use for Facebook, it can be on a separate, non-medical network.

You'd allow external media because you need the data off the device somehow. Unfortunately, if the monitor uses a COTS operating system (doesn't matter which), that's one way in for malware. Unlike their military applications, air gaps in health care settings aren't there to protect confidentiality, but availability.

You would be shocked (I am constantly) to learn how many devices, kiosks, ATMs, and other terminals simply run Windows.

They're running Windows because that's what vendors design for. Nobody cares what the OS is. Nobody.

They're on the internet because it's convenient. The vendor has a support contract (so they can keep pulling money out of the hospital) which allows them to do software updates or maintenance without having to visit the site. Which they almost never do, anyway.

Are you being serious? If so, I'm just stunned that you're apparently of the opinion that medical data from recording devices should be sneakernetted around.

We had a rather unfortunate incident where our security engineering team disabled the network port of a device showing viral behavior - turns out it was a medical device in active use. Article has the right of it though - these devices are black boxes which we in IT were not allowed to modify.

Having worked on the vendor side of things, every hospital IT department is different, does different things to their systems, and half of them are incompetant. Forbidding IT from touching your recording devices is a necessary step for sanity - it's IT's job to know what's best for the infrastructure, but it's unrealistic for them to know the requirements of custom medical devices, of which there are hundreds of different types in any hospital.

A medical record-keeping package was installed at a site of mine recently. Their technician's first step: disabling all firewalls and then sharing the C:\ drive of every workstation out across the LAN. Not only for basic functionality, but to enable unencrypted "backups".

It's mindboggling that this is the quality one can expect from a $30,000 software package covering -three- seats in 2012.

What's scary is that not only are these machines infected, they often end up as part of large-scale botnets. When these botnets are involved in DDoS attacks, the medical machines hosting the botnets cannot be shut down or easily stopped because they are in mission-critical roles.

I'm not the biggest fan of Microsoft Windows but I realize it has its place. Is one of those places, though, really on mission critical medical devices, and if so, what advantages does it provide over the alternatives, such as a hardened or more use-specific operating system?

Why use Windows? It's easy and inexpensive to get developers who are familiar with the platform. You can leverage a lot of tools that already exist for the platform. You get a lot of hardware support "for free" using manufacturer-provided drivers.

Medical device manufacturers are for-profit entities looking to make a profit. If using Windows makes it easier to make a profit then they'll use it. If that's problematic to society, from a security perspective, then regulations should be put in place to put make security costs impact the manufacturer's bottom line.

Personally, I'd like to see pentesting as part of device certification requirements.

My understanding is that one of the biggest challenges (expenses) for these systems is getting them certified. If I recall correctly, reusing an Operating System that has already been used in certified products helps make the various certification bodies more convinced that the software involved will function "correctly".

I think the other issue here is liability -- if the manufacturer provides a "security update" and subsequently causes an error which kills a patient, it's the manufacturer's fault. Whereas if there's malware on the device, then it's the hospital's fault for not keeping the device clean.

Plus, there's a great deal of vendor lock-in in the medical devices industry, so I wouldn't expect to see hospitals suddenly adding devices from $NEW_VENDOR which bothers to spend the extra money to write security updates and spend millions getting them recertified.

This is incorrect. All COTS in a medical device is considered SOUP (Software Of Unknown Pedigree). All COTS must be validated for its intended use regardless of the supplier and a risk analysis must be performed for the use of the COTS. The device manufacturer is held liable for defects, not the supplier.

Although I never saw one myself, I heard that during NT times, it was relatively easy to get a custom (but still supported) build of the system from MS that matched some requirements if you had reasons and enough cash for it (which medical device producers did).

I'm not sure if that's still possible these days, considering windows server weights in disk space and memory than an usual device should ever require... Maybe someone has first-hand / more up to data information about it?

At we had a few (non-medical) products that ran on Windows XP Embedded [1]. It was pretty nice, it had something much like a Linux package manager where you could select which components you wanted and didn't want, and it would generate a disk image that you could dump on your target device.

And no, we didn't offer security updates (although Microsoft did provide some infrastructure to do this). This was a hardware company, the idea of providing anything other than consumables and spare parts was quite alien.

[1] The original plan was to use Linux, but we needed to connect various hardware that only came with Windows drivers...

I think that's exactly what I was told about. Thanks for the details.

It's even easier than you are suggesting, you just customise it yourself:

http://en.wikipedia.org/wiki/Windows_Embedded

Yes. We had systems running a custom build of windows 2000.

11 years ago I worked as a developer in the ER department of a hospital near Seattle. During my first two weeks I noticed that many of the workstations in the department were compromised (even though they had antivirus software). I was 18 at the time and figured the best way to start a dialogue about the problem was to email one of the mailing lists that showed up in Outlook when I started typing "IT". Unfortunately it was a list of IT vice presidents who now wanted to know why their direct reports had no idea that there were issues with malware or viruses. Those direct reports in turn wanted my head; I quit soon after because it became so uncomfortable.

I learned a valuable lesson, though: don't work for companies that would rather save face than know about serious issues. I've also tried to be slightly more tactful since then. :P