Connect CrowdStrike Falcon to Versus over the OAuth2 Falcon API to look up hosts, network-contain a compromised endpoint, pull Spotlight CVEs, triage detections, and run Real Time Response scripts — from governed, approval-gated workflows or your own script steps.
Versus connects to CrowdStrike Falcon through the Falcon platform API, so endpoint context and response actions become steps in your automation rather than a separate console you switch to. From a workflow you can verify a host is real, network-contain a compromised machine, pull its Spotlight vulnerabilities, triage detections, and run a Real Time Response (RTR) script — each action recorded as part of a durable, auditable run.
The integration is built for the way security work actually flows in a regulated shop: a containment isn't a one-click button, it's an emergency change request, an approval gate, the isolation action, and a written-back record. Versus ships that whole loop as a built-in workflow, and exposes every underlying capability to the Workflow Builder and to custom script steps.
A CrowdStrike connection in Versus is a stored record pointing at one Falcon tenant. Versus authenticates to it with OAuth2 client credentials — the same API client you create under Falcon → Support → API Clients & Keys.
POST /oauth2/token for a bearer token.Authorization: Bearer … and returns Falcon's standard envelope; Versus surfaces any errors array as a failed step rather than swallowing it.Because CrowdStrike is a multi-region platform, each connection also carries the cloud base URL for the tenant:
| Region | Base URL |
|---|---|
| US-1 (default) | https://api.crowdstrike.com |
| US-2 | https://api.us-2.crowdstrike.com |
| EU-1 | https://api.eu-1.crowdstrike.com |
| US-GOV-1 | https://api.laggar.gcw.crowdstrike.com |
The client secret is write-only and encrypted at rest — it is never returned by the API once saved, and editing a connection lets you leave it blank to keep the existing value. See Security & Compliance for how Versus handles integration credentials.
Grant the API client only the scopes your workflows use. In practice that maps to:
| Capability in Versus | Falcon scope area |
|---|---|
| Look up / list hosts | Hosts (read) |
| Contain / lift containment | Host Group / device actions (write) |
| Detections triage | Detections (read & write) |
| Spotlight CVEs | Spotlight Vulnerabilities (read) |
| RTR scripts | Real Time Response, RTR Admin |
Scope the client tightly and use a dedicated one for Versus so its activity is attributable in the Falcon audit log.
Go to Integrations → CrowdStrike and choose Add CrowdStrike Connection:
Falcon Production).Use Test Connection to verify the credentials. Versus performs a real OAuth2 token exchange against the region's /oauth2/token endpoint and records the outcome (Connected, Connection error, or Not tested) with a message and timestamp on the connection.
Connections are tenant-scoped in multi-tenant deployments, so one tenant never sees or uses another's Falcon credentials.
CrowdStrike ships as a set of workflow action steps under the crowdstrike category. Each step takes an optional CrowdStrike Source name — leave it blank to use the first enabled connection, or name one explicitly when you run more than one Falcon tenant.
| Step key | What it does |
|---|---|
crowdstrike.check_connectivity | Verifies the Falcon API is reachable and the token is valid |
crowdstrike.get_host_details | Resolves a hostname (or AID) to a host, sets cs_host_aid and friends |
crowdstrike.contain_host | Network-isolates the host (device action contain) |
crowdstrike.lift_containment | Removes network containment (device action lift_containment) |
crowdstrike.list_detections | Fetches recent detections, optionally filtered by FQL |
crowdstrike.get_vulnerabilities | Pulls open Spotlight CVEs for a host AID |
crowdstrike.run_rtr_script | Runs a PowerShell/shell script on a host via RTR |
crowdstrike.update_detection | Sets a detection's status (e.g. close as false positive) |
The steps are designed to chain. get_host_details looks a host up by hostname and writes context variables the later steps read by default:
| Variable | Set by | Used by |
|---|---|---|
cs_host_aid | get_host_details | contain_host, lift_containment, get_vulnerabilities, run_rtr_script |
cs_host_hostname | get_host_details | logging / write-back |
cs_containment_status | get_host_details, contain_host | conditionals, write-back |
cs_vuln_count, cs_critical_vuln_count | get_vulnerabilities | ticket bodies |
cs_detection_count, cs_detections | list_detections | analyst review, tickets |
cs_rtr_output | run_rtr_script | downstream steps |
So a typical chain is: check connectivity → look up host → (approval) → contain → collect CVEs → write back to the ticket, with each step reading cs_host_aid from the one before it. Any step also accepts a hard-coded AID override when you already know it.
CrowdStrike keys hosts on an AID (Agent ID), not a hostname. A hostname can be ambiguous or reused; the AID is the stable handle every action targets. That's why containment, Spotlight, and RTR steps expect an AID — you resolve it once with get_host_details (which matches on hostname:'…' and returns the first match) and reuse it. Hard-code the AID directly only when you've already pinned the exact host.
Three governed workflows are seeded and ready to run under the security category. They combine the CrowdStrike steps with ServiceNow change/incident steps and approval gates, so a response action always carries a record and a sign-off.
cs-host-containment)Network-isolates a compromised host under change control:
Run inputs: target hostname, a containment reason / incident summary, and an optional ServiceNow assignment group. Containment never fires before the approval — the destructive action sits behind an explicit human decision by design.
cs-vulnerability-scan)Looks a host up in Falcon, pulls its open Spotlight CVEs, surfaces the Critical/High findings, and files a ServiceNow security incident with the totals. Run inputs: target hostname and an optional CVE cap.
cs-detection-investigation)Turns a manual triage loop into a governed flow: fetch Falcon detections matching an FQL filter, open a ServiceNow security incident, pause for analyst review and approval, then update the detections' status in Falcon. Run inputs: an FQL detection filter, a max-detections cap, and the final status to apply (for example in_progress).
You can run these as-is, clone them, or use them as reference wiring when you build your own. To trigger any of them from a pipeline or ITSM tool, see Running Workflows via the API.
CrowdStrike queries use FQL (Falcon Query Language). Any step that lists or searches accepts an FQL filter, and getting it right is how you keep a workflow scoped to the hosts and findings you mean:
hostname:'BIGIP-01'
status:'contained'
platform_name:'Windows'
tags:'CriticalInfra'
status:'new'+max_severity_displayname:'Critical'
aid:'abc123'+status:'open' # Spotlight: open CVEs for one host
Combine terms with + (logical AND). The detection steps default their sort to newest-first, so a filter like status:'new'+max_severity_displayname:'Critical' gives you the freshest critical detections to triage.
The crowdstrike.run_rtr_script step runs a PowerShell or shell script on a live host through Falcon RTR and returns its standard output. Under the hood Versus opens an RTR session against the host's AID, runs the script with the runscript base command, polls for completion, then tears the session down — so you don't leave sessions open. The step exposes a timeout (default 120 seconds); a script that doesn't finish in time fails the step rather than hanging the run.
RTR executes real commands on a real endpoint. Gate it behind an approval node, scope the Falcon API client's RTR privileges tightly, and keep scripts read-only unless a change is explicitly authorized. Every run is captured in the Versus run history and in Falcon's own RTR audit trail.
Everything the built-in steps do is available to custom script steps through the workflow SDK's integrations object, when you need logic the visual steps don't cover:
cs = integrations.crowdstrike() # first enabled source
# cs = integrations.crowdstrike('Falcon Production') # or by name
host = cs.find_host(versus.get_input('target_hostname'))
if host and host['containment_status'] == 'normal':
vulns = cs.get_host_vulnerabilities(host['aid'])
critical = [v for v in vulns if v['severity_name'] == 'CRITICAL']
versus.log(f"{len(critical)} critical CVEs on {host['hostname']}")
if critical:
cs.contain_hosts([host['aid']])
versus.set_output('contained_aid', host['aid'])
The client surfaces the full Falcon surface Versus supports — hosts, containment, detections, alerts, incidents, Spotlight vulnerabilities, RTR, and prevention policies / host groups. integrations.crowdstrike_list() returns every enabled connection (id, name, base_url, status) if you need to fan out across tenants. See the Workflow SDK Reference for the object model, and Secret Vault for how integration credentials are protected.
CrowdStrike is one of Versus's platform integrations — external systems modeled as connections that workflow steps act through. That places endpoint security in the same automation fabric as your ADC and firewall changes: a single run can look at a Falcon detection, correlate it to an F5 BIG-IP virtual server, contain the host, and open the change ticket — all recorded together.
Falcon calls are outbound HTTPS from the Versus application core to the region's API endpoint; nothing about the integration requires an inbound path into your network. For where this sits in the overall system, see Platform Architecture.