So your workstation is next to a bed and is attached to a machine which feeds a drip to keep a little girl alive and it gets your untested patch or whole OS upgrade and the dosage is increased or the driver stops and the patient dies.
Only non-critical machines can just automatically apply software patches from Redmond (or anybody). This is not laziness or incompetence - only a few weeks ago military grade exploits from the USG were leaked onto the internet and are currently being re-purposed for non-spying applications. Does anyone think any organisation is prepared for this? Chinese chatter indicates that ms17-010smb doesn't even fix all cases! Many organisations will have been saved by infra guys making sure ms17-010smb was rushed through and that McAfee sigs were updated 'just because'.
Machines like that, which cannot shoulder the risk of applying updates to a network-connected general purpose OS designed to run third party (potentially malicious) code on a non-deterministic non-realtime system... probably should not be using such a system. Patching is risky, not patching is risky.
They should have formally validated software running on formally validated deterministic realtime hardware, running in non-networked environments (But with telemetry and remote control from networked computers if that's convenient) we just don't bother because it's cheaper and legal to get away with selling hacky nonsense.
I agree. A mission critical MRI machine should not be running an off the shelf OS (Win, Mac, Linux). If you're paying $5 million for a machine, it better have its own real time operating system that had been independently audited.
Now the machine that you pull up the images on is most likely going to be a general purpose PC/Mac. You still need to patch that. Your IT dept needs to have patch cycles that deploy in sets, so all mission critical equipment can be tested before everything gets patched. It takes diligence, and planning. If you prepare at a very large hospital with two MRI machines, then a bad patch can leave you degraded, but not totally offline.
Custom operating systems would require higher development costs and extremely rare sysadmin skills, which would mean larger hospital budgets, which would mean higher taxes or premiums.
So your workstation is next to a bed and is attached to a machine which feeds a drip to keep a little girl alive and it gets hit by a worm like this one, stops working and the patient dies.
As long as the chance of cyberattacks is larger than the chance of horrible patches, you simply accept the risk of horrible patches and install them anyway. Or keep the system totally isolated from everything, if it's that critical.
The IV drip machine is not plugged into the CoW (Computer on Wheels). That workstation is running a version of enterprise Windows primarily to allow the medical professional to view and update patient records.
The IV drip machine is plugged into the wall, and is operated by buttons on the front.
In reality, a huge number of modern IV drip machines plug into the wall for power and get their network connectivity via 802.11. This is to allow remote configuration and status monitoring.
Your hypothetical situation distracts from the actual issue. The ransomware infected NHS patient records servers and receptionist workstations, according to the article.
> Well this justifies MS's decision for forced updates in Win10. Not that I like it, just saying.
Unfortunately, I think the active hours period cannot be set to more than twelve hours, which is less than the time required for some surgical interventions. I can almost imagine it: OK everyone, ten-minute break while Windows installs its updates, this guy who's been on life support for the last ten hours can wait a little longer.
That's why updates are not forced on business-grade installs, and forcing them would be a very, very stupid decision.
Forced updates make sense for home users, since Microsoft can't depend on someone requiring them to keep their networks secure. For other types of users, second-guessing update policies is always a bad idea.
Windows is not a real time OS. Neither is Linux (except for perhaps a limited number of forks/distros).
If someone is going to die if a computer stops working for any reason at all, it should not be running Windows, or Linux, or macOS. It certainly shouldn't be connected to the internet or to any other network.
When we treat computers as nice-to-have mixed-use machines with all the bells and whistles, you need to treat them like nice-to-haves and not need-to-haves.
> Surgeon workstations can absolutely be restarted once per month to install the monthly roll-up.
I was replying to the part about forcing updates. I didn't know about the group policy setting (rightfully pointed out by sp332); without it, you don't wait a month, you wait at most 12 hours :-).
Win10 Pro is more flexible, although you might have to drop down to Group Policy to do it. http://pureinfotech.com/defer-windows-10-upgrades-updates/ At the very least, the workstations can be pointed to internal WSUS servers which control the rollouts. I'm guessing that's how most of the currently-vulnerable computers stayed vulnerable until now.
Keep in mind that on business grade installs the updates are not forced.
And there have already been situations where updates have caused problems. Maybe not as severe as a full on attack, but enough to potentially disrupt production and thus risk someones job.
The infection I'm dealing with happened from a fully-patched Win 10 Pro machine running Windows Defender and Outlook 2013 (32). It already had authenticated access to the files on the server it encrypted.
There was a Windows script file on the desktop, something like "UPS tracker.js", but it disappeared before I could grab it and a free space recovery didn't return it. (Possibly due to TRIM, it was on an SSD workstation.)
Not all patches require reboots on many OSs. Some OS's even apply kernel patches live. :) They could have taken a more user friendly approach. I understand they were boxed in a little technically, but they built the box.
