Zero Trust Access with F5 Identity Aware Proxy and Crowdstrike Falcon

Introduction

Organisations are constantly trying to defend against evolving threats to their digital infrastructure. Attacks are ever-present and sophisticated, so the need to be vigilant for attacks and limit the potential for disruption has seen modern security architecture evolve into Zero Trust type solutions.  The principle of Zero Trust has been widely explored, but briefly, the principle is that all users, regardless of location, should be authenticated, authorised, and continuously evaluated for security posture before getting access to any data. 

In this article, I will explore a solution built for an F5 Access Policy Manager (APM) customer, that was also a Crowdstrike Falcon customer. In order to fully understand the posture of the endpoint, Falcon was used to provide real-time zero trust assessments, while F5 APM was used to authenticate the user, and constantly evaluate the endpoint posture data generated by Falcon. This Zero Trust Access approach would be defined in an APM policy for use with any app across the entire enterprise.

Please review the following diagram to understand the solution architecture:

 

 

 

 

 

 

As can be observed in the diagram, the Crowdstrike Falcon software running on the endpoint is constantly evaluating the posture of the device, and pushing this data into the Crowdstrike cloud. The Crowdstrike cloud identifies each endpoint with a unique identity known as an Agent ID. The Falcon API allows access to these endpoint assessments via an API endpoint known as the Zero Trust Assessment.

Crowdstrike

CrowdStrike Falcon is an Anti-Virus and Endpoint Detection and Response (EDR) solution. It provides advanced defensive capabilities against modern computer and network threats. It replaces traditional signature-based antivirus with a sophisticated set of behavioral models, enabling it to detect advanced and novel threats. Crowdstrike Falcon uploads a transcript of system events like program launches and network connections to a cloud-based detection infrastructure, and those logs are used to detect threats. The CrowdStrike agent continues to protect systems even while they are offline.

An interesting part of the Falcon solution is a feature called the Zero Trust Assessment. For more information on this feature, please review the following link. The Zero Trust Assessment information that is generated is published via the Crowdstrike Falcon API, and available to the tenants for integrations with other systems.

To access the Zero Trust Assessment, first we have to generate a token. Note in the request we will need to supply a client ID and client secret:

curl -H "User-agent: f5" -X POST "https://api.crowdstrike.com/oauth2/token" -H  "accept: application/json" -H  "Content-Type: application/x-www-form-urlencoded" -d "client_id=<your_client_id>&client_secret=<your_client_secret>"

Then we use the token in a request to the Zero Trust Assessment API, specifying the Agent ID that we are interested in as a query in the request. The Agent ID is the workstation/endpoint ID that we are interested in:

curl --oauth2-bearer "<your_token_here>" -X GET "https://api.crowdstrike.com/zero-trust-assessment/entities/assessments/v1?ids=0b5abb999c1544f1af71983753ff8d22" -H  "accept: application/json"

The Zero Trust Assessment API provides all manner of interesting data on an endpoint, but the one that we are focussed on for this article is the assessment overall score.

{
	"resources": [{
		"aid": "0b5abb999c1544f1af71983753ff8d22",
		"cid": "e5d4a79a091448bfb80afc724b3cf952",
		"system_serial_number": "Redacted",
		"event_platform": "Win",
		"product_type_desc": "Redacted",
		"modified_time": "2022-02-10T03:17:03Z",
		"sensor_file_status": "confirmed",
		"assessment": {
			"sensor_config": 88,
			"os": 48,
			"overall": 74,
			"version": "3.2.0"
		},
		"assessment_items": {
			"os_signals": [{
				"redacted": "for brevity",
			}],
			"sensor_signals": [{
				"redacted": "for brevity",
			}]
		}
	}]
}

The assessment score is a based on a variety of factors, and when implementing the solution described in this article, the threshold number for what constitutes an acceptable score is something that will require thought by security architects. It's doubtful that there is a one size fits all acceptable score for every organisation, or indeed, every app.

The flexibility of an APM policy means that there is no need for a one-size-fits-all approach.

Identity Aware Proxy on APM

Identity Aware Proxy is principal in F5 BIG-IP Access Policy Manager (APM). BIG-IP APM and F5 Access Guard deliver Identity Aware Proxy, using a Zero Trust model validation for every access request. Providing authenticated and authorized secure access to specific applications, it leverages F5’s best-in-class access proxy. BIG-IP APM centralizes user identity and authorization. Authorization is based on the principles of least privileged access. With its IAP approach, BIG-IP APM is able to examine, terminate, and authorize application access requests. The context-awareness required for Zero Trust compels the development and enforcement of extremely granular authorization policies. BIG-IP APM, through its IAP support, delivers just that. For more information please review the following link.

On the F5 APM platform, the solution is fairly simple, and will likely look familiar to those who have worked with APM policies before. We will focus on three types of object in APM;

• HTTP Connector
• Per-session policy
• Per-request policy

The HTTP Connector is used to facilitate communications between APM and the Crowdstrike Falcon API, it consists of a HTTP Connector transport profile, and a HTTP Connector request profile. The transport profile configures items such as the DNS resolver and SSL certificate, while the HTTP Connector request profile is where you specify the various HTTP parameters for the query, such as the URL.

Below is the HTTP Connector request profile used in the solution:

apm aaa http-connector-request hcr_crowdstrike {
    auth bearer
    method GET
    response-action parse
    token REDACTED
    transport hct_crowdstrike
    url "https://api.crowdstrike.com/zero-trust-assessment/entities/assessments/v1\?ids=%{subsession.crowdstrike_agent_id}"
}

There are a few interesting elements to the HTTP Connector request profile; firstly, we have to supply a token as described in the Crowdstrike section of this solution, secondly we have a per-request policy variable embedded in the URL that will align with the endpoint we are trying to assess, and lastly, the response action is parse. The response action will ensure that the JSON response will be parsed into variables that we can use in the per request policy.

As a side note, the token used in the HTTP Connector request profile will need to be updated periodically so that access to the Crowdstrike API can continue. A PATCH on the HTTP Connector request profile iControl REST endpoint will allow the token to be updated:

curl -X PATCH -k -u admin:your_admin_password -H "Content-Type: application/json" -d '{ "token": "new_token_data_goes_here" }' https://your_bigip/mgmt/tm/apm/aaa/http-connector-request/hcr_crowdstrike

This can be automated via an iCall or even a simple cron job, the timing of which should match the token expiry.

Once we have the HTTP Connector set up, we can configure an APM Per Session policy, which for the purposes of this article will be quite simple - we just provide a login page and authenticate against Active Directory:

Note that the only part of the Per Session Policy that is relevant to this solution is that we are querying the Windows registry to discover the Crowdstrike Agent ID:

After the Crowdstrike Agent ID is read out of the registry, it is applied as a subsession variable, and the resulting subsession variable can then be used in the HTTP Connector Request profile to form the API query. There are likely other ways to discover the Agent ID using the Falcon API, but the registry method was readily available in the environment used for this solution.

The last piece of the solution is the Per Request policy. This is the policy that APM will evaluate with every client request, and the part of the solution that is enforcing the constant posture assessment associated with a Zero Trust solution.

In the API call part of the Crowdstrike subroutine, we are using the result of the HTTP Connector request, that has been populated into subsession variables. Particularly, we are using the assessment overall score to determine if we will allow this request to proceed. As the overall score for an endpoint is constantly updated in response to what Crowdstrike Falcon is seeing on the endpoint, in terms of software patch levels, indicators of compromise, and myriad other, the overall score represents a good indicator of the endpoint security.

The details are below:

Lastly, it should be noted that this very simple set of policies do not represent the only way to implement the solution. The Per Request policy has the opportunity to take further actions rather than a simple binary Pass or Fail of the request. We could prompt for additional authentication, be it another factor, or a type of step-up authentication. The possibilities are many and will likely be prescribed by an organisations security policy.

Summary

With the integration between Crowdstrike Falcon and F5 Identity Aware Proxy described in this solution, the customer was able to leverage existing investments to provide a Zero Trust Access solution that increased the security and therefore reduced the risk to the organisation. When combined with other features on the F5 platform, such as Web Application Firewall, Bot Protection, a rich set of flexible user and app security controls can be easily realised.