In the last blog, we covered several possible explanations for how we got to where we are today with enterprise security. We also discussed whether zero trust is marketing, architecture, a solution, or something else. In this blog, we will attempt to answer that question.
Before we get to zero trust, let’s use this high-level view of an enterprise to illustrate the necessity for zero trust. In this diagram, a few things are occurring:
- Perimeters have dissolved as the workforce became distributed, leading to projects to eliminate the VPN in favor of “Software Defined Perimeters” or “Zero Trust Network Access,” which we will touch on later.
- The use of best-of-breed security everywhere continues to drive siloed approaches to security, leading to high operational overhead
- Correlation of events only happens in the SOC with complex bespoke evaluations in after-the-fact incident response
- Once the attackers get in, they can spread laterally in the data center and even hop between clouds
This diagram and its descriptive comments are not indicative of every enterprise. But they are a justifiable description of several typical architectural and operational issues many find themselves in as they begin their path towards a zero trust model. Let’s wade further into our search for a descriptive meaning for zero trust.
What is Zero Trust
Let’s look at a few definitions of Zero Trust from industry-recognized standard committees. We are providing these definitions to seed our discussion as a high-level view with a couple of observations. Still, it is neither an exhaustive list of definitions nor an in-depth analysis of the stated definitions.
First up: The DoD Zero Trust Reference Architecture Version 1.0
This diagram shows a model for interactions from end to end, starting from defined entry points, identity services, applications, and data. We can summarize the model by stating that a dynamic decision determines resource access. The process of providing this access decision includes the observed state of:
- The client’s identity
- The application and services
- The requesting asset
- Contextual metadata, including behavioral and environmental attributes
This data-centric approach drives the continual verification of trust. There are mechanisms positioned throughout the architecture to secure, manage, and monitor the devices, users, applications, the network transactions at the perimeter and within the network enclaves. There are requirements to verify anything attempting to establish access on a per-request per access process. This requirement specifies a continual verification for each user, device, application, and transaction. The data-centric approach builds confidence levels using multiple attributes such as identity, location, time, and other substantive descriptive properties, for authenticating the subject.
Next, we have the NIST 800-207 Zero Trust Architecture. Let’s take a look at the components that make up the architecture.
There is much to this architectural document and the corresponding graphic from the NIST Cybersecurity Practice Guide SP 1800-35 Vol B, Implementing a Zero Trust Architecture. Still, we can summarize a few key takeaways:
- Heavy on risk: assessment methodology for classification and FIPS for mitigation controls.
- Workflow and resource-centric approach
- Per-session access decisions
- Access decisions use the observable state of the client identity, application/service/ the requesting asset, and may include behavioral and environmental attributes
- Continual verification of the state of all resources (user, device, application, and transaction) to improve policy
Trust is the bidirectional belief established between two entities. The first belief is that the other entity is what it claims to be, while the second is that it will behave in expected ways during the duration of the interaction. Trust leads to access.
Implications
- Trust is not inherently a good thing. It is what we use instead of absolute certainty.
- Trust is not absolute, binary, or static. It is an indication of the level of the relative level of strength of the assurance of the belief, which may change over time.
- Perimeters don’t go away. There is an increase in the number of demarcation boundaries of trust: ephemeral micro-perimeters are created and destroyed with each transaction.
So, what is Zero Trust?
As with any new security definition that is getting a lot of hype, it tends to get a marketing once-over of existing solutions that meet some of the criteria for Zero Trust. It also gets broken down into components that can be consumed in a partial solution. We don’t see a problem with that as it is a journey, and those are part of the natural progression to moving to a meaningful solution, but as Tom Gillis mentions, “There’s no zero-trust product, per se. You can’t take a zero-trust pill”.
Put simply; zero trust is a new security model with a set of architectural design principles rooted in the simple fact that you have already been compromised and that trust is not inherent to where the users, assets, or applications are located, nor to who owns them. Therefore, verify trust every step along the way.
Here are some fundamental principles of zero trust in the crawl, walk, run, phase, and why VMware for zero trust.
- Assume you have already been compromised
- Must be driven end-to-end – Workloads, Users, Devices, Applications, Networks
- While crawling, brownfield, etc. is ok
- Deploy in its purest form in modern apps/cloud and adopt back to brownfield
- Must take into account business criticality and risk management
- Context drives policy
- Context is king – the more you know, the better decisions you can make. Focus on understanding what you don’t know and what you do know.
- We want to prevent a continual evolving door of tactical solutions
- Zero trust is a journey that will continue to evolve as attackers continue to advance/evolve
- We have no allusions that security discussions ever have an end as zero trust is an evolving journey
In our next blog post, we will review and discuss how a Zero Trust Architecture can be adopted, what best practices are already available, and what we at VMware think about it.
