SIGMA Rules: The Universal Detection Format

When Log4Shell (CVE-2021-44228) dropped in December 2021, the SigmaHQ community published detection rules within hours — organizations running any supported SIEM deployed detection the same day. Teams writing vendor-specific Splunk SPL or Elastic KQL from scratch took two to five days to reach equivalent coverage. That gap — hours versus days — is the entire argument for SIGMA in a single incident.

Why Now: The Portability Imperative

SigmaHQ crossed 3,000 community-contributed detection rules in 2025, making it the largest open-source detection content library in existence. At the same time, organizations are increasingly operating multi-SIEM environments — a primary cloud SIEM for most workloads, a specialized tool for OT/ICS, maybe a legacy on-prem instance still handling classified traffic. Writing the same detection three times in three query languages is unsustainable. SIGMA's write-once, convert-many model is no longer a convenience — it is an operational necessity.

CISA's Shields Ready guidance and the push toward continuous monitoring across federal and DIB environments make rapid detection deployment a compliance differentiator, not just a security one.

What SIGMA Actually Is

SIGMA is an open standard for writing log-based detection rules in a SIEM-agnostic YAML format. Think of it as the YARA of log analysis: you describe a detection pattern once, and converters translate it into the native query language of your target platform — Splunk SPL, Elastic/Lucene, Microsoft Sentinel KQL, IBM QRadar AQL, Chronicle YARA-L, or any of the 30+ supported backends.

A SIGMA rule does not run directly against logs. It is a specification that a conversion tool (sigma-cli, pySigma, or a commercial converter) translates into an executable query. This indirection is both SIGMA's greatest strength and its most misunderstood limitation.

The Contrarian Truth About Portability

SIGMA portability is a myth for 80% of organizations — the moment you add a vendor-specific field modifier, reference a custom log source mapping, or depend on a pipeline processing step that only exists in your Splunk environment, your "portable" rule is locked to one platform. The SigmaHQ community rules work across backends because they deliberately constrain themselves to generic field names and standard log sources. Your custom rules, written against your environment's specific field mappings, rarely port cleanly without manual adjustment.

This does not make SIGMA worthless. It makes SIGMA a lingua franca for sharing detection logic between humans, not a push-button migration tool between vendors. Treat it as a specification language for detection intent, not as compiled code.

SIGMA Rule Structure

Every SIGMA rule is a YAML document with four primary sections. Understanding this structure is the foundation for both consuming community rules and writing your own.

Metadata Block

title: Suspicious Scheduled Task Creation via Schtasks
id: a4b7c3d2-1234-5678-9abc-def012345678
status: test
description: |
  Detects scheduled task creation using schtasks.exe with parameters
  commonly associated with persistence mechanisms.
author: Security Team
date: 2026/07/01
modified: 2026/07/15
references:
    - https://attack.mitre.org/techniques/T1053/005/
tags:
    - attack.persistence
    - attack.t1053.005
    - attack.execution

The id field is a UUID that uniquely identifies the rule across all repositories. The status field (experimental, test, stable, deprecated) communicates confidence level. Tags map directly to MITRE ATT&CK techniques, enabling coverage analysis.

Log Source Declaration

logsource:
    category: process_creation
    product: windows
    service: sysmon

The log source tells converters which data source the rule targets. The category field (process_creation, network_connection, file_event) maps to generic event types. product and service narrow the scope. Converters use backend-specific pipelines to translate these declarations into the correct index, sourcetype, or table in your SIEM.

Detection Logic

detection:
    selection_process:
        Image|endswith: '\schtasks.exe'
    selection_args:
        CommandLine|contains|all:
            - '/create'
            - '/sc'
    filter_legitimate:
        User: 'SYSTEM'
        CommandLine|contains:
            - '\Microsoft\Windows\UpdateOrchestrator'
            - '\Microsoft\Windows\Defrag'
    condition: selection_process and selection_args and not filter_legitimate

SIGMA's detection section uses field modifiers (contains, endswith, startswith, re, base64, cidr, all, windash) to express matching logic without vendor-specific syntax. The condition line combines named selections and filters using Boolean logic.

Severity and Context

level: medium
falsepositives:
    - Legitimate administrative scheduled task creation
    - Software deployment systems (SCCM, PDQ)
    - Monitoring agent installation

The level field (informational, low, medium, high, critical) informs alert routing. The falsepositives section is operationally critical — it tells the analyst receiving the alert what legitimate activity looks like for this pattern.

The Conversion Pipeline

Converting SIGMA rules into executable queries requires three components:

sigma-cli / pySigma — The open-source conversion toolchain. pySigma is the Python library; sigma-cli is the command-line interface built on it. Both support plugin-based backends and processing pipelines.

Backend plugins — Each target SIEM has a backend plugin that knows how to translate SIGMA's abstract logic into that platform's query language. The Splunk backend produces SPL; the Elasticsearch backend produces Lucene or EQL; the Sentinel backend produces KQL.

Processing pipelines — Pipelines transform field names and log source declarations to match your environment's specific naming conventions. If your Splunk deployment indexes Windows process creation events under sourcetype=WinEventLog:Sysmon with a field called process_name instead of Image, the pipeline handles that mapping.

The pipeline step is where portability typically breaks. Every environment has unique field naming, index structures, and log source configurations. Without a pipeline tailored to your environment, even the cleanest SIGMA rule converts into a query that returns zero results.

The SigmaHQ Community Repository

SigmaHQ (github.com/SigmaHQ/sigma) is the canonical public repository of SIGMA detection rules. It is organized by log source category, reviewed by maintainers, and tagged against ATT&CK. Key facts:

• 3,000+ rules covering Windows, Linux, macOS, cloud, network, and application logs
• Rules are peer-reviewed before merge — quality is generally high
• Coverage maps against ATT&CK show which techniques have community detection content
• New rules appear within hours of major vulnerability disclosures (Log4Shell, MOVEit CVE-2023-34362, Citrix Bleed CVE-2023-4966)
• Rules carry a status field — only deploy stable rules without review; treat test and experimental as starting points requiring validation

Writing Custom SIGMA Rules

Community rules cover common threats. Custom rules cover your environment's specific risks, applications, and data sources. Writing custom SIGMA rules requires:

Step 1: Define the Detection Hypothesis

Start with a behavior, not a tool name. "Detect lateral movement via PsExec" is better than "detect psexec.exe" because it leads to a rule that catches renamed binaries and alternative implementations.

Step 2: Identify the Log Source

Which logs contain evidence of this behavior? Process creation? Network connections? Authentication events? If the log source does not exist in your environment, you need to enable it before writing the rule.

Step 3: Express the Logic

Use the narrowest field modifiers that capture the behavior. CommandLine|contains|all with multiple terms is more precise than a single CommandLine|contains with a broad substring.

Step 4: Add Exclusions

Every detection rule generates false positives in some environment. Add filter blocks for known legitimate triggers. Document them in falsepositives so future analysts understand the tuning decisions.

Step 5: Test Against Historical Data

Convert the rule to your SIEM's query language and run it against 30 days of historical data. If it generates zero hits, it may be too narrow — or the attack simply has not occurred. If it generates thousands of hits, it is too broad and needs tighter conditions or additional filters.

Testing and Validation

Detection rules that ship untested are detection rules that fail silently. A validation workflow should include:

Sigma-test — The SigmaHQ project provides a test framework that validates rule syntax, required fields, and logical consistency.

Historical replay — Convert and query against 30-90 days of retained logs. Measure hit rate and review a sample for true/false positive ratio.

Atomic Red Team simulation — Run the corresponding Atomic Red Team test (mapped by ATT&CK technique) and verify the rule fires. If your rule targets T1053.005 (Scheduled Task), run the Atomic test for T1053.005 and confirm detection.

Production burn-in — Deploy in alert-only mode (no automated response) for 7-14 days. Review all hits. Tune false positives before promoting to production with automated response actions.

Maintaining a Rule Library

A detection library is a living system, not a deploy-and-forget artifact. Maintenance practices that prevent rule rot:

• Version control everything — Store SIGMA rules in Git alongside your infrastructure-as-code. Track changes, reviews, and deployment state.
• Map coverage to ATT&CK — Maintain a heatmap of which techniques have detection coverage. Identify gaps and prioritize rule development against the techniques most relevant to your threat model.
• Review quarterly — Rules written for last year's threat landscape may not detect this year's tradecraft. Review rules for relevance, false positive rates, and effectiveness.
• Retire stale rules — A rule that has never fired and targets a product you no longer run is noise in your library. Archive it.
• Sync with SigmaHQ — Pull updates monthly. New rules address emerging threats; modifications fix false positives discovered across the community.

SIGMA vs Vendor-Native Rules: Tradeoffs

Factor	SIGMA	Vendor-Native
Portability	High (with pipeline caveats)	Zero
Performance	Depends on conversion quality	Optimized for the platform
Advanced features	Limited to SIGMA's modifier set	Full platform capabilities
Community content	3,000+ rules	Vendor-specific libraries (varying size)
Learning curve	YAML + SIGMA syntax	Platform-specific query language
Maintenance cost	One rule serves multiple platforms	One rule per platform
Debugging	Two layers (SIGMA + converted query)	Direct query debugging

The practical approach: use SIGMA for portable detection content that applies across environments, and vendor-native rules for platform-specific optimizations that exploit features SIGMA cannot express (statistical aggregations, machine learning lookups, multi-event correlations).

Key Takeaways

• SIGMA is a specification language for detection intent — it enables sharing detection logic between humans and tools, but is not a push-button migration system
• The SigmaHQ repository provides 3,000+ peer-reviewed community detection rules, covering major ATT&CK techniques across Windows, Linux, cloud, and network log sources
• Portability requires investment in processing pipelines tailored to your environment's field naming and log source configuration
• Custom SIGMA rules should start with behavioral hypotheses, not tool names, to catch renamed binaries and alternative implementations
• Testing against historical data and Atomic Red Team simulations is non-negotiable before production deployment
• Rule libraries require quarterly review, ATT&CK coverage mapping, and retirement of stale content

Frequently Asked Questions

Can SIGMA rules detect zero-day exploits?

SIGMA rules detect behaviors, not specific exploits. A rule targeting "suspicious child process of a web server" would detect exploitation of a zero-day in that web server without knowing the specific CVE. However, SIGMA cannot detect truly novel attacker techniques that have no known behavioral pattern. Post-disclosure, the SigmaHQ community typically publishes targeted rules within hours — the Log4Shell (CVE-2021-44228) response demonstrated detection content shipping faster than most vendor advisories.

How long does it take to convert a SIGMA rule library to a new SIEM?

The conversion itself takes minutes — sigma-cli can batch-convert thousands of rules in a single command. The real time investment is building and validating the processing pipeline for your new environment's field mappings and log source naming. For a well-documented environment, expect 2-4 weeks to build a pipeline and validate conversion quality across your top 100 rules. For an undocumented environment, double that.

Should I replace vendor-native detection content with SIGMA?

No. Use both. SIGMA provides portable community content and a standardized way to document your custom detection logic. Vendor-native rules exploit platform-specific features (ML models, statistical baselines, multi-event correlation) that SIGMA's modifier set cannot express. The optimal approach is SIGMA for shareable, documented, portable detections and vendor-native for platform-specific optimizations.

How many SIGMA rules should a mid-size organization deploy?

There is no universal number, but a reasonable starting point is 200-400 rules mapped against your top 50 ATT&CK techniques. Deploy SigmaHQ's stable rules relevant to your log sources first, then add custom rules for your specific applications and risks. More important than rule count is coverage breadth — 100 rules covering 40 techniques is better than 500 rules all targeting process creation.

What skills does my team need to write custom SIGMA rules?

SIGMA's YAML syntax is straightforward — the barrier is not the format. Effective rule writing requires understanding attacker tradecraft (how does this technique manifest in logs?), knowledge of your specific log sources and field names, and the analytical discipline to test and tune for false positives. A SOC analyst with 2+ years of experience investigating alerts typically has the domain knowledge; they need a few hours with the SIGMA specification to learn the syntax.

How Advisedly Helps

Advisedly supports SIGMA rule ingestion, conversion, and lifecycle management across 500+ compliance frameworks — mapping detection coverage against MITRE ATT&CK techniques and identifying gaps that community SIGMA rules or custom development should fill, with all detection decisions feeding directly into your compliance evidence trail. Contact begin@advisedly.ai

<!-- LI hook: Your "portable" SIGMA rules are vendor-locked the moment you add custom fields -->