Sigma — Generic SIEM Detection Rule Format

Introduction

Sigma is an open, vendor-agnostic format for writing detection rules that can be converted to queries for various SIEM platforms. Maintained by the SigmaHQ community, it provides a shared language for describing log-based detections so that security teams can write rules once and deploy them across Splunk, Elasticsearch, Microsoft Sentinel, and many other backends. The project includes a large repository of community-contributed detection rules.

What Sigma Does

• Defines a YAML-based rule format for describing log event patterns and detection logic
• Converts rules into native queries for dozens of SIEM and log analysis platforms
• Maintains a curated repository of community-written detection rules covering common attack techniques
• Maps rule fields to platform-specific log schemas using processing pipelines
• Supports rule metadata including MITRE ATT&CK mappings, severity levels, and false positive notes

Architecture Overview

Sigma consists of three layers: the rule specification, processing pipelines, and backend converters. Rules are written in YAML with a standardized schema covering log source, detection logic, and metadata. Processing pipelines handle field name mapping and value transformations to adapt generic rules to specific log formats like Sysmon or Windows Security logs. Backend converters (built on pySigma) translate the processed rules into the native query language of the target platform, such as SPL for Splunk or KQL for Microsoft Sentinel.

Self-Hosting & Configuration

• Install sigma-cli via pip for command-line rule conversion
• Clone the SigmaHQ/sigma repository to access the full community rule collection
• Install backend plugins for your target SIEM using sigma plugin install
• Processing pipelines are configured per backend to handle field mapping and log source translation
• Rules can be integrated into CI/CD pipelines for automated deployment to SIEM platforms

Key Features

• Support for 20+ SIEM backends including Splunk, Elasticsearch, QRadar, and Microsoft Sentinel
• MITRE ATT&CK technique tagging on rules for threat coverage analysis
• Modular processing pipelines that separate log schema mapping from detection logic
• Rule validation and testing tools for CI/CD integration
• Active community contributing thousands of detection rules for known threats and attack patterns

Comparison with Similar Tools

• YARA: Designed for file and memory pattern matching in malware analysis; Sigma focuses on log-based event detection in SIEM systems
• Snort/Suricata: Network intrusion detection with packet-level rules; Sigma operates on parsed log events rather than raw network traffic
• Elastic Detection Rules: Native to the Elastic stack; Sigma is platform-agnostic and converts to Elastic queries among many other formats
• Splunk Security Content: Splunk-specific detections; Sigma rules can target Splunk but also work with any supported backend

FAQ

Q: Which SIEM platforms does Sigma support? A: Sigma supports Splunk, Elasticsearch/OpenSearch, Microsoft Sentinel, QRadar, CrowdStrike, Grafana Loki, Google Chronicle, and many others through pySigma backend plugins.

Q: Can I write custom Sigma rules for my organization? A: Yes. Sigma rules are YAML files following a documented specification. You can write custom rules, validate them with the sigma-cli tools, and convert them to your SIEM's query language.

Q: How does Sigma handle different log formats across platforms? A: Processing pipelines map generic field names in Sigma rules to platform-specific field names. For example, a pipeline might map the generic CommandLine field to process.command_line in Elastic Common Schema.

Q: Is there a way to test Sigma rules before deploying them? A: Yes. The sigma-cli includes validation commands, and the community provides test frameworks for verifying that rules match expected log events and do not produce excessive false positives.

Sources

• Repository: https://github.com/SigmaHQ/sigma
• Documentation: https://sigmahq.io/docs/guide/getting-started.html