Convert One Sigma Rule to KQL, SPL, and Elastic with Validation

Tier: Core · Workflow area: Detection engineering with AI

This playbook uses a transpiler-first workflow (pySigma does the deterministic conversion) with the LLM handling only the field-mapping gaps, and every backend proven against the same test data.

When to reach for this

• •
  One detection must live in multiple SIEMs with different query languages and field schemas.
• •
  pySigma's backend gets you most of the way but the field mappings for your environment are incomplete.
• •
  You want the three deployed queries to be provably equivalent, not "probably the same."

Skip the LLM entirely when a pySigma backend already has a complete mapping for your environment — the transpiler alone is more reliable than any model.

The workflow

1. 1.

   Transpile deterministically first. Run the Sigma rule through pySigma for each backend. The transpiler is deterministic and correct where it has a field mapping — use it as the source of truth and only bring in the LLM for what it cannot resolve.

   Copy

   sigma convert -t kusto rule.yml       # KQL / Sentinel
   sigma convert -t splunk rule.yml      # SPL
   sigma convert -t esql rule.yml        # Elastic
   

2. 2.

   Use the LLM only to close mapping gaps. When a backend errors on an unmapped field or your environment uses non-standard column names, ask for the mapping — not a free rewrite.

   Copy

   pySigma could not map field "SourceImage" for the Splunk backend against
   our schema. Our Sysmon data in Splunk uses these field names: [paste real
   field list]. Give me ONLY the field-mapping (Sigma field -> our field) so
   I can add it to the pipeline config. Do not rewrite the whole query; do not
   invent field names outside the list I gave you.
   

   Expected output: a small, checkable field-mapping table you add to the pySigma pipeline — not a hand-written query you have to trust wholesale.

3. 3.

   Read all three generated queries side by side. Confirm each references fields that exist in that SIEM's schema and that the logic (AND/OR/NOT structure) is identical across all three. Divergence means one translation drifted.

4. 4.

   Run every backend against the same test data. Load an identical known-bad and known-good sample into each SIEM (community editions) and confirm all three fire on the bad and stay silent on the good. Equivalent rules must produce equivalent verdicts.

5. 5.

   Diff the result sets. If KQL matches the bad sample but SPL does not, the SPL translation is wrong — usually a case-sensitivity or wildcard-semantics difference. Fix the mapping and re-run until all three agree.

Verify before you trust it

• Field-existence check per backend: each SIEM has a different schema. Confirm every field in the KQL query exists in the KQL data, every SPL field in the SPL data, and so on. A field that is valid in one is often absent in another.
• Semantics check: verify operator equivalence across dialects — KQL has is not SPL =, and Elastic wildcards differ from both. Mistranslated operators are the classic silent failure.
• False-positive catch across backends: run all three against the same known-good sample. If one lights up and the others do not, that backend's translation is over-broad — reconcile before deploying any of them.

Pitfalls

• Letting the LLM rewrite instead of map. A free-rewritten query drops pySigma's correctness guarantees and reintroduces hallucinated fields. Keep the model on mappings only.
• Case and wildcard drift. SIEMs differ on case-sensitivity and wildcard behavior; a translation that ignores this matches different events in each system while looking identical.
• Testing only one backend. Validating the KQL and assuming SPL "must be the same" is how divergent detections ship. Test every backend against the same data.
• Stale pipeline configs. A field mapping written for last quarter's schema silently breaks when the schema changes. Version the mapping with the schema.

Tools

• Sigma + pySigma backends (sigma-cli): the deterministic transpiler that does the real conversion work across KQL/SPL/Elastic.
• SIEM community editions (Elastic, Splunk Free): where you load identical test data and prove all three queries agree.
• Open LLM run locally (Ollama): resolves the field-mapping gaps pySigma cannot, without exposing your schema.

Client-safe variant

Field mappings expose a client's schema and naming conventions, so treat them as sensitive. Run the LLM mapping step on a local Ollama model or the client's approved endpoint, and where possible give it a generalized field list rather than the client's literal index names. Do all three-way testing against the client's sample or lab indices in their own SIEM instances. Commit the pySigma pipeline config and the validated queries into the client's detection repository so the mappings are versioned alongside their schema — the equivalence proof (identical verdicts on identical test data) is the artifact the client's detection owner signs off on.