The solution is complete zero trust and distrusting the network in organizations. You should treat the internal network as external -- hostile. Google does this. They were the first ones to widely adopt zero trust with BeyondCorp and there has not been a Google internal organizational breach since Aurora (which made them adopt BeyondCorp, what they call zero trust).
You have completely managed endpoints, strong hardening of the endpoint and complete inventorization of all the resources in the organization. You have certificates installed onto each device. You have an ACL engine that determines whether a user should get access to a particular resource. You can use deterministic lists and also incorporate heuristics to detect anomalies (working hours, etc). All Google internal apps are internet-facing. You can open them, get redirected to the SSO portal. Come and do try to get in. You will not.
Many of these security problems are solved. You just need to implement the solutions.
Google makes zero-trust work by having a highly "centralized" or "uniform" tech stack all the way from tooling, to hosting, to infra. So everything defaults to zero-trust and it's not something you would need to think about setting up.
Most big organizations have built up their internal/external tech over decades, with large parts of it being essentially "mothballed", and high degree of heterogeneity stemming from tech changes over time/acquisitions/departments having flexibility in what tools and design they can use. Shifting to zero-trust requires a lot of migration work across all of this, "training" ie figuring out how to get stubborn IT people to buy in to the new way of doing things, and most likely a shift to the "centralized" kind of model that Google uses.
Even if the first two are funded, that third "centralized"/"uniform" model can be very expensive. One of the reasons Google has to deprecate things so much is that the centralized model requires constant migrations and breaking upgrades to keep things running, which makes it so "mothballing" isn't a thing: you either have enough people assigned to handle the migrations, or turn it down.
I agree that zero-trust is the best security model and it solves many problems. But I guess I'm also saying it's much easier said than done. With my startup I want to solve a lot of these kinds of problems (ie introducing "uniformity" that follows best practices) for my customers, but it's inevitable that some point a customer will ask for the ability to "turn off zero-trust and allow for IP whitelisting" - is it worth it to close a potentially big deal? It's also probable that any reasonably successful company will at some point perform an acquisition involving a company without a zero-trust model - is that reason to cancel the acquisition?
> Shifting to zero-trust requires a lot of migration work across all of this, "training" ie figuring out how to get stubborn IT people to buy in to the new way of doing things[...]
You're right, most times organizations need a fire lit underneath them to change, for Google, it probably was the NSA annotation "SSL added and removed here :^)" on a slide showing Google's architecture from the Snowden leaks.
> You're right, most times organizations need a fire lit underneath them to change, for Google, it probably was the NSA annotation "SSL added and removed here :^)" on a slide showing Google's architecture from the Snowden leaks.
> You have completely managed endpoints, strong hardening of the endpoint and complete inventorization of all the resources in the organization. You have certificates installed onto each device. You have an ACL engine that determines whether a user should get access to a particular resource.
None of those are “solved” for any mid or large-sized enterprise where tech isn’t their code competency. In fact, I’d say most of these are insurmountably hard.
This is a “draw the whole owl” kind of response. Its very well to say that you can do things differently, but imagine Shaw Industries (22k employees, largest carpet/flooring manufacturer in the USA) doing any of that.
The first step to saying you're not doing any of that is saying you're not doing it.
I work at an older company and it has successfully moved an number of apps to this model.
Some will take another decade, but many are there.
I think I agree with this conclusion. But I work in a Shaw-like enterprise (only the products are more mundane than flooring). What are the hurdles we’d see if we tried it? What processes and practices are we likely using, that would break under the zero trust model?
For a start, you'll have a bunch of internal applications that are not hardened to be exposed on the public internet, and that you have neither the time nor the money to replace. A "zero trust" product vendor will therefore offer you something exactly like a VPN, but for some reason they'll say it's not a VPN.
You will have "heuristics to detect anomalies" and users won't be allowed to directly see what 'anomalies' are being detected, for security reasons. Instead, if someone plugs their phone into their laptop to charge it, they'll start getting network timeouts when they try to use the ERP system. After waiting 30 minutes for it to come back online, then calling the helpdesk, they'll be told that the charging phone counts as an unencrypted disk and they need to unplug it.
Other heuristics will create a huge backlog of 'maybe' alerts they'll invite you to manually review. Warning, a user who hasn't logged into the holiday booking system in 9 months just logged into the holiday booking system. Finding the real problems will be like looking for a needle in a haystack.
In-house infrastructure - which your team provides - will start appearing flaky, with mysterious outages. Public-internet SaaS products like Github will start looking better and better.
It will turn out the "zero trust" system doesn't work with your office's networked printers, access control system, CCTV cameras, meeting room conferencing system, server BMCs, networked UPSes, networked oscilloscopes, networked 3D printers, networked telephones, and so on.
It will also turn out, once a vendor is giving you "completely managed endpoints, strong hardening of the endpoint" you can't update without going through them first. And they aren't in any hurry to support the latest OS versions. Maybe they'll support Ubuntu 24.04 some time in 2025? Of course you'll pay them the same whether they hit that target or not.
> if someone plugs their phone into their laptop to charge it, they'll start getting network timeouts when they try to use the ERP system. After waiting 30 minutes for it to come back online, then calling the helpdesk, they'll be told that the charging phone counts as an unencrypted disk and they need to unplug it.
Good thing they killed the nic or blocked the LAN traffic on the laptop while it's connected to that high speed cellular network modem! And as we all know, once a potentially malicious payload delivering unencrypted drive is unplugged, the threat is gone and you can have your network back. If that weren't true, you'd see folks sprinkling usb thumb drives in the parking lots of their target's offices. What's next, usb cables with microcontrollers, keyloggers, and wifi?
/s
If helpdesk is making calls like that, add all the zero trust you want, you're still screwed
More of a "pay someone else to do it" situation then. And the question is how much do they value security, and can they afford it without killing their business.
I have found that thinking a security problem is "solved" is a big warning that you're at risk. There's no such thing as perfect security in anything. If you adopt the mindset that you're "safe" in some sort of absolute way, you stop looking very hard for security breaches and won't catch the one that will, sooner or later, happen.
Indeed, zero trust is a powerful mindset but only an incompetent organization willingly opens all internal resources to the Internet for no good reason.
Another important philosophy is defense in depth: Just because you use zero trust principles internally doesn't mean you shouldn't still put a big freaking moat around your environment.
That is a bit hypocritical of Google though since they do have scanned mails of their users for example. In that way they certainly did implement zero trust, but maybe here it has another meaning.
And I don't think such an architecture fits every company. Most (non-software) tech companies suffer under simple social engineering, scam mails and giving third parties their credentials. A threat is also economic espionage in all its forms.
Google certainly has other security concerns as well. Internal whistleblowers and maybe activist circles that run counter to the vision of management. For these problems their architecture might make sense, but it doesn't mean every company has the same threat vectors.
Of course security problems can be solved, but the infrastructure needed isn't trivial and many software stacks for engineering just don't allow for third party auth anyway.
Many developers (software or not) also shudder about their "managed endpoints". Works for Google obviously, but they are a special case here.
Much more effective here is sensible network segmentation. You don't need fancy auth services for that, just classic IT with a little sense for real threats. "Everything facing the internet" certainly is a very specific strategy that cannot be generalized.
For most companies Zero Trust is strong device management, cert in TPM, buy okta service and then buying an appliance that you put between users and services and then cut off direct user access. Can still use vpn or expose the appliance to the internet.
I'm half with you, but riddle me this: in a ZT environment, every request needs to be accompanied by some verifiable assertion of identity and authorization. In this case, and others we've seen recently, the identity provider themselves has been compromised. For example because an attacker has obtained signing keys that allow them to effectively masquerade approval from.the identity provider. So even in a ZT environment, isnt it game over at that point?
It seems that we have a situation where all out trust is in the identity provider now, and we suffer when that provider is compromised.
You have completely managed endpoints, strong hardening of the endpoint and complete inventorization of all the resources in the organization. You have certificates installed onto each device. You have an ACL engine that determines whether a user should get access to a particular resource. You can use deterministic lists and also incorporate heuristics to detect anomalies (working hours, etc). All Google internal apps are internet-facing. You can open them, get redirected to the SSO portal. Come and do try to get in. You will not.
Many of these security problems are solved. You just need to implement the solutions.