Disclaimer: The views expressed in the content below are solely those of the author and do not necessarily reflect the views of the IDPro organization.
Many organizations hear from vendors, thought leaders, and perhaps strange women lying in ponds who distribute swords that they need to get to “Zero Trust.” Zero trust as a marketing term has exploded over the past few years, and it feels like everywhere you look, the term is being used, but very little is being said on what it means—and indeed, what it means to identity. It would be prudent then to understand what is meant by zero trust, select a model that provides a basis by which a zero trust architecture may be achieved, and dig into the ramifications of the model chosen for identity.
What is Zero Trust?
Zero Trust is broadly defined by many sources. For instance, Gartner couches Zero Trust within the context of networks, stating, “Zero trust network access (ZTNA) is a product or service that creates an identity—and context-based, logical access boundary around an application or set of applications.” The UK’s NCSC also defines it within this context of networks-—they offer that “A zero trust architecture is an approach to system design where inherent trust in the network is removed.” If we are to believe NIST SP 800-207 (Zero Trust Architecture), it is “the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.” Given the spread of definitions, we should look to synthesize these definitions to provide a holistic perspective.
- Zero trust seeks to eliminate implicit trust.
- Zero trust seeks to make access determinations that are identity, context, and resource-driven.
- Zero trust seeks to move past using static network configurations as a defense.
What is Implicit Trust?
Implicit trust, put simply, is where actions taken between systems, users, and other resources are allowed due to some facet of their relationship with each other. In an extremely simple example, a database within a traditional, organizationally managed data center may have a line of sight from a network perspective to hundreds of other systems because of the tasks the database helps those systems perform. These in-datacenter systems may have a common set of administrators, and one of these administrators may have access to a laptop that uses a VPN client to get into the data center remotely for management, specifically that database. These systems then share a tremendous degree of implicit trust- an attacker who gets access to the administrator’s laptop could potentially do immense damage to a number of systems because each system in the chain has put some degree of faith in the next one down the line. Ransomware, in particular, exploits implicit trust, utilizing whatever tools it can to move laterally within an organization to cause as much damage as possible.
What Do Zero Trust Folks Mean When They Say “Identity,” “Context,” and “Resource”?
When we speak of identities in a zero-trust context, we refer to both traditional users (as in people) and non-person entities (such as machine accounts used for programmatic access). These identities must have appropriate context, meaning they must meet specific conditions (e.g., time of day, location, compliance to specific requirements identified by the organization, attributes, role-based access signifiers, etc.) to perform a given operation. Resources are objects an organization possesses that are subject to access determinations, such as applications, workflows, systems, assets that respond and conform to logical access (such as doors), and so on. We describe all of this to indicate that a user, in certain contexts, has access to perform actions on specific resources.
What Happens to the Network?
The network, as we understand it, still exists. However, the focus shifts from hardening the perimeter of a network to securing resources. Typical implementations focus on identities sufficiently authenticating and having sufficient authorization (by having appropriate context), with these entitlements being dynamic and assessed continuously such that if the identity no longer meets requirements, access is terminated immediately; if the identity is sufficiently authenticated and authorized, it is allowed access to the resource for that specific interaction. Each interaction with a given resource requires a new and separate assessment; prior successful assessments do not indicate future success. The common terminology used for the interaction of identity to resource under this model is “microsegmentation”—to effectively construct a network segment from resource to resource and dynamically assign it based on context.
What Models Are There of Zero Trust?
While vendors quickly provide their own view of zero trust, few (if any) have provided comprehensive models that outline critical functions necessary to achieve such a state in a distributed computing environment. Various countries and blocs, such as the UK and the EU, have offered either broad guidance (https://www.ncsc.gov.uk/collection/zero-trust-architecture) or pay lip service to it in reports (https://www.europarl.europa.eu/doceo/document/A-9-2021-0313_EN.html) but few government-sponsored and independent reference models have been put forward. The US Government has offered some guidance on this across its agencies, notably NIST by way of its work in the NCCoE (https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture) as well as NIST SP 800-207, and the Department of Defense with its Zero Trust Reference Architecture (henceforth the DoD ZTRA). While all of the NIST SPs are great reading on this subject, let’s focus for a bit on the DoD ZTRA.
An Extremely High-Level View of the DoD ZTRA for Identity
The DoD ZTRA asserts that zero trust’s goal is to protect data. It does this through the interrelated nature of six separate focus areas: User, Device, Network/Environment, Applications/Workload, Visibility/Analytics, and Automation/Orchestration. The DoD ZTRA asserts that conditional authentication and authorization are critical to each focus area and provides a figure that offers capabilities related to those areas. See Figure 1 for their highlighted capabilities.
Figure 1: Authentication and Authorization Capability Taxonomy. Source: DoD ZTRA
A point that the DoD ZTRA really drives home with this figure, as well as the other capability taxonomies and capabilities outlined, is that authentication and authorization need to be driven into every decision possible, as close as possible to the point of decision. These authentication and authorization decisions need to be constant, fine-grained, adaptive, and provide rapid mechanisms for restricting access should it become incongruent with a user’s standard use patterns.
The DoD ZTRA indicates that a service external to the previously mentioned focus areas, known as the “Enterprise Identity Service” (EIS), should be utilized at the control plane to facilitate this. The EIS is made up of three capabilities: the Enterprise Federated Identity Service (EFIS), Automated Account Provisioning (AAP), and the Master User Record (MUR). At a high level, these capabilities map to federated authentication and authorization, identity governance/lifecycle management, and the aggregation of contextually important attributes for a given entity (person or otherwise) for the purposes of driving those authentication and authorization decisions. Examples include credentials, roles, attributes defining access classifications, policy/context-driving attributes (such as a risk score for a given user), and so on.
This begs a question of scale: is the DoD ZTRA meant to construct one system to rule them all? Not necessarily. To quote the DoD ZTRA on this, “DoD enterprise ICAM service providers provide one or more services that support ICAM capabilities. A service is defined as DoD enterprise if it can be used by anyone across the DoD, and, for externally facing federation services, by any DoD mission partner”. The document goes on to define requirements for these service providers, as well as DoD component organization requirements. Ultimately, there will be many implementations of an EIS across the DoD. In these many implementations, they will be able to best meet the needs of the mission while still conforming to the goal of eliminating implicit trust wherever possible.
A goal of this externalized service is then to be reusable and interoperable- while the DoD does not provide specifics around each service, it is to be assumed that an EIS for a given DoD organizational component should be able to communicate effectively to every other DoD organizational component and mission partner as it needs to. If this were not the case, the DoD would be back to building stovepipe systems- systems with limited scope and function, possessing data that, by the nature of the system, is difficult to use outside of the system. Identity commonly falls into this trap, where a given system owner may wish to implement their own flavor of an identity capability with a custom schema or custom relationship model.
In Summary
There should be minimal surprise when we see that the DoD ZTRA offers no revolutions in security or identity thought. It is instead a synthesis of practices that identity and security practitioners have been pointing towards as being critical for years. Whether the people who perform integrations across the federal government take this guidance to heart remains to be seen. It is this author’s hope that given time and appropriate space the DoD ZTRA will not act as the final word on the topic but is merely the beginning of the conversation with respect to integrating sound identity practices into large and distributed organizations.
Author Bio
Rusty Deaton has been in Identity and Access Management for over a decade. He began in technology as a technical support engineer for a Broker-Dealer and has since worked across many industries, carrying forward a passion for doing right by people. When not solving problems, he loves to tinker with electronics and read. He currently works as Federal Principal Architect for Radiant Logic.
