Enterprise 3 Build 5 (E3B5) - SDP and SASE - Microsoft Entra Conditional Access (formerly called Azure AD Conditional Access) and Microsoft Security Service Edge as PEs

Note

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

Technologies

E3B5 uses products from Mandiant, Microsoft, 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.

E3B5 components consist of Microsoft Entra Conditional Access, Microsoft Security Service Edge (SSE) (which includes Entra Private Access, Entra Internet Access, and Microsoft 365 Access), Microsoft Entra Private Access Connector, Microsoft Entra ID, Microsoft Entra ID Governance, Microsoft Intune, Microsoft Defender for Endpoint, Microsoft Global Secure Access Client, Microsoft Purview DLP, Microsoft Purview Information Protection, Microsoft Purview Information Protection Scanner, Microsoft Entra ID Identity Protection, Microsoft Defender for Identity, Microsoft Defender for Cloud, Microsoft Sentinel, Tenable.io, Tenable.ad, Mandiant Security Validation, Microsoft Azure (IaaS), Microsoft 365 (SaaS), and DigiCert CertCentral. (Note that Microsoft Entra ID was formerly named Microsoft Azure AD.)

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

Table 1 - E3B5 Products and Technologies

E3B5 Products and Technologies

Component	Product	Function
PE	Microsoft Entra Conditional Access (formerly Microsoft Azure AD Conditional Access), Microsoft Defender for Cloud, Microsoft Intune, Microsoft Security Service Edge (SSE), Microsoft Sentinel	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 Entra Conditional Access, Microsoft Defender for Cloud, Microsoft Intune, Microsoft SSE, Microsoft Sentinel	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 Entra Conditional Access, Microsoft Defender for Endpoint, Microsoft Intune, Microsoft SSE	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 Entra ID	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 Entra ID	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 Entra ID	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 Entra ID Governance	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	Microsoft Entra ID	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; 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	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 - EPP	Microsoft Global Secure Access Client	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 - SOAR	Microsoft Sentinel	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 - Identity Monitoring	Microsoft Entra Identity Protection	Monitors the identity of subjects to detect and send alerts for indicators that user accounts or credentials may be compromised, or to detect sign-in risks for a particular access session.
Security Analytics - User Behavior Analytics	Microsoft Defender for Identity	Monitors and analyzes user behavior to detect unusual patterns or anomalies that might indicate an attack.
Security Analytics - Security Monitoring	Microsoft Defender for Identity	Monitors and detects malicious or suspicious user actions based on on-premises AD signals.
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	Microsoft Defender for Cloud, 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. Enable 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 - Security Analytics and Access Monitoring	Microsoft SSE	Monitors cloud resource access sessions for conformance to policy.
Data Security - Data Discovery, Classification, Labeling, Access Protection, and Auditing and Compliance	Microsoft Purview DLP, Microsoft Purview Information Protection, and Microsoft Purview Information Protection Scanner	Discovers, classifies, and labels sensitive business-critical data in the cloud and on-premises, and provides protection by preventing unauthorized access and minimizing the risk of data theft and data leaks using security policy rules.
General - Remote Connectivity	Microsoft SSE	Enables authorized remote users to securely access the inside of the enterprise.
Resource Protection - Cloud Workload Protection	Microsoft Defender for Cloud	Secures cloud workloads to protect them from known security risks and provides alerts to enable real-time reaction to prevent security events from developing. Monitors traffic to and from cloud and web applications and provides session control to prevent sensitive information from leaving.
Resource Protection - Cloud Security Posture Management	Microsoft Defender for Cloud	Continually assesses the security posture of cloud resources.
Resource Protection - Application Connector	Entra Private Access 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	Azure GitLab and 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.
General - Cloud SaaS	DigiCert CertCentral, Microsoft Entra ID, Microsoft Defender for Endpoint, Microsoft Defender for Cloud, Microsoft Entra ID Governance, 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 Entra ID using SAML, and Microsoft Sentinel pulls logs from GitLab.)
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 E3B5. We also describe E3B5’s physical architecture and present message flow diagrams for some of its processes.

Logical Architecture

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

E3B5 was designed with Microsoft Entra Conditional Access, Microsoft Defender for Cloud, Microsoft Intune, Microsoft SSE, and Microsoft Sentinel as the ZTA PEs and PAs and Microsoft Entra ID providing ICAM support. It includes four PEPs: Microsoft Entra Conditional Access, Microsoft Defender for Endpoint, Microsoft Intune, and Microsoft SSE. A more detailed depiction of the messages that flow among components to support user access requests in the case in which a new endpoint is detected on the network and checked for compliance can be found in Message Flows for a Successful Resource Access Request.

Figure 1 - Logical Architecture of E3B5

Physical Architecture

Enterprise 3 describes the physical architecture of the E3B5 network.

Message Flows for a Successful Resource Access Request

This section presents three high-level message flows in which Microsoft Entra ID and Microsoft Entra SSE determine and enforce whether a user will be granted access to a requested resource. The user’s endpoint is running Microsoft Global Secure Access (GSA) Client. The first flow depicts the case in which an authenticated, authorized user requests access to a private resource. The second case depicts a user requesting access to an internet resource that they are permitted by policy to access, and the third case depicts a user requesting access to a Microsoft SaaS services resource that they are permitted by policy to access.

Use Case in which Access to a Private Resource is Requested

Figure 2 depicts the message flow for the use case in which a user requests and receives access to a private resource.

Figure 2 - Use Case E3B5 - User Requests and Receives Access to a Private Resource

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

1. A user attempts to navigate to a private resource. The GSA Client on the user’s endpoint intercepts the first IP packet, consults its traffic acquisition policy, and determines that the packet should be acquired. The GSA Client queues the packet until it determines that a tunnel has been established.

   The GSA Client checks if there is already an outer tunnel instance. If not, it reaches out to the Tunneling Client to create the outer tunnel instance. Entra SSE forces Entra ID user authentication to create an authenticated tunnel.

2. The GSA Client forces the user to authenticate to Entra ID. The user authenticates with Entra ID, providing both first and second authentication factors. Assuming the authentication is successful, Entra ID sends an access token for Entra Private Access to the GSA Client.

3. The user attempts to navigate to the private resource, but the GSA Client recognizes that this is part of the traffic profile to be captured and sends this request to the Entra SSE instead, inside the tunnel created earlier.

4. The GSA Client validates with Entra ID that the user has been assigned to the private resource and enforces any conditional access policies that apply to the private resource.

5. Entra ID sends the GSA Client an access token for the user to access the private resource.

6. The GSA Client sends this access token to Entra SSE.

7. Entra SSE forwards the access token to the private resource via the connector.

8. The private resource responds via the connector, and the response is forwarded to Entra SSE.

9. Entra SSE forwards the response to the GSA Client. Subsequent traffic on the access session continues to flow on the authenticated tunnel between the GSA Client and Entra SSE and then to the private resource via the Entra Private Access Connector. Throughout this communication session, Entra SSE Private Access Service enforces any conditional access policies that apply to this private resource access session.

Use Case in which Access to an Internet Resource is Requested

Figure 3 depicts the message flow for the use case in which a user requests and receives access to an internet resource.

Figure 3 - Use Case E3B5 - User Requests and Receives Access to an Internet Resource

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

1. A user attempts to navigate to an internet resource. The GSA Client on the user’s endpoint intercepts the first IP packet, consults its traffic acquisition policy, and determines that the packet should be acquired. The GSA Client queues the packet until it determines that a tunnel has been established. The GSA Client checks if there is already an outer tunnel instance. If not, it reaches out to the Tunneling Client to create the outer tunnel instance.

2. The GSA client forces the user to authenticate to Entra ID. The user authenticates with Entra ID, providing both first and second authentication factors. Assuming the authentication is successful, Entra ID sends an access token for internet Access to the GSA client.

3. The queued packet is now sent inside the tunnel that was created earlier to the Microsoft Entra SSE Internet Access Service.

4. Microsoft Entra SSE Internet Access Service determines with Entra ID the user (or group) and enforces any conditional access policies that apply to the conditional access security profile.

5. Entra ID sends the GSA client an access token with an identifier that indicates the conditional access policy and security profile to be applied to the access session.

6. GSA Client sends encapsulated data destined for the Internet location with the access token for the matching security profile(s) to Entra SSE.

7. If the traffic is matched to a policy rule (first match wins), traffic is forwarded to the internet destination.

8. The internet destination responds to Entra SSE.

9. Entra SSE forwards the response to the GSA Client. Subsequent traffic on the access session continues to flow on the tunnel between the GSA Client and Entra SSE and then to the internet destination. Throughout this communication session, Entra SSE Internet Access Service enforces any conditional access policies that apply to this internet access session.

Use Case in which Access to a Microsoft SaaS Service Resource is Requested

Figure 4 depicts the message flow for the use case in which a user requests and receives access to a Microsoft SaaS Service resource.

Figure 4 - Use Case E3B5 - User Requests and Receives Access to a Microsoft SaaS Service Resource

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

1. An M365 client app or an Entra ID aware native client app is requesting a new token using the Microsoft Authentication Library.

2. The GSA Client intercepts the first IP packet for the M365 destination and determines if the packet is to be acquired based on its traffic acquisition policy, which in this case is the Microsoft 365 traffic profile, and queues the packet until the tunnel is established.

   1. The GSA Client checks if any outer tunnel instance is present. If not, it reaches out to the Tunneling Client to create the outer tunnel instance.

   2. The Entra SSE service forces Entra ID user authentication to create an authenticated tunnel.

   3. The GSA Client initiates an Entra ID authentication, and Entra ID provides the access token to the GSA Client. The GSA Client stores it locally.

3. The queued packet is now sent inside the tunnel that was created earlier to the Microsoft SSE Internet Access service.

   1. Entra ID enforces any Conditional Access policies that apply to the Conditional Access Control targeting the Microsoft 365 traffic profile under Target resource or other Conditional Access policy controls such as Compliant Network with Microsoft’s SSE Internet Access Service.

4. Entra ID returns an M365 access token or rejects the request to the M365 app, depending on policy. In this case, Entra ID returns an M365 access token via Microsoft SSE Internet Access and the GSA Client.

5. The M365 app sends the request to the M365 service, such as SharePoint online, via the GSA Client and the Microsoft SSE Internet Access service.

6. The respective M365 service endpoint (e.g., SharePoint Online) will respond to the M365 app via the Microsoft SSE Internet Access service and the GSA Client.