01 - Sigma Rules: Universal Detection Logic & SIEM Conversion

Sigma Rules: Universal Detection Logic and SIEM Conversion

One of the most persistent problems in defensive cybersecurity has been the fragmentation of detection languages: every SIEM has its own proprietary syntax, every platform requires different queries, and rules written for Splunk don't work on Elastic, which in turn isn't compatible with Microsoft Sentinel. The result is that SOC teams spend enormous amounts of time rewriting the same detection logic for each tool, instead of focusing on what really matters: finding threats before they cause damage.

Sigma rules were created exactly to solve this problem. Introduced by Florian Roth and Thomas Patzke, Sigma is today the de facto standard format for writing portable, platform-independent detection rules. A Sigma rule written once can be automatically converted to Splunk SPL, Elasticsearch KQL, Microsoft Sentinel KQL, IBM QRadar, Chronicle YARA-L, and over 40 other targets. In this article we explore Sigma syntax in depth, logsource mapping patterns, modification and conversion techniques, and how to integrate Sigma into a modern Detection-as-Code pipeline.

What is Sigma and Why It Became the Standard

Sigma is an open, YAML-based format for describing detection patterns on security logs in a platform-independent way. Think of it as YARA for logs: just as YARA allows writing rules for malicious files that work on any scanner, Sigma allows writing detection rules that work on any SIEM.

The SigmaHQ project hosts today over 3,000 community rules under continuous maintenance, mapped to the MITRE ATT&CK framework, and ready for conversion. Growth has been explosive: from a niche tool for threat hunters, Sigma has become the common language of professional detection engineers. The main advantages are three:

• Portability: write one rule, deploy it on N different SIEMs
• Collaboration: rules are readable by anyone, regardless of the SIEM in use
• Automation: conversion is fully automatable in CI/CD

Anatomy of a Sigma Rule

A Sigma rule is a YAML file with well-defined fields. Let us examine the complete structure with a real example that detects mimikatz usage through Windows Event Logs:

title: Mimikatz Detection via Windows Security Events
id: 0d82df6e-0e4e-4fbb-a12b-6e7a00a9c7c3
status: stable
description: Detects mimikatz usage patterns via LSASS access events
  and command-line indicators
references:
  - https://github.com/gentilkiwi/mimikatz
  - https://attack.mitre.org/techniques/T1003/001/
author: Federico Calo
date: 2026/03/01
modified: 2026/03/09
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.defense_evasion
logsource:
  category: process_access
  product: windows
detection:
  selection_lsass:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1038'
      - '0x1400'
      - '0x143a'
  selection_mimikatz_cli:
    CommandLine|contains|all:
      - 'sekurlsa'
      - 'logonpasswords'
  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Program Files\Windows Defender\'
  condition: (selection_lsass and not filter_legitimate) or selection_mimikatz_cli
falsepositives:
  - Legitimate security tools performing LSASS inspection
  - Antivirus and EDR solutions
level: high

Mandatory Fields and Metadata

The metadata block at the beginning of the rule serves both documentation and management automation purposes:

• title: human-readable rule name. Must be unique and descriptive. Convention: "Verb + Subject + Context"
• id: unique UUID v4. Never changes over time, allows tracking versions and false positive reports
• status: rule lifecycle. Valid values are: stable, test, experimental, deprecated, unsupported
• level: severity. Values: informational, low, medium, high, critical
• tags: list of MITRE ATT&CK tags in format attack.t<ID> for techniques or attack.<tactic> for tactics

Logsource: The Heart of Portability

The logsource block is the magic that makes Sigma portable. Instead of specifying a SIEM-specific index or data stream, it defines the log type abstractly through three fields: category, product, and service.

The sigma-cli pipeline system translates these abstract logsources into the concrete paths of each SIEM. For example, category: process_creation on product: windows becomes:

Advanced Modifiers

Modifiers are suffixes added to field names with the pipe character | to modify the match type. Knowing them all is fundamental for writing effective rules:

Aggregation Conditions: Statistical Detection

Some detections require counting events within a time window, not matching a single event. Sigma supports aggregation conditions for these use cases:

# Brute force detection: more than 10 failed logins in 60 seconds
title: Windows Brute Force Login Attempt
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
    LogonType: 3
  condition: selection | count() > 10
timeframe: 60s
level: medium

---

# Port scan detection: many different ports from same source
title: Network Port Scan Detection
logsource:
  category: network_connection
detection:
  selection:
    EventID: 5156
  condition: selection | count(DestinationPort) by SourceAddress > 30
timeframe: 10m
level: medium

Conversion with sigma-cli: Practical Guide

sigma-cli is the official tool for converting Sigma rules into SIEM query languages. Installation and basic usage:

# Installation
pip install sigma-cli
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender

# List available backends
sigma list backends

# Basic conversion: Sigma -> Splunk SPL
sigma convert -t splunk -p splunk_windows rules/mimikatz.yml

# Conversion with custom pipeline
sigma convert \
  -t splunk \
  -p splunk_windows \
  -p my_custom_field_mapping.yml \
  rules/

# Conversion for Elasticsearch with ECS
sigma convert \
  -t elasticsearch \
  -p ecs_windows \
  -f lucene \
  rules/credential_access/

# Conversion for Microsoft Sentinel (KQL)
sigma convert \
  -t microsoft365defender \
  -p microsoft365defender \
  rules/lateral_movement/

# JSON output for automation
sigma convert \
  -t splunk \
  -p splunk_windows \
  --format-output json \
  rules/ > converted_rules.json

Detection Patterns for Common Use Cases

A collection of ready-to-use Sigma rules for high-priority use cases, mapped to the most exploited MITRE ATT&CK techniques:

Lateral Movement: Pass-the-Hash

title: Pass-the-Hash Attack Pattern
id: 6571d552-4c16-4f50-b5f6-11ae9d1b0a38
status: stable
description: Detects Pass-the-Hash attacks via anomalous NTLM authentication
tags:
  - attack.lateral_movement
  - attack.t1550.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: NTLM
    KeyLength: 0
  filter_local:
    IpAddress:
      - '127.0.0.1'
      - '::1'
  filter_machine:
    SubjectUserName|endswith: '$'
  condition: selection and not filter_local and not filter_machine
level: high

Exfiltration: DNS Tunneling

title: Potential DNS Tunneling via High Subdomain Count
id: b7c3a9f1-d4e5-4a7b-9f2c-8d0e1b3c5a7f
status: experimental
description: Detects potential DNS tunneling via unusually long DNS queries
tags:
  - attack.exfiltration
  - attack.t1048.001
  - attack.command_and_control
  - attack.t1071.004
logsource:
  category: dns
detection:
  selection_long_query:
    QueryName|re: '^([a-zA-Z0-9]{32,}\.)+'
  condition: selection_long_query
timeframe: 5m
falsepositives:
  - CDN providers with hashed subdomains
level: medium

GitHub Actions for CI/CD of Sigma Rules

# .github/workflows/sigma-pipeline.yml
name: Sigma Rules CI/CD

on:
  push:
    paths:
      - 'rules/**/*.yml'
  pull_request:
    paths:
      - 'rules/**/*.yml'

jobs:
  validate:
    name: Validate Sigma Rules
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          pip install sigma-cli pySigma-backend-splunk \
            pySigma-backend-elasticsearch pyyaml

      - name: Run validation
        run: python scripts/validate_rules.py ./rules

  convert-and-deploy:
    name: Convert and Deploy Rules
    needs: validate
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Convert rules for Splunk
        run: |
          sigma convert \
            -t splunk \
            -p splunk_windows \
            --format-output savedsearches \
            rules/ > converted/splunk_rules.conf

      - name: Deploy to SIEM
        env:
          SPLUNK_TOKEN: ${{ secrets.SPLUNK_TOKEN }}
        run: python scripts/deploy_to_splunk.py --rules converted/splunk_rules.conf

Conclusions and Next Steps

Sigma represents today the state of the art for writing portable and collaborative detection logic. Mastering its syntax, advanced modifiers, and automatic conversion is a fundamental skill for any modern detection engineer. The key points to remember:

• The logsource structure is the heart of portability: one rule, N platforms
• Modifiers allow flexible matching without sacrificing precision
• Aggregation conditions enable behavioral and statistical detections
• A well-organized repository with CI/CD is a prerequisite for scalability
• ATT&CK mapping allows measuring coverage objectively