Sigma + Chainsaw → commercial XDR detection content
Sigma + Chainsaw ↔ commercial XDR content: integration to migration path.
Your XDR vendor pack is the live safety net, so we never delete it. A CI-tested Sigma overlay stands up alongside the pack first — covering telemetry the vendor never sees — and only then takes over the rule classes Sigma can actually express, cohort by cohort. No flag day, no detection blackout, and every cohort rolls back in minutes with a git revert.
The honest exception: behavioural process-tree detections built on proprietary telemetry — Falcon EAM, SentinelOne Storyline — cannot be reproduced as Sigma and stay on the vendor pack indefinitely. We flag every one in Phase 0.
The idea
Overlay the pack first. Own the lifecycle in code.
The topology that makes this zero-blackout is a CI-tested Sigma overlay: the vendor pack stays authoritative while a git repo of Sigma rules compiles per backend through pySigma processing pipelines and deploys into a dedicated overlay namespace, gated by a test harness that asserts known-bad events fire and known-good ones do not. Every change is a diffable, signed, reviewable PR with a manifest pinning git tag to vendor-console rule ID, so rollback is a revert and redeploy. Only once a Sigma rule proves parity in a parallel-fire window does the matching vendor rule drop to monitor-only — each cohort independently, each reversible, the pack never gone.
The phases
Seven steps. Each one reversible.
Vendor-pack inventory & corpus
We document every enabled vendor rule with its ID, severity, ATT&CK tags, 90-day fire count, true positives and suppression list, flagging which rules need fields only the vendor sees. A 30-day capture of representative production events becomes the seed test corpus. Read-only.
Stand up the Sigma overlay (no rules)
A git repo with sigma, tests, pipelines and mappings goes live behind CI: lint, convert, run pytest against the corpus, human review, then automated deploy to a dedicated overlay namespace. The namespace is empty. The bulk of the work is the per-backend field-mapping pipelines.
Cover the long tail Sigma owns
Sigma rules deploy into the overlay for telemetry the vendor pack ignores — custom app logs, third-party SaaS audit (Okta, GitHub, Slack) not integrated into the XDR, Linux auditd on hosts without the endpoint. Net-new coverage, not a re-implementation of vendor content.
Author Sigma equivalents in parallel
For every vendor rule not flagged vendor-only-telemetry, a Sigma equivalent deploys to the overlay and runs in parallel. A CI artifact compares firing sets — vendor-only, Sigma-only, both — and surfaces the delta over a soak window so misses get fixed, accepted, or marked not-portable.
Downgrade covered vendor rules to monitor-only
Vendor rules with a green Sigma equivalent drop to severity info, routed to a vendor-overlay review queue rather than primary SOC. Sigma becomes primary. The proprietary-telemetry vendor rules stay primary, and a weekly review of the queue catches vendor drift.
Retire covered vendor rules (optional)
After at least 30 days monitor-only with no SOC-missed events, covered vendor rules are disabled — not deleted, since re-enable is one toggle and you pay for the pack regardless. Proprietary-telemetry rules remain enabled and primary.
Steady state
Sigma is primary for the rule classes it can express; the vendor pack stays primary for behavioural process-tree and vendor-specific endpoint indicators; Chainsaw is used by DFIR for retroactive EVTX hunting during incident scope. Weekly queue review, monthly firing-rate review, quarterly corpus refresh.
Feature parity
Where Sigma leads, and where the vendor pack wins.
| Capability | Sigma + Chainsaw | commercial XDR detection content | Parity |
|---|---|---|---|
| Detection authoring format | Sigma YAML (logsource / detection / condition / tags) | Vendor-authored rules in the vendor console | At parity |
| Cross-platform portability | sigma-cli / pySigma backends to SPL, KQL, EQL, FQL, YARA-L, PPL | SaaS-locked; rewrite to change vendor | OSS only |
| Source-of-truth in git | YAML under PR review, diffable, signed commits | Silent console updates; diffs not exposed | OSS only |
| CI-tested detections | pytest-style harness asserts known-bad fires / known-good doesn't per UUID | Vendor tests internally; you see the production result only | OSS only |
| Custom telemetry coverage | Author against any normalisable source (logsource: product: custom-app) | Vendor ships no rules for internal apps | OSS only |
| Retroactive / offline hunting | Chainsaw hunt --sigma against an EVTX corpus offline | Live-data only; separate IR tooling | OSS only |
| Behavioural process-tree detection | None (Sigma process_creation is parent / child, not multi-hop) | Falcon EAM / SentinelOne Storyline graph | SaaS only |
| Telemetry-back tuning loop | Tuned only against your own fleet signal | Fleet-wide firing-rate observation plus auto-tune | SaaS only |
| Sub-hour content updates | PR-test-deploy cycle of days or more | Dedicated threat-research team, sub-hour pushes | SaaS only |
| ATT&CK tagging / coverage matrix | tags: lint-enforced; Navigator layer auto-built | Vendor tags; coverage surfaced in the console | At parity |
| False-positive feedback | falsepositives: block per rule (captures why) | Suppression lists (capture what) | Partial |
| Conversion-lossiness audit | sigma-cli convert --check flags unsupported modifiers per backend | Abstracted; not visible | OSS only |
| Unified triage console | None (alerts arrive as SIEM events) | Fused detection plus process tree plus network plus identity pane | SaaS only |
| Compliance / rule-version evidence | Per-rule version evidence via git plus manifest (auditor-facing) | Often no per-date rule-version evidence | Partial |
What we're honest about
The caveats most vendors leave out.
Proprietary telemetry has no Sigma equivalent
Behavioural process-tree detections — Falcon EAM, SentinelOne Storyline graph — literally cannot be reproduced as Sigma rules, because the underlying fields do not exist outside the vendor's normalised event model. We flag these in Phase 0, never attempt to migrate them, and keep the vendor pack primary for them indefinitely.
Backend conversion is lossy
Modifiers like cidr, re, and base64offset-contains, plus aggregation conditions, do not translate uniformly across backends — a converted query can match different events than the Sigma source intended. A per-rule per-backend lossiness audit runs in CI and rejects any merge that uses an unsupported construct on a deployed backend.
The vendor's tuning and update cadence is theirs alone
Vendors observe firing rates across thousands of customers, auto-tune silently, and ship net-new detections within hours of a CVE; your overlay's PR-test-deploy cycle takes days. We document the latency gap honestly and use a fast-path — vendor rules accepted read-only with lint but no test gate — for time-critical CVE coverage.
This needs a detection engineer and a governed corpus
A working Sigma plus CI pipeline assumes someone who can author Sigma, debug pySigma pipelines and own the test corpus — and that corpus holds real PII and adversary indicators, so it is a security-sensitive, access-controlled artifact. With zero detection-engineering headcount, the honest answer is to stay on the vendor pack and accept the lock-in.
Why this beats a flag day
Reversible per cohort, soaked before you disable.
Every cohort cutover rolls back in under 15 minutes — a git revert and manifest redeploy, or a single vendor-console toggle to re-promote the rule — so a bad migration is a revert, not an incident. And we never disable a vendor rule on a hunch: each Sigma equivalent clears at least a 30-day parallel-fire window catching 95% or more of the vendor's firing events for the same entity before the vendor rule drops to monitor-only, and covered rules sit a further 30 days monitor-only before they are disabled, never deleted. You are never betting the SOC on one big cutover.
See whether your detection content moves into code cleanly.
A call with a senior detection engineer. We inventory your vendor pack by ATT&CK technique and telemetry source, separate the rule classes Sigma can express from the proprietary-telemetry set that stays on the vendor pack, and tell you honestly whether you have the detection-engineering headcount to own it.
Map my migration →