What Are Sigma Rules?

Sigma rules are YAML-based, platform-independent detection definitions used to identify suspicious activity in log data. They standardize how events such as process creation, registry modification, or file access are described, enabling consistent detection across different SIEM platforms. Built for operational efficiency, Sigma rules help SOC teams automate threat detection, minimize false positives, and improve overall alert accuracy.

This blog is a hands-on guide to writing Sigma rules. It walks through a real example step by step, explaining how each part works and how to turn threat behaviors into effective, platform-independent detections.

How to Write a Sigma Rule?

To write a Sigma rule, start by defining the behavior you want to detect, then translate it into Sigma’s YAML format. A well-written rule clearly describes what to look for in logs, which data source to use, and how to minimize false positives. 

Each Sigma rule follows a structured format that ensures it can be easily shared and converted for different SIEM or detection tools.

Structure of a Sigma Rule

Header: Include essential metadata such as the title, description, author, and status. This section documents what the rule detects and who maintains it.

Log Source: Specify where the data comes from, including the product and service that generate logs. For example, a rule might target Windows logs collected by Sysmon.

Detection: Define the detection logic using three elements:

• Selection: Describe the specific events or field values to match.
• Filter: Identify normal or expected behavior to exclude.
• Condition: Combine the two logically to determine when the rule should trigger.

Fields: List which log fields should appear in alerts when the rule matches. This helps analysts quickly understand and investigate the event.

Tags: Add keywords and framework identifiers such as MITRE ATT&CK technique IDs. Tags make the rule easier to organize, search, and correlate with known threat behaviors.

A clear structure and precise detection logic are key to writing effective Sigma rules. Start with a specific adversary behavior, define the related log source, and build selections and filters that capture malicious activity while minimizing noise.

How to Read and Understand a Sigma Rule (With Example)

Sigma rules are the building blocks of modern detection engineering. They define suspicious activity in a simple, SIEM-agnostic format, a kind of “universal detection language” that helps security teams turn raw log data into actionable detections.

Let’s break down a real Sigma rule line by line to understand how it works and why each part matters.

The Example: Detecting Suspicious Outlook VBA File Activity

Dissecting the Sigma Rule

1. Title and Description

These provide the first layer of context.

• title: Gives a clear summary of what’s being detected.

• description: Explains the detection logic and its relevance.

In this case, the rule detects the creation or modification of Outlook’s VbaProject.otm file, a known persistence vector used by threat actors.

2. Status

The status field indicates the rule’s maturity.

• Experimental: Under testing.
• Stable: Validated and production-ready.
• Deprecated: Outdated or replaced.

Including this helps SOC teams manage rule lifecycles.

3. Author and References

• author: Specifies who wrote or maintains the rule. Used for traceability, version tracking, and ownership within detection repositories.

• references: Cites external technical sources, such as MITRE ATT&CK techniques (e.g., T1137.001, T1204.002) or threat research, to justify the detection logic and link it to documented adversary behavior.

Together, these fields make Sigma rules transparent, verifiable, and machine-readable.

4. Log Source

The logsource field defines where the Sigma rule should look for telemetry.
Here, the rule applies to Windows Sysmon logs, a powerful source of detailed system activity. Sysmon (System Monitor) records events such as process creation, file modification, network connections, and registry changes.

By specifying:

• product: windows → The rule targets Windows operating systems.

• service: sysmon → It focuses specifically on Sysmon event logs.

This setup ensures high-fidelity telemetry for detecting behaviors like the creation or modification of files in sensitive paths.

5. Detection Logic

Detection logic is the core of a Sigma rule. This is where you define exactly what to match, what to ignore, and how to combine those conditions. It consists of three main parts:

• selection: conditions that must be met (i.e., what to look for)

• filter: conditions that must not be met (i.e., what to ignore)

• condition: the logical expression that ties selection and filter together

Here:

• EventID: 11 refers to Sysmon Event ID 11, which tracks file creation or overwrite operations. 

TargetFilename|endswith: '\Microsoft\Outlook\VbaProject.otm' means we are looking specifically for a file with that exact ending path, which corresponds to Outlook’s VBA project file. Threat actors may modify this file to achieve persistence or execute malicious macros.

Here:

• The filter excludes events where the Image (i.e., the process executable) ends with OUTLOOK.EXE, EXCEL.EXE, WINWORD.EXE, or POWERPNT.EXE.

• These are legitimate Office processes; excluding them helps reduce false positive alerts when user-driven macro activity occurs normally.

• This defines the logic: the rule triggers when the selection criteria are true and the filter criteria are not true.

In plain English: “Raise an alert if Outlook’s VbaProject.otm file is created or modified by a process other than the standard Office executables.”

6. False Positives

This section acknowledges safe operations that might still trigger alerts. It helps SOC analysts tune detections intelligently without weakening coverage.

7. Severity Level 

Severity level indicates the risk level.

“High” means this event is likely to represent a real persistence attempt and deserves priority review.

8. Tags

• Tags connect detections to MITRE ATT&CK tactics (e.g., persistence, execution, defense evasion).

• They improve searchability, reporting, and validation during CTEM assessments.

For example, a CTEM validation cycle can automatically verify whether detections like this one are firing correctly across relevant ATT&CK categories.

Benefits of Sigma Rules

In a nutshell, Sigma rules provide the following benefits for simplifying and standardizing threat detection:

• Standardization: A unified format for creating and sharing detection rules.
• Compatibility: Works with multiple SIEM and log management platforms.
• Flexibility: Applicable to various log sources and customizable for specific needs.
• Efficiency: Enables automated detection and reduces manual log analysis.
• Improved Incident Response: Generates actionable alerts with meaningful context.
• Cost-Effectiveness: Reduces false positives and optimizes analyst time.
• Scalability: Suitable for large and diverse IT environments.

Continuous Improvement: Benefits from regular updates and community-driven enhancements.

From One Format to Every SIEM

As an open-source community project, Sigma rules enable security operations teams to write queries in a single, standardized format instead of vendor-specific SIEM languages. This means that one rule can be automatically translated into SIEM-specific code with a single click.

Example Sigma Rule Translation

For example, the following Sigma rule detects suspicious modification of Windows Volume Shadow Copy Service (VSS) registry keys using esentutl.exe. 

Adversaries often exploit this technique to create, modify, or delete shadow copies for data exfiltration or persistence. When converted, the rule would appear as follows in Microsoft Sentinel (Azure SIEM):

And the same rule would automatically be translated into the following query for Splunk:

In practice, this means that a detection created in Sigma format for one SIEM instantly becomes usable for all others, allowing SOC teams to share, adapt, and deploy threat detections universally, without ever rewriting a single line of logic.

How Picus Sigma Rules Help SOC Teams Detect Smarter, Not Harder

The Picus Mitigation Library is a comprehensive repository of validated prevention and detection content that helps organizations strengthen and maintain their security posture.

Figure 1. Picus Platform Provides Both Prevention and Detection Content

It delivers tailored mitigation coverage for a wide range of security technologies, enabling teams to close exposure gaps quickly and effectively.

The library includes:

• 80,000+ vendor-specific prevention signatures tailored for security controls such as Next-Generation Firewalls (NGFWs), Intrusion Prevention Systems (IPS), and Web Application Firewalls (WAFs).

4,400+ validated vendor-specific detection rules and 600+ vendor-neutral Sigma rules for major SIEM and EDR technologies to detect endpoint and network-based attacks.

Figure 2. Picus Platform Detection Content Library

• Log source recommendations to enhance visibility, optimize SIEM performance, and strengthen detection coverage across the environment.

Ready to put your defenses to the test and apply real-world mitigation?

Start your demo now to simulate attack scenarios, validate which controls stop threats, and instantly apply tailored mitigation suggestions through the Picus platform.

Key Takeaways

• Universal Detection Format: Sigma rules establish a standardized, YAML-based schema for describing suspicious or malicious behavior in log data, independent of any specific SIEM syntax.
• Structured Composition: Each rule contains defined sections, Header, Log Source, Detection, Fields, and Tags, ensuring machine-readable consistency and clear metadata hierarchy.
• Detection Logic Core: The selection, filter, and condition elements encode Boolean logic for identifying relevant events while minimizing false positives, enabling deterministic rule interpretation.
• Cross-Platform Portability: A single Sigma rule can be automatically translated into multiple SIEM query languages (e.g., Splunk, Sentinel, Elastic), supporting interoperability across detection ecosystems.
• Operational Efficiency and Reuse: Sigma’s open-source, vendor-agnostic design allows automated deployment, version control, and knowledge transfer, making it ideal for scaling detection engineering and model-based reasoning.