# Sigma Rules
PDM Domain(s): TID, RGA
Sigma is a generic and open signature format that allows security teams to write detection rules once and deploy them across any SIEM platform. Often described as "YARA for logs," Sigma provides a vendor-neutral way to express detection logic that can be automatically converted into queries for Splunk, Elastic, QRadar, Microsoft Sentinel, CrowdStrike Falcon LogScale, and dozens of other platforms.
Created by Florian Roth and Thomas Patzke in 2016, Sigma emerged from a fundamental problem in detection engineering: every SIEM platform uses different query languages, but the underlying attack techniques remain consistent across environments. A detection rule for PowerShell Empire lateral movement should work the same way whether the organization uses Splunk's SPL, Elastic's Lucene syntax, or Microsoft's KQL. Sigma makes this possible by providing an abstraction layer that separates detection logic from platform-specific implementation.
The format has become the de facto standard for sharing log-based detection rules in the security community. The SigmaHQ repository now contains over 3,000 community-reviewed rules covering Windows event logs, Linux auditd, cloud service logs, web server logs, and application logs. Major threat intelligence providers, including MITRE, publish detection content in Sigma format. Security vendors build Sigma conversion capabilities into their platforms. When security researchers discover new attack techniques, they increasingly publish detection logic as Sigma rules rather than platform-specific queries.
Sigma fundamentally changes how organizations approach detection engineering by decoupling rule development from SIEM vendor selection. Instead of building detection libraries that lock teams into specific platforms, Sigma enables portable detection capabilities that survive technology migrations and enable multi-platform deployments.
Sigma rules are written in YAML format with three primary components: metadata, log source specification, and detection logic. The metadata section includes fields like title, description, MITRE ATT&CK technique mapping, severity level, and false positive guidance. The log source section identifies the type of logs the rule analyzes using product, service, and category fields. The detection section contains the actual logic for identifying suspicious activity.
Here is a basic Sigma rule that detects suspicious PowerShell execution:
title: Suspicious PowerShell Invocation
description: Detects PowerShell execution with encoded command parameters
author: Security Team
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains:
- '-EncodedCommand'
- '-enc'
- '-ec'
condition: selection
level: medium
tags:
- attack.execution
- attack.t1059.001This rule identifies Windows process creation events where PowerShell runs with encoded command parameters, a common technique for obfuscating malicious scripts. The pipe symbols indicate field modifiers: endswith matches strings ending with the specified value, while contains matches strings containing any of the listed values.
Detection logic supports complex boolean operations through multiple selection conditions. Rules can combine positive selections with exclusion filters to reduce false positives. For example, a rule detecting suspicious network connections might exclude known administrative tools or legitimate software update mechanisms:
detection:
selection:
Image|endswith: '\powershell.exe'
DestinationPort: 443
filter:
DestinationHostname|endswith:
- '.microsoft.com'
- '.windowsupdate.com'
condition: selection and not filterSigma supports over twenty field modifiers for different data manipulation needs. The base64 modifier automatically decodes Base64-encoded values. The base64offset modifier handles Base64 strings that do not start at expected boundaries. Regular expression support through the re modifier enables pattern matching for complex attack indicators. The all modifier requires that all specified values appear in a field, while 1of requires at least one match from a list.
The pySigma framework handles conversion from Sigma rules to SIEM-specific queries through backend plugins. Each backend translates Sigma's abstract syntax into the target platform's query language. The Splunk backend converts rules to SPL searches. The Elastic backend generates Lucene or EQL queries. The Microsoft Sentinel backend outputs KQL. Over thirty backends exist for different SIEM platforms, log management tools, and security analytics engines.
Backend conversion is not simply text replacement. Different platforms handle data types, field naming, and boolean logic differently. Sigma backends perform intelligent translation that accounts for platform-specific requirements. They map generic field names to platform-specific log schemas, convert time formats, and adjust query syntax to match platform capabilities.
The SigmaHQ repository organizes rules by log source and attack technique. Windows rules cover authentication events, process creation, network connections, registry modifications, and file system activity. Linux rules focus on auditd events, system calls, and application logs. Cloud rules address AWS CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs. Web application rules detect common attack patterns in Apache, Nginx, and IIS logs.
Rules include severity ratings from informational to critical based on attack impact and false positive likelihood. They map to MITRE ATT&CK techniques and sub-techniques, enabling coverage analysis across the framework. Many rules include references to threat intelligence reports, vulnerability disclosures, or security research that inspired their development.
Sigma addresses one of the most persistent problems in enterprise security: vendor lock-in at the detection engineering level. Organizations that build extensive detection rule libraries in proprietary SIEM query languages face enormous switching costs when migrating to different platforms. A Splunk environment with hundreds of custom SPL searches represents years of detection engineering investment that does not transfer to Elastic, QRadar, or other platforms. Teams must manually rewrite detection logic, often losing institutional knowledge and introducing errors in the process.
This lock-in effect influences technology decisions in ways that may not serve long-term security effectiveness. Organizations continue using SIEM platforms that no longer meet their needs because the cost of migrating detection content appears prohibitive. They avoid multi-platform deployments that might improve visibility or reduce costs because managing different query languages across platforms requires specialized expertise that most teams lack.
Sigma eliminates these constraints by making detection engineering portable. Organizations can invest in building detection capabilities once and deploy them across multiple platforms. When business requirements drive SIEM migrations, the entire detection rule library converts automatically rather than requiring months of manual rewriting. Teams can adopt best-of-breed platforms for different use cases without fragmenting their detection capabilities.
The shared community repository accelerates detection engineering programs by providing a baseline of validated rules that cover common attack techniques. Instead of starting from scratch, security teams can deploy proven detection logic and focus their custom development efforts on organization-specific threats and attack patterns. This is particularly valuable for smaller organizations that lack the resources to build comprehensive detection libraries independently.
Sigma also improves detection quality through community review and standardization. Rules in the SigmaHQ repository undergo peer review for accuracy, false positive rates, and coverage effectiveness. The standardized format makes it easier to audit detection logic, identify gaps in coverage, and ensure consistent quality across different rule authors.
The format enables better threat intelligence integration by providing a common language for expressing detection logic. When threat intelligence providers publish indicators of compromise, they can include Sigma rules that immediately translate into actionable detection capabilities rather than generic descriptions that require manual implementation.
However, Sigma is not a complete solution for all detection engineering challenges. The conversion process may not capture platform-specific optimizations that improve query performance. Complex detection logic that relies on statistical analysis, machine learning, or cross-event correlation may not translate effectively through Sigma's rule-based format. Organizations still need platform-specific expertise to tune converted rules for optimal performance and minimal false positives.
Within the Predictive Defense Methodology framework, Sigma rules serve as a critical capability bridge between Threat Intelligence & Defense (TID) and Risk & Governance Assurance (RGA) domains. TID owns the threat detection logic that Sigma rules express, while RGA ensures that detection capabilities align with compliance requirements and risk management objectives.
The PDI methodology emphasizes seeing threats before they complete their objectives. Sigma rules enable this by translating threat intelligence into automated detection capabilities that identify attack techniques early in the kill chain. Rather than waiting for completed compromises or damage assessment, Sigma-based detection identifies reconnaissance activity, initial access attempts, and lateral movement techniques while defenders still have time to respond effectively.
CDA's approach to Sigma differs from conventional thinking in several important ways. Most organizations treat Sigma rules as static detection content, deploying community rules without systematic customization for their specific threat landscape or environment characteristics. CDA treats Sigma as a detection development framework that enables rapid prototyping and testing of threat intelligence hypotheses.
When TID analysts identify new threat actor TTPs or attack techniques relevant to an organization's risk profile, they should be able to express detection logic as testable Sigma rules within hours rather than weeks. This requires treating Sigma rule development as an operational capability rather than an engineering project. Detection logic should flow directly from threat intelligence analysis without lengthy development cycles or platform-specific implementation delays.
The PDI methodology also emphasizes detection tuning based on environmental reality rather than theoretical attack models. Community Sigma rules provide excellent starting points, but they require adaptation to specific network architectures, application portfolios, and operational practices. A rule detecting unusual PowerShell execution may generate excessive false positives in environments where administrators routinely use PowerShell for legitimate automation. The rule needs modification to account for expected administrative activity while maintaining sensitivity to actual threats.
CDA recommends maintaining parallel Sigma rule libraries: baseline community rules for comprehensive coverage and customized rules optimized for organizational threat models. The baseline library ensures coverage of common attack techniques and provides a foundation for threat hunting activities. The customized library focuses detection resources on threats most likely to target the organization based on industry, geography, technology stack, and threat intelligence analysis.
This approach requires treating Sigma rule management as an intelligence operation rather than a configuration management task. Rules should evolve based on attack campaign analysis, threat actor profiling, and effectiveness measurement. Detection logic that consistently generates high-quality alerts should expand to cover related attack techniques. Rules that produce false positives or miss known attack activity need systematic refinement or replacement.
• Sigma provides a vendor-neutral format for writing detection rules that convert automatically to any SIEM platform, eliminating vendor lock-in at the detection engineering level.
• The SigmaHQ repository contains over 3,000 community-reviewed rules covering Windows, Linux, cloud, and web application logs with MITRE ATT&CK mapping for comprehensive threat coverage.
• Sigma rules use YAML format with metadata, log source specification, and detection logic sections that support complex boolean operations and over twenty field modifiers for flexible pattern matching.
• Organizations can invest in detection engineering once and deploy across multiple platforms, making SIEM migrations and multi-platform deployments operationally feasible.
• Effective Sigma implementation requires treating rules as living detection logic that evolves based on threat intelligence rather than static configuration files.
• Predictive Defense Intelligence (PDI): See the Threat First • MITRE ATT&CK Framework Implementation • SIEM Platform Selection and Migration • Detection Engineering Best Practices • Threat Intelligence Operations
• MITRE ATT&CK Framework, "Software: Sigma," ATT&CK Knowledge Base, https://attack.mitre.org/software/S0633/
• NIST Special Publication 800-61 Rev. 2, "Computer Security Incident Handling Guide," National Institute of Standards and Technology, 2012.
• SigmaHQ Project, "Sigma - Generic Signature Format for SIEM Systems," GitHub Repository, https://github.com/SigmaHQ/sigma
• SANS Institute, "Detection Engineering: Defending Networks with Purpose," SANS Blue Team Operations, 2022.