Detection-first ingestion. Each Falcon detection becomes its own ContraForce incident across every tier (EDR, XDR, NG-SIEM). Cases and automated leads are not surfaced as incidents — they are CrowdStrike’s analyst- and AI-curated groupings over the underlying detections, and ingesting them too would either double-count the signal or leave detections that never roll into a case or lead as silent blind spots. A first-class ContraForce Cases primitive that sits above incidents (cross-source) is on the roadmap as separate work.
This page describes what the integration does and what the tier you pick on the configuration page unlocks. For the step-by-step setup, see CrowdStrike Falcon Detection and Response Modules.
What the Integration Does
Ingestion
Polls CrowdStrike’s unified Alerts API on a continuous loop and surfaces every new Falcon detection in the Command Dashboard as a ContraForce incident.
Investigation
Hydrates the detection with process tree, events timeline, device, and identity context drawn from CrowdStrike NG-SIEM and the alert payload itself.
Status round-trip
Status changes you make in ContraForce (New → In Progress → Closed) PATCH back to CrowdStrike via the Alerts API.
Owner assignment (with optional writeback)
Assigning a CrowdStrike incident in ContraForce always records the owner in the ContraForce audit log. If the workspace has a CrowdStrike service account bound on the Assignment Writeback card, the assignment is also PATCHed onto the underlying Falcon alert as that service account. See the callout below.
Response actions
Powers the Contain, Lift Containment, and On-Demand Scan Gamebooks on Falcon-managed devices via the Response API client.
Agents on queue
Triggers Security Delivery Agents on every CrowdStrike incident that lands in the unified pipeline.
Why owner assignment defaults to audit-only. In MSSP topologies the ContraForce user (Entra UPN) frequently has no matching principal in the customer’s CrowdStrike tenant, so pushing the assignment directly to Falcon either fails or lands on the wrong account. Recording the assignment locally lets every ContraForce user who can see the incident see the assigned owner without requiring a vendor-side identity match. The list view and the incident detail both hydrate the owner from the audit log on read.The optional service-account writeback lets you opt back into vendor-side visibility without giving up the MSSP-friendly default. You bind one Falcon user (typically a named service account in the customer’s tenant) on the workspace’s Assignment Writeback card; from then on every analyst assignment in ContraForce is mirrored onto the underlying alert as that bound user, and unassigning in ContraForce clears the Falcon-side assignee. The CF audit log is still the source of truth for which analyst actually picked up the incident; the writeback only controls what the customer sees on the Falcon side. Writeback failures (Falcon outage, deleted user, missing scope) are logged but do not fail the CF-side assignment, so the analyst queue stays responsive even when the vendor is degraded.
Tier Selection — What You Pick on the Configuration Page
When you configure the Detection module in ContraForce, you pick which Falcon tier the customer is licensed for. The tier you declare drives which scopes the API client needs and which advanced investigation surfaces (Process Tree ancestor walk, Events Timeline) unlock. It does not change the ingestion shape — every Falcon detection becomes its own ContraForce incident on every tier. There are three options:- Falcon Insight (EDR)
- Falcon Insight XDR
- Falcon NG-SIEM
For tenants on Falcon Insight (EDR) only. Cases workbench is not available on this tier.
How the Pipeline Works
The ingestion shape is uniform across tiers — every Falcon detection becomes a ContraForce incident — and every downstream consumer reads from the same unified incident pipeline:
The tier you declare on the configuration page only changes which scopes the API client needs and which advanced investigation surfaces unlock. It does not change the ingestion shape.
Per-Product Allow-List
Independent of the tier, each workspace can narrow ingestion to a subset of CrowdStrike’sproduct values via the Alert Types card on the Detection module configuration page. Useful for MSSPs whose contract scope is narrower than the customer’s full Falcon SKU.
How the filter is applied
The allow-list is enforced at every ingestion site so the queue, stats, agents, and gamebook auto-run all see the same shape:
Detections from products outside the allow-list never reach the pipeline — they are dropped at the retriever / poller layer, not hidden in the UI. Re-enabling a product surfaces its detections from the next poll cycle onward; previously dropped detections are not back-filled.
Persistence model
Changing the allow-list is independent of credential save. The Alert Types card has its own Save button and does not require Test Connection or Client Secret re-entry.
Tier-driven shortlist
The Alert Types card only shows the products typical for the declared tier by default to keep the UI compact:
A “Show all products” toggle reveals the full catalog for non-standard SKU combos (e.g. EDR + Mobile add-on). The toggle auto-defaults to “show all” when the persisted selection already includes products outside the tier shortlist, so saved selections are never hidden.
The shortlist is a UX hint rather than a hard licensing gate — the source of truth for tier-to-product availability still lives on the CrowdStrike side.
Why a CF-side filter
CrowdStrike’s OAuth scopes don’t expose per-product granularity — the only available scope isalerts.read across all products. So the filter has to live in ContraForce code; we cannot narrow at the API-client level.
Verification Panel
After you click Test Connection on the configuration page, ContraForce runs a live probe of the API client and renders a verification panel below the form. The panel doesn’t override your tier choice — it confirms the claim against what’s actually present on the API client:
The verification panel is informational — you can save with a missing-required indicator, but the corresponding feature won’t work until you add the scope and re-test.
CrowdStrike Data Retention — How It Affects the Platform
The data ContraForce surfaces from CrowdStrike is bounded by Falcon’s own retention policy. The Falcon console may have access to additional historical data that ContraForce doesn’t query.Where retention shows up in the platform
What this means in practice
Tuning the retention horizon
ContraForce does not control your CrowdStrike retention — it’s set by the customer’s NG-SIEM SKU. To change it:- Open the Falcon console
- Navigate to Next-Gen SIEM → Configuration → Settings → Data ingest (path may vary by tenant)
- Adjust the retention policy on the
base_sensorrepository according to your subscription terms - After the change takes effect, run Test Connection on the ContraForce configuration page so the new horizon persists on the workspace
How the Pieces Fit Together
The Detection API client carries the scopes for everything in the top-half (detection ingestion + investigation + case-context resolution + status writeback); the Response API client carries the scopes for the Hosts / ODS gamebook actions in the bottom half.Related Documentation
CrowdStrike Falcon Detection and Response Modules
Step-by-step setup with per-tier scope requirements
What are Gamebooks?
How Gamebook response actions work
Entity Insights
Investigation context for an incident’s entities
Roles and Permissions
Detailed role reference for ContraForce users
Questions about the CrowdStrike Falcon integration? Contact us at support@contraforce.com.