Enterprise 2 Build 4 (E2B4) - SDP and SASE - Symantec Cloud Secure Web Gateway, Symantec ZTNA, and Symantec Cloud Access Security Broker as PEs#
Note
This page is supplementary material for the NIST SP 1800-35 publication.
Technologies#
E2B4 uses products from Google Cloud, IBM, Mandiant, Okta, Radiant Logic, SailPoint, Symantec by Broadcom, Tenable, and VMware. Certificates from DigiCert are also used. For more information on these collaborators and the products and technologies that they contributed to this project overall, see Collaborators and Their Contributions.
E2B4 components consist of Symantec Cloud Secure Web Gateway (Cloud SWG), Symantec Zero Trust Network Access (ZTNA), Symantec Cloud Access Security Broker (CASB), Symantec Endpoint Security Agent, VMware Workspace ONE UEM, Symantec DLP Cloud Detection Service, Symantec ZTNA Connector, 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, and DigiCert CertCentral.
Table 1 lists all of the technologies used in Build E2B4. It lists the products used to instantiate each ZTA component and the security function that each component provides.
Table 1 - E2B4 Products and Technologies
Component |
Product |
Function |
---|---|---|
PE |
Symantec Cloud SWG, Symantec ZTNA, Symantec CASB |
Decides whether to grant, deny, or revoke access to a resource based on enterprise policy, information from supporting components, and a trust algorithm. |
PA |
Symantec Cloud SWG, Symantec ZTNA, Symantec CASB |
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 |
Symantec Cloud SWG, Symantec ZTNA, Symantec CASB |
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. |
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 |
VMware Workspace ONE UEM |
Manages and secures enterprise desktop computers, laptops, and/or mobile devices in accordance with enterprise policy to protect applications and data; ensure device compliance; mitigate and remediate vulnerabilities and threats; monitor for suspicious activity to prevent and detect intrusions; prevent, detect, and disable malware and other malicious or unauthorized traffic; repair infected files when possible; provide alerts and recommend remediation actions; and encrypt 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 - EPP |
Symantec Endpoint Security Agent |
Detects and stops threats to endpoints through an integrated suite of endpoint protection technologies including antivirus, data encryption, intrusion prevention, EDR, and DLP. May include mechanisms that are designed to protect applications and data; ensure device compliance with policies regarding hardware, firmware, software, and configuration; monitor endpoints for vulnerabilities, suspicious activity, intrusion, infection, and malware; block unauthorized traffic; disable malware and repair infections; manage and administer software and updates; monitor behavior and critical data; and enable endpoints to be tracked, troubleshooted, and wiped, if necessary. |
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 |
Symantec DLP Cloud Detection Service |
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 |
Symantec ZTNA |
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 |
Symantec ZTNA 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. A connector enables access to a resource to be controlled 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 |
DigiCert CertCentral, Okta Identity Cloud, Symantec Cloud SWG, Symantec ZTNA, Symantec CASB, Tenable.io, and VMware Workspace ONE |
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 E2B4. We also describe E2B4’s physical architecture and present message flow diagrams for some of its processes.
Logical Architecture#
Figure 1 depicts the logical architecture of E2B4. 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 E2B4. Figure 1 also does not depict any of the resource management steps found in Architecture - Figure 1 because the ZTA technologies deployed in E2B4 do not support the ability to perform authentication and reauthentication of the resource or periodic verification of resource health.
E2B4 was designed with Symantec by Broadcom components that serve as PEs, PAs, and 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 E2B4
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 E2B4, 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 E2B4 as they are in E1B1, E1B2, E1B3, and E1B4. These interactions are described in E1B1 - ICAM Information Architecture.
Physical Architecture#
Enterprise 2 describes the physical architecture of the E2B4 network.
Message Flows for Successful Resource Access Requests#
This section depicts several authentication message flows supported by E2B4. In each flow, a subject who is authorized to access a resource requests and receives access to that resource. Access to the resource is authenticated and authorized by various Symantec by Broadcom components that act as PDPs and PEPs. The scenarios differ according to whether or not the requesting user’s device has a Symantec Endpoint Security Agent running on it, and whether the resource is an enterprise resource (i.e., located on-premises or in a private IaaS cloud) or on the public internet.
Message Flow for Symantec Endpoint Security Agent Initialization and an Identity Aware Tunnel Establishment#
If the requesting user’s device has the Symantec Endpoint Security Agent running on it, then the agent must be initialized and the user must log into it. Once successfully logged in, an identity-aware tunnel will be established between the agent and the Symantec Cloud SWG that secures all of their subsequent communications. In addition, the Symantec Endpoint Security Agent will continually evaluate the compliance of the endpoint and provide ongoing updates to the SWG via the tunnel, thereby keeping the SWG informed of the device’s compliance status.
Figure 2 depicts the high-level message flow supporting Symantec Endpoint Security Agent initialization and establishment of the identity-aware tunnel. In all scenarios in which the requesting user’s device has a Symantec Endpoint Security Agent installed, initialization of the agent and establishment of the tunnel are the first things that happen.
Figure 2 - Use Case E2B4 - Symantec Endpoint Security Agent Initialization and Identity Aware Tunnel Establishment
The message flow depicted in Figure 2 consists of the following steps:
The Symantec Endpoint Security Agent sends a message to the Symantec Cloud SWG requesting the organizational configuration.
The Symantec Cloud SWG provides the agent with the configuration.
The Symantec Endpoint Security Agent sends a SAML request to Okta, the IdP for this build.
Okta challenges the user for authentication credentials (i.e., username and password).
The user responds with their credentials.
Assuming the user was able to be authenticated, Okta provides the Symantec Endpoint Security Agent with a SAML assertion.
The identity-aware tunnel is established between the Symantec Endpoint Security Agent and the Symantec Cloud SWG.
On an ongoing basis, the Symantec Endpoint Security Agent evaluates the compliance of the user’s device.
The Symantec Endpoint Security Agent periodically sends updates on the device’s compliance status to the Symantec Cloud SWG via the tunnel.
Message Flow for a User with a Symantec Endpoint Security Agent-Equipped Endpoint Requesting Access to an Enterprise Resource#
Figure 3 depicts the high-level message flow supporting a user who has a Symantec Endpoint Security Agent-equipped endpoint and requests access to an enterprise resource. The enterprise resource may be located either on-premises or in a private IaaS cloud.
Figure 3 - Use Case E2B4 - User with a Symantec Endpoint Security Agent-Equipped Device Accesses an Enterprise Resource
The message flow depicted in Figure 3 consists of the following steps:
As explained earlier, before the user can access the resource, the Symantec Endpoint Security Agent on the user’s device must be initialized, and it must establish an identity-aware tunnel with the Symantec Cloud SWG. The message flow that accomplishes this is described in Message Flow for Symantec Endpoint Security Agent Initialization and an Identity Aware Tunnel Establishment.
The user requests access to an enterprise resource. This request is sent over the secure identity-aware tunnel to the Symantec Cloud SWG.
The Symantec Cloud SWG forwards the user’s access request to the Symantec ZTNA Controller.
The Symantec ZTNA Controller forwards the request to the site-specific ZTNA connector, i.e., the connector for the resource to which access is being requested. The choice of connector will depend on the location of the resource—e.g., whether it is on-premises or in the cloud, and what subnetwork it is on.
The ZTNA connector queries the private DNS for the resource’s IP address.
DNS provides the IP address of the resource to the user’s device.
The user’s device sends the Symantec ZTNA Controller a request to establish an access tunnel to the resource.
The ZTNA Controller evaluates this access tunnel request against organizational policy to determine if it is authorized.
Assuming the access tunnel request is permissible by policy, the Symantec ZTNA Controller sends the approved access tunnel request to the ZTNA Connector for the resource (again, the ZTNA Connector selected will depend on where the resource is located—on-premises or in a private IaaS cloud, and what subnetwork the resource is on if there are multiple connectors at that location).
The ZTNA Connector establishes a tunnel to the resource.
Access is established from the user’s endpoint to the resource.
The user attempts to log into the resource (e.g., the GitLab application).
The resource redirects the user’s access request to the organization’s IdP, Okta, via SSO. Okta challenges the user for their first- and second-factor authentication credentials.
The user provides their first- and second-factor authentication credentials to Okta.
Assuming the user is authenticated successfully, Okta provides a SAML assertion to the user.
The user sends the SAML assertion to the resource. The resource accepts the assertion and grants the access request.
A session between the user and the resource is established. User traffic to and from the resource is secured according to policy.
Message Flow for a User Requesting Access to an Enterprise Resource from a Web Browser#
Figure 4 depicts the high-level message flow supporting a user who requests access to an enterprise resource from a web browser. The enterprise resource may be located either on-premises or in a private IaaS cloud.
Figure 4 - Use Case E2B4 - User Requesting Access to an Enterprise Resource from a Web Browser
The message flow depicted in Figure 4 consists of the following steps:
The user requests access to an enterprise resource. The user makes this request by typing the URL for the enterprise resource into their browser.
The user’s browser sends a request to the Global DNS to get the IP address of the enterprise resource.
The DNS resolves the address request to the Symantec ZTNA Controller.
The Symantec ZTNA Controller redirects the user to Okta, the organization’s IdP, which challenges the user for their first- and second-factor authentication credentials.
The user provides their first- and second-factor authentication credentials to Okta.
Assuming the user is authenticated successfully, Okta provides a SAML assertion to the user.
The user sends the SAML assertion to the Symantec ZTNA Controller.
The ZTNA Controller evaluates the SAML assertion in light of the organization’s access policy and the device’s compliance status.
Assuming the access request is permissible by policy, the Symantec ZTNA Controller forwards the approved request to the site-specific ZTNA Connector. (The ZTNA Connector selected will depend on where the resource is located—on-premises or in a private IaaS cloud, and what subnetwork the resource is on if there are multiple connectors at that location.)
The ZTNA Connector establishes a tunnel to the resource.
A session between the user and the resource is established. User traffic to and from the resource is secured according to policy, and the session is evaluated on an ongoing basis to ensure that it continues to be permitted according to organizational policy.
Message Flow for a User with a Symantec Endpoint Security Agent-equipped Endpoint Requesting Access to a Public Internet Resource#
Figure 5 depicts the high-level message flow supporting a user who has a Symantec Endpoint Security Agent-equipped endpoint and requests access to a public internet resource.
Figure 5 - Use Case E2B4 - User with a Symantec Endpoint Security Agent-Equipped Device Accesses a Public Internet Resource
The message flow depicted in Figure 5 consists of the following steps:
As explained earlier, before the user can access the resource, the Symantec Endpoint Security Agent on the user’s device must be initialized, and it must establish an identity-aware tunnel with the Symantec Cloud SWG. The message flow that accomplishes this is described in Message Flow for Symantec Endpoint Security Agent Initialization and an Identity Aware Tunnel Establishment.
The user requests access to a public internet resource by providing the resource’s URL. This request is sent over the secure identity-aware tunnel to the Symantec Cloud SWG.
The Symantec Cloud SWG’s policy engine evaluates this access request against organizational policy and risk protection engines.
Assuming the requested access has been determined to be permissible, the request is forwarded onto the internet.
A web session between the user and the public internet resource is established, with all communications flowing to and from the user’s device via the tunnel that was established between the device and the Symantec Cloud SWG. Throughout the web session, the Symantec Cloud SWG performs ongoing policy-based evaluation of the session to ensure that it continues to be permissible.