4 ms·
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
by horsawlarway 2y ago
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.
- bornfreddy 2y agoThe 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"?
- kwhitefoot 2y ago>you can't send an e-mail without an Internet connection Of course you can.
- bornfreddy 2y agoTo an external recepient? And you misquoted me by removing end of the sentence in parenthesis.
- averageRoyalty 2y agoOf 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?
- deleted 2y ago[deleted]
- throw0101a 2y ago> I can think of a LOT of reasons that hospital computers really should be connected to a network. Connected to network ≠ connected to Internet.
- kube-system 2y agoThere'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.
- throw0101a 2y ago> 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.
- kube-system 2y agoAh, well, this is already done in many places. It doesn't prevent malware from spreading, though. The latest malware is good at moving horizontally.
- kelnos 2y agoFor 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.
- flumpcakes 2y ago> 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.
- deleted 2y ago[deleted]
- worthless-trash 2y ago> 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.
- horsawlarway 2y ago> 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!"?
- CapstanRoller 2y agoMost 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)
- Spivak 2y ago* 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.
- flumpcakes 2y ago> * 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.