Enterprise 2 Build 6 (E2B6) - SASE - Google Chrome Enterprise Premium (CEP) - Access Context Manager as PE

Note

This page is supplementary material for the NIST SP 1800-35 publication.

Technologies

E2B6 uses products from Google Cloud, IBM, Mandiant, Okta, Omnissa, Radiant Logic, SailPoint, and Tenable. Certificates from DigiCert are also used. For more information on these collaborators and the products and technologies they contributed to this project overall, see Collaborators and Their Contributions.

E2B6 components consist of Google Chrome Enterprise Premium (CEP), Google Application Connector, Omnissa Workspace ONE UEM, Okta Identity Cloud, Okta Verify App, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable Nessus Network Monitor (NNM), Mandiant Security Validation (MSV), Google Cloud (IaaS), Google Workspace (SaaS), and DigiCert CertCentral.

Table 1 lists all of the technologies used in Build E2B6. It lists the products used to instantiate each ZTA component and the security function that each component provides.

Note that after the VMware End User Computing division products were implemented at NCCoE, VMware was acquired by Broadcom, then the VMware End User Computing Division was divested and reformed under a new entity, Omnissa LLC.

Table 1 - E2B6 Products and Technologies

E2B6 Products and Technologies

Component	Product	Function
PE	Google Chrome Enterprise Premium (CEP) - Access Context Manager	Decides whether to grant, deny, or revoke access to a resource based on enterprise policy, information from supporting components, and a trust algorithm.
PA	Google CEP - Access Context Manager	Executes the PE’s policy decision by sending commands to a PEP that establishes and shuts down the communication path between subject and resource.
PEP	Google CEP - Identity Aware Proxy	Guards the trust zone that hosts one or more enterprise resources; establishes, monitors, and terminates the connection between subject and resource as directed by the PA; forwards requests to and receives commands from the PA.
	Google CEP - Chrome Browser
ICAM - Identity Management	Okta Identity Cloud	Creates and manages enterprise user and device accounts, identity records, role information, and access attributes that form the basis of access decisions within an organization to ensure the correct subjects have the appropriate access to the correct resources at the appropriate time.
ICAM - Access & Credential Management	Okta Identity Cloud	Manages access to resources by performing user and device authentication (e.g., SSO and MFA) and using identity, role, and access attributes to determine which access requests are authorized.
ICAM - Federated Identity	Radiant Logic RadiantOne Intelligent Identity Data Platform	Aggregates and correlates all attributes relating to an identity or object that is being authorized by a ZTA. It enables users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Federated identity encompasses the traditional ICAM data, supports identities that may be part of a larger federated ICAM community, and may include non-enterprise employees.
ICAM - Identity Governance	SailPoint IdentityIQ	Provides policy-based, centralized, automated processes to manage user identity and access control functions (e.g., ensuring segregation of duties, role management, logging, access reviews, analytics, reporting) to ensure compliance with requirements and regulations.
ICAM - MFA	Okta Verify App	Supports MFA of a user identity by requiring the user to provide not only something they know (e.g., a password), but also something they have (e.g., a token).
Endpoint Security - UEM/MDM	Omnissa Workspace ONE UEM	Manages and secures enterprise desktop computers, laptops, and/or mobile devices in accordance with enterprise policy to protect applications and data; ensures device compliance; mitigates and remediates vulnerabilities and threats; monitors for suspicious activity to prevent and detect intrusions; prevents, detects, and disables malware and other malicious or unauthorized traffic; repairs infected files when possible; provides alerts and recommend remediation actions; and encrypts data.
		Pushes enterprise applications and updates to devices, enables users to download enterprise applications that they are authorized to access, remotely deletes all applications and data from devices if needed, tracks user activity on devices, and detects and addresses security issues on the device.
Endpoint Security - Endpoint Compliance	Google CEP - Chrome Browser	Performs device health checks by validating specific tools or services within the endpoint including antivirus, data encryption, intrusion prevention, EPP, and firewall.
Security Analytics - SIEM	IBM Security QRadar XDR	Collects and consolidates security information and security event data from many sources; correlates and analyzes the data to help detect anomalies and recognize potential threats and vulnerabilities; and logs the data to adhere to data compliance requirements.
Security Analytics - Endpoint Monitoring	Tenable.io	Discovers all IP-connected endpoints and performs continuous collection, examination, and analysis of software versions, configurations, and other information regarding hosts (devices or VMs) that are connected to the network.
Security Analytics - Vulnerability Scanning and Assessment	Tenable.io and Tenable.ad	Scans and assesses the enterprise infrastructure and resources for security risks, identifies vulnerabilities and misconfigurations, and provides remediation guidance regarding investigating and prioritizing responses to incidents.
Security Analytics - Traffic Inspection	Tenable NNM	Intercepts, examines, and records relevant traffic transmitted on the network.
Security Analytics - Network Discovery	Tenable NNM	Discovers, classifies, and assesses the risk posed by devices and users on the network.
Security Analytics - Security Validation	Mandiant Security Validation	Provides visibility and evidence on the status of the security controls’ effectiveness in the ZTA. Enables security capabilities of the enterprise to be monitored and verified by continuously validating and measuring the cybersecurity controls; also used to automate the demonstrations that were performed to showcase ZTA capabilities. Deployed throughout the project’s laboratory environment to enable monitoring and verification of various security aspects of the builds. VMs that are intended to operate as actors are deployed on each of the subnetworks in each of the enterprises. These actors can be used to initiate various actions for the purpose of verifying that security controls are working to support the objectives of zero trust.
Data Security - Data Access Protection	Google CEP - Chrome Browser	Discovers, classifies, and labels sensitive business critical data in the cloud and on-premises; provides protection by preventing unauthorized access and minimizing the risk of data theft and data leaks using security policy rules.
General - Remote Connectivity	Google CEP	Enables authorized remote users to securely access the inside of the enterprise. (Once inside, the ZTA manages the users’ access to resources.)
Resource Protection - Application Connector	Google Application Connector	Component that is deployed to be the front-end for an internal resource (whether located on-premises or in the cloud) and act as a proxy for it. Requests to access the resource are directed to the connector, which responds by initiating a secure connection to the PEP. It enables access to a resource without requiring the resource to be visible on the network.
General - Certificate Management	DigiCert CertCentral TLS Manager	Provides automated capabilities to issue, install, inspect, revoke, renew, and otherwise manage TLS certificates.
General - Cloud IaaS	Google Cloud - GitLab	Provides computing resources, complemented by storage and networking capabilities, hosted by a cloud service provider, offered to customers on demand, and exposed through a GUI and an API.
General - Cloud SaaS	Google Workspace - DigiCert CertCentral, Okta Identity Cloud, Tenable.io, and VMware Workspace ONE UEM	Cloud-based software delivered for use by the enterprise.
General - Application	GitLab	Example enterprise resource to be protected. (In this build, GitLab is integrated with Okta and IBM Security QRadar XDR pulls logs from GitLab.)
General - Enterprise-Managed Device	Windows client, macOS client, Linux client, and mobile devices (iOS and Android)	Example endpoints to be protected. All enterprise-managed devices are running Symantec Endpoint Security agent and have the Okta Verify App installed.
General - BYOD	Windows client, macOS client, Linux client, and mobile devices (iOS and Android)	Example endpoints to be protected.

Build Architecture

In this section we present the logical architecture of E2B6. We also describe E2B6’s physical architecture and present message flow diagrams for some of its processes.

Logical Architecture

Figure 1 depicts the logical architecture of E2B6. It uses numbered arrows to depict the general flow of messages needed for a subject to request access to a resource and have that access request evaluated based on subject identity (both requesting user and requesting endpoint identity), user authorizations, and requesting endpoint health. It also depicts the flow of messages supporting periodic reauthentication of the requesting user and the requesting endpoint and periodic verification of requesting endpoint health, all of which must be performed to continually reevaluate access. The labeled steps in Figure 1 have the same meanings as they do in Architecture - Figure 1. However, Figure 1 includes the specific products that instantiate the architecture of E2B6. Figure 1 also does not depict any of the resource management steps found in Architecture - Figure 1 because the ZTA technologies deployed in E2B6 do not support the ability to perform authentication and reauthentication of the resource or periodic verification of resource health.

E2B6 was designed with Google CEP - Access Context Manager serving as PE, PA, and Google CEP - Identity Aware Proxy and Google CEP - Chrome Browser serving as PEPs. Okta Identity Cloud serves as the identity, access, and credential manager. Radiant Logic acts as a PIP for the PDP as it responds to inquiries and provides identity information on demand in order for Okta Identity Cloud to make near-real-time access decisions. A more detailed depiction of the messages that flow among components to support a user access request can be found in Message Flows for Successful Resource Access Requests.

Figure 1 - Logical Architecture of E2B6

ICAM Information Architecture

How ICAM information is provisioned, distributed, updated, shared, correlated, governed, and used among ZTA components is fundamental to the operation of the ZTA. The ICAM information architecture ensures that when a subject requests access to a resource, the aggregated set of identity information and attributes necessary to identify, authenticate, and authorize the subject is available to be used as a basis on which to make the access decision.

In E2B6, Okta Identity Cloud, Radiant Logic, and SailPoint integrate with each other as well as with other components of the ZTA to support the ICAM information architecture. The ways that these components work together to correlate identity information and to support actions such as users joining, changing roles, and leaving the enterprise are the same in E2B6 as they are in E1B1, E1B2, E1B3, E1B4, and E2B4. These interactions are described in E1B1 ICAM Architecture.

Physical Architecture

Enterprise 2 describes the physical architecture of the E2B6 network. IaaS - Google describes the cloud architecture of E2B6.

Message Flows for Successful Resource Access Requests

This section depicts three authentication message flows supported by E2B6. In each flow, a subject who is authorized to access a resource requests and receives access to that resource. In the first flow, we show a user signing into Google Chrome Enterprise Premium - Chrome Browser. In the second flow, the resource is located either on-premises or in an IaaS cloud. In the third flow, the resource is located in Google Workspace, a SaaS cloud. Before a user can access a resource in either of these locations, the user must be onboarded to Google Chrome Enterprise Premium - Chrome Browser. Figure 2 depicts the steps that must be performed to onboard the user to Google Chrome Enterprise Premium - Chrome Browser.

Figure 2 - Use Case E2B6 - User Signs into Google Chrome Enterprise Premium

The message flow depicted in Figure 2 consists of the following steps:

1. The user opens Google Enterprise Chrome Enterprise Premium (CEP) - Chrome Browser, clicks on the user icon at the top right, and selects “Turn on sync”.

2. The Google login page opens and requests a username. The user enters their username.

3. The user is redirected to Okta, the organization’s SAML identity provider, for authentication.

4. Okta challenges the user for their first- and second-factor authentication credentials.

5. The user provides their first- and second-factor authentication credentials to Okta.

6. Assuming the user is authenticated successfully, Okta provides a SAML assertion and attributes to the client.

7. Once the user is successfully authenticated, the user is signed in to Google Chrome Browser. Google CEP -Access Context Manager validates device compliance.

Message Flow for User Access to an Enterprise Resource that is Located Either On-Premises or In an IaaS Cloud

Figure 3 depicts the high-level message flow supporting a user who requests access to a resource located either on premises or in an IaaS cloud. Prior to this message flow, the user is assumed to have already signed in to Google Chrome.

Figure 3 - Use Case E2B6 - User Requests Access to a Resource Located either On Premises or in an IaaS Cloud

The message flow depicted in Figure 3 consists of the following steps:

1. A user initiates access to a resource, e.g., GitLab.

2. The endpoint sends a request packet to the resource via the Google Application Connector and then the connector forwards the message to the resource.

3. The resource, which in this case is GitLab, displays the option for the user to sign in with SAML. When the user clicks on the sign-on with SAML icon on the GitLab screen, the resource creates a SAML request and sends the SAML request to the user’s endpoint via the Application Connector.

4. The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is SaaS based.

5. Okta challenges the user for username and password.

6. The user responds with username and password.

7. Okta authenticates the user and verifies the device certificate.

8. Okta challenges the user to perform second-factor authentication using the Okta Verify App.

9. The user provides the second authentication factor (i.e., biometrics).

10. Okta generates a SAML assertion and sends it to the user’s endpoint.

11. The user’s endpoint sends the SAML assertion to the resource (GitLab) via the connector. The resource accepts the assertion and grants the access request.

12. The user accesses the resource based on enterprise policies.

Message Flow for User Access to an Enterprise Resource that is Located in Google Workspace

Figure 4 depicts the high-level message flow supporting a user requesting access to a resource that is located in Google Workspace, which is a SaaS cloud. Prior to this message flow, the user is assumed to have already signed in to Google CEP - Chrome Browser.

Figure 4 Use Case E2B6 - User Requests Access to a Resource Located in Google Workspace

The message flow depicted in Figure 4 consists of the following steps:

1. A user initiates access to a resource in Google Workspace

2. Google Identity creates a SAML request and sends the SAML request to the user’s endpoint.

3. The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is SaaS based.

4. Okta challenges the user for username and password.

5. The user responds with username and password.

6. Okta authenticates the user and verifies the device certificate.

7. Okta challenges the user to perform second-factor authentication using the Okta Verify App.

8. The user provides the second authentication factor (e.g., biometrics).

9. Okta generates a SAML assertion and sends it to the user’s endpoint.

10. The user’s endpoint sends the SAML assertion token to Google Identity. Google Identity accepts the assertion and passes it to Google CEP - Access Context Manager.

11. Google CEP - Access Context Manager postures user’s endpoint

12. The user accesses the Google Workspace resource based on enterprise policies identified by Google CEP - Access Context Manager.