5 ms·

I suppose the thesis that it’s a bad name is borne out by the fact that many technical people misunderstand it; it’s a contraction of “zero trust networking” an

I suppose the thesis that it’s a bad name is borne out by the fact that many technical people misunderstand it; it’s a contraction of “zero trust networking” and is a fine description of the technical approach: don’t trust anyone by virtue of their network location. (Trust is negotiated at the application layer.) #NoVPN or Zero Perimeter could be better slogans. On the other hand, the only people I have seen confused are technical people that (incorrectly) think they have identified an inconsistency; non-technical folks seem fine to just map name->feature-set.

otterley 4y ago
+1 for NoVPN. It's short, sweet, and quickly conveys the benefit. It may also remind people of the frustrations they often face using VPN software, which is often flaky and has a poor UI, so eliminating it could be met with feelings of relief. Nevertheless, it's always a little unsettling whenever some Internet rando confidently posits that a phrase conveys a certain meaning or emotional reaction to people without any evidence whatsoever. I mean, come on, do a little market research. Do your homework. (The same goes for me!)
- vasco 4y ago
  Makes no sense to do market research for this. You throw a new naming out there and see if it sticks. If it sticks, done, if not, no market research needed.
  - l33t2328 4y ago
    I don’t really have an opinion on this but isn’t “seeing if it sticks” just other words for market research?
    - phonepostingsux 4y ago
      The "fuck it, do it in prod" of market research.
  - otterley 4y ago
    The blog author wasn't recommending a new name. He was merely complaining about the name without any data whatsoever to back up his claim. Mere destructive criticism is cheap and easy, and isn't worth posting here IMO. Creativity and success, OTOH, are frequently difficult and worthy of praise and sharing.
- goalieca 4y ago
  I disagree with novpn because having a vpn or private network is a useful layer in the overall defence.
  - xbar 4y ago
    I don't agree, but I would like to try to give you the benefit of some doubt--what is it about vpn that you think adds to the overall defennce when zero trust networking is fully implemented?
    - otterley 4y ago
      Zero-trust networking -- with or without a VPN -- requires that every internal service be properly configured. If a sensitive service escapes the lab and becomes accessible without bring properly set up, then at least having it behind a VPN gives you a little air cover. If there's no VPN whatsoever, then this service can potentially be accessed by the public. IOW, "when zero trust networking is fully implemented" is a precondition that isn't always realistically achievable, especially in large distributed organizations where you don't always have complete control over what your colleagues build and deploy.
herghost 4y ago
Agreed - I've seen the same result in my current company. The only real objection raised is from a technical pedant who argues that we're trusting identity and so we shouldn't call in _Zero_ Trust. He's almost deliberately missing the point though. Our users, on the other hand, are not making any real noise about it because from their point of view it's the natural extension of SSO (from the point of view of that being the only bit that they will interact with in any meaningful way) and that was something that reduced friction for them too. We've not suffered from the name really, to be honest.
feanaro 4y ago
It's a bad term in the sense that it's not self-explanatory. Hearing just the term itself is likely to give you the wrong idea about what it means. Learning a name -> feature mapping isn't a problem in itself, but the fact that you have to do it before you get an approximately correct idea regarding what it's about is an unnecessary inefficiency.
powerhour 4y ago
We could take cues from the food world: Better Than VPN, I can't believe it's not VPN! I'm not really convinced the name is a real problem. We use a lot of terms that aren't obvious and it works just fine. For example, http. First you have to learn that means Hypertext Transfer Protocol, then you have to learn what Hypertext means, and then you have to learn that it's used for a lot more than Hypertext these days.
- cmeacham98 4y ago
  The problem isn't that it's not obvious, but that it's actively counterintuitive. If a car company was called 'GJKN', and that stood for some obscure acronym, you'd just memorize that. But you'd probably be a lot more confused by the car company 'NoWheels' when their car still has wheels, just in different places.
staticassertion 4y ago
You can have ZTN with a VPN and you can have a perimeter with ZTN. What you can't have is trust based on network position. So I think Zero Trust is fine. It's a marketing term ultimately and any practitioner should be able to understand what it means. If they don't it's kinda on them.
- theptip 4y ago
  I’m not familiar with anyone in the ZTN space advocating for a need for VPNs. Do you have any examples you can share? Google explicitly positions BeyondCorp as a replacement for VPN: > BeyondCorp is a Zero Trust security framework modeled by Google that shifts access controls from the perimeter to individual devices and users. The end result allows employees to work securely from any location without the need for a traditional VPN. https://beyondcorp.com/ https://beyondcorp.com/
  - staticassertion 4y ago
    Advocating for a VPN or not isn't relevant. ZeroTrust isn't "no vpns". You can do ZeroTrust and have a VPN. ZTN is more about what you do than what you don't do, despite the name. 1. Clients authenticate servers 2. Servers authenticate clients 3. Communications are encrypted and auditable 4. Fine grained authorization using available context like device health You could have employees hold a client cert, connect to a VPN, have the VPN attest the employee's state, and then provide them access to a subnet. From that subnet they can continue talking to other services that also perform authn/authz. The VPN doesn't make it "less" zero trust, it's just that the traditional VPN model is one where it's the single point of auth.
atoav 4y ago
Without going to much into it I thought Zero Trust is some new funky cryptographic way of eliminating the need for trust in some interaction between parties. Turns out it is just a different phrase for the existing concept of defense in depth.
- lucideer 4y ago
  Zero trust isn't the same as defence in depth. Certainly one could define defence in depth as a component of zero trust I guess (very vaguely) but they represent different perspectives. Defence in depth is a technologically focused approach: implementing redundant checks at multiple architectural layers of a stack. Zero trust is about the high-level approach to perimeters and ACLs, including not only tech & stack architecting, but organisational messaging / policy / culture.
  - dhx 4y ago
    If using Google's BeyondCorp architecture as the definition of "Zero Trust"[1], it does away with traditional "defence in depth" redundancy such as implementing, in series, IPSec/Wireguard/TLS tunneling AND mutually authenticated application layer TLS to mitigate a single technology failing. Instead, network boundaries are removed and anyone can access internal system login pages across the Internet from a web browser[2]. In place of network boundaries, device attestation[3] is relied upon to ensure control over the state of devices that are being used to access the internal system. I would argue that the "Zero Trust" definition in the BeyondCorp architecture is somewhat an opposite of "defence in depth" because it appears to advocate so many single points of failure. You have to trust the TPM manufacturer's claims. You have to be certain the software running the public facing login portal is free of remotely exploitable vulnerabilities. You have to trust your whole business on the source code of a single vendor providing the software for centralised user authentication. You have to trust the few employees who manage these single points of failure with an entire business rather than a small part of the business. Defence in depth is either achieved by implementing systems in series, or in parallel. Systems in series have decreased availability and thus have a downside of an exploitation in any one system in series being a more likely occurrence (larger attack surface), and upon an occurrence, the availability of all systems in series is impacted. For example, let there be two proxies in series from two vendors, each proxy performing deep packet inspection and analysis of files being transferred. To get a file transferred through both proxies, an attacker has to convince both proxies (independently implemented) that the file is not malicious, and thus it is harder to fool two systems rather than one. However an attacker can find a content parsing vulnerability in either proxy (double the attack surface) and use the access gained to more readily deny service, leak information or inject or modify information. Systems in parallel introduce a larger attack surface and thus exploitation occurrences are more likely, but each occurrence has significantly decreased consequence. An example of such an architecture is different divisions of a business using SFTP, TLS or SMB protocols to transfer files, and different divisions using different implementations of those protocols in different software. An encryption vulnerability in one implementation of one protocol may only expose two divisions of the business, but the other divisions would not be directly impacted. It is likely that incidents occur more frequently as there is a much larger attack surface, but each incident has a less severe outcome. [1] https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43231.pdf https://storage.googleapis.com/pub-tools-public-publication-... [2] Example: https://login.corp.google.com/ https://login.corp.google.com/ [3] Example of how device attestation could work: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/
omginternets 4y ago
>don’t trust anyone by virtue of their network location. Sounds like an impoverished way of saying "ambient authority is bad" ;) (I do concede the article's point that marketing actually matters.)

otterley 4y ago

+1 for NoVPN. It's short, sweet, and quickly conveys the benefit. It may also remind people of the frustrations they often face using VPN software, which is often flaky and has a poor UI, so eliminating it could be met with feelings of relief. Nevertheless, it's always a little unsettling whenever some Internet rando confidently posits that a phrase conveys a certain meaning or emotional reaction to people without any evidence whatsoever. I mean, come on, do a little market research. Do your homework. (The same goes for me!)

vasco 4y ago
Makes no sense to do market research for this. You throw a new naming out there and see if it sticks. If it sticks, done, if not, no market research needed.
- l33t2328 4y ago
  I don’t really have an opinion on this but isn’t “seeing if it sticks” just other words for market research?
  - phonepostingsux 4y ago
    The "fuck it, do it in prod" of market research.
- otterley 4y ago
  The blog author wasn't recommending a new name. He was merely complaining about the name without any data whatsoever to back up his claim. Mere destructive criticism is cheap and easy, and isn't worth posting here IMO. Creativity and success, OTOH, are frequently difficult and worthy of praise and sharing.
goalieca 4y ago
I disagree with novpn because having a vpn or private network is a useful layer in the overall defence.
- xbar 4y ago
  I don't agree, but I would like to try to give you the benefit of some doubt--what is it about vpn that you think adds to the overall defennce when zero trust networking is fully implemented?
  - otterley 4y ago
    Zero-trust networking -- with or without a VPN -- requires that every internal service be properly configured. If a sensitive service escapes the lab and becomes accessible without bring properly set up, then at least having it behind a VPN gives you a little air cover. If there's no VPN whatsoever, then this service can potentially be accessed by the public. IOW, "when zero trust networking is fully implemented" is a precondition that isn't always realistically achievable, especially in large distributed organizations where you don't always have complete control over what your colleagues build and deploy.

herghost 4y ago

Agreed - I've seen the same result in my current company. The only real objection raised is from a technical pedant who argues that we're trusting identity and so we shouldn't call in _Zero_ Trust. He's almost deliberately missing the point though. Our users, on the other hand, are not making any real noise about it because from their point of view it's the natural extension of SSO (from the point of view of that being the only bit that they will interact with in any meaningful way) and that was something that reduced friction for them too. We've not suffered from the name really, to be honest.

feanaro 4y ago

It's a bad term in the sense that it's not self-explanatory. Hearing just the term itself is likely to give you the wrong idea about what it means. Learning a name -> feature mapping isn't a problem in itself, but the fact that you have to do it before you get an approximately correct idea regarding what it's about is an unnecessary inefficiency.

powerhour 4y ago

We could take cues from the food world: Better Than VPN, I can't believe it's not VPN! I'm not really convinced the name is a real problem. We use a lot of terms that aren't obvious and it works just fine. For example, http. First you have to learn that means Hypertext Transfer Protocol, then you have to learn what Hypertext means, and then you have to learn that it's used for a lot more than Hypertext these days.

cmeacham98 4y ago
The problem isn't that it's not obvious, but that it's actively counterintuitive. If a car company was called 'GJKN', and that stood for some obscure acronym, you'd just memorize that. But you'd probably be a lot more confused by the car company 'NoWheels' when their car still has wheels, just in different places.

staticassertion 4y ago

You can have ZTN with a VPN and you can have a perimeter with ZTN. What you can't have is trust based on network position. So I think Zero Trust is fine. It's a marketing term ultimately and any practitioner should be able to understand what it means. If they don't it's kinda on them.

theptip 4y ago
I’m not familiar with anyone in the ZTN space advocating for a need for VPNs. Do you have any examples you can share? Google explicitly positions BeyondCorp as a replacement for VPN: > BeyondCorp is a Zero Trust security framework modeled by Google that shifts access controls from the perimeter to individual devices and users. The end result allows employees to work securely from any location without the need for a traditional VPN. https://beyondcorp.com/ https://beyondcorp.com/
- staticassertion 4y ago
  Advocating for a VPN or not isn't relevant. ZeroTrust isn't "no vpns". You can do ZeroTrust and have a VPN. ZTN is more about what you do than what you don't do, despite the name. 1. Clients authenticate servers 2. Servers authenticate clients 3. Communications are encrypted and auditable 4. Fine grained authorization using available context like device health You could have employees hold a client cert, connect to a VPN, have the VPN attest the employee's state, and then provide them access to a subnet. From that subnet they can continue talking to other services that also perform authn/authz. The VPN doesn't make it "less" zero trust, it's just that the traditional VPN model is one where it's the single point of auth.

atoav 4y ago

Without going to much into it I thought Zero Trust is some new funky cryptographic way of eliminating the need for trust in some interaction between parties. Turns out it is just a different phrase for the existing concept of defense in depth.

lucideer 4y ago
Zero trust isn't the same as defence in depth. Certainly one could define defence in depth as a component of zero trust I guess (very vaguely) but they represent different perspectives. Defence in depth is a technologically focused approach: implementing redundant checks at multiple architectural layers of a stack. Zero trust is about the high-level approach to perimeters and ACLs, including not only tech & stack architecting, but organisational messaging / policy / culture.
- dhx 4y ago
  If using Google's BeyondCorp architecture as the definition of "Zero Trust"[1], it does away with traditional "defence in depth" redundancy such as implementing, in series, IPSec/Wireguard/TLS tunneling AND mutually authenticated application layer TLS to mitigate a single technology failing. Instead, network boundaries are removed and anyone can access internal system login pages across the Internet from a web browser[2]. In place of network boundaries, device attestation[3] is relied upon to ensure control over the state of devices that are being used to access the internal system. I would argue that the "Zero Trust" definition in the BeyondCorp architecture is somewhat an opposite of "defence in depth" because it appears to advocate so many single points of failure. You have to trust the TPM manufacturer's claims. You have to be certain the software running the public facing login portal is free of remotely exploitable vulnerabilities. You have to trust your whole business on the source code of a single vendor providing the software for centralised user authentication. You have to trust the few employees who manage these single points of failure with an entire business rather than a small part of the business. Defence in depth is either achieved by implementing systems in series, or in parallel. Systems in series have decreased availability and thus have a downside of an exploitation in any one system in series being a more likely occurrence (larger attack surface), and upon an occurrence, the availability of all systems in series is impacted. For example, let there be two proxies in series from two vendors, each proxy performing deep packet inspection and analysis of files being transferred. To get a file transferred through both proxies, an attacker has to convince both proxies (independently implemented) that the file is not malicious, and thus it is harder to fool two systems rather than one. However an attacker can find a content parsing vulnerability in either proxy (double the attack surface) and use the access gained to more readily deny service, leak information or inject or modify information. Systems in parallel introduce a larger attack surface and thus exploitation occurrences are more likely, but each occurrence has significantly decreased consequence. An example of such an architecture is different divisions of a business using SFTP, TLS or SMB protocols to transfer files, and different divisions using different implementations of those protocols in different software. An encryption vulnerability in one implementation of one protocol may only expose two divisions of the business, but the other divisions would not be directly impacted. It is likely that incidents occur more frequently as there is a much larger attack surface, but each incident has a less severe outcome. [1] https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43231.pdf https://storage.googleapis.com/pub-tools-public-publication-... [2] Example: https://login.corp.google.com/ https://login.corp.google.com/ [3] Example of how device attestation could work: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/

omginternets 4y ago

>don’t trust anyone by virtue of their network location. Sounds like an impoverished way of saying "ambient authority is bad" ;) (I do concede the article's point that marketing actually matters.)