A couple of months ago, we began our discussion of Zero Trust Identity by talking about what this often-misunderstood concept actually means. Zero Trust is more than a technology. And despite what many security vendors might like you to believe, it isn’t a product you can buy. Instead, adopting a Zero Trust approach to identity requires a mindset shift across the organization. It also demands that you redesign your overall security strategy to focus on identity as the perimeter instead of point solutions.
In this article, we’ll take a closer look at what’s involved in building a Zero Trust Identity architecture.
Zero Trust is becoming an industry-wide standard. And as Zero Trust is ever more broadly adopted, growing numbers of security leaders and practitioners are focusing their attention on deploying identity-based solutions and building identity-centric architectures. A Zero Trust Identity approach makes it possible to deliver robust security without negatively impacting productivity or agility — at the speed of modern business.
Most of the emerging technologies whose popularity has exploded over the past year reside outside of traditional organizational boundaries. Cloud infrastructures, for example, include a broad array of various services, each of which needs its own mechanism for enforcing access control and governance. And Software-as-a-Service (SaaS) applications introduce additional sets of disparate security requirements.
Many organizations have shifted to a modern application strategy to keep pace with consumer demand for rapid innovation. This means that they’re taking advantage of newer technologies like microservices and DevSecOps pipelines to create software that can unlock the full benefits of the cloud. While leveraging these technologies will contribute to business acceleration, it can also introduce new security risks. It can be challenging to maintain visibility into – and control over – the various components with legacy security solutions or a conventional perimeter-based strategy. This is why it’s essential to supply access control and governance engineered to secure the CI/CD pipeline.
Refactoring your security architecture to support modern cloud-based technologies requires a modern identity solution that integrates with existing security and compliance tools. This way, a Zero Trust Identity Architecture can continue to enforce existing use cases while enabling the creation of new ones. Achieving this requires architecture built upon interoperable solutions that can readily exchange information. This will also enable your organization to make use of visibility, risk, and threat intelligence to drive automated decision-making.
In the wake of several high-profile cyberattacks and breaches involving federal agencies, the National Institute of Standards and Technologies (NIST) created an abstract definition of a Zero Trust Architecture along with several deployment models. Elaborated in NIST SP 800-207, Zero Trust Architecture, this model is explicitly intended to provide a roadmap for enterprise security architects looking to implement Zero Trust-based approaches to information security.
According to the NIST model, a Zero Trust Architecture must incorporate three core components. These are:
NIST Abstract Zero Trust Logical 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.
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.
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:
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.