Mastering Sigma Rules: A Deep Dive into Writing Detection Rules for Modern SIEMs

Akshay Jain
Apr 8
5 min read

Updated: Apr 9

In cybersecurity, detection is only half the battle. The other half is making sure your rules actually work!

Security Information and Event Management (SIEM) solutions are at the heart of modern threat detection. But what powers effective detection?

The answer: well-crafted detection rules.

Sigma, a generic signature format for SIEM systems, bridges the gap between raw log data and actionable intelligence. In this blog, we’ll break down what Sigma is, how to write robust Sigma rules, and how they help blue teams respond faster and smarter.

What is Sigma?

Sigma is an open standard for writing detection rules in a SIEM-agnostic format. Developed by Florian Roth and Thomas Patzke, Sigma lets analysts write simple YAML based rules that can be converted into SIEM-specific queries (like Splunk SPL, ElasticSearch DSL, or QRadar AQL) using the Sigma CLI tool.

Why Sigma Matters

Platform independence: One rule format for any backend.
Speed and collaboration: Easy sharing of detections across teams.
Open-source ecosystem: Hundreds of rules and tools available.

Sigma Rule Structure Explained

Sigma rules are written in YAML, a human-readable data-serialization standard that's both easy to understand and machine parsable. The structure is designed to be simple yet expressive enough to capture detection logic across multiple SIEMs.

Here's a breakdown of the rule's anatomy, followed by technical considerations:

title: Suspicious PowerShell Download
id: 9c6a8e04-d470-11eb-b8bc-acde48001122
status: stable
author: AJ
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - "Invoke-WebRequest"
      - "iwr"
  condition: selection
fields:
  - CommandLine
level: high
tags:
  - attack.execution
  - attack.t1059.001

Key Fields

title: A concise, human-readable name for the rule.
id: A unique UUID to track the rule over time.
status: Indicates rule maturity (e.g., stable, experimental, deprecated).
logsource: Defines the data source. Crucial for matching the right log type.
detection: The core logic that defines what patterns to look for.
fields: Specifies which fields to include in the alert output.
level: Indicates severity (low, medium, high, critical).
tags: Often include MITRE ATT&CK mappings for traceability.

Advanced Technical Insights

Supported Sigma Condition Operators

Sigma supports a range of condition operators for flexible logic building:
- selection: Direct match of a pattern.
- condition: selection1 or selection2: Logical OR conditions.
- condition: selection1 and not selection2: Exclusion conditions.
- 1 of selection*: Matches if at least one condition in a group is true.
- all of selection*: All conditions in a group must match.
- selection1 and (selection2 or selection3): Nested Condition

YAML Nuances

Indentation is critical. Use two spaces, not tabs for nested blocks.
Lists use '-' with proper alignment.
Strings containing special characters may need quoting.

Pro Tips for Effective Rule Development

Always test in a non-production environment.
Leverage Sigma CLI with the correct backend target.
Normalize field names using Sigma’s field mapping conventions to improve compatibility.
Validate rules using YAML linters and Sigma schema checkers.

Writing a Sigma Rule: Step-by-Step Guide

Writing Sigma rules involves more than just matching strings. To develop effective and reliable detections, it’s essential to understand the underlying log format, YAML structure, and how rule components interact with SIEM translation engines.

Step 1: Define the Log Source

Clearly specify the data origin to ensure the rule applies to the right event type and log schema.
Use field mappings (fieldmappings in Sigma backend configs) to align different log schemas across platforms like Sysmon, Windows Event Logs, and Linux audit logs.

logsource:
  category: process_creation
  product: window

Step 2: Craft the Detection Logic

This is the heart of the rule. This section uses field-value pairs and conditions to define suspicious activity. Sigma supports several condition operators as mentioned above.

detection:
  selection:
    CommandLine|contains:
      - "Invoke-Expression"
      - "IEX"
  condition: selection

Step 3: Add Metadata

Metadata fields give context and severity to the rule. These do not affect logic but help in classification and alert triage.

tags:
  - attack.execution
  - attack.t1059.001
level: high
fields:
  - CommandLine

Best Practices for Writing Sigma Rules

Use the MITRE ATT&CK framework to tag techniques
Keep detection logic concise and specific
Test rules using sample logs or in lab environments
Use UUIDs to track changes and updates
Follow consistent naming conventions

Real-World Example: Mimikatz Memory Pattern

title: Mimikatz Memory String Indicators
id: 2d9b17dc-17a6-4d95-bb45-3767486d4031
status: experimental
description: Detects Mimikatz execution by identifying known command-line arguments or memory string patterns linked to credential dumping.
author: AJ
date: 2025/04/07
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - "sekurlsa::logonpasswords"
      - "privilege::debug"
      - "lsadump::sam"
      - "sekurlsa::tickets"
      - "mimikatz"
  condition: selection
level: critical
tags:
  - attack.credential_access
  - attack.t1003
  - detection.mimikatz

Detection Engineering and Sigma

Sigma rules form the building blocks for scalable detection engineering workflows.

Teams often:

Use version control (e.g., GitHub) to manage rule sets
Integrate Sigma into CI/CD pipelines for security rule testing
Convert Sigma rules using the sigma CLI tool into SIEM-specific queries

Challenges and Considerations

The effectiveness of Sigma rules depends heavily on the quality and consistency of the underlying log data. If the log fields aren’t standardized (e.g., CommandLine vs cmdline), your detection logic may silently fail. Field normalization using Sigma’s mapping system (via sigma CLI) is crucial to ensure cross-platform compatibility.
Some SIEMs don’t support every Sigma operator
Overly broad rules = high false positives
Always test in a non-production environment first

Sigma rules bring consistency, shareability, and efficiency to detection engineering. Whether you're building detections for Windows process creation events or looking for privilege escalation attempts, Sigma provides a solid foundation for scalable, maintainable threat detection.

And if you’re ever in doubt, just remember the golden rule of Sigma:

It’s better to tune a noisy rule than to miss the quiet attacker.

Course Recommendation & A Huge Thanks!!

I want to take a moment to spotlight a fantastic resource that helped shape my understanding of Sigma rule development.

This blog post is inspired by an incredible course created by Josh Nickels, whose dedication to Detection Engineering has made learning both approachable and deeply insightful. The course is hosted on The Taggart Institute, an exceptional platform founded by Michael Taggart that’s committed to providing high-quality, low-cost cyber security education to everyone.

The course, titled "Automated Detection with Sigma" walks you through everything from writing and converting Sigma rules, to deploying them into Splunk SIEM, automating detection pipelines, and even managing rules through GitHub-based workflows. Whether you're new to cybersecurity or brushing up on detection strategies, it's a gem.

Check out the course here: Automated Detection with Sigma

A big thank you to both for making this kind of high-impact learning available to the community!!

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don’t forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let’s keep the conversation going and make cybersecurity a community effort!

-AJ