4 ms·
> 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
by 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!"?
- flumpcakes 2y agoMany 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).