Medical device vuln allows hackers to falsify patients' vitals

Hackers may be able to falsify patient vitals by messing with the traffic on hospital networks. Research from McAfee shows it’s possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and a central monitoring station. Most patient monitoring systems comprise a minimum …

[Pen-y-gors]

Bit of a bummer.

We are all well aware of the need for security with, well, everything! IoT in particular of course. But spare a thought for the poor sods developing this stuff 14 years ago. I don't know if they genuinely didn't think of the possible problems, or whether they thought that no-one would be enough of a sick bastard to play with critical medical systems for fun or profit.

Either way it's tricky. This old system has holes, I suspect the latest systems have holes. We can make systems that are much, much more secure. But that takes time and money.

Question: is it better to get life-saving technology into the market now at an affordable price (but with an obscure hole or two), or wait another five years (while people die) and then deliver something secure at twice the price, making it less widely used.

I have no simple answer. Do we trade off the possible risks of injury due to (unlikely) hacking against likely deaths from delay and increased price?

I think better to focus on US voting machines!

[Anonymous Coward]

Re: Bit of a bummer.

> spare a thought for the poor sods developing this stuff 14 years ago.

March 2008: “a team of computer security researchers plans to report Wednesday that it had been able to gain wireless access to a combination heart defibrillator and pacemaker.” ref

[Alister]

Question: is it better to get life-saving technology into the market now at an affordable price (but with an obscure hole or two), or wait another five years (while people die) and then deliver something secure at twice the price, making it less widely used.

To be fair, very little of this technology could be classed as life saving... standalone monitors, syringe drivers etc have been around for years, and do a perfectly adequate job, so to suggest that not having this equipment available will allow patients to die is unrealistic at best.

The main reason that Hospital authorities are pushing for this sort of always connected, centrally managed equipment is so they don't have to employ as many staff - one person sitting at a desk with all the patients' vital signs available to them at the same time, and all the alerting in one place.

That doesn't mean that it's essential to the care of patients - the machine that goes beep is a nice-to-have...

[Anonymous Coward]

Now why should I believe McAfee?

Their false positive rate on their AV has gone through the roof in recent months and they've seemed to have stopped correcting their buggy database when the false positives are reported to them.

[Anonymous Coward]

Use case

So what is the use case / attack vector that this would achieve?

I hacked this reader and made the person look like they are dead / alive?

All security needs to look at the risk and the mitigation/cost to secure and resolve. Not all things need securing and I feel this may be one of them. A poster above "or wait another five years (while people die) " has it spot on.

[teebie]

Re: Use case

"I hacked this reader to make it look like the patient was dead, and now they are"

"I hacked this reader to make it look like the patient was alive, and now, thanks to the delay in the arrival of the crash cart, they permanently aren't"

[Anonymous Coward]

Re: Use case

"I hacked this reader to make it look like the patient was alive, and now, thanks to the delay in the arrival of the crash cart, they permanently aren't"

Or take the easier option - torch a dozen ambulances and cause a lot more deaths.

[Intractable Potsherd]

Re: Use case

"Or take the easier option - torch a dozen ambulances and cause a lot more deaths."

That's a blunt tool with a different type of outcome. The scenario you responded to is directed at an individual, probably with a specific reason. Your scenario is not directed at a specific target, but catches random others. To me, it would be part of a disruption of society, and, though I never use the term lightly*, would probably be classed as terrorist action.

*For example, I spent several minutes swearing at the TV for classing a Fiesta driver's actions as "terrorist" simply because of location and skin colour. Morons.

[iron]

Wrong Medications?

Any hospital or doctor who is dispensing medication based on the remote monitoring console without checking the readings on the local monitor has bigger problems than hackers.

[ReggiePerrin]

Tip of the ice berg

Tip of the iceberg. Having worked in healthcare IT for over 10 years i doubt if most medical device companies even know what encryption is.

Hospital IT: "What OS is this running then?"

Supplier: "Ermmmm... Windows XP"

Hospital IT: "Really? Christ... what AV is on it?"

Supplier: "None... and you cant install one because that would mean we need to get FDA approval again for this"

H IT: "... did you just type 'admin admin' in that logon screen"

S: "Yeah... don't change it because its the same on them all... our support guys need them to be all the same"

H IT: "... you ever heard of Wannacry?"

S: "Is that a rapper?"

...

[Alan Johnson]

Not as big a problem as suggested.

It is impossible to asses the ipact of this without an understanding of the intended use of the device but it is almost certainly the case that if it is being used as a vital signs monitor it will have a local audible alarm and alert feature. These must be there because the network/wireless communications cannot be relied upon. Yes misleading information could be fed into the remote monitoring system and this might be a factor in misleading clinicians but the same clinicians will still use visual observations and information from many other sources. In addition advice from the manufacturers will certainly include sensible security measures on the hospital network.

[Barleyman]

Re: Not as big a problem as suggested.

"It is impossible to asses the ipact of this without an understanding of the intended use of the device but it is almost certainly the case that if it is being used as a vital signs monitor it will have a local audible alarm and alert feature. These must be there because the network/wireless communications cannot be relied upon."

Not true. The main motivator for remote monitoring is to cut down on the individual devices with displays going "BEEP". Those cost money, have to be certified and then maintained for a decade or more and nobody's looking at them 99% of the time. So a remote device wouldn't have much in the way of displays or so on, having those would defeat the remote monitoring benefit to start with.

[Ken Moorhouse]

Manufacturer's T's&C's...

Just need to point out that their kit is for private LAN use only. The equipment is not to be used on LAN's connected to a WAN.

IMHO development of this kind of kit - surmounting the medical technicalities is far more important to all parties than its ability to work with, say Windows 10.

If the developers were expected to provide their kit for systems loaded with Win 10 then they'd either be spending a lot of development resources ensuring that Win 10 did not demand an update halfway through a critical medical event, or they'd have to put a disclaimer in their T's&C's about it not working entirely flawlessly using Windows 10 as the host Operating system.

Which would you prefer at the side of your hospital bed? A DOS screen, or a W10 one?

[eldakka]

Re: Manufacturer's T's&C's...

Just need to point out that their kit is for private LAN use only. The equipment is not to be used on LAN's connected to a WAN.

I was thinking this, so this isn't IoT kit, as the I stands for Internet.

I would expect that the manufacturers expect these devices to be placed on secure, segmented, access controlled (i.e. no open RJ45 ports for anyone walking past to just hook something into) networks.

But even saying that, in this day and age implementing reasonable security precautions should be a no-brainer automatic development process. Basic security is available from standard libraries, it's not like they'd have to roll their own, they'd just have to use whats already out there.

Even tho these are 14 year-old devices, I bet they were at the time (and probably still are) quite expensive as all medical equipment seems to be, therefore it would be standard practice that such devices are used for at least a decade, probably two to three decades in smaller regional hospitals or hand-me-downs to poorer regions of the world. Therefore manufacturers should still be supporting them with the occasional firmware updates (even if just every 3-4 years) to implement newer security practices in them.