Enterprise 2 Build 1 (E2B1) - EIG Crawl - Ping Identity Ping Federate as PE

Note

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

Technologies

E2B1 uses products from Cisco Systems, IBM, Mandiant, Palo Alto Networks, Ping Identity, Radiant Logic, SailPoint, and Tenable. 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.

E2B1 components consist of PingFederate, which is connected to the Ping Identity SaaS offering of PingOne, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Cisco Duo, Palo Alto Networks Next Generation Firewall, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable Nessus Network Monitor (NNM), Mandiant Security Validation (MSV), and DigiCert CertCentral.

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

Table 1 - E2B1 Products and Technologies

E2B1 Products and Technologies

Component	Product	Function
PE	Ping Identity PingFederate	Decides whether to grant, deny, or revoke access to a resource based on enterprise policy, information from supporting components, and a trust algorithm.
PA	Ping Identity PingFederate	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	Ping Identity PingFederate and Cisco Duo	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	Ping Identity PingFederate	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	Ping Identity PingFederate	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	Cisco Duo	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	None	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	None	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	Cisco Duo	Performs device health checks by validating specific tools or services within the endpoint including antivirus, data encryption, intrusion prevention, EPP, and firewall. If the device does not pass the health check, Duo fails second-factor authentication and denies user access.
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.
General - Remote Connectivity	Palo Alto Networks NGFW	Enables authorized remote users to securely access the inside of the enterprise. (Once inside, the ZTA manages the user’s access to resources.)
General - Certificate Management	DigiCert CertCentral TLS Manager	Provides automated capabilities to issue, install, inspect, revoke, renew, and otherwise manage TLS certificates.
General - Cloud IaaS	None	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	Cisco Duo, DigiCert CertCentral Ping Identity PingOne (PingFederate service), and Tenable.io	Cloud-based software delivered for use by the enterprise.
General - Application	GitLab	Example enterprise resource to be protected. (In this build, GitLab and WordPress are integrated with Okta using SAML, and IBM Security QRadar XDR pulls logs from GitLab.)
General - Enterprise-Managed Device	Windows client, macOS client, and mobile devices (iOS and Android)	Example endpoints to be protected.
General - BYOD	Windows client, macOS client, and mobile devices (iOS and Android)	Example endpoints to be protected.

Build Architecture

In this section we present the logical architecture of E2B1 relative to how it instantiates the EIG crawl phase reference architecture depicted in Architecture - Figure 2. We also describe E2B1’s physical architecture and present message flow diagrams for some of its processes.

Logical Architecture

Figure 1 depicts the logical architecture of E2B1. The figure 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 and Architecture - Figure 2. However, Figure 1 includes the specific products that instantiate the architecture of E2B1. Figure 1 also does not depict any of the resource management steps found in Architecture - Figure 1 and Architecture - Figure 2 because the ZTA technologies deployed in E2B1 do not support the ability to perform authentication and reauthentication of the resource or periodic verification of resource health.

E2B1 was designed with a single ICAM system (Ping Identity PingFederate) that serves as the identity, access, and credential manager as well as the ZTA PE and PA. PingFederate also serves as its PEP. Radiant Logic acts as a PIP for the PDP as it responds to inquiries and provides user identity and authentication information on demand in order for Ping Identity PingFederate to make near-real-time access decisions. Cisco Duo provides endpoint protection by monitoring the status and configuration of the endpoint to ensure that its health posture continues to conform with enterprise policy. Duo also provides second-factor user authentication. Note that both multifactor authentication and directory services are also available through Ping, but for purposes of this collaborative build, Ping is demonstrating standards-based interoperability by integrating with Cisco Duo for MFA and Radiant Logic RadiantOne for federated identity services. A more detailed depiction of the messages that flow among components to support a user access request can be found in Message Flow for a Successful Resource Access Request.

Figure 1 - Logical Architecture of E2B1

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 E2B1, Ping, Radiant Logic, and SailPoint integrate with each other as well as with other components of the ZTA to support the ICAM information architecture. Ping Identity PingFederate uses authentication and authorization to manage access to enterprise resources. SailPoint governs and RadiantOne aggregates identity information that is available from many sources within the enterprise. RadiantOne stores, normalizes, and correlates this aggregation of information and extended attributes and provides appropriate views of the information in response to queries. RadiantOne monitors each source of identity truth and updates changes in near real-time to ensure that Ping is able to enforce access based on accurate data. SailPoint is responsible for governance of the identity data. It executes automated, policy-based workflows to manage the lifecycle of user identity information and manage user accounts and permissions, ensuring compliance with requirements and regulations. To perform its identity aggregation and correlation functions, Radiant Logic connects to all locations within the enterprise where identity data exists to create a virtualized central identity data repository. SailPoint may also connect directly to sources of identity data or receive additional normalized identity data from Radiant Logic in order to perform its governance functions.

Use of these three components to support the ICAM information architecture in Enterprise 2 is intended to demonstrate how a large enterprise with a complex identity environment might operate—for example, an enterprise with two ADs and multiple sources of identity information, such as HR platforms, the back-end database of a risk-scoring application, a credential management application, a learning management application, on-premises LDAP and databases, etc. Mimicking a large, complex enterprise enables the project to demonstrate the ability to aggregate identity data from many sources and provide identity managers with a rich set of attributes on which to base access policy. By aggregating risk-scoring and training data with more standard identity profile information found in AD, rich user profiles can be created, enabling enterprise managers to formulate and enforce highly granular access policies. Information from any number of the identity and attribute sources can be used to make authentication and authorization decisions. In addition, such aggregation allows identities for users in a partner organization whose identity information is not in the enterprise AD to be made available to the enterprise identity manager so it has the information required to grant or deny partner user access requests. Policy-based access enforcement is also possible, in which access groups can be dynamically generated based on attribute values.

Although federated identity and identity governance technologies provide automation to ease the burden of aggregating identity information and enforcement of identity governance, they are not required supporting components for implementing a ZTA in situations in which there may only be one or a few sources of identity data.

The subsections below explain the operations of the ICAM information architecture for E2B1 when correlating identity information and when a user joins, changes roles, or leaves the enterprise. The operations depicted support identity correlation, identity management, identity authentication and authorization, and SIEM notification. It is worth noting that both Ping Identity and SailPoint also support additional features that we have not deployed at this time, such as the ability to perform just-in-time provisioning of user accounts and permissions and the ability to remove access permissions or temporarily disable access authorizations from user accounts in response to alerts triggered by suspicious user activity.

Identity Correlation

Figure 2 depicts the ICAM information architecture for E2B1, showing the steps involved in correlating identity information to build a rich global profile that includes not just identity profiles found in AD, but additional profiles and attributes from other platforms as well. The steps are as follows:

1. RadiantOne aggregates, correlates, and normalizes identity information from all sources of identity information in the enterprise. In complex architectures, a ZTA requires an identity data foundation that bridges legacy systems and cloud technologies, and that extends beyond legacy AD domains. In our builds, the identity source used is an example HR database that is augmented by extended user profile and attribute information that is representative of information that could come from a variety of identity sources in a large enterprise. A credential management database, an LDAP database, and a learning management application are some examples of such identity sources. These are depicted in the lower left-hand corner of Figure 2 in the box labeled “Enhanced Identity Data Sources.”

2. The correlated identity profiles in RadiantOne are consumed by SailPoint.

3. SailPoint provisions identities into AD. Multiple AD instances may be present in the enterprise, as depicted. However, each of our builds includes only one AD instance.

4. RadiantOne correlates endpoint identities from AD.

5. SailPoint provisions identities into appropriate enterprise resources—e.g., SaaS, IaaS, enterprise applications, and endpoint protection platforms. (This provisioning may occur directly or via Ping.)

6. As the new identities appear in the SaaS, IaaS, enterprise application, endpoint protection, and other components, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds it back into the global identity profile that it is maintaining. It also updates its HR, authentication, and authorization views to reflect the recent changes. Ping will eventually query these authentication and authorization information views in Radiant Logic to determine whether to grant future user access requests.

   Note that in this architecture, persistent storage of personally identifiable information (PII) is not required within any SaaS service. RadiantOne stores all user identity information, and RadiantOne has been installed on-premises. Ping does not store any user data. When Ping needs user identity data, it looks up this information directly from RadiantOne.

The identity correlation lifecycle is an ongoing process that occurs continuously as events that affect user identity information, accounts, and permissions occur, ensuring that the global identity profile is up to date. Examples of such events are depicted in the subsections below.

Figure 2 - E2B1 ICAM Information Architecture - Identity Correlation

User Joins the Enterprise

Figure 3 depicts the ICAM information architecture for E2B1, showing the steps required to provision a new identity and associated access privileges when a new user is onboarded to the enterprise. The steps are as follows:

1. When a new user joins the enterprise, an authorized HR staff member is assumed to input information into some sort of enterprise employee onboarding and management HR application that will ultimately result in a new, active HR record for the employee appearing in the Radiant Logic human resources record view. In practice, the application that the HR staff member uses will typically store identity records in backend databases like the ones depicted in the lower left-hand corner of Figure 3 that are in the box labeled “Enhanced Identity Data Sources.” As these databases get updated, Radiant Logic is notified, and it responds by collecting the new information and using it to dynamically update its HR view.

2. In the course of performing its governance activities, SailPoint detects the new HR record in Radiant Logic. SailPoint evaluates this new HR record, which triggers a Joiner lifecycle event, causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, and 5.

3. SailPoint provisions access permissions to specific enterprise resources for this new user. These access permissions, known as the user’s Birthright Role Access, are automatically determined according to policy based on factors such as the user’s role, type, group memberships, and status. These permissions comprise the access entitlements that the employee has on day 1. SailPoint creates an account for the new user in AD, thereby provisioning appropriate enterprise resource access for the new user. Also (not labeled in the diagram), Radiant Logic then collects and correlates this user information from AD into the global identity profile that it is maintaining.

4. Assuming there are resources for which access is not managed by AD that the new user is authorized to access according to their Birthright Role, SailPoint also provisions access to these resources for the new user by creating new accounts for the user, as appropriate, on SaaS, IaaS, enterprise application, MDM, EPP, and other components. (This provisioning may occur directly or via Ping.)

5. Once the new identity and its access privileges have been provisioned, SailPoint audits the identity and provisioning actions that were just performed.

6. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint protection, and other components, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds it back into the global identity profile that it is maintaining. It also updates its HR, authentication, and authorization (AuthN/AuthZ) views to reflect the recent changes. Ping will eventually query these authentication and authorization information views in Radiant Logic to determine whether or not to grant future user access requests. (Note that Ping will only query these views in Radiant Logic when a user tries to access a resource; it will not query if there is no action from the user. Also, RadiantOne stores all user identity information; Ping does not store any user data. When Ping needs user identity data, it looks up this information directly from RadiantOne.)

Figure 3 - E2B1 ICAM Information Architecture - New User Onboarding

User Changes Roles

Figure 4 depicts the ICAM information architecture for E2B1, showing the steps required to remove some access privileges and add other access privileges for a user in response to that user changing roles within the enterprise. The steps are as follows:

1. When a user changes roles within the enterprise, an authorized HR staff member is assumed to input information into some sort of enterprise employee management application that will result in the Radiant Logic HR record for that user indicating that the user has changed roles.

2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR record, which triggers a Mover lifecycle event, causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, 5, and 6.

3. SailPoint removes access permissions associated with the user’s prior role (but not with the user’s new role) from the user’s AD account and removes access from other enterprise resources (e.g., SaaS, IaaS, enterprise applications, MDM) that the user had been authorized to access as a result of their prior role but is not authorized to access as a result of their new role. Also (not labeled in the diagram), Radiant Logic then collects and correlates any changes that were made to the user’s account from AD into the global identity profile that it is maintaining.

4. Assuming there are enterprise resources that the user’s new role entitles them to access that are not managed by AD, SailPoint provisions access to these resources for the user by creating new accounts for the user, as appropriate, in SaaS, IaaS, enterprise application, endpoint protection, MDM, and other components. (This provisioning may occur directly or via Ping.)

5. SailPoint generates an access review for management to confirm or revoke the changes that have been made. Such an access review is not strictly necessary. The permission changes could be executed in a fully automated manner, if desired, and specified by policy. However, having an access review provides management with the opportunity to exercise some supervisory discretion to permit the user to temporarily continue to have access to some resources associated with their former role that may still be needed.

6. Once the access review has been completed and any access privilege changes deemed necessary have been performed, SailPoint audits the changes.

7. As the new enterprise accounts appear in the SaaS, IaaS, enterprise application, endpoint protection, and other components, and as existing account access is removed, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds it back into the global identity profile that it is maintaining. It also updates its HR, authentication, and authorization views to reflect the recent changes. Ping will eventually query these authentication and authorization information views in Radiant Logic to determine whether to grant future user access requests. (RadiantOne stores all user identity information; Ping does not store any user data. When Ping needs user identity data, it looks up this information directly from RadiantOne.)

Figure 4 - E2B1 ICAM Information Architecture - User Changes Roles

User Leaves the Enterprise

Figure 5 depicts the ICAM information architecture for E2B1, showing the steps required to disable or delete an identity and remove access privileges in response to a user leaving the enterprise. The steps are as follows:

1. When a user’s employment is terminated, an authorized HR staff member is assumed to input information into some sort of enterprise employee management application that will result in the Radiant Logic HR record for that user indicating that the user has changed from active to inactive status.

2. SailPoint detects this updated HR record in Radiant Logic. SailPoint evaluates this updated HR record, which triggers a Leaver lifecycle event, causing SailPoint to execute a policy-driven workflow that includes steps 3, 4, 5, and 6.

3. SailPoint removes all access permissions associated with the user identity from AD. Also (not labeled in the diagram), Radiant Logic then collects and correlates this user access authorization change from AD into the global identity profile that it is maintaining.

4. SailPoint either disables or deletes all enterprise resource accounts associated with the user identity, as defined by policy, from components such as SaaS, IaaS, enterprise applications, and endpoint protection platforms. (SailPoint may perform these actions directly or via Ping.)

5. SailPoint removes the user identity from all governance groups the identity is in.

6. SailPoint audits the changes made as a result of this user termination.

7. As the enterprise accounts associated with the user’s identity are deleted or disabled, Radiant Logic is notified. Radiant Logic collects, correlates, and virtualizes this new identity information and adds it back into the global identity profile that it is maintaining. It also updates its HR, authentication, and authorization views to reflect the recent changes. Ping will eventually query these authentication and authorization information views in Radiant Logic to determine whether or not to grant future user access requests. (RadiantOne stores all user identity information; Ping does not store any user data. When Ping needs user identity data, it looks up this information directly from RadiantOne.)

Figure 5 - E2B1 ICAM Information Architecture - User Termination

Physical Architecture

Enterprise 2 describes the physical architecture of the E2B1 network.

Message Flow for a Successful Resource Access Request

Below is depicted the high-level message flow supporting the use case in which a subject who has an enterprise ID, who is located on-premises, and who is authorized to access an enterprise resource, requests and receives access to that resource. In the case depicted here, access to the resource is protected by PingFederate, which acts as a PDP and an identity provider; Cisco Duo, which consists of an agent on the endpoint and a cloud component that work together to perform second-factor user authentication and also to gather device health information to ensure device compliance; and Radiant Logic, which performs credential validation for authentication and provides granular user-relevant attributes and groups for authorization at the request of PingFederate.

The message flow depicted in Figure 6 shows 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 on an ongoing basis:

• The Cisco Duo endpoint agent periodically syncs with the Cisco Duo cloud component 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 health (e.g., firewall running, anti-malware software, iOS version).

• Cisco Duo is integrated with PingFederate and periodically sends PingFederate assurance that, based on the device health information collected by Cisco Duo, the device is compliant with configured policy.

Figure 6 depicts the message flow for the user’s request to access the resource.

Figure 6 - Use Case E2B1 - Access Enforced by PingFederate, Cisco Duo, and Radiant Logic

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

1. A user requests to access a resource by typing the resource’s URL into a browser.

2. The resource receives the access request and sends a user authentication request to PingFederate.

3. PingFederate consults the device health information it has received in the background from Cisco Duo verifying that the device has been authenticated and is compliant with policy.

4. PingFederate prompts for username and password.

5. The user responds with username and password.

6. PingFederate sends the user’s username and password to the Ping LDAP Gateway to facilitate communication between the cloud-hosted Ping and the on premises Radiant Logic resources.

7. The LDAP gateway forwards the LDAP authentication request to Radiant Logic.

8. Radiant Logic authenticates that the username exists in the master user record and the provided password (credential) is valid based on credentials stored in Radiant Logic or in another source of identity credentials federated by Radiant Logic.

9. Radiant Logic replies to the LDAP gateway with a valid BIND indicating a successful user authentication and all additional user attributes requested by Ping at the time of Authentication

10. The LDAP gateway forwards the response from Radiant Logic to PingFederate with the successful BIND and applicable user’s attributes.

11. PingFederate requests Cisco Duo to perform second-factor user authentication.

12. Cisco Duo challenges the user to provide the second authentication factor.

13. The user responds with the second authentication factor.

14. Cisco Duo responds to PingFederate, indicating that the user authenticated successfully.

15. PingFederate sends a SAML assertion token to the resource. The resource accepts the assertion and grants the access request.

16. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).

Note that the message flow depicted in Figure 6 applies to several of the use cases we are considering. It applies to all cases in which a user with an enterprise ID who can successfully authenticate themselves and who is using an enterprise-owned endpoint requests and receives access to an enterprise resource that they are authorized to access. The message flow 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. It is also the same regardless of whether the resource is located on-premises or in the cloud.