Hacker News Reader

Comment by gz5 | Hacker News Reader

I have previously read most of these docs, and NIST has done some excellent work in what can be tough territory, even if 'zero trust' is now* a misleading term (the question is more like who/what do you trust under which circumstances and how do you implement that in a simple, scalable, extensible way...so I prefer something closer to 'authorize everything').

* The term was more applicable when originally coined - the context back then was don't trust an endpoint just because it is on your network.

View on HN

I'm not sure I see the difference between zero trust networking and authorize everything. Seems like they are saying pretty much the same thing, differing in positive vs negative assertions.

If you are to provide access to an app or network, you need to trust (something) under some circumstances.

> provide access to a network

That's your first mistake. You should be providing access to software, not networks. The idea of a "trusted" network that applications or users can communicate on is the fundamental idea that zero-trust architecture aims to get rid of.

absolutely. can even completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions.

* requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side

> You should be providing access to software, not networks.

You should be providing access to an identity, not software. If someone is running the same software but with the wrong identity, it should be denied access.

One non-malicious example that comes to mind is the right application from the wrong environment, e.g. dev frontend calling prod backend, or even worse prod backend calling test DB, etc.

I think they meant that software is 'what the identity should gain access to', and you 'should not grant that identity access to networks'; it is worded a bit confusingly.

From a known identity to an API

Close! Identity and environment. Even if you have "launch the missiles" authority, you might not have it on the weekends, at night, or from Cuba.

I feel like you need to go back and read the comment I'm responding to again, because you have deeply misinterpreted what I'm saying. I'm talking about the things users access, not who they are when they access them.

Indeed. Resulting in similar complexity between cloud and internal apps.

You can also call it 'perimeter-less security'.

As for zero trust - that seems to be a bit of a misnomer to me - doesn't it tend to aggregate trust into one big bucket - certs?

Won't anybody who can do man-in-the-middle or has access to root certs have total free reign?

Security services wet dream.

Zero trust means "don't authn/authz based on IP address, authn/authz at the application level where you should have been doing that in the first place."

How long has authn/authz been in your lexicon? Took me a second but I rather like the abbreviation even if the spelling omitted is different.

The idea that many vendors have is an agent on the client and server that scrutinizes every connection, at both ends, based on policy and/or entitlement to specific resources. For an enterprise this means not having to worry as much about locking down your internal network as it is no longer the only boundary. In reality this is a very tall order. All your internal systems, legacy systems, cloud vendors, etc. have to be on board. The reality is a hybrid solution with all the attendant complexity.

Good point. I would also like as an argument that the hybrid approach should be seen as having multiple lines of defense. A corporate network should have an outer boundary that is hard-ish to penetrate. Personal devices should either require approval or use some kind of vpn to access any part of this network. Inside, the network should be divided into subnets with their own border protections, in case an attacker penetrates the outer shell/userland. For all subnets, zero-trust should be implemented when possible, even for communication within a subnet. Finally, monitoring should be in place to listen for unusual activity, whether that is unusual or suspicious traffic, unexpected changes in configurations of nodes on the network, etc.

> the context back then was don't trust an endpoint just because it is on your network.

The majority of the world is still in this context...

Although "authorize everything" can also be confusing - so, what, you just let anything query your system?

Agree, not a perfect term. You certainly make a good point and in fact the strongest zero trust approaches don't even let you on the network (even at layer 3) until after you are authorized.

Err, no - the strongest zero trust approaches never let you “on the network” - authorized or not.

They are designed to connect you to an application, you should never see the network.

yeah, agree, 'on the network' is a bad phrase. long form:

completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions (strong auth - not IP-address based auth).

* requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side

That seems appropriate in many contexts. The originator of the "beyond corp" meme has all their critical systems just hanging out there on port 443. You could just download all their source code, if you were authorized. The point is if you want the extra layer of security, the belt of physical or VPN access to go along with the "authorize everything" suspenders, you can just put it on top. But you don't assume that the network security actually works, you don't allow its existence to degrade the rest of your security story.

> But you don't assume that the network security actually works, you don't allow its existence to degrade the rest of your security story.

If you implement security at the network layer, what’s to stop app developers from kicking the can down the road rather than implement app security?

Usually there is a "after authentication" implied

"Authenticate everyone, authorize everything"

This is a valid solution - open everything up to the public internet, but gate everything on the domain behind authn (with the application performing authz only if authn is successful). Proxies can also handle the authn part and ensure the app isn't touched without authn, see: https://teams.cloudflare.com/

I met customers who put anything under that umbrella. And they want to use PaaS/SaaS products - like, you need to encrypt table names, or some unrelated data… Some companies just use that to protect their …

> the context back then was don't trust an endpoint just because it is on your network.

I remember working for a major tech company that had contracts for big critical industries (think oil, aviation, trains, etc.). All the R&D department pretty much rested on one Brent, because they made no efforts to upgrade their systems for 15 years+.

tl;dr: I asked him: hey maybe we shouldn't trust devs computers just because they are "on the network", he just shrugged and said: "if we're compromised we'll have other things to worry about anyway".

While zero trust as a goal is impossible, it still is the guiding principle that everyone should follow; especially if you have a Brent.

What was its original coining? PC Booting?

Reply on news.ycombinator.com