> Our adversaries are in our networks, exfiltrating our data, and exploiting the Department’s users.
I'm happy to see this admission lead the document; it's bold coming from an org as conservative as the DoD. To see critical mass around the idea that -- like it or not -- adversaries (both malicious insiders and outsiders) are already on trusted networks is really encouraging to see.
First, let's be clear what this document is and isn't.
> Importantly, this document serves only as a strategy, not a solution architecture. Zero Trust Solution Architectures can and should be designed and guided by the details found within this document.
This is a long term strategy doc, not an implementer's guide. Operators looking for zero-trust easy mode won't find it here. It's also very DoD specific.
But there are some good parts. I read the doc so (maybe?) you don't have to.
I made some screenshots of the portions I thought most relevant.
The comments will make more sense if you are viewing those.
> Zero Trust uses continuous multi-factor authentication, micro-segmentation, advanced encryption, endpoint security, analytics, and robust auditing, among other capabilities, to fortify data, applications, assets, and services to deliver cyber resiliency. The Department is evolving to become a more agile, more mobile, cloud-supported workforce, collaborating with the entirety of DoD enterprise, including federal and non-federal organizations and mission partners working on a variety of missions.
If you somehow managed to read the above without going into a post word salad coma, I'm sorry. I highlighted the section just to bring up there's an awful lot of enterprise security buzzword and DoD acronym bingo going on. But there are some good thoughts too.
> Zero Trust is much more than an IT solution. Zero Trust may include certain products but is not a capability or device that may be bought.
It's nice to hear this being reiterated so often. A good start!
> Zero Trust security eliminates the traditional idea of perimeters, trusted networks, ...
Zero trust is -- to me at least -- mostly about the idea of removing perimeters and trusted networks as the basis for trust and access control. So I'm with you so far.
> ... devices, personas, or processes and shifts to multi-attribute-based levels of confidence that enable authentication and authorization policies founded on the concept of least privileged access concept of least privileged access
But it's interesting here that the authors are also calling out and devices, personas which is what I'd argue are the fundamental contextual attributes that allow you to replace a "trusted perimeter"; if we aren't using perimeters, devices, personas... what is the DoD suggesting we use? I can't find it.
> At its core, ZT assumes no implicit trust is granted to assets or users based solely on their physical or network location (i.e., local area networks versus the Internet) or asset ownership (enterprise or personally owned).12
I strongly agree with the first point, but disagree and am perplexed by the second. Zero trust is all about getting rid of a trusted network location.
However, asset ownership *matters* because it affects not only the identity of the user, but also the _state_ of the device. It's totally reasonable to have different levels of trust for a managed company owned device with a known set of endpoint protection tools, vs a BYOD device whose device state is largely unknown.
The doc does a good job of outlining the "Why" of zero trust. And what's required from an org to make it possible.
Unfortunately, while the document starts out strong, it quickly becomes "actually, zero trust is every security thing you've ever heard of". Paired with a timeline no one will ever meet ever.
I agree that it quickly became a radar for every single tech/vendor which slaps a 'zero trust' sticker on their product. Personally, I believe that while zero trust applies to all pillars, the most consequential is the network if we pair it with comcepts/components of the other pillars.
For example, if we state we want to have zero trust in the network, we can achieve this by switching from authenticate/authorise-after-connect (i.e., how TCP/IP/almost every network is built), to authenticate/authorise-before-connect. This is achieved with strong identity (e.g., x509) and an overlay network built on zero trust principles which further provides us microsegmentation, least privilege, etc. It allows us to close all inbound ports and make access decision at the source (rather than destination) edge (e.g., device/user) and close all inbound ports. This makes many MITRE attacks impossible and massively reduces the affect of others. We can have zero trust in the WAN/internet (no inbound ports), LAN and even host OS.
Zero trust is about not trusting anything, not only the network, and instead focusing on controlling the access/damage. It is 100% authz, about limiting what you can access and how long you can access it to what is required. That you there is no trust in those agent (ie. assume authn is already compromised) so you limit the damage possible.
I would extend it to not inherently trusting the agent as well as being able to not have to trust the network (e.g., internet WAN) by closing all inbound ports by implementing authentication-before-connect using strong identity (e.g., x509)
> authentication-before-connect using strong identity
Identity always involves trust and is authn. Zero-trust assumes authn is already compromised (ie. don't trust anything) and therefore identity is out of scope.
Quote from NIST, "Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established."
Zero Trust is not assume everything is compromised and you dont trust anything. Its about reducing implicit trust across the pillars to reduce risk.
I think you are just misreading it. Read correctly, IMO, it says that no trust is granted to anything... note how they list multiple general examples, enough items to cover everything multiple times, to help make sure this was the reading. That authentication is discrete from authorization and outside of each others purview. And given zero trust is all about access control, I think my framing makes sense.
Any framing which helps one to reduce systematic risk is fine by me and fully agreed that authentication is discrete from authorization. My framing is set by the open source project I work on (https://openziti.github.io/) which allows anyone to embed zero trust networking into anything including an application with an SDK, this allows us to have zero trust in the network, be it internet/WAN, local or even the host OS network. This reduces a lot of the attack surface but you do have the trust the overlay control plane.
I'm happy to see this admission lead the document; it's bold coming from an org as conservative as the DoD. To see critical mass around the idea that -- like it or not -- adversaries (both malicious insiders and outsiders) are already on trusted networks is really encouraging to see.
First, let's be clear what this document is and isn't.
> Importantly, this document serves only as a strategy, not a solution architecture. Zero Trust Solution Architectures can and should be designed and guided by the details found within this document.
This is a long term strategy doc, not an implementer's guide. Operators looking for zero-trust easy mode won't find it here. It's also very DoD specific.
But there are some good parts. I read the doc so (maybe?) you don't have to.
I made some screenshots of the portions I thought most relevant.
https://imgur.com/a/Dhm7yvi
The comments will make more sense if you are viewing those.
> Zero Trust uses continuous multi-factor authentication, micro-segmentation, advanced encryption, endpoint security, analytics, and robust auditing, among other capabilities, to fortify data, applications, assets, and services to deliver cyber resiliency. The Department is evolving to become a more agile, more mobile, cloud-supported workforce, collaborating with the entirety of DoD enterprise, including federal and non-federal organizations and mission partners working on a variety of missions.
If you somehow managed to read the above without going into a post word salad coma, I'm sorry. I highlighted the section just to bring up there's an awful lot of enterprise security buzzword and DoD acronym bingo going on. But there are some good thoughts too.
> Zero Trust is much more than an IT solution. Zero Trust may include certain products but is not a capability or device that may be bought.
It's nice to hear this being reiterated so often. A good start!
> Zero Trust security eliminates the traditional idea of perimeters, trusted networks, ...
Zero trust is -- to me at least -- mostly about the idea of removing perimeters and trusted networks as the basis for trust and access control. So I'm with you so far.
> ... devices, personas, or processes and shifts to multi-attribute-based levels of confidence that enable authentication and authorization policies founded on the concept of least privileged access concept of least privileged access
But it's interesting here that the authors are also calling out and devices, personas which is what I'd argue are the fundamental contextual attributes that allow you to replace a "trusted perimeter"; if we aren't using perimeters, devices, personas... what is the DoD suggesting we use? I can't find it.
> At its core, ZT assumes no implicit trust is granted to assets or users based solely on their physical or network location (i.e., local area networks versus the Internet) or asset ownership (enterprise or personally owned).12
I strongly agree with the first point, but disagree and am perplexed by the second. Zero trust is all about getting rid of a trusted network location.
However, asset ownership *matters* because it affects not only the identity of the user, but also the _state_ of the device. It's totally reasonable to have different levels of trust for a managed company owned device with a known set of endpoint protection tools, vs a BYOD device whose device state is largely unknown.
The doc does a good job of outlining the "Why" of zero trust. And what's required from an org to make it possible.
Unfortunately, while the document starts out strong, it quickly becomes "actually, zero trust is every security thing you've ever heard of". Paired with a timeline no one will ever meet ever.