Findings with a detectable log signal can generate a starter Sigma rule — a starting point, not a deployed detection. This guide covers where the rules come from and how to adapt them to your SIEM responsibly.
The lifecycle is the discipline: starter means generated, tuned means adapted and tested in your environment, verified means recorded evidence shows it fires. Never skip a step because the YAML looks finished.
Where rules come from
- The generator creates a starter rule when a finding has a signal that can appear in logs. Not every finding can be detected this way.
- Download the full bundle from the run page (Download Sigma rules .yml button) or via API: GET /v1/demo/runs/{run_id}/sigma for sandbox runs, GET /v1/runs/{run_id}/sigma for tenant runs.
- Each rule ships with a starter disclaimer — tune field names, thresholds, and log source paths for your SIEM before deploying to production.
The generator creates a starter rule only when a finding has a signal that can appear in logs — not every finding can. Download the full bundle from the run page or via the API, and treat each rule's disclaimer as part of the artifact.
Import and tune
- Splunk: pipe the YAML to sigma-cli convert -t splunk. Import the resulting SPL as a correlation search. Set timeframe and threshold to match your log ingestion latency.
- Elastic (ESQL / Security Solution): use sigma-cli convert -t esql or the Security Solution import endpoint. Map sigma.logsource.service to the matching index pattern in your deployment.
- Move from `starter` to `tuned` only after adapting and testing the rule. Use `verified` only when recorded evidence shows that it detects the expected case without an unacceptable false-alert rate.
Convert with sigma-cli to your platform — Splunk SPL or Elastic ESQL — and map the log source to your actual LLM request log index. Set timeframes and thresholds from your own traffic, and move a rule forward only after adapting and testing it.