Sigma Rules Explained

What Are Sigma Rules?

Sigma rules are a generic, open-source signature format for writing detection logic that works across multiple SIEM platforms. Think of Sigma as the YARA for log files — it defines what to look for in log data without being tied to any specific query language.

Sigma was created by Florian Roth and the Sigma project community to solve a fundamental problem: security teams write detection rules once, then manually rewrite them for Splunk, Elastic, QRadar, Microsoft Sentinel, and every other SIEM. Sigma eliminates that redundancy by providing a single, platform-agnostic format that can be automatically converted into native queries.

Sigma Rule Format

Every Sigma rule follows a structured YAML format with several mandatory and optional sections. Here is the anatomy of a Sigma rule:

Title and Identification

title: Suspicious PowerShell Execution
id: abc12345-6789-def0-1234-56789abcdef0
status: experimental
date: 2026-07-01
author: Security Team

The title is a human-readable name. The id is a UUID that uniquely identifies the rule across installations. status indicates maturity — common values are stable, test, experimental, and deprecated.

Log Source

logsource:
  category: process_creation
  product: windows
  service: sysmon

The logsource section describes the type of log data the rule targets. It typically includes category (e.g., process_creation, network_connection), product (e.g., windows, linux), and service (e.g., sysmon, security). This metadata ensures the rule only matches against relevant log sources.

Detection

detection:
  selection:
    Image|endswith: '\\powershell.exe'
    CommandLine|contains:
      - '-EncodedCommand'
      - '-Enc'
      - '-E '
  condition: selection

The detection section is the heart of the rule. It defines log field mappings and value matches using a range of modifiers:

• |contains — substring match
• |endswith — suffix match
• |startswith — prefix match
• |re — regular expression match
• |all — all values must match
• |gt, |lt — numeric comparisons

False Positives and Tags

falsepositives:
  - Administrative scripts
  - Approved automation tools
level: high
tags:
  - attack.execution
  - attack.t1059.001

Falsepositives documents known scenarios that might trigger the rule. level sets severity (low, medium, high, critical). tags map to MITRE ATT&CK techniques for enrichment and correlation.

Why Sigma is SIEM-Agnostic

Sigma achieves SIEM independence through backends — converter tools that translate Sigma rules into native query languages. The sigmac tool and pySigma library support dozens of target formats:

• Splunk Search Processing Language (SPL)
• Elasticsearch Query DSL / EQL
• QRadar AQL
• Microsoft Sentinel (KQL)
• LogRhythm
• Shieldlix native queries

This means you can write a rule once and deploy it to your entire SIEM ecosystem. Organizations running Shieldlix SIEM can import the Sigma rule repository directly and have detection logic running in minutes.

Example Sigma Rule: Suspicious PowerShell

Here is a complete Sigma rule that detects suspicious PowerShell execution with encoded commands — a common technique used by malware and ransomware:

title: Suspicious PowerShell EncodedCommand
id: a7b8c9d0-1234-5678-9abc-def012345678
status: experimental
description: Detects PowerShell execution with
  encoded command parameters
logsource:
  category: process_creation
  product: windows
  service: sysmon
detection:
  selection:
    Image|endswith: '\\powershell.exe'
    CommandLine|contains:
      - '-EncodedCommand'
      - '-enc'
      - '-e '
  filter:
    CommandLine|contains:
      - 'approved_script.ps1'
  condition: selection and not filter
falsepositives:
  - Approved administrative scripts
level: high
tags:
  - attack.execution
  - attack.t1059.001

Converting to Other Formats

The same rule converted to different SIEM formats:

Splunk SPL:

source="WinEventLog:Microsoft-Windows-Sysmon/Operational"
EventCode=1
Image=*\\powershell.exe
(CommandLine=*-EncodedCommand* OR CommandLine=*-enc* OR CommandLine=*-e *)
NOT CommandLine=*approved_script.ps1*

Elasticsearch EQL:

process where process.name == "powershell.exe"
  and (
    process.command_line : "*-EncodedCommand*"
    or process.command_line : "*-enc*"
    or process.command_line : "*-e *"
  )
  and not process.command_line : "*approved_script.ps1*"

How to Write Your First Sigma Rule

Follow these steps to create and test your own Sigma rule:

1. Identify the behavior — Choose a specific technique you want to detect (e.g., LSASS dumping, scheduled task creation, registry persistence).
2. Find the log source — Determine which log produces the relevant events. Sysmon Event ID 1 for process creation, Windows Security Event ID 4688, etc.
3. Write the YAML — Use the format above as a template. Be specific with field matches and include filters to reduce noise.
4. Test with Sigma CLI — Use sigma-cli or pySigma to validate your rule syntax and convert it to your target SIEM.
5. Convert and deploy — Run the converter for your SIEM and deploy the generated query. In Shieldlix Detection, you can import Sigma rules directly.

Shieldlix and Sigma Compatibility

Shieldlix Detection provides native Sigma rule support, including:

• Direct rule import — Upload any Sigma rule YAML and Shieldlix converts it automatically.
• Sigma rule marketplace — Browse hundreds of community-contributed rules curated by the Shieldlix team.
• Automated conversion — Shieldlix translates Sigma rules into optimized internal queries with no manual work.
• Bulk import from GitHub — Sync from the sigma/sigma repository or your private fork.
• Version tracking — Know when upstream rules change and review diffs before updating.

For teams building a detection program from scratch, combining Sigma with Shieldlix SIEM gives you a community-backed detection library with enterprise-grade performance.

Best Practices for Sigma Rules

• Start with stable rules — Use rules with status: stable in production. Test experimental rules in a staging environment first.
• Add filters aggressively — A rule with no false positives is more valuable than a broad rule that generates alert fatigue.
• Tag with MITRE ATT&CK — Mapping rules to tactics and techniques makes alert triage and reporting much easier.
• Keep detection logic simple — Complex conditions are harder to maintain and harder to convert across backends.
• Use specific field names — Avoid generic field names that may not exist in all log sources.
• Version your rules — Track changes with the modified field and update the id if the detection logic changes significantly.

Conclusion

Sigma rules have become the standard for writing portable, SIEM-agnostic detection logic. Whether you are securing a single office or a global enterprise, Sigma lets you write detection rules once and deploy them everywhere. Combined with a modern SIEM like Shieldlix, Sigma rules give your security team a head start on threat detection without the vendor lock-in.