Follow Detection rule portability is the practice of writing and managing threat-detection logic so it moves across SIEM, EDR, and XDR platforms without a full rewrite.
What happens to my detection rules when I migrate to a new SIEM platform?
Rules written in a platform’s native query language do not travel. SPL stays in Splunk. KQL stays in Microsoft Sentinel. YARA-L stays in Google SecOps. When you migrate, those rules must be rewritten or translated for the destination platform.
Translation fidelity depends on the construct, not the language pair. Two degradation axes decide what survives.
Axis 1: field mapping. Source field taxonomies (CIM, ASIM, ECS, OCSF, Sysmon-native, vendor-native) map incompletely. An unmapped or renamed field silently narrows or breaks the rule.
Axis 2: construct semantics. Aggregation and time-window semantics, sequence or transaction logic, regex dialect, and eval/lookup/join-style functions often have only partial analogues on the target platform. This axis carries the rewrite share.
Sigma rules are designed for translation. They are authored once and translated per backend via pySigma, sigma-cli, or Uncoder.
Translation is not preservation. Every translated rule still requires backend-specific validation against the destination’s parsed fields before it is trusted. A syntactically correct translation can reference fields the new platform never populates.
Telemetry pipeline routing is a separate mechanism. Routing a log stream to a new destination does not port the detection logic that ran on it. SPL stays SPL regardless of where the logs land.
What’s the difference between vendor-specific and vendor-agnostic detection rules?
A vendor-specific rule is an asset of the platform. A vendor-agnostic rule is an asset of the team.
| Dimension | SPL (Splunk) | KQL (Microsoft Sentinel) | YARA-L (Google SecOps) | Sigma |
|---|---|---|---|---|
| Runs natively on | Splunk | Microsoft Sentinel | Google SecOps | None directly. Translates to all three plus IBM QRadar, Elastic, CrowdStrike, and others. |
| Moving it requires | Rewrite in the target language | Rewrite in the target language | Rewrite in the target language | Translation via pySigma/sigma-cli or Uncoder, then field-mapping validation |
| Who owns it | The Splunk deployment | The Sentinel workspace | The SecOps tenant | Your team, in version control |
| Multi-platform cost | Write N copies | Write N copies | Write N copies | Translate once per backend, validate once per backend |
The cost difference shows up at migration and at multi-platform operation. Vendor-agnostic detection logic stays portable across your stack.
How do I migrate detection content from Splunk to Microsoft Sentinel?
Six steps. This is one of the harder language pairs because SPL and KQL differ on data model, field naming, and function semantics.
- Inventory SPL rules. Export every saved search, alert, and correlation search. Record each rule’s data model dependencies (sourcetype, index, field names).
- Classify by construct type. Sort rules into three bins: plain selection logic (ports clean), field-mapping-dependent (ports with mapping work), and correlation/stateful logic (expect a hand rewrite).
- Translate via Sigma. Convert SPL rules to Sigma, then translate Sigma to KQL using pySigma with the Microsoft Sentinel backend, sigma-cli, or Uncoder. This handles syntax. It does not handle field mapping.
- Map fields against the Sentinel schema. Align CIM field names to ASIM equivalents. Microsoft documents their schema at learn.microsoft.com. Every field in the translated rule must resolve to a column in the destination table.
- Test on Sentinel tables. Run each translated rule against real ingested data. Keep a test event per rule so you can verify matching after any schema change.
- Cut over with a parallel-run window. Run both platforms on the same log sources. Compare alert output. Retire the SPL version only after the KQL version fires on the same events.
Before cut-over, map the deployed rules on both platforms to MITRE ATT&CK techniques and compare the two maps, so a technique the migration drops shows up before cut-over, not after; SOC Prime’s MITRE ATT&CK Audit maps deployed detections and data sources to ATT&CK as a service.
Migrating a rule library? Explore SOC Prime’s Prime Architect for cross-platform rule translation, threat research, and detection engineering workflows.
What are the best practices for translating query languages like SPL to KQL?
Translate logic, not syntax. A character-by-character port produces fragile rules that reference fields the destination may not populate.
- Map fields against the destination schema. Do not assume field names carry over. Splunk CIM and Sentinel ASIM are different contracts. The migration effort sits in the mapping between them.
- Keep a test event per rule. A known-bad event paired with a known-benign event. If the translated rule does not match the bad and reject the benign, something broke in translation.
- Review anything the translator flags. Automated translators handle plain selection logic well. Correlation rules, proprietary functions, and complex aggregations need human review.
- Name your tools. Prime Architect translates Sigma into 65 detection languages, migrates between native query languages such as SPL and KQL, applies field-mapping presets for the environment you connect, and deploys from a governed rule repository into a supported target platform. The open-source Uncoder IO covers the translation step and can run self-hosted (source on GitHub). None of the three eliminates field-mapping validation.
Example: a simple process-creation rule translating EventCode=4688 and New_Process_Name (Splunk CIM) to EventID == 4688 and NewProcessName (Sentinel SecurityEvent table). Same fact, different field name per platform contract.
The SPL trailing-anchored wildcard becomes a KQL endswith operator. This pair works because it is a single-event field match. Correlation rules do not translate this cleanly.
How long does migrating a rule library take, and what drives it?
Three drivers determine effort.
Rule count. More rules, more validation cycles. Each translated rule needs a test run against the destination’s ingested data.
Custom fields and data model dependencies. Rules that reference vendor-specific fields, custom extractions, or lookup tables require per-field mapping work. The more customization in the source, the more hand work in the migration.
Validation effort. Every translated rule must be validated against the destination platform’s parsed fields. A syntactically correct translation can silently fail if the target schema does not populate the referenced field.
The honest deliverable from a migration assessment is a per-rule classification: ports clean, ports with mapping work, or requires a hand rewrite. A single time estimate for the whole library misrepresents the distribution of effort.
How do you avoid lock-in next time?
Three practices.
- Author in Sigma. Write vendor-agnostic detection logic from the start. Sigma rules translate to every major SIEM, EDR, and XDR platform. Detection content sourced already in Sigma, such as the Sigma rules in SOC Prime’s Core, keeps the library portable from the first rule.
- Keep logic in version control. Store your detection rules in Git alongside the field mappings and test events for each target backend. The rules travel with the team, not the platform.
- Translate at deploy. Use pySigma, sigma-cli, or Uncoder to generate platform-native queries at deployment time. The source stays portable. The compiled output is disposable.
This separation means a platform migration changes the translation target, not the detection logic.
Is routing telemetry through a pipeline the same as porting your detections?
No. A telemetry pipeline (Cribl and similar tools) moves data. It does not move detection logic.
Routing a log stream from Splunk to Microsoft Sentinel through a pipeline delivers the events to a new destination. The SPL rules that ran on those events in Splunk do not follow. SPL stays SPL. The detection logic must still be translated or rewritten for the destination platform.
Pipeline routing solves the data-delivery problem. Detection portability solves the logic-translation problem. They are independent. A team that routes telemetry to a new SIEM without porting its detections has data in a new place and no rules to match on it.
The exception is a pipeline that runs the detections itself: SOC Prime’s Prime Detect applies rules in Sigma at the pipeline layer before the SIEM, and its open-source edition is on GitHub.
Where this does not hold
Not everything translates, even with Sigma. Four construct classes require hand rewrites on the destination platform.
- Correlation and stateful logic. Count and value aggregation, temporal sequence, multi-event correlation. Sigma added correlation rule types in its v2 specification, but backend support varies per pySigma backend. Scheduling versus streaming execution also changes what a rule can express.
- Proprietary functions. Splunk transaction, eval expressions, lookup-driven enrichment, macros. KQL analogues are partial.
- Some aggregation patterns. Threshold-over-window constructs and stats … by … span= patterns translate unevenly across platforms.
- Schema-contingent field references. The same Sigma process_creation rule lands on a different field depending on the pipeline. On Sysmon it is Image. On Splunk Windows Security it is New_Process_Name. The translation is correct only against the schema actually deployed.
These constructs are where the per-rule classification matters most. Expect them to require manual validation and, in many cases, a ground-up rewrite.
Migration readiness checklist
[ ] Full rule inventory exported (saved searches, alerts, correlation searches)
[ ] Each rule classified: ports clean / ports with mapping / rewrite required
[ ] Field-mapping table built: source schema to destination schema
[ ] Sigma versions of portable rules created and stored in version control
[ ] Translation tooling selected (pySigma/sigma-cli, Uncoder, or both)
[ ] Test event pairs created per rule (one known-bad, one known-benign)
[ ] Translated rules validated against destination tables with real ingested data
[ ] Correlation and stateful rules identified for hand rewrite
[ ] Proprietary functions cataloged (transaction, eval, lookups, macros)
[ ] Parallel-run window defined: both platforms ingesting same sources
[ ] Alert-output comparison criteria documented
[ ] Rollback plan defined: conditions for reverting to source platform
FAQ
What happens to my detection rules when I migrate to a new SIEM platform?
Platform-native rules do not travel. SPL, KQL, and YARA-L must be rewritten or translated for the destination platform. A rule authored in Sigma is translated once per backend, and every translated rule still needs validation against the destination’s parsed fields. Correlation, stateful logic, proprietary functions, and some aggregation patterns do not translate cleanly.
How do I migrate detection content from Splunk to Microsoft Sentinel?
Inventory the SPL rules, classify each by construct type, translate through Sigma with pySigma or Uncoder, map fields from the Splunk schema to the Sentinel schema, test each rule against real ingested Sentinel data, then cut over with a parallel-run window before retiring the SPL version. Microsoft documents the Sentinel schema at learn.microsoft.com.
What is the difference between vendor-specific and vendor-agnostic detection rules?
A vendor-specific rule is an asset of the platform it runs on. A vendor-agnostic rule authored in Sigma is an asset of the team, kept in version control and translated per backend. The cost difference shows up at migration and at multi-platform operation.
Does routing telemetry through a pipeline make my detections portable?
No. A telemetry pipeline moves data to a new destination. It does not move the detection logic that ran on it. SPL stays SPL wherever the logs land, so the rules still need translation or a rewrite.
What are the best practices for translating a query language like SPL to KQL?
Translate the logic, not the syntax. Map every field against the destination schema, keep a known-bad and a known-benign test event per rule, and review anything the translator flags, because correlation rules and proprietary functions need human review. pySigma, sigma-cli, and Uncoder handle Sigma translation, and none of them removes field-mapping validation.
Assess your existing SIEM coverage and create a plan for your transition by using Prime Hunt. Prime Hunt reviews all of your SIEM rules, identifies gaps and charts you on a course to complete coverage – critical work before a SIEM migration.
