1. 12
  1.  

  2. 6

    There’s a bunch of meanings people place on the “Zero Trust” part, to the point where you usually have to ask what kind of “Zero Trust” do they mean, similar to “Agile”.

    If my memory serves correctly, originally “Zero Trust” was coined to name the approach Google took for securing their internal systems. And in that meaning, it’s “Zero Trust in the network”, as they abandoned using the source of the network traffic in authenticating the users - meaning that access to their company VPN didn’t give access to anything else. In this sense, there’s no “Zero Trust” in users or in providers - they are still trusted, but not because of their network location, but because of their credentials.

    1. 7

      I’ve seen Zero Trust employed to describe systems with exactly the opposite design: they authenticate endpoints and then place absolute trust in them. I wish people pushing this buzzword nonsense would just think about two core principles:

      • The principle of least privilege. If I don’t need a privilege to accomplish a take, I shouldn’t be put in a situation where I need to elevate to a state where have it. If a system doesn’t require a privilege then it should never be granted to it. Systems should check and fail if operating with too many permissions.
      • The principle of intentionality. If I am exercising a privilege, then I should always do so explicitly by presenting something that indicates that I know that I am exercising that privilege.

      Designing systems with these two ideas in your mind will produce far more secure results than the current Zero Trust nonsense.

      1. 2

        FWIW endpoint authentication can still mean that zero trust is placed in the network. Some companies have systems which you can only access if you’re connecting from some specific IP range, but that don’t have any further checks about who is connecting. Placing trust on the endpoints that have been attested by a TPM means that you now don’t need to work as hard on securing your network, but you have to make sure the endpoints don’t get compromised.

        As all things security, there’s usually a tradeoff, and everyone has different priorities.

        1. 3

          Placing trust on the endpoints that have been attested by a TPM means that you now don’t need to work as hard on securing your network, but you have to make sure the endpoints don’t get compromised.

          This is the bit I object to. Placing trust in the endpoints that have been attested by a TPM means that you have, at a minimum, ten million lines of C code in your TCB, more likely an order of magnitude more. You’re reliant on on-device intrusion-detection, which is always reactive. If you authenticate actions, not endpoints, and you aggressively restrict the privileges that an endpoint holds (especially temporally: if I only hold elevated privileges for a few seconds then an attacker needs to be running active malware on my device to exploit that) then you’re in a much better situation. If you reduce the privileges required for operations then users don’t sit in a high-privilege state waiting to have their credentials stolen for a long time.

          The way that Zero Trust seems to be deployed encourages you to install privileged software that significantly increases the attack surface on your client devices, attest that you’re running them, elevate privilege to ‘I can do all the things’ mode on that device, and then sit there. That client device is then an insecure high-value target. You have a lot of Zero Trust compliance and no actual security.

          1. 2

            The way that Zero Trust seems to be deployed encourages you to install privileged software that significantly increases the attack surface on your client devices

            As someone who works on this sort of stuff, I might have a myopic point of view but I don’t quite see what you mean. What’s significantly increasing the attack surface? From my perspective, the idea is that this device does not define what services/resources a given device/user/identity. Instead, it merely presents its current state to some ‘controller’ that uses the state to make the decision as to what service can be accessed. I don’t see how it increases the attack vector at all but I’m happy to learn.

            Some ‘other device’ on the network won’t have that TPM and that associated ‘strong identity’. They can’t spoof their way into fooling the network. I’m not seeing what you are yet.

            1. 2

              What’s significantly increasing the attack surface?

              The software that we are required to run on client devices runs with elevated privileges and deals with untrusted data. Every single one of the required pieces of software that we are required to deploy on client devices has had at least one critical CVE in the last year. When it is working, we see that this device is running Windows, a load of third-party drivers (the vulnerability in my webcam driver that allows local elevation to SYSTEM privilege last year did not prevent this attestation), a load of privileged system services, and so on. Making any security claims about such a client device that are stronger than ‘might not have been compromised yet’ is impossible.

              Once the central system has received this attestation, it decides to trust the device. The device is allowed to connect to servers and do almost anything that I can do with any of our work systems, as long as the attacker is able to compromise something that can talk to the service that asks the TPM to sign things (hint: almost every piece of software running on the device, with a very small number of sandboxed exceptions, has that privilege).

              Once the endpoint is compromised, the entire system is wide open. We get an attestation that the endpoint isn’t doing any of the most dangerous things, but it’s still processing untrusted data from an attacker, in code written in unsafe languages, with the ambient authority of my user.

            2. 2

              I’m pretty sure all such “best practices” are geared to compliance and not security. I can speculate as to the incentive structures at play motivating this theatre.

        2. 4

          what kind of “Zero Trust” do they mean, similar to “Agile”.

          lol so true. When I talk/present about “zero trust” (I work for a company-supported, open source project) I always talk about how it’s a misnomer. Really, when I think of “zero trust”, I like to state that this is “explicit trust”. There needs to be some strong identity that the network can use to prove the person/device is who they claim to be that has already been pre-trusted and somehow the network can rely on the strong identity. that’s why it’s usually some kind of PKI/mTLS.

          Then there’s a controller that explicitly authorizes that authenticated identity to “connect to the network and connect to other strong identities”. That combines the principle of least priv with strong identity making a pretty decent start at ‘zero trust’