Enterprise 1 Build 4 (E1B4) - SDP - Appgate SDP Controller as PE

Enterprise 1 Build 4 (E1B4) - SDP - Appgate SDP Controller as PE#

Note

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

Technologies#

E1B4 uses products from Amazon Web Services, Appgate, IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zimperium. 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.

E1B4 components consist of Appgate SDP Controller, Appgate SDP Gateway, Appgate SDP client, Appgate Portal, Appgate Injector (Appgate for Kubernetes), Okta Identity Cloud, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Okta Verify App, Ivanti Neurons for Unified Endpoint Management (UEM) Platform, Zimperium Mobile Threat Defense, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable NNM, IBM Cloud Pak for Security, Mandiant Security Validation (MSV), DigiCert CertCentral, and AWS IaaS.

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

Table 1 - E1B4 Products and Technologies

E1B4 Products and Technologies#
Component	Product	Function
PE	Appgate SDP Controller	Decides whether to grant, deny, or revoke access to a resource based on enterprise policy, information from supporting components, and a trust algorithm.
PA	Appgate SDP Controller	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	Appgate SDP Gateway and Appgate SDP Client	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	Ivanti Neurons for Unified Endpoint Management (UEM) Platform	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	Zimperium Mobile Threat Defense	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.
Endpoint Security - Endpoint Compliance	Appgate SDP Client	Can enforce policies based on a defined set of endpoint compliance checks to allow or deny user/endpoint access to a resource, but does not perform the functions of an EPP solution to automatically remediate an endpoint.
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 - SOAR	IBM Cloud Pak for Security	Integrates the SIEM and other security tools into a single pane of glass to support generation of insights into threats and help track, manage, and resolve cybersecurity incidents. Executes predefined incident response workflows to automatically analyze information and orchestrate the operations required to respond.
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.
General - Remote Connectivity	Appgate SDP Controller	Appgate components are used to provide remote users’ connectivity to on-premises or cloud resources.
Resource Protection - PaaS/Kubernetes Security	Appgate Injector	The Appgate Injector (Appgate for Kubernetes) creates a per-pod secure connection to the PEP, enabling authorized service-to-service and service-to-resource communication without the Pod or the resource visible on the Internet.
Resource Protection - Cloud Workload Protection	Appgate Headless Client	The Appgate Headless Client validates security compliance of the protected workload and creates a secure connection to the PEP, enabling authorized service-to-service and service-to-resource communication.
General - Certificate Management	DigiCert CertCentral TLS Manager	Provides automated capabilities to issue, install, inspect, revoke, renew, and otherwise manage TLS certificates.
General - Cloud IaaS	AWS - GitLab, WordPress	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. An IPsec tunnel is used to provide a secure connection from the enterprise to the cloud.
General - Cloud SaaS	DigiCert CertCentral, Ivanti Neurons for UEM, Okta Identity Cloud, Tenable.io, Zimperium MTD	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 using SAML, and IBM Security QRadar XDR pulls logs from GitLab). There are instances of GitLab on-premises and in AWS.
General - Enterprise-Managed Device	Mobile devices (iOS and Android) and desktops/laptops (Windows and Mac)	Example endpoints to be protected. All enterprise-managed mobile devices are running an Ivanti Neurons for UEM agent and also have the Okta Verify App installed. If Ivanti Neurons for UEM agent is used to push Appgate SDP Client to the endpoint, that endpoint is considered to be a managed device.
General - BYOD	Mobile devices (iOS and Android) and desktops/laptops (Windows, Linux and Mac)	Example endpoints to be protected.

Build Architecture#

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

Logical Architecture#

Figure 1 depicts the logical architecture of E1B4. 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, the requesting endpoint, and the resource; 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 E1B4.

E1B4 was designed with Appgate components that serve as PEs, PAs, and PEPs, and Okta Identity Cloud that 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 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 E1B4

This figure depicts the logical architecture of E1B4. 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.

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 E1B4, Okta, 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 E1B4 as they are in E1B1, E1B2, and E1B3. These interactions are described in E1B1 - ICAM Information Architecture.

Physical Architecture#

Enterprise 1 and Enterprise 1 Branch Office describe and depict the physical architecture of E1B4 headquarters network and E1B4 branch office network, respectively.

Message Flows for Successful Resource Access Requests#

This section presents the high-level message flows supporting the use cases in which a subject who has an enterprise ID and who is authorized to access an enterprise resource requests and receives access to that resource. In the cases depicted here, access to the resource is protected by the Appgate SDP System, which is comprised of Controllers that act as PDPs; Gateways that acts as PEPs; and the Appgate SDP Client, which supports endpoint compliance. The Appgate system integrates with Okta, which acts as identity provider (IdP); Ivanti Neurons for UEM, which acts as endpoint manager; and Zimperium Mobile Threat Defense. Two message flows are depicted: one in which the resource being accessed is located on-premises and another in which the resource is in the AWS cloud. For the on-premises case, the Appgate SDP Controller and Gateway are located on-premises. For the AWS case, the Appgate SDP Controller and Gateway are located in the cloud.

Both use cases that are depicted show only the messages that are sent in response to the access request. However, the authentication process also relies on the following additional background communications that occur among components:

The Ivanti Neurons for UEM agent that is running on the user’s endpoint (mobile devices only) periodically syncs with the Ivanti Neurons for UEM Platform in the cloud to reauthenticate the requesting endpoint device using a unique certificate that has been provisioned specifically for that device, and sends the cloud component information about device posture and health (e.g., risk score, threat defense status, iOS version).
Zimperium Mobile Threat Defense is integrated with Ivanti Neurons for UEM, and Zimperium periodically sends threat information to it. When Zimperium detects a threat, it can also block the threat as well as send Ivanti information about the threat.
When a user initiates login with the Appgate Mobile Client, the Appgate SDP Controller queries the Ivanti Neurons for UEM Platform to obtain real-time information regarding device health for the user’s device. The Appgate SDP Client running on the user’s endpoint periodically syncs with the Appgate SDP System to provide information regarding device compliance and dynamically adjusts user and device attributes and authorizations.

To access a resource in both use cases depicted here, the user must log into the Appgate SDP Client that is running on the user’s endpoint. When the user logs into the client, the following steps are performed to initiate operations:

The Appgate SDP Client sends an encrypted Single Packet Authorization (SPA) UDP packet to the Controller to pre-authorize the subsequent TLS connection.
The Appgate SDP Client establishes a TLS connection and authenticates to the Appgate SDP Controller. During this process, the user is redirected to Okta and the SAML assertion is sent to the Controller.
The Appgate SDP Controller issues a signed and encrypted entitlement token to the client that contains user and device attributes, protected resource authorizations, and the hostnames and SPA keys for authorized Appgate Gateways.
The Appgate SDP Client creates a TLS tunnel and passes the signed Entitlement token to an Appgate Gateway that is guarding resources the client is authorized to access. (Note: When there are multiple gateways guarding the same resource, the client chooses one of the gateways based on load balancing information contained in the entitlement token.)
The Appgate Gateway validates the token and creates a session-based microfirewall for the user/device to enforce policies created on the Appgate SDP Controller.

Once an authorized user has logged into the Appgate SDP Client, they may access any resource, either on-premises or in the cloud, that they are authorized to access, with the Gateway in each location acting as the PEP.

Use Case in which Access to a Resource that Is On-Premises Is Enforced by Appgate#

Figure 2 depicts the message flow for the user’s request to access the resource located on-premises. The message flow begins after the user has already successfully logged into the Appgate SDP Client and established tunnels to all authorized Gateways guarding access to protected resources, which, in this case, is the Appgate SDP Gateway that is located on-premises.

Figure 2 - Use Case E1B4 - Access to an On-Premises Resource Is Enforced by Appgate

This figure depicts the message flow for the user's request to access the resource located on-premises.

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

A user initiates access to an on-premises resource, e.g., GitLab.
The endpoint sends a request packet to the resource via this tunnel. The request is sent in the tunnel from the client to the Gateway, and then the Gateway forwards the message to the resource.
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 Appgate Gateway and the tunnel.
The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is located on the internet.
Okta prompts for username and password.
The user responds with username and password.
Okta authenticates the user and verifies the device certificate.
Okta challenges the user to perform second-factor authentication using the Okta Verify App.
The user provides the second authentication factor (i.e., biometrics).
Okta generates a SAML assertion and sends it to the user’s endpoint.
The user’s endpoint sends the SAML assertion to the resource (GitLab) via the tunnel between the Appgate SDP Client and the Appgate SDP Gateway. The resource accepts the assertion and grants the access request.
User traffic to and from the resource is transmitted back and forth through the Appgate tunnel, ensuring it is secured according to policy.

The Appgate SDP Client collects system attributes every five minutes and updates the Appgate SDP Controller to ensure the client conforms with policy.

Note that the message flow depicted in Figure 2 is the same regardless of whether the employee is located on-premises at headquarters, on-premises at a branch office, or off-premises at a remote location.

Use Case in which Access to a Resource in the AWS Cloud is Enforced by Appgate#

Figure 3 depicts the message flow for the user’s request to access the resource located in the AWS cloud. The message flow begins after the user has already successfully logged into the Appgate SDP Client and established tunnels to all authorized Gateways guarding access to protected resources, which, in this case, is the Appgate SDP Gateway that is located in AWS.

Figure 3 - Use Case E1B4 - Access to an AWS Cloud Resource Is Enforced by Appgate

This figure depicts the message flow for the user's request to access the resource located in the AWS cloud.

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

A user initiates access to an AWS cloud resource, e.g., GitLab.
The endpoint sends a request packet to the resource via this tunnel. The request is sent in the tunnel from the client to the Gateway, and then the Gateway forwards the message to the resource.
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 Appgate Gateway and the tunnel.
The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is located on the internet.
Okta prompts for username and password.
The user responds with username and password.
Okta authenticates the user and verifies the device certificate.
Okta challenges the user to perform second-factor authentication using the Okta Verify App.
The user provides the second authentication factor (i.e., biometrics).
Okta generates a SAML assertion and sends it to the user’s endpoint.
The user’s endpoint sends the SAML assertion to the resource (GitLab) via the tunnel between the Appgate SDP Client and the Appgate SDP Gateway. The resource accepts the assertion and grants the access request.
User traffic to and from the resource is transmitted back and forth through the Appgate tunnel, ensuring it is secured according to policy.

The Appgate SDP Client collects system attributes every five minutes and updates the Appgate SDP Controller to ensure the client conforms with policy.

Note that the message flow depicted in Figure 3 is the same regardless of whether the employee is located on-premises at headquarters, on-premises at a branch office, or off-premises at home or elsewhere.

Service-to-Service Use Case in which a request by one service to access another service is controlled by Appgate#

For this use case, the requesting service has an embedded headless client, i.e., a client that does not have a user interface. This headless client must be pre-configured with an identity profile and credentials. Upon boot-up, the headless client immediately tries to sign in to the Appgate SDP Controller (and it will continue retrying if it fails). The steps in the process are depicted in Figure 4 and described below.

Figure 4 - Use Case E1B4 - Server-to-Server Access Enforced by Appgate

This figure shows the steps in the process for the service-to-service use case in which a request by one service to access another service is controlled by Appgate.

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

The headless client sends an encrypted SPA UDP packet to the Controller to pre-authorize the subsequent TLS connection.
The headless client establishes a TLS connection and authenticates to the Appgate SDP Controller.
The Appgate SDP Controller issues a signed entitlement token to the headless client that enables it to access the resources protected by Appgate SDP that it has been authorized to access according to policy created on the Controller.
The headless client will automatically try to establish a secure connection with an Appgate Gateway that is guarding resources that the headless client is authorized to access by passing the signed entitlement token to the Gateway.
The Gateway validates the token and creates a session-based micro-firewall for the headless client to enforce policies created on the Appgate SDP Controller.

Once a session-based micro-firewall for the headless client has been created on an Appgate SDP Gateway at each site (e.g., on-premises and in AWS), the headless client may access any authorized resource, with the Gateway(s) in each location acting as the PEP. If the headless client initiates access to a protected resource it is authorized to access, the Gateway will route the request to the resource. If the headless client initiates access to a protected resource it is not authorized to access, the Gateway’s session-based micro-firewall will drop the network packets.

The headless client is not re-authenticated every time it initiates access to a protected resource. However, the Appgate SDP Headless Client collects system attributes every five minutes and updates the Appgate SDP Controller to ensure the client conforms with policy.