Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my opinion, hospitals should never run any kind of software accessing complex protocols locally. Should run everything, except real-time critical devices, using virtualized remote applications, so the security gets ensured at data-center level, instead of at client level.


The "complex protocol" is actually "plain" Windows file sharing, which is practically always enabled in the local networks. That's how the computers in the local network are traditionally supposed to be maintained.

I've managed a bunch of computers which weren't configured so, but configuring them that way you lose everything Microsoft created for the management of the computers in the local network -- to be effective you'd have to maintain and develop your own tools, which most of the companies wouldn't like you to do. It the users are supposed to "normal work" on the given computers, not enabling the file access is much harder to achieve.

I know there are "everything virtualized" approaches, but they are really expensive.


Windows file sharing (SMB/CIFS) is complex, in comparison to delivering remote applications using HTTPS (TLS/HTTP) through one single port (which is very simple, and easier to secure). So compare: local applications running many client remote protocols, or running remote applications through HTTPS (TLS/HTTP) with all the complexity at server-side (e.g. in-building data center, or remote data center, with high availability and being fault-tolerant, etc.).


Personally, I consider the approach "nothing done on the clients" problematic on many levels. I like what Apple is doing, like trying to make the client phones do the processing there, and not moving everything to the cloud, but still keeping the phones somewhat harder to be attacked "en masse". But there they have the user base that has grown effectively from nothing, on another side the whole personal computing approach has other historical development and expectations. The oldest known computing approach was actually "dumb terminals" but moving completely in that direction is quite wasteful.

At the end, I blame Microsoft for not recognizing enough what their users actually want: I know a lot of the companies which actually pay "the Microsoft tax" (as much as the Microsoft accounting is considered, they "use Windows 10") while in fact using Windows XP and anything but 10.

And they are right to do so. The problem with everything after XP wasn't that the companies wouldn't pay for support. The problem was that Microsoft "innovates" in the areas that businesses find directly harmful. The business would of course like updates, would of course like better and safer protocols implemented, would of course turn on new security settings if they would be delivered, but they don't want all the annoyance of all that doesn't have to do anything with the infrastructure, like "Windows or Windows Server which you have to use through the new 'phone' UI."

In short, there are many reasons there's a lot of Windows XP use, and Microsoft simply decided that they don't care.

Linux is of course even worse, even with the efforts of Red Hat to have long-term stable OS versions, the concept is that most of what the user consider "just apps" are typically so dependent of so many random stuff that maintaining the stability is unnecessarily hard.

Finally, Apple traditionally doesn't care for the company use of their products much.

Which leaves most of the infrastructures in not having any "straightforward" choice. And "redeveloping everything" every time the OS companies decide to "innovate" is really not possible.

That's were we are now. There's simply not enough awareness among the OS companies that "every non-programming entity" wants the stable infrastructure. Instead, the attention deficit goals of the managers of the moment are typically chased.


Designing expensive vertical market hardware that connects to the Internet around an embedded copy of Windows that never, ever gets updates is obviously insane, and yet that's the world we live in. It's well outside hospitals, etc - this is a world in which the SCADA worm was even possible.

More specifically on the NHS, it appears there was a decision in 2015 not to update some OSes because of Conservative budget cuts. I'm trying to track down details.


26 May 2015 "Thousands of computers still running Windows XP at risk after Government Digital Service opted not to renew support in April"

https://www.theguardian.com/technology/2015/may/26/uk-govern...


yeah. They finally said "look, get off this thing" which is fair enough, but they then cut funding to the bone, and IT is always the first thing skimped on.

I'm told by a friend in IT in an NHS Trust that the NHS actually came off quite lightly - all the affected systems were front-end PCs that don't store patient data locally, the patient data was safe on back end databases, so he spent Saturday reimaging a few hundred PCs and not one satoshi of ransom was paid to the attackers. Hopefully they won't get complacent about the bullet they dodged. (Ahh, who am I kidding.)


How would you handle emergency situations where communications could be disrupted?

Instead of remote apps, I think we need something more like Microsoft's edge intelligence they demoed at Build. The central data-centre pushes containers down to the devices and monitors them. You get the centralised control without the latency and disruption that remote communication would add and be unacceptable in many medical scenarios.


PCs without network are useless in a hospital context, anyway, as everything is already networked, even with applications being running locally (the database is not stored locally). It is easier to ensure connectivity through simple protocols (TLS/HTTP) running remote applications, than running local applications plus complex "remote monitoring" stuff. Regarding latency, if the servers are in the same building, you can get < 5ms latency with the default configuration (e.g. accessing Windows remote applications using HTML5 web clients).


This isn't true in a medical environment - the devices have value "in the room" whether its device control, test results interpretation or organisation of staff, procedures or patients, you can't just lose every computing device during DDOS and switch to paper.

edit: regarding the "same building latency" do we want every hospital, clinic and doctor's office running its own local datacentre? That will come with its own availability horror stories. For something like the NHS a multi-region centralised AWS style datacentre makes sense.


In a medical environment there are two kind of devices:

- Critical devices (that in most cases don't even run Windows): already safe, because using higher security standards.

- Administration devices (patient reports, etc.): don't have local database. And if you don't have connection, your computer is useless. That's the reason of "computers are not working" on hospitals when network is down. So a network failure would be a denial of service both when running local applications accessing a remote database, and for the case of pure remote applications. With the difference that with pure remote applications the attack surface would be near-zero at client side.


That is an oversimplification and the precise point of our disagreement. I don't believe "administrative" devices are non-critical to providing care. The last time I saw an NHS doctor examine an xray - it was an XP box. Is organising ER triage non-critical too?

Distribution, redundancy and routing around faults should be our vision for these systems and IMHO edge devices get closer to that. There are many ways a hospital can still shunt data around and use it locally in an emergency without giving up due to failure of remote systems.


Ahh yes the magic cloud, solving all security problems

Move to the Cloud and never have to worry about security again /s


You're taking it to a weird extreme of magic. There are reasons to run things locally and there are reasons for centralisation. Medical centres (at least on my area) often run on thin clients, because that's a better solution than having local technical staff in each village and town. This makes things like security controls easier to manage. It also makes things like backups a part of the contract rather than part of infrastructure you need to buy. On the other hand when the internet goes down, your results may not be available.

Look at tradeoffs. There are no magic solutions. Pretending that cloud services don't solve any problems is as bad as pretending they solve all.


It doesn't need to be 'cloud' - running a centralised VDE infrastructure would achieve the same without Captain Cloud to the rescue.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: