Integrating AWS Verified Access with device trust providers

In this post, we discuss how to architect Zero Trust based remote connectivity on AWS. Specifically, we will be exploring how to integrate Verified Access with CrowdStrike, a device trust provider. This solution builds upon the Okta-based identity provider integration previously published in this AWS post.

Zero Trust is a conceptual model, and an associated set of mechanisms that focus on providing security controls around digital assets that do not solely or fundamentally depend on traditional network controls or network perimeters. In a traditional setup, access to corporate applications solely depends on the user’s location within a corporate network. Remote users must connect to the network through a Virtual Private Network (VPN) for access.

AWS Verified Access provides secure access to corporate applications without a VPN by focusing the access model on applications rather than the corporate network. Verified Access lets you centrally create and manage access policies for your applications hosted in AWS. The policies that you create utilize additional context beyond the source IP address, such as the users’ identity or device posture. Verified Access provides the flexibility to integrate with both user and device trust providers to evaluate each user request in real-time. When writing policies, we recommend working backward from the requirements and sensitivity of the data in each of your applications.

CrowdStrike and Zero Trust assessment score

Verified Access integrates with third-party device management providers to provide additional security context. This lets you conditionally allow or deny access attempts using information about the security and compliance state of the user’s device.

Verified Access integrates with CrowdStrike, an AWS Partner Network (APN) partner with the AWS Security Competency. CrowdStrike is a cloud-delivered next-generation extended detection and response (XDR) platform — all delivered via a single lightweight sensor. CrowdStrike’s Software as a Service (SaaS) security platform, Falcon, is built on AWS.

CrowdStrike’s Zero Trust Assessment (ZTA) monitors the OS settings and sensor settings of endpoints within your organization. This granular assessment of endpoints is used to produce an overall score that uniquely represents the security posture of each endpoint. ZTA calculates a security score from 1 to 100 for each endpoint, where a higher score indicates a better security posture.

ZTA security scores are derived from two distinct assessment sources:

• OS settings (Windows and macOS only): Settings that track built-in OS security options, firmware availability, and Common Vulnerabilities and Exposures (CVE) mitigations.
• Falcon sensor settings: Falcon sensor configurations that track Reduced Functionality Mode (RFM) status, as well as prevention and Real Time Response policies.

Solution overview

In this example solution, you are an IT administrator setting up remote access to an IT Helpdesk application for your engineers. For access, engineers are required to be part of the Engineering group in Okta. Engineers must also utilize a device with the CrowdStrike Falcon sensor installed and a minimum ZTA score of 50. To achieve this, you configure Okta as an identity trust provider and CrowdStrike as a device trust provider. Then you configure Verified Access policies to allow access based on the requirements. After completing the walkthrough, engineers can securely access the application using your domain name mapped to a Verified Access endpoint.

Figure 1: Verified Access architecture with Okta and CrowdStrike trust providers

Prerequisites

Before continuing with this solution, follow our Okta setup post to configure the OIDC application in Okta.

Walkthrough

After completing the Okta setup, note the following:

1. Client Credentials
   1. Client ID
   2. Client Secret
2. Users to group mapping
3. Your Okta developer portal log in URL

Device provider Integration — CrowdStrike

Prerequisites

1. Subscription to CrowdStrike Falcon Insights XDR. CrowdStrike Falcon is available in the AWS Marketplace.
2. For testing, access to a Windows host with the CrowdStrike Falcon sensor deployed.
3. Install the Native Messaging Host. This allows the Verified Access browser extension to get the ZTA from the CrowdStrike agent running on the user’s devices.
   1. Download the MSI via this link.
4. Install the Verified Access browser extension for either Chrome web store or the Firefox add-on site.

Obtain your CrowdStrike Tenant ID

1. Navigate to Host setup and management in the CrowdStrike Falcon console.
2. Choose Sensor downloads.
3. On the Sensor Downloads page, copy the CrowdStrike Customer ID (CID) in lowercase without the checksum. For example, if the Customer ID and checksum is 84CXXXXXXXXXXXXXX19B-91, then copy 84cxxxxxxxxxxxxx19b. You need this when creating the Verified Access trust provider.

Figure 2: CrowdStrike Sensor downloads page

Review the ZTA score across your organization’s endpoints

A ZTA score is specific to the unique configurations of your environment. ZTA does not define what constitutes a good score. Instead, the ZTA dashboard provides visibility into possible risks and insight into settings that can increase the security posture of your endpoints. Therefore, you must review the score across your organization to determine the minimum score necessary for users to gain access to each Verified Access application.

To review the ZTA dashboard:

1. Navigate to Host setup and management in the CrowdStrike Falcon console.
2. Choose Zero Trust Assessment. If you don’t see Zero Trust Assessment, then reach out to your CrowdStrike Falcon administrator or to CrowdStrike support to enable the feature.

On the ZTA Dashboard, you can review the average assessment score and the score for each host. We keep this information in mind when writing Verified Access policies.

Figure 3: CrowdStrike ZTA Dashboard

Verified Access setup

There are four steps to set up Verified Access:

1. Create Verified Access trust provider
2. Create Verified Access instance
3. Create Verified Access group
4. Create Verified Access endpoint

 Step 1: Create Verified Access trust providers

Create an identity-based trust provider

1. Open the Amazon VPC console.
2. In the navigation pane, choose Verified Access trust. providers, and then Create Verified Access trust provider.
3. Enter an identifier to use later when working with policy rules for the Policy reference. For this example, enter Okta.
4. For Trust provider type, select User trust provider.
5. Select OIDC.
6. Next, use your Okta developer portal log in URL – `https://<okta dev portal>/.wellknown/openid-configuration` to get the values for Issuer, Authorization endpoint, Token endpoint, and user endpoint.
7. Copy Client ID and Client Secret from your Okta developer portal.
8. Set Scope as OpenID profile groups, as Okta supports these scopes for OIDC currently. Change the scope configuration appropriately if you want to include multiple scopes.
9. Choose Create Verified Access trust provider.

Figure 4: AWS Verified Access Okta trust provider details

Create a device-based trust provider

1. Open the Amazon VPC console.
2. In the navigation pane, choose Verified Access trust providers, and then Create Verified Access trust provider.
3. For Name tag and Description, enter a CrowdStrike-Trust-Provider and a description for the trust provider.
4. Enter an identifier to use later when working with policy rules for Policy reference name. For this example, enter CrowdS
5. For Trust provider type, select Device trust
6. For Device identity type, choose
7. For Tenant ID, enter the lowercase CrowdStrike CID.
8. Choose Create Verified Access trust provider.

Figure 5: AWS Verified access CrowdStrike trust provider details

Step 2: Create Verified Access instance

1. Under AWS Verified Access, choose Verified Access instances and then Create Verified Access instance.
2. Select Okta Trust provider created above (Step 1) From the dropdown – “Okta-Trust-provider”.
3. Choose Create Verified Access Instance.
4. Once created, select the Verified Access instance and choose Actions > Attach Verified Access trust provider.
5. Select CrowdStrike-Trust-Provider created earlier from the dropdown.

Figure 6: AWS Verified access instance details

Step 3: Create Verified Access group

1. In the navigation pane, choose AWS Verified Access, and then Create Verified Access group.
2. Select Verified access instance created above (Step 2) from the dropdown.
3. Leave the policy empty for now.
4. Choose Create Verified Access group.

Figure 7: AWS Verified access group details

Note that before creating Verified Access endpoints, you must set up an application with internal Application Load Balancer (ALB).  You must also request an ACM certificate that includes the public domain name your users can use to access the application.

Step 4: Create Verified Access endpoints

1. Choose Verified Access endpoints under AWS Verified Access.
2. Choose Create Verified Access endpoint.
3. For Verified Access group, choose a Verified Access group that we created in Step 3.
4. Under Application details, enter the public DNS name for your application, and select the public TLS certificate created or imported to ACM. For example: “it.xxxxx.people.aws.dev”.
5. For attachment type, select VPC.
6. For security groups, select the security group to be used for the endpoint. Traffic from the Verified Access endpoint that enters your load balancer is associated with this security group.
7. For Endpoint type, choose Load Balancer. Select the HTTP, port 80, Load Balancer ARN, and Subnet that you created as a prerequisite.
8. Choose Create Verified Access endpoint.
9. Before proceeding, make sure that the status of the endpoint changes to Active.

Figure 8: AWS Verified access endpoint with Active status

Creating Verified Access policies that incorporate trust data from the device trust provider

Now we review the creation of policies that incorporate context from both the identity and device of the users. Verified Access policies are written in Cedar, an AWS policy language. Review the Verified Access documentation for details on policy syntax. Note that the name after context in the following policies is the name we entered as the Policy reference name when we created the Verified Access trust providers.

Also, note that the context that is available to use in policies varies based on the trust provider. You can review the documentation to learn more about the available trust data for supported trust providers.

For our solution, we allow users in the Engineering group to access the IT application. For all users, we enforce a minimum CrowdStrike ZTA score of 50.

We can utilize Verified Access group policies to enforce the requirements which are shared between a group of Verified Access endpoints, each representing an application. For requirements specific to each application, we utilize Verified Access Endpoint policies.

To modify the group policy:

1. In the Amazon VPC console, choose Verified Access groups, then select the group we created earlier.
2. Choose Actions, then Modify Verified Access group policy.
3. For Policy, copy the following policy:

   // group policy
   permit(principal, action, resource) 
   when {
      context.crowdstrike.assessment.overall > 50
   };

4. Choose Modify Verified Access group policy to save the group policy.

With this policy in place, all devices accessing the Verified Access endpoints associated with the Verified Access group must have the CrowdStrike Falcon sensor installed and an overall ZTA score above 50. If the ZTA score for the device is 50 or less, then the user receives a 403 Unauthorized error.

Now let’s look at how we can add a policy for the endpoint representing our sample IT Helpdesk portal.

To modify an endpoint policy:

1. Choose Verified Access groups, then select the endpoint for the IT Helpdesk Portal we created earlier.
2. Choose Actions, then Modify Verified Access endpoint policy.
3. For Policy, copy the following policy:

   // endpoint policy
   permit(principal, action, resource) 
   when {
      context.okta.groups.contains(”Engineering”)
   };

4. Choose Modify Verified Access endpoint policy to save the endpoint policy.

With this policy in place, only users who are part of the Engineering group can access the application that is associated with the Verified Access endpoint.

Update redirect URI in Okta Developer portal

After completing Step 4, note the Device validation domain for the Verified Access endpoint. This tells Okta to send the authentication response to this URL.

Figure 9: AWS Verified access endpoint details

Log in to the Okta developer portal and add the device validation domain in Application > General > LOGIN > Sign-in redirect URIs, which is https://edge-00a23bcxxxxxxx.vai-0e85b7xxxxxx55.prod.verified-access.us-east-1.amazonaws.com/oauth2/idpresponse in this case.

Figure 10: Update redirect URI configuration in the Okta developer portal

Amazon Route53 configuration

Use the Verified Access Endpoint domain to create a CNAME records for your application domain in Amazon Route53 with the record name as it.xxxxx.people.aws.dev and value as the endpoint domain as shown in the following:

Figure 11: Amazon Route53 hosted zone CNAME details in the AWS Management Console

Testing the solution

When you have added both a Verified Access group and endpoint policy for an application, both policies must allow access for the user. With the group policy in place, all devices must have a ZTA score above 50.

Use a web browser with the Verified Access extension to test access to the application. Before signing in, you should be redirected to the Okta sign-in page. After successful authentication, if the device does not have a ZTA score above the threshold in the group policy, then the user receives a 403 Unauthorized error.

Figure 12: Successful remote access to the sample IT Helpdesk portal

Conclusion

In this post, you learned how to leverage additional context from device trust providers when permitting access to corporate applications with AWS Verified Access. Aligning with the principles of Zero Trust, you learned how to keep your applications hosted in AWS secure without relying only on the network perimeter for protection at the boundary. Using the capabilities of Verified Access allows for frictionless management of access to existing and new AWS applications at scale. Considering the status of a user’s identity and device is an additional layer of protection made possible by the partnership between AWS and device trust providers like CrowdStrike. To get started with Verified Access, visit the Amazon VPC Console. To learn more about CrowdStrike and AWS, visit the CrowdStrike AWS Partner page and review their listings on the AWS Marketplace.

Authors