In my previous blog post, I discussed some of the observed challenges when implementing a zero trust architecture and how you can use Citrix technology to overcome them. In this post, I’ll dive deeper into the components that make up a mature zero trust model and will review a sample Citrix zero trust architecture in detail.
Core Zero Trust Architecture
Let’s start with the logical components of a zero trust architecture, as specified in NIST SP 800-207 and shown in this image:
Of course, there are more working parts of a zero-trust architecture than pictured above, but there are really three core components: policy engine, policy admin, and policy enforcement point. These three components enforce least privilege access to IT resources with granular controls while ensuring accuracy of policy and providing visibility to keep data, infrastructure, and other assets safe. Let’s look at each:
- Policy Engine: Responsible for the ultimate decision to grant access to a resource for a given subject.
- Policy Admin: Responsible for establishing and/or shutting down the communication path between a subject and a resource.
- Policy Enforcement Point: Responsible for enabling, monitoring, and eventually terminating connections between a subject and an enterprise resource.
Consider a subject on an untrusted system who makes an access request to a particular resource. The request goes from the policy enforcement point to the policy admin, ultimately ending up at the policy engine for evaluation. The policy engine has been configured to authorize access based on the organization’s trust algorithm.
If the request is authorized based on the parameters received, the policy engine deems a subject as trusted, and the policy admin grants authorized resource access to the subject by opening a communication channel. If a subject on their system becomes untrusted at any point, the policy admin can close communication channels, preventing unauthorized access to enterprise resources.
Citrix Zero Trust Architecture
Now that we’ve covered the core components of a zero trust architecture, let’s look at an example using Citrix technologies, shown here (click image to view larger):
In the diagram, I have a subject on an untrusted system requesting access to a resource. The policy engine must validate the request before the policy admin can open a channel of communication to the resource.
In this case, the subject is a user, the system is their device with Citrix Workspace app installed, and the resource could be a SaaS app, internal web app, VDI, TCP/UDP connection, or a client-server app. Citrix Workspace with Citrix Secure Private Access has become the zero trust delivery mechanism for the enterprise resources.
Now let’s look at what happens when the access request arrives at Citrix Workspace.
To begin the validation process, the subject must first authenticate. The fourth tenet of a zero trust architecture as specified by NIST states that “Access to resources is determined by dynamic policy including the observable state of client identity, application/service, and the requesting asset — and may include other behavioral and environmental attributes.”
To abide by this principle, Citrix Workspace sends the access request to the adaptive authentication service. This is the policy engine that dynamically recognizes the identity of the individual and challenges them with the appropriate authentication method (LDAP, RADIUS, SAML, OAuth, Certificate), device posture check, product scans (e.g. Avast! Free Antivirus), vendor scan (e.g. Avast Software), generic scan (e.g. antivirus), and system scan (e.g. device certificate).
The organization must establish the specifics of the adaptive authentication / authorization process (often called the trust algorithm). Some of the building blocks of a trust algorithm include the resource requirements (defines minimal requirements for access to resources — MFA, geolocation, etc.); the asset database (known status and requirements of enterprise owned assets or unmanaged devices); and the subject database (the “who” that is requesting access, set of subjects, and collection of attributes).
At this point, the subject has been authenticated, but they are only halfway to becoming fully trusted for enterprise resource access. The adaptive authentication service sends identity, context, and location information that it has learned about the subject to adaptive access, the secondary policy engine, to enable certain security controls (remote browser isolation, enterprise browser) and lockdown policies (clipboard restriction, inability to download, watermarking, blocking of drive mapping, and more) when launching resources. Doing this satisfies the third tenet — “Access to individual enterprise resources is granted on a per-session basis” — and the sixth tenet — “All resource authentication and authorization are dynamic and strictly enforced before access is allowed” — of a zero trust architecture as specified by NIST.
Now that the subject has been fully validated and has requested access to a particular resource, the policy admin (Citrix Workspace) will open a communication channel to the resource. While that occurs, the policy enforcement point (Citrix Workspace app) will enforce the security controls and lockdown policies as determined by the outcome of the adaptive authentication and adaptive access policy evaluation. At this point, the subject’s system is now securely connected in a trusted fashion via the proxy service to the enterprise resource and will continue to be until the subject and/or system violate the trust algorithm.
To ensure that only trusted users are connected, raw events from the Citrix environment are fed to Citrix Analytics for Security, which monitors and analyzes end-user behavior and reports on risky actions. Machine learning techniques are leveraged to identify anomalous behavior and take closed loop autonomous action when necessary, such as starting a session recording, logging a user off, requesting end-user response, or locking a user’s account.
What’s Next
As enterprises migrate toward a mature zero trust architecture, it is important to understand the core concepts of how to design the architecture and how to configure the environment to satisfy the tenets of a zero trust architecture. In a future article on Citrix Tech Zone, I will dive into a step-by-step configuration of sample zero trust architecture scenarios leveraging Citrix Secure Private Access, Citrix adaptive authentication, Citrix adaptive access, and Citrix DaaS.
