# how to write a Sigma rule for your SIEM

## TL;DR
Write a YAML rule with a title, a logsource naming the product and category, and a detection section with named selections plus a boolean condition. Keep the logic simple enough to read in one glance, set a level that matches the real severity, and test it against historical logs before enabling alerts. Convert it with sigma-cli to your SIEM's query language (Splunk, Elastic, Sentinel) instead of hand-writing one rule per platform.

## The query
```text
how to write a Sigma rule for your SIEM
```

## Use this when
- you want a portable detection rule that works across SIEMs
- someone asks "how do I write a Sigma rule" or "convert this Sigma to Splunk"
- you are adding a new detection for an attack technique you just read about
- you need to share a detection with another team on a different SIEM

## Not for this skill when
- you need real-time streaming detection with sub-second latency (Sigma is batch and search oriented)
- your SIEM has no Sigma converter support (write native, or add a converter)
- you are tuning an existing noisy rule (that is threshold work, different skill)

## Steps
1. Sketch the behavior in one sentence: "alert when a non-admin process launches an encoded scripting command" or similar.
   Expected output: a single sentence anyone on the team can understand.
2. Write the logsource: name the product (for example windows) and category (for example process_creation).
   Expected output: the rule declares exactly which log stream it reads.
3. Write the detection with named selections and a condition:
   ```yaml
   detection:
     selection:
       CommandLine|contains: '-EncodedCommand'
     filter:
       ParentImage|endswith: 'admin-tool.exe'
     condition: selection and not filter
   ```
   Expected output: the YAML parses and the logic reads as "encoded command lines, except when launched by the admin tool".
4. Set the level (informational, low, medium, high, critical) based on how often the benign version happens.
   Expected output: a level the on-call team agrees matches the noise.
5. Convert and test: run the sigma-cli convert command for your target (for example `sigma convert -t splunk -s rule.yml`) and run the output query against last week's logs.
   Expected output: a result set you can manually review, mostly true positives.
6. Tune with the results: add filters for the benign cases you found, then enable the alert.
   Expected output: the alert fires on the test cases and stays quiet on the benign ones.

### Variant: sigma-cli output targets
Targets like elasticsearch, splunk, sentinel, and qradar cover the common SIEMs. One rule, many backends.

### Variant: correlation rules
Sigma supports timeframe and aggregation conditions for "5 failures in 10 minutes" style rules. Use them when single events are too noisy.

### Variant: rule packages and testing
Keep rules in git, validate syntax in CI, and require a test log sample with each new rule.

## Why this happens
Every SIEM has its own query language, so a detection written for Splunk dies when the team moves to Sentinel. Sigma is the shared intermediate language: the logic lives once in YAML and converters render it per platform.

## Edge cases and pitfalls
- Field names differ per log source. A rule written for one agent's field names wont match another's; check the logsource mapping.
- `|contains` on high-volume fields is expensive. Scope with an index or time window first.
- Rules rot as log formats change. Re-test on a schedule, not just at creation.
- A rule nobody tunes becomes an ignored alert. Assign an owner and a review date.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rLOfNH6Mk7-AjO-RdSocsA