Hacker News Reader

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.

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?

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

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

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

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

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.

> Hospital computers should not be connected to the internet.

Scheduling an urgent care appointment is connected to my account at the hospital network. When I step into the hospital and get tests done, everything is automatically uploaded to a web portal where I can view it and doctors can easily forward my test results to other facilities. Lot of the imaging work is actually done at third party facilities but they still show up in my medical records , presumably having been forwarded.

When my appointment begins my doctor can look up any comments I left when scheduling the appointment so she knows why I'm there.

Is it possible all the different buildings and facilities that are part of the hospital Network I belong to which extends across multiple counties across my state could all be running on their own private isolated network that is air gapped with medical records manually transferred over to the web portal via sneaker net?

Sure, but no one is going to do that.

When my appointment begins my doctor can look up any comments I left when scheduling the appointment so she knows why I'm there.

Or, you could… you know… talk to her.

I work for a healthcare company that runs several hospitals and primary care clinics. When you become a patient, you're given a little notebook and a branded pen so that inbetween appointments, the patient writes down every little health question and problem they have. When the patient shows up for the appointment, the little notebook is reviewed by the doctor.

Convenience should not always trump security.

That sounds like an absolute nightmare. I'd lose the pen and paper within 30 seconds. I much prefer being able to send a quick message to a healthcare provider on my phone and have them get back to me same or next day. Especially for the "should I come in for this rash?" types of questions. (I got MRSA at the gym one time!)

At my child's pediatrician I can upload images through the web portal and have a nurse call me back anytime of the day or night. If there's any follow-up questions at my child's next appointment, his doctor has full access to all communications that happened through both text message and the web portal.

This kind of 24-hour digitally connected healthcare access with a huge boon as a first-time parent and made life a lot easier, especially when incidents like when my son woke up at 3:00 in the morning screaming and then projectile vomited 6 ft across his room (which by the way, was nothing to worry about and apparently completely normal... So long as it just happened once.)

I'd lose the pen and paper within 30 seconds.

We should reduce the security of the entire healthcare system because you can't adult?

I much prefer being able to send a quick message to a healthcare provider on my phone and have them get back to me same or next day.

Goalposts moved.

This kind of 24-hour digitally connected healthcare access with a huge boon as a first-time parent and made life a lot easier

Your moved goalposts pretend that we don't also offer a 24-hour medical hotline.

> We should reduce the security of the entire healthcare system because you can't adult?

I commented that my hospital network has the ability for me to see test results, communicate with medical providers asynchronously, and lets healthcare providers communicate what I said to them with each other.

Your counter proposal was a notepad and a pen.

Those two things have very different feature sets.

A site not directly hooked up to the main hospital system where I can add notes of things I want to talk to during my next visit, sure, maybe that is a decent proposal to trade off security vs convenience.

> We should reduce the security of the entire healthcare system because you can't adult?

Do you expect patients dealing with depression or anxiety to be able to keep track of that notepad? How about patients who don't have secure housing, or who live with an abusive partner?

Or anyone who is elderly and just forgets things now and then.

Or anyone who is not neurotypical and has issues with memory?

That sounds awful. If I went to a doctor that did that, I would immediately find a different doctor.

Just to add to this: Apart from the security aspect of hosting your software dependencies internally, it also gives you the added benefit of better availability and performance.

As you mentioned in your other comment however, this presumes a certain mindset in people where they are willing to plan upfront and are mindful of the dependencies their software needs. As you say, just pulling whatever from Docker hub is certainly easier.

Internally hosted repositories also allow you to pull and install updates at your own pace, possibly days after they have been released upstream. So if a patch is borked you won't be affected.

I hate to be that guy but 'back in my day', that was called "testing/production" deployments.

> Hospital computers should not be connected to the internet.

But then how will doctors google the patients' symptoms?

If your answer is "they should already know all that is required to do their job without looking it up online", then consider whether you hold yourself to the same standard. I don't.

It is hard to make assumptions about what parent means by that statement, given that there are degrees in which a system can be "connected to the internet". For example, every request coming in or going out, as well as SSH access, could go through a proxy. I would still call that being "connected to the internet", but it's different from giving your server a public IP address.

They could have designated internet connected computers and other computers for admin tasks and processing x-rays etc.

Having the hospital admin and some machines connected outwards seems like a recipe for killing patients.

If the admin computers aren't connected to the internet, how do patients interact with the administrative staff, for things like appointments, referrals, etc.? If the x-ray processing isn't connected to the internet, how do the x-rays & the radiologist's evaluation end up in the patient's record, or in a place where the patient can download their imaging results?

This information (looking up symptoms) would be better served by a curated internal wiki that all practitioners have access to. Not google.

What about medical reference service like uptodate.com

Medical care is so bad now I have had the doctors and nurse practitioners look up webmd while I’m in the room with them.

Doctors and nurses have always had large reference tomes that they refered to.

List of medication side effects, dosing guidelines and so forth have been common throughout the industry almost since it's very inception. Indeed, there are books going back thousands of years across multiple cultures around the world that are just referenced guides for medical practitioners.

doctor: heart arythmia

google ai: remove heart

doctor: ok lets schedule the operation!

Mobile device, second network, vlan etc. Lots of options.