Writing Sigma Rules

Sigma is a generic, vendor-neutral signature format for log-based detections. You write the detection logic once in YAML, then convert it to Splunk SPL, Elastic queries, Sentinel KQL, and many other backends.

Sigma is to log detection what YARA is to file detection: a portable lingua franca. It lets teams share rules publicly and avoid rewriting the same idea per SIEM.

A Sigma rule is a YAML document with required and optional sections. The essentials are title, logsource, and detection.

The logsource block tells the converter which logs the rule applies to. It does not query data directly; it selects the right field mapping and index during conversion.

Common keys:

• product — e.g. windows, linux, aws
• category — e.g. process_creation, network_connection, file_event
• service — e.g. sysmon, security, sshd

Pick the most specific combination your data supports so the pipeline maps fields correctly.

Inside detection you define one or more named search identifiers (selections). Each is a map of field-to-value criteria. Multiple fields inside one selection are joined with logical AND.

Here both conditions must be true for selection to match.

Modifiers refine how a value is matched. They attach to the field name after a pipe.

• contains — substring match
• startswith / endswith — anchored match
• all — every value in a list must be present
• re — regular expression
• base64offset|contains — match base64-encoded substrings

Modifiers chain left to right, applied in order.

Two rules govern logic inside a selection:

• A list of values under one field is OR — any value matches.
• A map of multiple fields is AND — all fields must match.

Below, Image matches either binary, and User must also equal SYSTEM.

The condition combines your named selections with boolean logic. This is where you express filters and exclusions.

Operators include and, or, not, parentheses, and aggregations like count(). You can also use 1 of selection* / all of selection* to reference groups of identifiers by prefix.

To suppress known-good activity, define a separate identifier and subtract it in the condition with not. This keeps the malicious logic readable and the exclusions explicit.

Here the rule fires on rundll32 spawning a network connection, except for a known legitimate update process.

Beyond logic, good rules carry metadata that helps responders act fast and helps engineers maintain coverage.

• level — informational, low, medium, high, critical
• tags — ATT&CK techniques, e.g. attack.t1059.001
• falsepositives — known benign triggers
• references — threat reports or docs
• author and date

These fields cost minutes to write and save hours during an incident.

Single-event rules cannot express multi-step attacks. Sigma correlation rules combine multiple base rules over time to catch sequences and patterns.

Supported types include event_count (N matches in a window), value_count (distinct values, e.g. many failed users), and temporal (rule A then rule B). This lets you detect, say, a successful login right after a burst of failures.

With sigma-cli you convert a rule to your target query language. A processing pipeline maps Sigma field names to your real schema.

The output is a ready-to-deploy query you can paste or push via API.

Check your grasp of Sigma detection logic.

You can now author portable Sigma rules:

• logsource selects which logs and field mappings apply
• Selections are named field-value criteria (fields = AND, value lists = OR)
• Modifiers like contains, endswith, all, re refine matching
• condition joins selections with and/or/not, filters, and aggregations
• Separate filter identifiers subtract known-good noise
• Metadata (level, tags, falsepositives) speeds triage
• sigma convert compiles the rule to your SIEM backend

Next, you will tie these rules to adversary techniques with MITRE ATT&CK.