Hacker News new | ask | show | jobs
by api 2246 days ago
My approach is and was always edge-first. Security begins at connected devices; everything else is an afterthought. The only time you try to secure something primarily at the network level rather than the device level is when it's legacy junk you can't secure otherwise and that you must use.

I am not opposed to network firewalls and such, but they're just defense in depth. If the whole network wouldn't remain secure if it were connected to the Internet with no firewall, it's not secure.

Given that these things are afterthoughts, I am not willing to prioritize them much over efficiency, complexity reduction, and user experience. Afterthoughts should be sacrificed to complexity reduction because complexity negatively impacts security a lot more. Inefficiency and poor UI/UX also have security implications. They increase the amount of "shadow IT" type activity and also seem to make phishing easier. If you secure something in ways that prevent people from getting their work done, they will get their work done insecurely.

Treating NAT as a must-have or should-have rather than the ugly hack you don't want to have increases complexity and negatively harms UI/UX by making P2P stuff not work and making people have to work harder to do simple things. If removing NAT makes you insecure, you were insecure to begin with.

Needless to say I am a fan of the BeyondCorp/deperimeterization approach. Ideally physical networks should be dumb pipes and everything should be virtual. The LAN itself is legacy baggage.

1 comments

I do not disagree.

If you look at my original message, I was not suggesting NAT was useful - on the contrary, I was cautioning against relying on your internal NAT as a mitigation of the other enterprise's change processes. My whole post was about complexity reduction (as it relates to inter-enterprise conections)...

> Needless to say I am a fan of the BeyondCorp/deperimeterization approach. Ideally physical networks should be dumb pipes and everything should be virtual. The LAN itself is legacy baggage.

I also like it. But the post I was originally replying to implied a server->server connection between two enterprises, which is afaik not at all addressed by BeyondCorp or any of the projects it inspired - specifically, you need to treat the other corp like a Google user at home, rather than a Google employee in a hotel because you cannot enforce trusted hardware, inventory tracking, or any of the other things that make BeyondCorp as useful as it is.