Enterprise 4 Build 5 (E4B5) - SDP and Microsegmentation - AWS Verified Access and Amazon VPC Lattice as PEs

Note

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

Technologies

E4B5 uses products from AWS, IBM, Mandiant, Okta, 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.

E4B5 components consist of AWS Verified Access, Amazon VPC Lattice, Amazon ECS and AWS Lambda Functions, Okta Identity Cloud, Okta Verify App, IBM Security QRadar XDR, Tenable Cloud Security, Mandiant Security Validation (MSV), DigiCert CertCentral, and AWS IaaS.

Table 1 lists all of the technologies used in Build E4B5. It lists the products used to instantiate each ZTA component and the security function that each component provides. The technologies in this table are used to support zero trust access for cloud resources only, not on-premises resources.

This build is focusing on implementing zero trust in AWS IaaS only.

Table 1 - E4B5 Products and Technologies

E4B5 Products and Technologies

Component	Product	Function
PE	AWS Verified Access,	Decides whether to grant, deny, or revoke access to a resource based on enterprise policy, information from supporting components, and a trust algorithm.
	Amazon VPC Lattice
PA	AWS Verified Access,	Executes the PE’s policy decision by sending commands to a PEP that establishes and shuts down the communication path between subject and resource.
	Amazon VPC Lattice
PEP	AWS Verified Access,	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.
	Amazon VPC Lattice
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	Okta Identity Cloud	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	None	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	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; 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 that can integrate with AWS Verified Access are not the collaborators of this project. Therefore, no Endpoint Security was installed in this build.
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 - Network Discovery	Tenable Cloud Security	Discovers, classifies, and assesses the risk posed by cloud components and configurations.
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	AWS Verified Access	Used to provide remote users’ connectivity to cloud 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	AWS	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, Okta Identity Cloud, Tenable Cloud Security	Cloud-based software delivered for use by the enterprise.
General - Application	Amazon ECS and AWS Lambda Functions	Example enterprise resource in AWS to be protected.
General - Enterprise-Managed Device	Desktops/laptops (Windows, Mac and Linux)	Example endpoints to be protected. It uses bowser on any device.
General - BYOD	Desktops/laptops (Windows, Linux and Mac)	Example endpoints to be protected. It uses bowser on any device.

Build Architecture

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

Logical Architecture

Figure 1 depicts the logical architecture of E4B5. 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, as well as 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 E4B5.

E4B5 was designed with AWS Verified Access and Amazon VPC Lattice serving as PE, PA, and PEP, and Okta Identity Cloud serving as the identity, access, and credential manager. 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 Request to Access a Resource that is Located in Amazon AWS IaaS.

Figure 1 - Logical Architecture of E4B5

Physical Architecture

This build is not using on-prem resources and is only focusing on Zero Trust implementation in AWS IaaS.

Figure 2 depicts the physical architecture of the AWS infrastructure that has been set up for use by Enterprise 4. As shown, the NCCoE ZTA lab on premises is connected to AWS via direct connect through NOAA/NWAVE, AWS direct connection and NCCoE’s management account. From NCCoE’s management account’s transit gateway, it connects to AWS ZTA lab’s transit gateway attachment which is then connected to AVA and to user interface VPC consisting of application load balancer and the application storefront. The application storefront is then connected to the checkout service in the checkout VPC via Amazon VPC lattice. Also, the application storefront is connected to the lambda as the orders service through Amazon VPC lattice.

Figure 2 - Physical Architecture of the AWS Infrastructure Used by Enterprise 4

Message Flow for a Request to Access a Resource that is Located in Amazon AWS IaaS

This section depicts the authentication message flow supported by E4B5. In this flow, a subject who is authorized to access a resource in Amazon AWS (IaaS) requests and receives access to that resource. Access to the resource is authenticated and authorized by AWS Verified Access. The user may be accessing the resource from a non-mobile or mobile device. The device’s posture is not being monitored.

---

Figure 3 depicts the high-level message flow supporting a user who requests access to a resource that is located in Amazon AWS IaaS.

Figure 3 - Use Case E4B5 - User Requests Access to an Enterprise Resource in Amazon AWS IaaS

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

1. A user initiates access to an enterprise resource that is located on AWS IaaS. The endpoint sends a request packet to the resource that is intercepted by AVA.

2. AVA redirects the user to send a SAML request to the Okta Identity Cloud.

   Note: AWS partners with EPP vendors to perform compliance checks but they are not CRADA partners of this project. Therefore, compliance checks are out of scope.

3. The user’s endpoint sends the SAML request to the Okta Identity Cloud, which is located on the internet.

4. Okta prompts for username and password.

5. The user responds with username and password.

6. Okta authenticates the user and verifies the device certificate.

7. Okta challenges the user to provide second-factor authentication by using the Okta Verify App.

8. The user provides the second authentication factor (e.g., biometrics).

9. Okta generates a SAML assertion token and sends it to the user’s endpoint.

10. The user’s endpoint sends the SAML assertion to AVA. AVA accepts the assertion and grants the access request.

11. The user accesses the resource based on enterprise policies.