Computer Viruses Are "Rampant" on Medical Devices in Hospitals

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.

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.

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.

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.

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.

- 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.

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.

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?

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.

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.