5 ms·

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

by gz5 4y ago

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.

alexott 4y ago
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 …
eikenberry 4y ago
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.
- gz5 4y ago
  If you are to provide access to an app or network, you need to trust (something) under some circumstances.
  - nightpool 4y ago
    > 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.
    - gz5 4y ago
      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
    - cassianoleal 4y ago
      > 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.
      - judge2020 4y ago
        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.
        lokar 4y ago
        From a known identity to an API
      - politician 4y ago
        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.
      - nightpool 4y ago
        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.
    - DrScientist 4y ago
      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.
- tenebrisalietum 4y ago
  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."
  - plussed_reader 4y ago
    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.
- mberning 4y ago
  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.
  - trashtester 4y ago
    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.
philjohn 4y ago
Although "authorize everything" can also be confusing - so, what, you just let anything query your system?
- gz5 4y ago
  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.
  - happyopossum 4y ago
    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.
    - gz5 4y ago
      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
- jeffbee 4y ago
  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.
  - 4y ago
doliveira 4y ago
> 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...
pyuser583 4y ago
What was its original coining? PC Booting?
TeeMassive 4y ago
> 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.

by gz5 4y ago

alexott 4y ago

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 …

eikenberry 4y ago

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.

gz5 4y ago
If you are to provide access to an app or network, you need to trust (something) under some circumstances.
- nightpool 4y ago
  > 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.
  - gz5 4y ago
    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
  - cassianoleal 4y ago
    > 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.
    - judge2020 4y ago
      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.
      - lokar 4y ago
        From a known identity to an API
    - politician 4y ago
      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.
    - nightpool 4y ago
      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.
  - DrScientist 4y ago
    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.
tenebrisalietum 4y ago
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."
- plussed_reader 4y ago
  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.
mberning 4y ago
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.
- trashtester 4y ago
  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.

philjohn 4y ago

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

gz5 4y ago
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.
- happyopossum 4y ago
  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.
  - gz5 4y ago
    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
jeffbee 4y ago
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.
- 4y ago

doliveira 4y ago

> 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...

pyuser583 4y ago

What was its original coining? PC Booting?

TeeMassive 4y ago

> 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.