The Building Blocks of a Zero Trust Identity Architecture

Within this architecture, all interactions are to be achieved in the most secure manner possible, emphasizing consistent identity verification and authentication. And all interactions are continuously reassessed. Each time access to a resource is granted, this is done for only one session — and for that resource alone. Every access request is evaluated dynamically based on organizational policy and risk evaluation. Each request is checked to ensure that the identity making the request (user or machine identity) should be granted access, that their laptop, mobile device, or other IT system is behaving appropriately, and that the requested resource has the right characteristics. 

To enforce security during sessions — not just at their start — all assets are continuously monitored. Whether access should be maintained is reassessed on an ongoing basis. Log and event data are collected and sent to the policy engine to provide a basis for policy alignment and enforcement. Security solutions within the architecture must seamlessly interoperate and exchange risk and contextual information to enable the required visibility. Using an open and standards-based approach makes this possible.

Why an Enterprise-Wide Platform Approach is Key

In the NIST model, following a Zero Trust approach requires more than just centralized access management. Identity governance and privileged access management are just as important. It must be possible for endpoint devices, enterprise computing resources, and networking and infrastructure components to exchange information seamlessly – across the entire IT ecosystem. And all parts of the data and endpoint security architecture must work together with security analytics tools and identity governance and access management solutions.

This is because identity lifecycle management must be based upon a holistic view of behaviors, entitlements, and organization-wide risks. The policy engine must detect segregation of duties (SoD) violations across multiple applications by continuously monitoring for and detecting out-of-policy activities to ensure that a requesting entity should indeed access a particular resource, for instance. To determine whether identities are still valid — or if roles have changed — the policy engine must be able to review and remove access as needed. And to ensure that permissions are granted only to users that truly need them, just-in-time access and zero standing privilege policies should be enforced.

Components of a Zero Trust Identity Architecture 

To obtain the complete set of capabilities needed to achieve holistic visibility and control, you’ll need multiple solutions with overlapping and tightly integrated capabilities.

Let’s take a closer look at what this involves. In the past, the “policy engine” component of the NIST model wasn’t really an engine but instead a static repository of access rules and policies written by administrators and stored centrally. Such legacy policy engines couldn’t evaluate access requests dynamically based on current threat intelligence or relevant contextual information. Nor could they detect out-of-policy activities taking place inside applications in real time. These policy rule sets were what one might describe as “static” — they couldn’t adapt and react to real-world conditions in real time.

To make the policy engine intelligent, it needs to have four core capabilities. It also has to interact with applications, security and access management solutions, and a broad array of IT resources across the entire enterprise computing ecosystem. This way, it can gather information from all these sources and incorporate this intelligence into the behavioral analytics it uses to assess and reassess risk posture on an ongoing basis.

The four core capabilities are as follows:

1. The solution must have an up-to-date inventory of all identities (human and machine) that need to access resources so that it can formulate consistent and accurate access policies for identities across the whole environment. Thus, it must be able to discover and correlate all identities and entitlements. This means it will need to know precisely which employees, contractors, third-party partners and vendors, devices, applications, and machine identities interact with one another in the environment, what roles each of them play, and what rights they should have.
2. The solution must be able to provide user and device identity and contextual information. It will supply this information to the access management and secure access service edge (SASE) solutions that enforce policies by allowing (or denying) access to resources in the environment. These include applications, data, DevOps pipelines, and other assets.
3. It must set least-privileged access policies based on current usage and outlier analysis — and share these policies with the solutions that will enforce them.
4. It must be able to ingest logs and data from security tools and solutions in the environment. This feeds its advanced identity analytics capabilities to respond to risky activities quickly, accurately and appropriately. 

To achieve a robust Zero Trust Identity posture, you need a security architecture that’s modeled as a closed-loop: all the components need to be able to interoperate and inform one another. This way, they can gather the intelligence to determine if particular activities are risky or not. Naturally, this extends to include activities that take place during sessions with privileged access, since these sessions have the potential to pose the greatest risks to the business, in terms of both application availability and cybersecurity. 

And it should ultimately extend to include all data, applications, identities, and resources in the environment. However, most enterprises will need to start with a smaller subset of target users, applications, or resources, and build capabilities as their Zero Trust security posture matures.

Building a Zero Trust architecture isn’t a simple, one-step process. It instead requires implementing new solutions that can gather intelligence across your IT ecosystem and inform the SASE, access management, and security tools that enforce policies. Designing such an architecture means thinking differently about interconnectivity and the value of an open, standards-based approach. It means thinking smarter in your entire approach to identity and security across your organization.