Step-by-step: Integrating CrowdStrike Falcon with Appgate for trust

The prevailing assumption in Zero Trust architectures is that identity is the new perimeter. However, my analysis of production security breaches suggests that identity alone is insufficient without robust, real-time *device health* context. A compromised credential on a healthy, managed device presents a different risk profile than the same credential used from an unpatched, non-compliant endpoint. This post details a methodological integration of CrowdStrike Falcon's endpoint telemetry with Appgate SDP's conditional access engine, moving beyond simple API checks to a more statistically sound, risk-adaptive trust model.

The core objective is to augment Appgate's Entitlement decisions with Falcon's deep device posture assessment. The integration is not merely binary (compliant/non-compliant), but should allow for graded policy actions based on specific telemetry fields. The following steps outline the configuration, which hinges on the HTTP Claims Provider feature in Appgate.

**Step 1: Establish the HTTP Claims Provider in Appgate**

First, configure Appgate to query an external service for claims. This will be a lightweight middleware service (our "adapter") that communicates with the CrowdStrike APIs.

1. In the Appgate Administration Console, navigate to *Claims Providers* and create a new HTTP Claims Provider.
2. Define a meaningful name (e.g., "crowdstrike-device-health").
3. Set the URL to your adapter service endpoint (e.g., ` https://adapter.internal/api/device-check`).
4. Configure the necessary headers for authentication to your adapter. The critical claim sent by the Appgate Client is `device.hostname`. Your adapter will use this to look up the device in Falcon.

**Step 2: Develop the Adapter Service Logic**

This service acts as a translator between Appgate's HTTP Claims Provider and CrowdStrike's OAuth2 APIs. It must:
* Authenticate to the CrowdStrike API using a Client ID/Secret with appropriate read permissions (`device:read`).
* Receive the `device.hostname` (or `device.id`) from Appgate in the POST request body.
* Query the Falcon Discover API (`/devices/queries/devices/v1`) and the Device Details API (`/devices/entities/devices/v1`) to retrieve the device's status.
* Map Falcon's response to meaningful Appgate claims.

Below is a simplified Python (Flask) example demonstrating the core logic:

```python
import requests
from flask import request, jsonify

FALCON_BASE_URL = "https://api.crowdstrike.com"
FALCON_CLIENT_ID = "your_client_id"
FALCON_CLIENT_SECRET = "your_client_secret"

def get_falcon_token():
"""Fetch OAuth2 token from CrowdStrike."""
url = f"{FALCON_BASE_URL}/oauth2/token"
data = {'client_id': FALCON_CLIENT_ID, 'client_secret': FALCON_CLIENT_SECRET}
resp = requests.post(url, data=data)
return resp.json()['access_token']

@app.route('/api/device-check', methods=['POST'])
def device_check():
appgate_data = request.json
hostname = appgate_data.get('device.hostname')
token = get_falcon_token()
headers = {'Authorization': f'Bearer {token}'}

# Query for device ID by hostname
query_url = f"{FALCON_BASE_URL}/devices/queries/devices/v1"
query_params = {'filter': f"hostname:'{hostname}'"}
query_resp = requests.get(query_url, params=query_params, headers=headers)
device_ids = query_resp.json().get('resources', [])

if not device_ids:
return jsonify({'crowdstrike_healthy': False, 'crowdstrike_reason': 'device_not_found'})

# Get detailed device info
detail_url = f"{FALCON_BASE_URL}/devices/entities/devices/v1"
detail_params = {'ids': device_ids[0]}
detail_resp = requests.get(detail_url, params=detail_params, headers=headers)
device_info = detail_resp.json().get('resources', [{}])[0]

# Map Falcon properties to Appgate claims
claims = {
'crowdstrike_healthy': device_info.get('status') == 'normal' and device_info.get('platform_id', '').endswith('Win'),
'crowdstrike_sensor_version': device_info.get('agent_version', 'unknown'),
'crowdstrike_last_seen': device_info.get('last_seen'),
'crowdstrike_groups': device_info.get('groups', []),
'crowdstrike_policy_name': device_info.get('policies', [{}])[0].get('policy_name', 'default') if device_info.get('policies') else 'default'
}
return jsonify(claims)
```

**Step 3: Construct Appgate Conditional Access Policy**

Within your Appgate policy, create conditions that utilize the returned claims. For example:

* **Condition 1:** `crowdstrike_healthy` **Equals** `true`
* **Condition 2:** `crowdstrike_sensor_version` **Matches Pattern** `7.*`
* **Action:** Combine these with other identity-based conditions. A failure of `crowdstrike_healthy` could route the user to a remediation network or block access entirely.

**Potential Pitfalls and Considerations**

* **Latency:** Each entitlement evaluation now incurs the overhead of an external HTTP call. Cache Falcon device states in your adapter with a short TTL (e.g., 60 seconds) to mitigate this.
* **Error Handling:** Your adapter must handle scenarios where Falcon is unreachable. A "fail-open" vs. "fail-closed" decision is a critical security trade-off. I recommend a "fail-closed" stance with a dedicated "health_check_unavailable" claim to trigger a more restrictive policy.
* **Claim Design:** The claims you return should be generic enough for policy reuse but specific enough for granular control. Avoid simply returning the entire Falcon JSON blob.
* **Statistical Significance:** When logging these decisions, ensure you capture the specific claims used. This data is vital for later analysis to correlate access patterns with device postures, allowing for a more evidence-based policy refinement.

This integration creates a feedback loop where access is explicitly contingent on continuous device health validation. The next logical step is to incorporate Falcon's detection scores to implement true risk-based access, where elevated detection scores could trigger step-up authentication or session revocation, even within an active SDP connection.

- Dr. C