> Traditional network access controls work by assuming that something is trustworthy based on some other factor - for example, if a computer is on your office network, it's trustworthy because only trustworthy people should be able to gain physical access to plug something in. If you restrict access to your services to requests coming from trusted networks, then you can assert that it's coming from a trusted device.
Every time I hear about ZTA they start with this straw man of restricted internal networks. There where never a time when admins relied only on restricted physical network access or VPN. There was always a strategy of defense in depth with multiple layers, network access being just one of them. You need to differentiate between users and their rights in an internal network anyway so of course you had some form of authentication and authorization.
> The proxy is made available on the public internet, DNS for the services points to the proxy, and every time your users try to access the service they hit the proxy instead and (if everything's ok) gain access to it no matter which network they're on
Why would you eliminate a split VPN though? Software has bugs, why would you expose the proxy or some app for automated scanners and exploiters on the internet? You can have both! You can have a locked building door and a locked apartment door. Of course relying on the building door is not enough but why would you eliminate it? How could that improve security?
It isn't exactly a straw man because it was often the default implementation. Yes, it was always a good practice to have the computers of the marketing team not have network access ( nor their user accounts LDAP/whatever access) to e.g. production servers, but not everybody deployed it like that, because it's hard, especially in big or acquired companies. There are environments where DHCP is disabled for "security" not to allow an attacker to get an IP in the network. For them obviously an IP is an "in", and they don't trust their defence in depth ( which of course, isn't a given).
In any case, Zero Trust fuses authn and authz and makes it so you no longer need firewall rules for protection. All of that now happens on the same layer, which makes it more accessible, accurate and easy to manage.
As for VPNs, the point is that they're of limited security utility, so they're just an extra hurdle for your own users. Yes, they "hide" your services from the generic internet, but those services should be hardened and protected in case of a breach of your VPN anyways, so the difference is minimal vs the effort and money spent on a VPN.
I feel like i should add a disclaimer that i work at a company who sell products around zero trust, among other things, so opinions my own, held before joining, etc.
One of the many problems with that approach is that any service on your machine with network access can now impersonate you, the classic example being malicious JavaScript.
> Every time I hear about ZTA they start with this straw man of restricted internal networks. There where never a time when admins relied only on restricted physical network access or VPN.
I assure you I've connected to more than one real-world network where the admins absolutely did rely on that.
> Why would you eliminate a split VPN though? Software has bugs, why would you expose the proxy or some app for automated scanners and exploiters on the internet? You can have both! You can have a locked building door and a locked apartment door. Of course relying on the building door is not enough but why would you eliminate it? How could that improve security?
If you put a weakly secured porch on the front of your building, it's easier for someone to take their time breaking into the main lock, and people are more likely to forget to lock the main door.
Most vulnerabilities come from either writing code in C or mixing up authorized and unauthorized users. So it's really important to have a simple and understandable authorization model. Weak security layers do more harm than good, because they make mistakes more likely.
> Every time I hear about ZTA they start with this straw man of restricted internal networks. There where never a time when admins relied only on restricted physical network access or VPN.
This absolutely used to be the primary method of security, and still is in many places, unfortunately. Even at the enterprise level, most companies only started making serious changes maybe 10 years ago, and are still far from completing the journey, and getting a device connected to a wired port will still get you too much access in most enterprises.
I'm a pen tester for a mid-ish sized company. I recently got approval to remove "port security" (802.11x) on a single port within the building. It is amazing the amount of access I now have (using a non-company managed laptop, plugged into this port).
Once a bad guy has equivalent access, they are very deep into our network (and have bypassed multiple layers of controls).
I don't think my company is unique in any way. I would expect this level of access at most companies to be game-over / large problem.
You can also do traditional VPNs ”the right way” - not granting access to resources just because user has a VPN connection, but configuring per-user/group access policies.
I suppose you could start at a really coarse level; it's pretty easy to have the VPN read the user's group from some central source and use that to decide what subnet(s) they get, and then you put ex. internal-use servers (say, file shares) on one subnet, customer application servers on another, and LOM consoles on a third.
Managing that at scale is so unbelievably hard. Network layer stuff like VPN tends to be really isolated from application access restrictions both in terms of data and operational processes, so you end up having to duplicate the access controls and it's never in sync. Ask me how I know; I've been trying for years.
Something like Google's BeyondCorp where the access restrictions are done in a proxy or other application layer is much more likely to be tied to the same access controls used within applications. That way ZTA acts as an additional security boundary but not an entirely separate authentication and authorization system that VPNs tend to be.
The point of ZTA, the idea of strong per-application RBAC, is that if you do it right, VPNs are useless.
To need a VPN for "defense-in-depth" is to admit you don't have or want ZTA within parts of your perimeter. And that isn't a bad thing! ZTA is really hard to do unless you're building your business and all its core apps from scratch.
Many, many resources on a traditional internal network do NOT have unified AAA. It's about more than slapping a login page on something, it's about making sure that every gateway to an application or data has a nigh unbreakable access control (think AWS IAM when properly configured).
Almost no large scale business network in the world can say this. And with IOT, it's even harder.
“Zero trust” is referring to the fact that you are not granting trust based on network location; at the IP layer, all connections are untrusted. Unlike a VPN/on-prem network, where you don’t trust IPs outside your network and trust everything inside the perimeter. This is a pretty big conceptual shift in corporate network design.
Of course you need to establish trust somehow. It’s just done above the IP layer now.
There is nothing in the zero trust network model that requires you to use a third party; you can do the same sort of thing with wireguard right? (A la Tailscale). Probably true that it’s harder to assemble all the pieces than running the minimal OpenVPN setup, granted.
27 comments
[ 5.3 ms ] story [ 70.4 ms ] threadhttps://news.ycombinator.com/item?id=30875908#30878711
Every time I hear about ZTA they start with this straw man of restricted internal networks. There where never a time when admins relied only on restricted physical network access or VPN. There was always a strategy of defense in depth with multiple layers, network access being just one of them. You need to differentiate between users and their rights in an internal network anyway so of course you had some form of authentication and authorization.
> The proxy is made available on the public internet, DNS for the services points to the proxy, and every time your users try to access the service they hit the proxy instead and (if everything's ok) gain access to it no matter which network they're on
Why would you eliminate a split VPN though? Software has bugs, why would you expose the proxy or some app for automated scanners and exploiters on the internet? You can have both! You can have a locked building door and a locked apartment door. Of course relying on the building door is not enough but why would you eliminate it? How could that improve security?
In any case, Zero Trust fuses authn and authz and makes it so you no longer need firewall rules for protection. All of that now happens on the same layer, which makes it more accessible, accurate and easy to manage.
As for VPNs, the point is that they're of limited security utility, so they're just an extra hurdle for your own users. Yes, they "hide" your services from the generic internet, but those services should be hardened and protected in case of a breach of your VPN anyways, so the difference is minimal vs the effort and money spent on a VPN.
I feel like i should add a disclaimer that i work at a company who sell products around zero trust, among other things, so opinions my own, held before joining, etc.
I assure you I've connected to more than one real-world network where the admins absolutely did rely on that.
> Why would you eliminate a split VPN though? Software has bugs, why would you expose the proxy or some app for automated scanners and exploiters on the internet? You can have both! You can have a locked building door and a locked apartment door. Of course relying on the building door is not enough but why would you eliminate it? How could that improve security?
If you put a weakly secured porch on the front of your building, it's easier for someone to take their time breaking into the main lock, and people are more likely to forget to lock the main door.
Most vulnerabilities come from either writing code in C or mixing up authorized and unauthorized users. So it's really important to have a simple and understandable authorization model. Weak security layers do more harm than good, because they make mistakes more likely.
This absolutely used to be the primary method of security, and still is in many places, unfortunately. Even at the enterprise level, most companies only started making serious changes maybe 10 years ago, and are still far from completing the journey, and getting a device connected to a wired port will still get you too much access in most enterprises.
Once a bad guy has equivalent access, they are very deep into our network (and have bypassed multiple layers of controls).
I don't think my company is unique in any way. I would expect this level of access at most companies to be game-over / large problem.
I think when most think VPNs though they're talking enterprise ICT VPNs that historically don't play in that space :(
Something like Google's BeyondCorp where the access restrictions are done in a proxy or other application layer is much more likely to be tied to the same access controls used within applications. That way ZTA acts as an additional security boundary but not an entirely separate authentication and authorization system that VPNs tend to be.
To need a VPN for "defense-in-depth" is to admit you don't have or want ZTA within parts of your perimeter. And that isn't a bad thing! ZTA is really hard to do unless you're building your business and all its core apps from scratch.
[1] https://www.boundaryproject.io/
Is there a rule somewhere that says that tech buzzwords in the networking sector have to be maximally wrong?
1. Server is authenticated. Client is authenticated.
2. Client has to pass some kind of attestation / meet policy requirements of the service.
3. Actions are auditable.
What would you call it? Zero Trust seems fine to me.
Almost no large scale business network in the world can say this. And with IOT, it's even harder.
But sure, AAA is an extremely broad term that absolutely could encompass ZT. Just like SOA encompasses Microservices.
Of course you need to establish trust somehow. It’s just done above the IP layer now.
There is nothing in the zero trust network model that requires you to use a third party; you can do the same sort of thing with wireguard right? (A la Tailscale). Probably true that it’s harder to assemble all the pieces than running the minimal OpenVPN setup, granted.
Use the right term, not twisting a wrong one.
It’s a little bit like other terms, democracy, peace process. Etc. Democracy is defined to be what I do. So you can never be undemocratic.