A detection engineer gets a routine-sounding ticket: the security team is standing up a second SIEM during a migration, and the rule that catches a suspicious child process spawned from a script host, the one that's caught two real incidents this year, needs to exist in both places until the cutover finishes. The original is written in Splunk SPL. The new platform speaks Sentinel KQL. The ticket says "port it over."
The naive move is reading the SPL line by line and writing what looks like the same logic in KQL. It compiles, it runs, it even fires on the same test case someone hand-checks. Then a month later a real event that would have tripped the Splunk rule doesn't trip its Sentinel twin, and nobody notices for weeks because the rule looks done.
This is the part that doesn't show up in a demo: the same detection logic behaves differently across SIEMs in ways that aren't visible until you go looking for them.
Why "the same rule" quietly isn't
A few places translation breaks silently, not loudly:
Field names never map one to one. Image in Sysmon-derived data might be process.executable somewhere else, and a rename that's off by one field means the condition never matches anything, not that it matches wrong things. That failure mode is worse: a rule that errors gets noticed, a rule that just never fires doesn't.
Time window and aggregation semantics differ. "More than 5 failed logons" means something different depending on whether the platform's default bucket is a rolling window or a fixed one, and whether the count resets on a successful login. Two engines can both claim "same threshold" and alert at genuinely different rates.
Case sensitivity and wildcard behavior aren't universal. A string match that's case-insensitive by default in one query language and case-sensitive in another will silently miss powershell.exe vs Powershell.exe depending on which system logged it.
Where Sigma actually helps, and where it doesn't
This is the exact problem Sigma was built for: a generic, backend-agnostic detection format that gets converted into SPL, KQL, Elastic EQL and others through a shared translation layer instead of everyone hand-porting rules and drifting apart. Writing the detection logic once in Sigma and generating both backends from the same source cuts out a whole category of copy-paste drift.
What Sigma doesn't do for you is verify the translation actually behaves the same on your data. The generic-to-specific conversion still runs into the field-mapping and semantics gaps above, because the converter doesn't know your schema quirks or your log source's exact field names. The rule that matters is: never trust a translated or ported detection until you've run it against a known-true-positive sample and confirmed it actually fires, in every backend it's supposed to run in, not just the one you tested by hand.
That discipline, writing one rule and correctly proving it holds across SPL, KQL and EQL instead of assuming a port is a port, is what Codelivly's Detection Engineering Book walks through end to end. If you want to practice the translation-and-verification loop hands-on first, the free detection engineering lab and Wazuh rule tuning lab are built around exactly this.
