Detection Engineering with Sigma: Where to Start

A CISO or analyst who wants to build an in-house detection practice hits the same wall almost every time: they know they need to "write rules," but have no idea where to start, or how to tell whether what they wrote actually covers anything real. The usual outcome is a folder of scattered rules, copied from here and there, never tested against a real engine, that create a false sense of coverage. Detection engineering exists precisely to close that gap: it treats detection as a lifecycle, not a text file you write once and forget.

Why Sigma is the pivot format

Before Sigma, every SIEM had its own rule language: SPL for Splunk, KQL for Sentinel or Elastic, EQL for Elastic Security. Writing a detection meant writing it once per platform, with no reuse across environments. Sigma solved this by becoming a declarative pivot format: you describe the detection logic once (which log source, which fields, which condition), and a backend translates it into the target engine's native language.

That decoupling changes the nature of the work. The analyst reasons about detection intent ("a suspicious child process spawned by a mail client") rather than the syntax of a particular SIEM. That is what made Sigma the reference format for sharing rules across the community, the same role YARA plays for files or Suricata for network traffic.

The anatomy of a Sigma rule

A Sigma rule is a YAML file structured into a handful of blocks. Here is an annotated example built on a classic case: an abnormal child process launched from winword.exe.

title: Suspicious Child Process from Office Application
id: 3d8f2b4a-1e29-4c7a-9a4e-8f6b2c1d0a11
status: test
description: >
  Detects a command interpreter or scripting engine spawned as a
  direct child of a Microsoft Office application, a common pattern
  in macro-based initial access.
references:
  - https://attack.mitre.org/techniques/T1204/002/
author: detection-team
date: 2026-06-10
tags:
  - attack.execution
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\mshta.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate add-ins that shell out for automation (rare)
level: high

Three blocks carry the essential logic. The logsource tells the backend which telemetry to query, here a Windows process creation event, independent of the product actually collecting it (Sysmon, EDR, native log). The detection block defines the patterns to look for as named selections, each a list of field conditions. The condition combines those selections with boolean logic, here a simple and between an Office parent and an interpreter child.

The tags field, with the attack.t1204.002 reference, ties the rule to the MITRE ATT&CK matrix. That mapping is not cosmetic: it lets you reason in terms of coverage (which techniques are detected, which are not) instead of raw rule count, and prioritize new rules based on the techniques that actually matter for the threat you are working against.

Minimal tooling to get started

Three building blocks are enough for a serious practice, all open source:

• pySigma: the Python library that parses the Sigma format and carries the translation backends (Splunk, Elastic, Microsoft Sentinel, QRadar, and a dozen others).
• sigma-cli: the command-line interface built on pySigma, for converting and validating rules without writing code.
• Access to the actual target engine (a Splunk instance, an Elastic cluster, or at minimum its sample data): without that, conversion stays theoretical.

The everyday usage fits in one command:

pip install sigma-cli
sigma convert -t splunk -p sysmon my_rule.yml

The -t flag names the target backend, -p a translation pipeline that maps Sigma's generic field names (Image, ParentImage) to the actual field names of the chosen collection product (here Sysmon). That pipeline is what separates a rule that converts cleanly from one that produces a syntactically valid query returning nothing, for lack of correct field mapping.

The detection engineering loop

Writing an isolated rule is not detection engineering. The discipline rests on a repeated loop:

1. Hypothesis: state what you are trying to detect, ideally tied to an ATT&CK technique and to a log source you actually have.
2. Rule: write the corresponding Sigma, with a precise logsource and a condition that reflects the hypothesis without overreaching it.
3. Test against Atomic Red Team: replay the technique in a controlled environment with a matching Atomic Red Team test, and confirm the converted rule actually fires on the target engine.
4. Shadow mode: deploy the rule in log-only mode, with no active alert, for an observation period against production traffic, to measure its real firing rate.
5. Promotion: if the alert volume stays manageable and the false positives are identified and filtered, promote the rule to an active alert.

This loop turns detection from a writing act into a validation act. A rule that never went through steps 3 and 4 is only an unverified hypothesis, no matter how clean its YAML syntax looks.

Prioritize by the telemetry you actually have, not by attack style

The most common beginner mistake is starting from a list of appealing attack techniques and trying to write a rule for each one, without first checking whether the required log source actually exists in the environment. A rule that depends on a Sysmon Event ID 1 field with an enriched CommandLine is useless if only the native Windows 4688 log, without command line, is collected.

The priority order that works in practice starts from the real source inventory:

• Sysmon, where deployed, offers the richest granularity (process creation with command line, network connections, registry access).
• The EDR already in place, when it feeds raw events to the SIEM and not just its own alerts, often covers a scope equal to or wider than Sysmon.
• Native Windows logs (4688, 4624, 4104 for PowerShell) remain the minimum baseline, poorer but universally present.
• Firewall and network logs cover a complementary axis: outbound traffic, beaconing, exfiltration.

Writing first for the source you actually collect, even if it covers a less spectacular technique, produces more value than a rule that is perfect on paper but will never fire for lack of data.

The beginner's false-positive traps

Three mistakes show up systematically in first rules:

• The bare token: searching for a plain keyword (powershell) with no field context or anchoring, which matches every occurrence of the string, including in unrelated file paths or legitimate arguments.
• Overly broad conditions: an unanchored contains (instead of endswith, startswith) or a single selection with no correlation to a second signal, which turns a rule into a noise detector.
• Missing exclusion filters: skipping a filter block for known legitimate cases (admin tools, internal deployment scripts), which forces a rewrite after the first batch of alerts instead of anticipating it at write time.

Shadow mode from the loop above is exactly where these three traps surface before they flood a real alert queue.

Why a curated pack beats a frozen GitHub clone

The most common temptation is to clone a community Sigma rule repository and wire it straight into the SIEM. The problem is not the initial quality of those rules, which is often fine, but their drift over time: the upstream repository keeps evolving, your clone does not. Rules broken by a log schema change never get fixed on the client side. New techniques documented after the clone are never added. The result is a false sense of coverage: the rule folder looks like active detection, while part of it has stopped firing for months without anyone noticing.

A curated, tested pack addresses this by construction: every rule has gone through the hypothesis-test-shadow mode-promotion loop described above, on a real engine, with drift tracked over time rather than a snapshot frozen on cloning day.

To start a detection practice without rebuilding every rule from scratch, the ThreatClaw Sigma pack provides that already-validated foundation, prioritized by the telemetry you actually have and maintained over time.