Enterprise 1 Build 2 (E1B2) - EIG Run - Zscaler ZPA Central Authority (CA) as PE Product Guides#
Note
This page is supplementary material for the NIST SP 1800-35 publication.
This section of the practice guide contains detailed instructions for installing, configuring, and integrating all of the products used to implement E1B2. For additional details on E1B2’s logical and physical architectures, please refer to Architecture and Builds.
Zscaler#
Zscaler provides secure user access to public-facing sites and on- or off-premises private applications via the Zscaler Zero Trust Exchange, a cloud-delivered security service edge technology. The Zscaler Internet Access (ZIA) manages user access to the internet. Zscaler Private Access (ZPA) manages user access to applications within an enterprise. Zscaler integrates with Okta for authentication and authorization of users.
To begin, contact Zscaler to create an instance of ZIA and ZPA. To do this, Zscaler will need the FQDN of the enterprise using ZIA and ZPA. Admin user information will need to be provided to Zscaler to create admin accounts. Refer to documents for ZIA and ZPA.
Zscaler ZPA Configuration and Integration#
Once admin access is available, log in to ZPA to perform the following:
Create additional admin accounts as needed.
Create a Zscaler App Connector Group and Zscaler App Connector in the ZPA portal. Note: App Connector Groups are recommended by Zscaler for availability and scaling. Note: This build has two App Connector Groups, one for on-prem applications and one for cloud applications in AWS.
Once the App Connector is configured in the ZPA portal, install the actual Zscaler App connector. Refer to the Zscaler Application Connector section below. Note: This build has two App Connectors, one for on-prem applications and one for cloud applications in AWS.
Create integration with Okta. All users accessing resources within the enterprise will use two-factor authentication when logging into the Zscaler Client Connector. Note: Step 1 of configuration is completed in the Okta cloud. Refer to Okta Identity Cloud. Step 2 of configuration is completed on the ZPA admin portal.
Deploy Zscaler Client Connectors (ZCCs) for various endpoints, including configuring ZCC policies to control the settings and behavior of ZCC. Refer to the Zscaler Client Connector section below.
Set up ZPA Application configuration for access to resources. In this step, applications are defined and applied to segments so that the proper App Connector can perform PEP functions.
Configure Access Policies to control user access to various applications. For our policies, we defined specific App Segments, configured specific IDP authentication parameters, and configured client posture checks.
Configure a log receiver for the IBM QRadar SIEM tool to receive logs for ZPA.
Zscaler ZIA Configuration#
Once admin access is available, log in to ZIA to perform the following:
Create additional admin accounts as needed.
Set up IdP integration with Okta.
Create policies to manage user access to various resources on the internet. For this build, we used many of the defaults built into ZIA. We created policies to allow certain users access to a resource on the internet and to block certain users based on their role and time of day.
Integrate ZIA Nanolog Streaming Service with IBM QRadar SIEM tool to receive ZIA logs.
Zscaler Client Connector#
Zscaler Client Connectors (ZCCs) are available for Windows, macOS, Linux, iOS, and Android endpoints. Deployment of ZCC includes configuring ZCC policies to control the settings and behavior of ZCC. For all these endpoints, a device manager can be leveraged to push the ZCC. For this build, we tested the use of Ivanti to push ZCC to Windows, iOS, and Android endpoints. For other devices we manually installed ZCC. Once ZCC is installed, users are prompted to log in, which allows the user and device to be managed by ZPA and ZIA, depending on the type of resource the user is accessing.
Zscaler Application Connector#
The Zscaler Application Connector is installed and configured on the same subnet where the resource will be protected. For this build, we use the documentation for Linux OS to install the App Connector. Zscaler supports other operating systems. Repeat steps 1 and 2 in the configuration section if an application residing in a different subnet segment needs to be protected. If that application is in the same subnet, then only one App Connector is needed to protect both applications.
Okta Identity Cloud#
For this build, the integration between Okta and Ivanti was disabled in Okta Identity Cloud. Users logging into a resource are authenticated via Okta with a password for the first factor and Okta Verify for the second factor. Use the link for integration with Zscaler to configure Okta.
No changes were made from Build 1 to the Okta Verify App and Okta Access Gateway. Refer to those sections for configuration details.
Radiant Logic RadiantOne#
No changes were made from Build 1. Refer to Radiant Logic RadiantOne.
SailPoint IdentityIQ#
No changes were made from Build 1. Refer to SailPoint IdentityIQ.
Ivanti Neurons for UEM#
No significant changes were made from Build 1. Ivanti Neurons for UEM was configured to deploy the Zscaler Client Connector to managed devices. For information, configuration, and integration instructions, refer to Ivanti Neurons for UEM.
IBM Security QRadar XDR#
For installation, configuration, and integration instructions, refer to IBM Security QRadar XDR.
Tenable.io#
For installation, configuration, and integration instructions, refer to Tenable.io.
Tenable.ad#
For installation, configuration, and integration instructions, refer to Tenable.ad.
Tenable NNM#
For installation, configuration, and integration instructions, refer to Tenable NNM.
Mandiant Security Validation (MSV)#
For installation, configuration, and integration instructions, refer to Mandiant Security Validation (MSV).
DigiCert CertCentral#
For installation, configuration, and integration instructions, refer to DigiCert CertCentral.
AWS IaaS#
Amazon Web Services is a cloud computing platform provided by Amazon that includes a mixture of IaaS, platform as a service (PaaS), and SaaS offerings. The following section describes the setup of AWS IaaS resources to serve as a public/private cloud host.
For details on the logical architecture of the AWS environment, please refer to IaaS - Amazon Web Services (AWS).
Configuration#
The purpose of this subsection is to outline how to set up a cloud infrastructure to provide a platform to host public and private resources which integrate with products from E1B2. AWS CloudFormation templates were used during the build of the AWS IaaS environment but are considered outside of the scope of this document. More information about CloudFormation may be found here.
Create and activate an AWS account. Use the root account to create administrative accounts with rights to create necessary resources for the project.
Create a Production and Management Virtual Private Cloud (VPC). Configure ingress and egress Security Group rules for each VPC.
Create Transit gateways to attach on-prem networks to the AWS environment. Create Internet gateways for access to the internet.
Within the Prod VPC, configure redundant public subnets in different Availability Zones for fault tolerance. Configure redundant private subnets for Web, Application, and Database tiers.
Set up resources for testing in the Prod VPC. For demonstration purposes, a private WordPress and GitLab server pair and a public WordPress server were built. Configure auto scaling and Elastic Load Balancing for servers/services set up on the Web, Application, and Database tiers.
Within the Mgmt VPC, configure redundant public subnets in different Availability Zones for fault tolerance. Configure private subnets for Satellite, Domain Controller, and Security Management Tiers.
Set up AWS Session Manager access for remote admins.
For shared AWS services, configure VPC endpoints with ICAM policies to control access.