Falco → CrowdStrike Container
Falco ↔ CrowdStrike Container: integration to migration path.
Falco deploys as a second privileged DaemonSet beside the Falcon sensor, watching the same kernel stream but paging nothing — observe-only until every Falcon detection it must replace is proven to fire at parity on the SIEM. Only then does Falco take over paging, one rule at a time, and Falcon is removed cluster by cluster.
Big-bang cutover is off the table: the kernel substrate is shared but the rule semantics are not, so a swap without a soak is an unmeasured detection-coverage gap.
The idea
Watch the same kernel. Prove parity before you page.
The topology that makes this gap-free: Falco's modern_ebpf driver and the Falcon sensor attach different probe
sets to the same kernel with no collision, both observing the same
(cgroup_id, pid, exe, container_id) tuple. During the parallel run the SIEM joins Falco and Falcon
detections on (cluster, node, container_id, technique_tag, ts ± 2s), so every Falcon IOA can be
measured against a matching Falco rule firing on the same event. Falco stays observe-only — fanning to a
non-paging index via Falcosidekick — until that match rate clears the per-cluster gate. Falcon keeps owning paging
throughout, so you are never running on an unproven detection plane.
The phases
Seven steps. Each one reversible.
Baseline & inventory
Read-only. We export 90 days of Falcon detection telemetry, classify it by ATT&CK technique, separate OverWatch-attributed detections from sensor-only ones, enumerate custom IOAs, and record kernel version, OS distro and node CPU/RSS budget per pool. Custom IOA inventory is frozen here.
Falco on a canary cluster
A Falco DaemonSet with the modern_ebpf driver stands up on one non-prod cluster alongside the Falcon sensor, fanning via Falcosidekick to a dedicated non-paging SIEM index. The community rule pack is pinned to a falcoctl digest, and a correlation field is added so Falco and Falcon events can be joined.
Detection parity on the canary
For every Falcon IOA that fired on the canary in 14 days, we either write a matching Falco rule firing on the same event or classify it as a vendor-only accepted gap with SOC sign-off. The ATT&CK tag on each Falco rule must match the IOA's technique. The parity report is version-controlled.
Expand Falco to all clusters
Falco rolls out to every cluster in low-to-high blast-radius waves, still observe-only, fanning to falco-* indices. Each cluster gets a 7-day soak against its own Falcon detections, since cluster-specific workloads shift the parity numbers. Falcon stays authoritative for paging.
Promote Falco to paging per rule
A documented subset of Falco rules begins paging directly via Falcosidekick instead of dropping to the silent index, with Falcon still paging in parallel. A SIEM suppression rule pages once when both fire on the same (container_id, technique) within two seconds, keeping both records for forensics.
Remove Falcon where parity holds
Falcon Container is uninstalled from clusters that meet the per-cluster parity gate, and retained on clusters where it doesn't — typically heavy Falcon Identity coupling, active OverWatch SOW, or regulated clusters where the vendor SOC 2 boundary is audit evidence. The CrowdStrike tenant is kept 30 days as a rollback option.
Final retirement
With Falcon removed from all in-scope clusters, a 30-day evidence window validates SIEM coverage and re-collects compliance evidence from the Falco pipeline — cosign + Rekor attestations and rules-as-code in git for the SOC 2 CC7.1 narrative. Contract termination follows once the window passes.
Feature parity
Where Falco matches CrowdStrike — and where it can't.
| Capability | Falco | CrowdStrike Container | Parity |
|---|---|---|---|
| Runtime syscall detection (eBPF) | Falco modern_ebpf driver + sinsp rules | Falcon sensor IOAs on syscall stream | At parity |
| K8s audit detection | k8saudit / k8saudit-eks plugin rules | Falcon k8s admission controller (partial coverage) | Partial |
| Cloud control-plane events | cloudtrail / gcpaudit / okta plugins | Falcon Cloud Security (separate product surface) | Partial |
| Rule transparency / detection-as-code | YAML rule:/condition:, falcoctl tests | Custom IOA grammar, vendor-opaque curated IOAs | OSS only |
| MITRE ATT&CK tagging on rule stream | native tags: [mitre_*, T####] | console-side IOA→ATT&CK mapping, not stream tags | Partial |
| Alerting / output channels | Falcosidekick (60+ destinations) | Falcon Streaming API + Fusion SOAR | At parity |
| Managed threat hunting | none | OverWatch managed hunting | SaaS only |
| Identity ↔ container correlation | serviceAccountName / UID only | Falcon Identity ↔ Container join | SaaS only |
| Vendor-curated IOA feed | community falcosecurity/rules (lags) | CrowdStrike telemetry-tuned IOAs | SaaS only |
| CSPM / cloud posture context | none | Falcon Cloud Security CSPM graph context | SaaS only |
| Sensor lifecycle management | Helm/chart upgrade, self-managed | vendor auto-update channel | SaaS only |
| Deployment model | self-hosted privileged DaemonSet | managed sensor DaemonSet + SaaS backend | At parity |
| Cost model | per-node compute + SIEM + curation labour | per-node license + CWP module SKU | At parity |
| Compliance boundary (SOC 2 / FedRAMP) | self-operated, your audit scope | vendor SOC 2 / FedRAMP boundary | SaaS only |
What we're honest about
The caveats most vendors leave out.
OverWatch managed hunting has no OSS equivalent
A team of CrowdStrike analysts actively hunts in your tenant. There is no open-source replacement — the substitute is your own SOC, a contracted MDR, or an explicitly accepted gap. If OverWatch is attributing detections your sensor alone wasn't catching, those detections stop. Retiring Falcon is a procurement decision here, not a tooling swap.
Falcon Identity ↔ container correlation can't be ported
Falcon enriches container detections with the human identity — the Entra, AD or Okta principal — behind a kubectl call by joining to Falcon Identity Protection. Falco sees serviceAccountName and process UID only. Correlating to a human identity means building your own SIEM-side enrichment pipeline before Phase 5; there is no OSS equivalent.
Vendor-curated IOAs lead the community pack
Falcon's IOAs encode attack patterns CrowdStrike tunes on telemetry across its whole customer base. Falco's falcosecurity/rules cover the public ATT&CK surface but lag that curation-on-real-telemetry feedback loop. We pin the rule pack to a tested digest and own a controlled update cadence with regression tests, rather than pretend the community pack keeps pace automatically.
You inherit sensor lifecycle and SIEM cost
Falcon auto-updates its sensor on a managed channel; Falco upgrades — chart, driver compatibility, rule-pack re-test — become your responsibility, realistically a platform engineer at meaningful FTE allocation, ongoing. And during dual-coverage, runtime-detection log volume roughly doubles for six to twelve months, so SIEM ingest headroom is a Phase 1 budget item.
Why this beats a flag day
Reversible per phase, soaked well past the minimum.
Every phase rolls back fast — uninstalling Falco takes under 5 minutes, demoting a paging rule or reinstalling Falcon on a cluster under 15 — because Falcon keeps paging in parallel until parity is proven. Falcon Container is only retired from a cluster after at least 30 consecutive days of paging-grade Falco operation with no Falcon-only detection missed, well past the 14-day floor, and the tenant is held 30 days more as the Phase 6 evidence window before any contract is cancelled. A cutover without that soak is a coverage gap nobody measured.
See whether your container runtime can move off CrowdStrike.
A 30-minute call with a senior engineer. We profile your kernel matrix, your custom IOA inventory and your OverWatch dependency, then tell you honestly which clusters can retire Falcon and which keep it for the vendor capabilities OSS can't reproduce — before you commit.
Map my migration →