Assume that the physical networks are compromised, and have all privileged resources only accept connections over VPN. Is it perfect? No, but it makes further compromise harder. The assumption of no trust also means acknowledging that you need gate incoming connections.
I can assure you that many, many security people (I would say all security people, but I have no doubt that there's some laggards working under the radar somewhere) already think like this. This is all part of a multi-layer security strategy, and having encrypted communication on top of a secured physical network is pretty standard and is what a lot of orgs strive for. Unfortunately, it really isn't feasible and it's not because of any decisions by the security people, because...
> have all privileged resources only accept connections over VPN
This sounds great until you remember that half of your organization runs on legacy software that doesn't play nice with forcing VPNs and your technical architect has informed you that they aren't planned to upgrade to newer software until 2030. This is especially so in government orgs (like NASA).
> isolate those machines
that's exactly what is done, but you just said that security people need to stop thinking in those terms, so...?
And isolating the machines: I mean separate networks, or vpn only access to privileged resources.
And it goes without saying: traffic from unknown systems on a privileged physical network get dropped at the router.
Congratulations to your company! That is quite a great policy. Unfortunately, that would be literally impossible in many of the rest of the world's companies.
We aren't talking about dropping access of a desktop machine that's a few days behind on its Windows updates. We're talking about massive, enterprise-spanning systems like mainframes, ERMs, industrial control systems, data pipelines, etc that interface with hundreds of other applications across your company and are 1000% mission critical. Dropping access could quite literally bring the entire company (and all of its revenue) to a grinding halt. And because of their size and importance, they take years and tens of millions of dollars (not an exaggeration; I've been on teams tasked with upgrades like this) to upgrade even when planned half a decade in advance.
Companies are complex, and security is not one-size-fits-all. You do what you can and hope for the best, but at some point there's only so much you can do without burning the entire company to the ground and starting all over.
A Microsoft certificate training I took recently literally put emphasis on randomizing source port numbers as a way to mitigate attacks.... let that sink in.
Many things, here's three to start:
* A measure of privacy - instead of every rando with ability to sniff packets (activities you have no way to ever know about, available to many parties along the path) only the DNS server (which you choose, presumably trust, and can change) knows what names you resolve.
* Stronger foundation for TLS - LetsEncrypt and other public certificate authorities depend on DNS to issue certificates. If an attacker controls DNS, they could easily generate certificates for any site they wanted to attack.
* There have been many shady incidents with certificate authorities. I just feel that beefing up some of the other layers in the stack is a good idea.
> faking DNS responses just results in a connection that is closed immediately
On the web it's often not closed immediately, the users often get a certificate warning that they may be conditioned to click through. Of course HSTS helps with that, but still... why the hostility to securing the name resolution layer?
I know at least Google and Apple gate almost all internal resources on VPN connection and per machine authentication. This is over 10s of thousands of machines and users.
It also makes attempts to use "unauthorized" devices with your privileged resources harder/impossible.
But more importantly: if you are allowing out of date machines on your network you are by design choosing to allow pretty much every attack that is happening at scale these days. If you are allowing out of date machines to access privileged resources you're rapidly heading to game over from a security PoV.
The Giants are in a class of their own. Lessons are often worth learning, but that doesn't mean most organizations can do what Google can do.
>(The model benefited the fact that all of Google’s internal applications are already on the Web).