Choosing a rule language per estate

The rule language question looks like taste. It is a cost question. A native language gives you every feature the engine has. A portable one gives you the option to leave. This guide sets out what each estate documents and gives a rule for choosing.

Native languages give you fidelity and lock you in

A rule in the engine's own language can use every operator, every enrichment and every platform quirk. It is also useless anywhere else. That is the trade.

Here is what each platform documents, from public docs read on 2026-11-03 and 2026-11-04.

Microsoft Sentinel analytics rules are KQL queries. Rule content deploys as Bicep or ARM templates, and the docs include a PowerShell script to convert public YAML rules. No Sigma path appears on the pages read (Sentinel custom content CI/CD, read 2026-11-04).

Splunk Enterprise Security detections are scheduled correlation searches written in SPL, and the content ships as YAML built by contentctl (Splunk detections docs, read 2026-11-03).

Google Security Operations uses YARA-L 2.0, documented in depth with meta, events, match, outcome and condition sections. The YARA-L examples page presents YARA-L 2.0 as the language for detection rules, and shows the same syntax used for UDM searches, dashboard queries and reference list checks (YARA-L 2.0 examples, read 2026-11-04). That page names no other rule language and no Sigma conversion path, and it does not say whether either exists.

Elastic offers more choice. Rule types include event correlation in EQL and ES|QL, and custom query rules in KQL or Lucene (Elastic rule types, read 2026-11-03). ES|QL is described as a piped query language for filtering, transforming and analysing data (Elastic ES|QL docs, read 2026-11-03).

Panther writes detections in Python, as rules, scheduled rules and correlation rules, and converts Sigma through sigma-cli (Panther detections docs, read 2026-11-04). Python gives you real unit tests and libraries. It also means a rule is a program and needs a reviewer who reads code.

Sekoia runs native Sigma YAML with correlation, and its own SOL queries as scheduled detection rules, with no stated relation to KQL (Sekoia Sigma rules, read 2026-11-03).

Sigma gives you portability and costs you features

Sigma is the portable choice. One rule converts to Splunk, Kusto and Elasticsearch backends, and a Google SecOps backend exists with status Development (Sigma backends, read 2026-11-03). The main repository states more than 3,000 community rules (SigmaHQ README, read 2026-11-03).

The cost is the lowest common denominator. A Sigma rule cannot use a platform feature the spec lacks. Complex joins, platform enrichments and engine-specific functions stay out. You also own the conversion step and its failures, covered in a separate guide. For many detections, process creation and simple log matching among them, Sigma is enough. For the rest, write native.

Vendors that do not name a language

Some vendors deploy to your SIEM and do not say what they emit. Anvilogic names Splunk, Azure Sentinel, CrowdStrike NG-SIEM and Elastic as targets and does not name the rule languages (Anvilogic home page, read 2026-11-04). Detecteam lists Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, AWS Security, Databricks and Cribl Stream as targets and names no rule language (Detecteam, read 2026-11-04). Hunters normalises data to OCSF and the platform page names no rule language (Hunters platform, read 2026-11-04). Mate Security does not say which language its agents write, and ranks eleventh of fourteen on the proposed scores.

That is a review problem. If an agent or a service writes rules into your SIEM, you need to read them. Ask for the output language and an export before you sign. A rule you cannot read in your own language cannot go in your repo.

A decision rule by estate

Use this as a starting point. Adjust for your team.

One SIEM, no plans to move: write native. Sentinel, Splunk, Google and Elastic estates all get the most from their own language, and the native CLI or repository connection takes native files.

One SIEM, a team that wants a reviewable common format: write Sigma for the 70 percent of rules it covers and native for the rest. The 70 percent is a rough planning figure from practice, not a measured one. Count your own.

Two or more SIEMs, for example Splunk on premises and Sentinel in the cloud: Sigma first. Keep the pipeline with its field mappings in one repo and generate per-platform output.

Starting from scratch with no SIEM chosen: pick the SIEM first, then the language. If you want the choice kept open, start with Sigma and Panther's documented Sigma path, or Sekoia's native Sigma.

A SIEM that is changing owners or direction: favour Sigma. Panther agreed to be acquired by Databricks on 2026-06-16, with completion unconfirmed on the pages read (Security Boulevard, read 2026-11-03). Splunk's contentctl README says future investment is shifting to Detection Studio (read 2026-11-03). Neither fact says leave. Both say keep an exit.

Skills matter as much as syntax

The best language is the one three people on your team can review. If nobody writes YARA-L well, a YARA-L estate leaves your detections to one person. Count the reviewers before you choose. Python is flexible and reviewers are scarce. KQL and SPL reviewers are common. Sigma reviewers are common, and the format is YAML, which lowers the barrier for analysts who do not code.

Checklist

• Name your SIEMs today and the ones you might run in 24 months.
• List the three people who can review each language you use.
• Pick native, Sigma or both, and write the rule for when to use which.
• If you use Sigma, keep field mappings and pipelines in the repo.
• Check the backend status for every Sigma target you plan to use.
• Ask any vendor that writes rules for the output language and an export.
• Keep one rule in each language in the test suite so a platform change shows up.
• Review the decision when you change SIEM, owner or team size.