Comment by horsawlarway | Hacker News Reader

Comment by horsawlarway | Hacker News Reader

Parent Full thread

I don't really think you're speaking from a spot that's actually considered the requirements of the system.

Ex - you say this:

> Hospital computers should not be connected to the internet.

But then you immediately jump onwards, as though what you've said is obvious common sense - but I don't think it is.

Can you explain to me why you believe hospital computers shouldn't be connected to the internet, and then discuss and weigh the downsides of NOT connecting them?

Because there I think that comment exposes the exact mindset that the author was discussing... no obvious appreciation or understanding of the situation, just an ill-informed off-the-cuff remark.

Can you tell me how you plan to implement cross facility dosage tracking for patients?

Can you let me know how you're going to send CT scans or x-rays to correct expert?

Can you tell me how that patient's records are going to be updated, how billing is going to be generated, or how their personal doctor is going to be notified of their condition?

I can think of a LOT of reasons that hospital computers really should be connected to a network. Maybe not every computer, maybe not every network, but even that distinction appears to be far beyond the thought you put into it before immediately saying "Hospital computers should be connected to the internet".

You're basically making the author's point for him here.

Most of your questions can be answered with these two weird old tricks: site-to-site VPNs && VLANs

Why has everyone seemingly discarded these ideas or forgotten? Yes, it is a pain to manage. Industry could reduce this pain, but investing in good security isn't profitable.

Blame the profit incentive. Blame the VCs (especially the people who own this website)

* Because they don't really work. It's better to assume the network is adversarial and work from there than to separate the world into the trustworthy network and untrustworthy network.

* It's much much easier to secure a network when you completely disallow client-to-client communication and block all communication to clients not initiated by them.

* Trusting the client that attackers can physically access is a recipe for disaster.

* Because VPNs are just an application on the internet.

> * It's much much easier to secure a network when you completely disallow client-to-client communication and block all communication to clients not initiated by them.

VPNs and VLANs are a technology that allow this. I think 'Zero Trust Architecture' wonks have done a disservice to industry. If your 'zero trust' app has a bug then your device is exposed (probably) directly to the internet, naked.

If you layer your security - starting with the bare minimum of VLANs, VPNs, network segregation, etc. then you can layer on top zero trust technologies.

What ends up happening is that people build their own pseudo-VPN with user space applications that network together a bunch of machines existing over the internet, potentially exposing dozens of new internal networks to malware vectors.

> You're basically making the author's point for him here.

And this is were I fundamentally disagree with the author. Nothing you've listed requires access to the internet - it requires access to a network.

It's a lot easier to just deploy everything and set the firewall to any-any and go home because it's working.

Like the author says, it's hard and difficult to find the right level, but to scoff at the simplest of advice of "it shouldn't be on the internet" is giving up.

> And this is were I fundamentally disagree with the author. Nothing you've listed requires access to the internet - it requires access to a network.

Ok - now what? I don't understand the disagreement you seem to think you have.

That network inevitably requires a connection to the outside world or those exact same features I listed above stop working. So you're just shifting blame without an answer...

So continue with your path - now I have an X-Ray machine that's connected to a network. The router on that network still has to connect to the internet to facilitate functional use of the machine, so let's assume crowdstrike is running there - tell me how your advice of "Don't connect it to the internet" is meaningful here?

I have an expert radiologist who I want to confer with on my patients x-ray, he's in a different state - what is your advice? How is my problem solved with a banal "Just don't connect it!"?

Many countries have dedicated network for medical services.

If you don't you could use dark fibre, MPLS, etc.

Connecting to an network should not automatically get you routable access to the internet. A lot of headaches from cyber attacks would go away with this was the principle. But for a lot of people connecting to the "network" means unfettered "Internet" connectivity.

I've worked at places that have used dark fibre and MPLS and had no security problems, as that's not an easy attack vector. Moving to 'SDN WAN' means now sites are connected to the _Internet_ and a simple DDOS can take your branch down.

This may or may not be important to you, but the general advice of keeping off the Internet as much as possible unless you need it is good advice (and a vendor not offering central deployment of updates is a pretty poor excuse).

> it's hard and difficult to find the right level

There are some pretty solid documentation on this and has been for some time, the knowledge simply has been lost or discarded because this kind of knowledge was considered 'arcane' or 'restrictive'.

There were times when infrastructure had devel/testing/production environments with staged rollouts and deployment.

Production had only only the minimal access, with admin config routable only to a private network, hidden behind the frontend cluster. Things were hard for admins and hackers alike.

There was at one point gated networks and the idea of militarized and demilitarized zones, router level firewalls, outgoing connection limiting. Centralized logging (nah, don't do that, just run your apps on a POD and forget your security, forensic recover of your app is dead by the next deployment (probably twice over today) already) and many many more things.

We bought the newthink of 'web security' as how we should build our infra as the the true way. When we see it fall apart on a blue friday afternoon do we look back to see the bigger picture ? No, we can't take responsibility for the weakness because any suggestion of personal responsibility that requires work is out of the question.

> I can think of a LOT of reasons that hospital computers really should be connected to a network.

Connected to network ≠ connected to Internet.

There's only one other network that connects all healthcare providers, POTS. Which is why fax was/is popular in the healthcare space for the longest time.

If you're suggesting that the hundreds of thousands of healthcare providers just in the US all get together and lease some dark fiber -- there's zero chance that happens.

Besides, doctors routinely use resources on the public internet.

> If you're suggesting that the hundreds of thousands of healthcare providers just in the US all get together and lease some dark fiber -- there's zero chance that happens.

I am suggesting that not all computers in a hospital need to have an Internet-accessible connection.

Nor even all applications on a PC need to be Internet-accessible: if you're using Windows you can have an application icon that does not launch a program locally, but rather initiates an RDP session to a terminal server (TS) and runs the program there, while the app window is displayed locally (like X11 forwarding). The (TS) server is dual-homed so the app that runs there can (e.g.) connect to patient records network, but the local PC that is just being used as a display is not on that sensitive network.

Ah, well, this is already done in many places. It doesn't prevent malware from spreading, though. The latest malware is good at moving horizontally.

For all practical purposes, yes it does. Unless you are expecting hospitals and doctor's offices everywhere to develop their own parallel internet-like network. Which seems a bit unreasonable to expect of everyone.

Certainly it's doable: other commenters point out that Sweden and Poland have systems like this. But they are also relatively small countries, and presumably their governments have decided to foot the bill for most or all of it. The idea of the US doing something like that is unfortunately laughable, and you can be sure healthcare institutions aren't going to pay for it.

> Unless you are expecting hospitals and doctor's offices everywhere to develop their own parallel internet-like network.

I am expecting (health) IT staff to make an assessment on whether a system needs to (a) have Internet access at all, or (b) have Internet access perhaps through a filter/proxy.

There are entire classes of devices that should not / do not need to be able to reach www.google.com or 1.1.1.1. While my DC HVAC & PDU and IPMI networks have network connectivity, but they do not have Internet connectivity.

The answer is simple: security. Attacker needs a way into the machine to control it. Granted, there are some obscure vectors of attack that don't need network connectivity (Stuxnet), however the game becomes much harder for the attacker when they have no direct connection to the target system.

Many countries solve this by having a separate network for hospitals, but it is not the only way.

In general, it is a trade-off between security and convenience. Yes, you can't send an e-mail without an Internet connection (well... not easily). But do you need to? From the computer that controls the MRI machine? Or is it just easier to say "we need Internet because updates"?

>you can't send an e-mail without an Internet connection

Of course you can.

To an external recepient? And you misquoted me by removing end of the sentence in parenthesis.

Of course. You send your email to an internal MTA that relays it (it likely has internet access). Segregation of access from terminals is a good thing, why would you want the terminal to be able to relay to an internet MTA itself?

Reply on news.ycombinator.com