Enterprise 3 Build 1 (E3B1) - EIG Crawl - Azure AD Conditional Access (later renamed Entra Conditional Access) as PE#
Note
This page is supplementary material for the NIST SP 1800-35 publication.
Technologies#
E3B1 uses products from F5, Forescout, Lookout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, 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.
E3B1 components consist of Microsoft Azure AD, Microsoft AD, F5 BIG-IP, Microsoft Intune, Microsoft Defender for Endpoint, Lookout MES, PC Matic Pro, Microsoft Sentinel, Tenable.io, Tenable.ad, Mandiant Security Validation, Forescout eyeSight, Palo Alto Networks NGFW, and DigiCert CertCentral. (Note that after this build was completed, the name Azure AD was changed to Entra ID. This appendix uses the original name of Microsoft Azure AD.)
Table 1 lists all of the technologies used in E3B1 ZTA. It lists the products used to instantiate each ZTA component and the security function that the component provides.
Table 1 - E3B1 Products and Technologies
Component |
Product |
Function |
---|---|---|
PE |
Microsoft Azure AD (Conditional Access), Microsoft Intune |
Decides whether to grant, deny, or revoke access to a resource based on enterprise policy, information from supporting components, and a trust algorithm. |
PA |
Microsoft Azure AD (Conditional Access), Microsoft Intune |
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 |
Microsoft Azure AD (Conditional Access), Microsoft Defender for Endpoint, Microsfot Intune, F5 BIG-IP, and Lookout MES |
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 |
Microsoft AD and Azure AD |
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 |
Microsoft AD and Azure AD |
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 |
Microsoft AD and Azure AD |
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 |
Microsoft AD and Azure AD |
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 |
Azure AD (Multifactor Authentication) |
Authenticates 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 |
Microsoft Intune |
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 |
Microsoft Defender for Endpoint, Lookout MES, PC Matic Pro |
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 |
Microsoft Sentinel |
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 and Forescout eyeSight |
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 - 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. Mandiant Security Validation is 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. |
Security Analytics - Traffic Inspection |
Forescout eyeSight |
Intercepts, examines, and records relevant traffic transmitted on the network. |
Security Analytics - Network Discovery |
Forescout eyeSight |
Discovers, classifies, and assesses the risk posed by devices and users on the network. |
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 users’ 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 |
Azure |
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, Lookout MES, Microsoft Azure AD, Microsoft Defender for Endpoint, Microsoft Intune, Microsoft 365, Microsoft Sentinel, 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 is integrated directly with Azure AD using SAML, and Microsoft Sentinel pulls logs from GitLab.) |
General - Application |
Guacamole |
Example enterprise resource to be protected. (In this build, BIG-IP serves as an identity-aware proxy that protects access to Guacamole, and BIG-IP is integrated with Azure AD using SAML. Also, Microsoft Sentinel pulls logs from Guacamole.) |
General - Enterprise-Managed Device |
Windows client, macOS client, and mobile devices (iOS and Android) |
Example endpoints to be protected. (In this build, all enterprise-managed devices are enrolled into Microsoft Intune.) |
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 E3B1 relative to how it instantiates the crawl phase EIG reference architecture depicted in Architecture - Figure 2. We also describe E3B1’s physical architecture and present message flow diagrams for some of its processes.
Logical Architecture#
Figure 1 depicts the logical architecture of E3B1. Figure 1 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), 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, while Architecture - Figure 2 depicts generic crawl phase ZTA components, Figure 1 includes the specific products that instantiate the architecture of E3B1. 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 E3B1 do not support the ability to perform authentication and reauthentication of the resource or periodic verification of resource health.
E3B1 was designed with a single ICAM system (Microsoft Azure AD) that serves as identity, access, and credential manager and also serves as the ZTA PE and PA. Microsoft Intune also serves as the ZTA PE and PA. It includes five PEPs: Microsoft Azure AD, Microsoft Defender for Endpoint, Microsoft Intune, F5 BIG-IP, and Lookout MES. A more detailed depiction of the messages that flow among components to support user access requests in the two different cases when the resource is being protected by the Azure AD PEP versus the F5 BIG-IP PEP can be found in Use Case in which Resource Access Is Enforced by Azure AD and Use Case in which Resource Access Is Enforced by an F5 BIG-IP PEP.
Figure 1 - Logical Architecture of E3B1
Physical Architecture#
Enterprise 3 describes the physical architecture of the E3B1 network.
Message Flows for a Successful Resource Access Request#
This section depicts two high-level message flows, both of which support the use case in which a subject who has an enterprise ID, is located on-premises, and is authorized to access an enterprise resource, requests and receives access to that resource.
The two message flows that are supported by Enterprise 3 for this use case depend on whether the resource being accessed is protected by Azure AD alone (see Use Case in which Resource Access Is Enforced by Azure AD) or by Azure AD in conjunction with the F5 BIG-IP PEP (see Use Case in which Resource Access Is Enforced by an F5 BIG-IP PEP).
Regardless of which components are being used to protect the resource, all endpoints are enrolled into Microsoft Intune, which is an MDM (and a UEM) that can configure and manage devices and can also retrieve and report on device security settings that can be used to determine compliance, such as whether the device is running a firewall or anti-malware. Non-Windows devices have an MDM agent installed on them to enable them to report compliance information to Microsoft Intune, but Windows devices do not require a separate agent because Windows has built-in agents that are designed to communicate with Intune. Intune-enrolled devices check in with Intune periodically, allowing it to authenticate the requesting endpoint, determine how the endpoint is configured, modify certain configurations, and collect much of the information it needs to determine whether the endpoint is compliant. Intune reports the device compliance information that it collects to Azure AD, which will not permit a device to access any resources unless it is compliant.
For demonstration purposes, one of the criteria that devices are expected to meet to be considered compliant in our example implementation is that they must have antivirus software updated and running. In both scenarios below, some requesting endpoints have Microsoft Defender Antivirus running on them and other requesting endpoints have PC Matic Pro (also antivirus software) running; no endpoints have both turned on. If a device is running Microsoft Defender Antivirus, the Intune MDM can sense this and report it to Azure AD. If a device is running PC Matic Pro, however, the device is configured to notify Windows Security Center that the endpoint has antivirus software installed, and the Security Center provides this information to Azure AD.
The authentication message flows depicted below 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 on an ongoing basis:
Microsoft AD periodically synchronizes with Azure AD to provide it with the most up-to-date identity information.
Intune-enrolled devices check in with Intune periodically. Checking in allows Intune to determine how the endpoint is configured and modify certain configurations that have been previously specified. It also allows Intune to report the compliance of the device to Azure AD.
Microsoft Defender for Endpoint has both a cloud component and built-in sensors that detect threat signals from Windows endpoints. So not only can it tell that a firewall is disabled or antivirus is off, but it can tell when certain malicious signals seen elsewhere have also been observed on your endpoint. It periodically reports this information to its cloud/management component, which uses it for risk determination. This information can be passed off to Intune to include in its compliance determination of an endpoint.
Microsoft Defender Antivirus (an endpoint agent) periodically syncs with Microsoft Intune and Microsoft Defender for Endpoint.
Microsoft Intune periodically sends device health information to Azure AD so that it can be sure that the device is managed and compliant.
PC Matic periodically syncs with Windows Security Center to inform it that that the endpoint has antivirus installed and active.
Windows Security Center periodically syncs with Azure AD to provide it with endpoint status information, e.g., that endpoints have antivirus installed.
Use Case in which Resource Access Is Enforced by Azure AD#
Figure 2 depicts the message flow for the case in which access to the resource is protected by Azure AD (with the Conditional Access feature), which acts as a PDP; and Microsoft AD, which provides identity information.
Figure 2 - Use Case E3B1 - Access Enforced by Azure AD
The message flow depicted in Figure 2 consists of the following steps:
A user requests access to a resource.
The resource sends the authentication request to Azure AD.
Azure AD prompts for username and password.
The user responds with username and password.
Azure AD authenticates the user. Azure AD consults the information about the device that it has received in the background from Microsoft Intune and Defender for Endpoint to authenticate the device and verify that it is managed and meets compliance requirements. If the device has PC Matic running on it, Azure AD also consults information about the device that it has received in the background from Windows Security Center to verify that the device is running antivirus software.
Azure AD challenges the user to provide the second authentication factor.
The user responds with the second authentication factor.
Azure AD sends a SAML assertion to the resource.
The resource accepts the assertion and grants the access request. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).
Use Case in which Resource Access Is Enforced by an F5 BIG-IP PEP#
Figure 3 depicts the message flow for the case in which access to the resource is protected by F5 BIG-IP, which acts as an identity-aware proxy PEP; Microsoft Azure AD, which acts as an ICAM provider and PDP; and Microsoft AD, which provides identity information.
Figure 3 - Use Case E3B1 - Access Enforced by F5 BIG-IP
The message flow depicted in Figure 3 consists of the following steps:
A user requests access to a resource.
BIG-IP, which is acting as an identity-aware proxy PEP that sits in front of the resource, intercepts and forwards the request to Azure AD.
Azure AD prompts for username and password.
The user responds with username and password.
Azure AD authenticates the user. Azure AD consults the information about the device that it has received in the background from Microsoft Intune and Defender for Endpoint to authenticate the device and verify that it is managed and meets compliance requirements. If the device has PC Matic running on it, Azure AD also consults information about the device that it has received in the background from Windows Security Center to verify that the device is running antivirus software.
Azure AD challenges the user to provide the second authentication factor.
The user responds with the second authentication factor.
Azure AD sends a SAML assertion to BIG-IP which serves as an identity-aware proxy, service provider, and the PEP protecting the resource.
BIG-IP accepts the SAML assertion and permits the access request to proceed to the resource. User traffic to and from the resource is secured according to policy (e.g., using TLS or HTTPS).