What are Sigma rules and why should your SOC use them?

If you’ve spent any time tuning a SIEM or EDR, you’ve probably written detection logic that lives in some proprietary query language - Splunk SPL, Elastic EQL, Microsoft KQL, or whatever the vendor decided to call their flavour. That logic works great until you switch platforms, and then you rewrite everything from scratch.

Sigma is the answer to that problem. It’s an open, vendor-neutral format for writing detection rules that you can convert to any backend your environment runs. One rule format, many targets.

What a Sigma rule actually looks like

Sigma rules are YAML files. They describe what to detect - event source, field conditions, filter exclusions - without tying you to a specific query syntax. Here’s a minimal example that detects a process spawning cmd.exe from Office applications, a classic phishing execution pattern:

title: Office Application Spawning CMD
id: 438025f9-5856-4663-83f7-52f878a70a50
status: stable
description: Detects Office application spawning a command shell
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
    Image|endswith: '\cmd.exe'
  condition: selection
falsepositives:
  - Legitimate macros that invoke cmd for automation
level: high
tags:
  - attack.execution
  - attack.t1059.003

That rule can be compiled to Splunk SPL, Elastic Query DSL, Chronicle YARA-L, Microsoft Sentinel KQL, or dozens of other formats using sigma-cli. The MITRE ATT&CK technique reference (attack.t1059.003 - Command and Scripting Interpreter: Windows Command Shell) travels with the rule automatically.

Why Sigma matters for SOC portability

You don’t own your detection logic if it lives in vendor-specific syntax. The moment you evaluate a competing platform - or the moment your vendor raises prices or gets acquired - all that carefully tuned logic is locked in. Sigma breaks that lock.

A few concrete benefits:

• Community rules: The SigmaHQ/sigma-rules repository contains over 3,000 community-contributed rules, many mapped to MITRE ATT&CK. You get immediate detection coverage without writing every rule yourself.
• Auditable format: YAML is readable by humans and version-controllable in git. Your detection engineering work lives in your repo, not in a vendor’s dashboard.
• Backend flexibility: The same rule compiles to different query languages. Test on Elastic, deploy to Splunk, evaluate a new platform - the rules follow you.
• Consistency: Teams that write in native query languages end up with inconsistent field naming and logic. Sigma enforces a shared vocabulary.

One thing Sigma doesn’t do: it doesn’t execute rules itself. It’s a description format, not a detection engine. You still need a platform to ingest and evaluate the compiled output.

Writing your own rules: the logsource and detection blocks

Two sections do most of the work.

The logsource block tells Sigma where this rule applies - what data source, product, and event category. Common categories include process_creation, network_connection, file_event, and dns_query. These map to normalised fields in the pipeline configuration for your target backend.

The detection block defines your matching logic. It supports:

• field matching: Image|endswith: '\powershell.exe'
• lists (OR logic): multiple values under one field
• multiple named selections (AND/OR): condition: selection1 and selection2
• NOT filters: condition: selection and not filter
• aggregation: | count() by User > 10 for threshold-based alerts

Here’s a slightly more complex rule using aggregation to detect brute-force login attempts:

title: Brute Force Login Attempts - Windows
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
  condition: selection | count() by TargetUserName > 10
timeframe: 5m
level: medium
tags:
  - attack.credential_access
  - attack.t1110

This fires if the same username accumulates more than 10 failed logins in a 5-minute window - a pattern that’s hard to express cleanly without a normalised format.

Getting started without overcomplicating it

You don’t need a dedicated detection-as-code pipeline to start with Sigma. A reasonable path:

1. Clone the SigmaHQ/sigma-rules repository to get the community rule set.
2. Install sigma-cli and the pipeline for your SIEM (pip install sigma-cli pySigma-backend-splunk for Splunk, for example).
3. Convert a handful of high-severity rules to your backend and deploy them.
4. When you write new detection logic, write it in Sigma first, then compile.

The cost of adopting Sigma is low. The benefit - detection logic you own, can version, can share, and can move - compounds over time.

LightEDR’s behavioural detection layer maps to MITRE ATT&CK technique IDs natively, using the same tagging conventions Sigma rules carry. If you’re already writing Sigma, that shared vocabulary means less translation work when correlating EDR telemetry with your SIEM alerts. If you’d like to see how that fits into your current stack, get in touch.