3 ms·

The author makes some good points here: devices and CAs are the most challenging part although I think it remains feasible for some types of companies(likely mo

The author makes some good points here: devices and CAs are the most challenging part although I think it remains feasible for some types of companies(likely more so than at Google). I was discussing about ZT with a friend recently and we were agreeing that one of the problems with the USGov memo (and most of ZT advocates) is referring to ZT as an "Architecture". The memo paints a picture of ZT as a destination whereas it really should be understood as a framework, culture and design philosophy. And that makes it, by definition, a journey. Its principles are supposed to guide your architecture design but they are not the architecture i.e there can never really be a point where you can call a friend and be like "Look at this, I've finally 'built' a Zero Trust Architecture". And you can't have a consultant come in and go back a few months later telling you "Alright, here's your Zero Trust Architecture". ZT has to be continuously entangled into your dev flow, ops, policies and day to day technical decision making. I also suspect that another important missing piece (whether you look at it as a journey or a destination) is how to quantitatively MEASURE progress on Zero Trust. Having precise reference metrics would help in actually enforcing the goal of the memo or at least being able to tell that company A has a better measured ZT progress than company B. I guess, like they say, "Zero Trust is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it." Disclaimer: Googler but I don't work on the BeyondCorp team.

jiveturkey 5y ago
I think you're overselling it, but not by much. Indeed, ZTA is not a destination.
0xbadcafebee 5y ago
But they do want to think of it as an architecture. They want some "Architecture Group" to publish a "ZeroTrust Standard" which every team will be required to mindlessly implement so they don't have to actually understand the underlying concepts. It's like those wonderful "security karate" mandatory training courses where they require you watch a video and fill out a multiple choice "test", and after that every application you build will be totally secure by default. I think the whole DevSecWhateverOps thing fails to account for the severe antipathy large organizations have for outside-the-box solutions. A solution that requires people leave their silos, learn new concepts, or adopt new practices is just too much for them.
- lokar 5y ago
  The vast majority of apps at Google that are available "beyond corp" are just normal web apps behind a smart reverse proxy that takes care of everything for them.
  - xyzzy_plugh 5y ago
    I'm not a Googler, but this massively understates the architecture they've built. The beyondcorp "smart reverse proxy" solves authentication, but the true innovation is entirely about contextual authorization. Beyondcorp just binds that context to a human's actions for systems to consume. You can also see this publicly in GCP's Workload Identity and ALTS primitives, which enable very sophisticated policies.
    - lokar 5y ago
      I was there when it was built Almost all the smarts are in the proxy. If you have a typical web based app integration is easy, not some impossible mandate.
      - xyzzy_plugh 5y ago
        Sure, I said nothing to the contrary. It's a minor simplification to call it a reverse proxy. The proxy is built upon a very deep investment in infrastructure, take all of the cert signing stuff, for example. Most BeyondCorp concepts seem simple, and they are, but they depend on a lot of existing machinery, almost all of which is non-existent in pre-existing corp networks. The average tech company is currently struggling to catch up.
        lokar 5y ago
        My point was that it is simple from the POV of the app developer. See the comment I replied to.
      - 0xbadcafebee 5y ago
        Do you notice all the different components on this page? https://beyondcorp.com/ https://beyondcorp.com/ There are a lot more components and concepts than just an OAuth proxy. A web developer may think it's all very simple from their perspective, but it goes much deeper.
theamk 5y ago
I think you are making it sound more complex than it is. ZT is an architecture where people don't need trusted network, but still have the same or better level of security as traditional VPN. To measure ZT progress, count the services and security controls which rely on VPN/LAN. The closer it is to zero, the closer you are to ZT.
- jiveturkey 5y ago
  eh no. !VPN is not the hallmark of ZT. It'd be so easy just to put services on the Internet with user/pass. Does that give you ZT?
  - sascha_sl 5y ago
    It gives you zero network trust, which is unfortunately what a lot of companies still have. How many companies really do device attestation to connect to a VPN? I haven't been in a single one. (well, one tried, but it didn't really keep you from using a third party client) Putting your internal apps behind an OIDC proxy instead of the VPN is a straight upgrade at that point. Especially if your provider already does some checks for you (e.g. Chrome Enterprise, requiring Cloudflare WARP app)
  - theamk 5y ago
    Just a plain user/pass is not going to cut it, I said "same or better level of security" for a reason. For example, all VPNs give you a single lockout/change password point, so this has to be at least common authentication. And VPNs have good logging for connections, so you got to have this too. And if your VPN client had device attestation, your solution should have have this too. And also services on VPN are not nearly vulnerable to auth bypass bugs, so your webserver should have some protection on this too (authenticating proxy?). I think !VPN is exactly hallmark of ZT... as long as security is preserved. If you disagree, what do you think ZT's hallmark is? (There is a philosophical question: if a company had a crappy VPN with no logging, and multiple VPN servers with no central auth.. and went to equally crappy user/pass webapp on internet.. does this count as "ZT transition"?)
  - deleted 5y ago
    [deleted]

jiveturkey 5y ago

I think you're overselling it, but not by much. Indeed, ZTA is not a destination.

0xbadcafebee 5y ago

But they do want to think of it as an architecture. They want some "Architecture Group" to publish a "ZeroTrust Standard" which every team will be required to mindlessly implement so they don't have to actually understand the underlying concepts. It's like those wonderful "security karate" mandatory training courses where they require you watch a video and fill out a multiple choice "test", and after that every application you build will be totally secure by default. I think the whole DevSecWhateverOps thing fails to account for the severe antipathy large organizations have for outside-the-box solutions. A solution that requires people leave their silos, learn new concepts, or adopt new practices is just too much for them.

lokar 5y ago
The vast majority of apps at Google that are available "beyond corp" are just normal web apps behind a smart reverse proxy that takes care of everything for them.
- xyzzy_plugh 5y ago
  I'm not a Googler, but this massively understates the architecture they've built. The beyondcorp "smart reverse proxy" solves authentication, but the true innovation is entirely about contextual authorization. Beyondcorp just binds that context to a human's actions for systems to consume. You can also see this publicly in GCP's Workload Identity and ALTS primitives, which enable very sophisticated policies.
  - lokar 5y ago
    I was there when it was built Almost all the smarts are in the proxy. If you have a typical web based app integration is easy, not some impossible mandate.
    - xyzzy_plugh 5y ago
      Sure, I said nothing to the contrary. It's a minor simplification to call it a reverse proxy. The proxy is built upon a very deep investment in infrastructure, take all of the cert signing stuff, for example. Most BeyondCorp concepts seem simple, and they are, but they depend on a lot of existing machinery, almost all of which is non-existent in pre-existing corp networks. The average tech company is currently struggling to catch up.
      - lokar 5y ago
        My point was that it is simple from the POV of the app developer. See the comment I replied to.
    - 0xbadcafebee 5y ago
      Do you notice all the different components on this page? https://beyondcorp.com/ https://beyondcorp.com/ There are a lot more components and concepts than just an OAuth proxy. A web developer may think it's all very simple from their perspective, but it goes much deeper.

theamk 5y ago

I think you are making it sound more complex than it is. ZT is an architecture where people don't need trusted network, but still have the same or better level of security as traditional VPN. To measure ZT progress, count the services and security controls which rely on VPN/LAN. The closer it is to zero, the closer you are to ZT.

jiveturkey 5y ago
eh no. !VPN is not the hallmark of ZT. It'd be so easy just to put services on the Internet with user/pass. Does that give you ZT?
- sascha_sl 5y ago
  It gives you zero network trust, which is unfortunately what a lot of companies still have. How many companies really do device attestation to connect to a VPN? I haven't been in a single one. (well, one tried, but it didn't really keep you from using a third party client) Putting your internal apps behind an OIDC proxy instead of the VPN is a straight upgrade at that point. Especially if your provider already does some checks for you (e.g. Chrome Enterprise, requiring Cloudflare WARP app)
- theamk 5y ago
  Just a plain user/pass is not going to cut it, I said "same or better level of security" for a reason. For example, all VPNs give you a single lockout/change password point, so this has to be at least common authentication. And VPNs have good logging for connections, so you got to have this too. And if your VPN client had device attestation, your solution should have have this too. And also services on VPN are not nearly vulnerable to auth bypass bugs, so your webserver should have some protection on this too (authenticating proxy?). I think !VPN is exactly hallmark of ZT... as long as security is preserved. If you disagree, what do you think ZT's hallmark is? (There is a philosophical question: if a company had a crappy VPN with no logging, and multiple VPN servers with no central auth.. and went to equally crappy user/pass webapp on internet.. does this count as "ZT transition"?)
- deleted 5y ago
  [deleted]