Sigma-Regeln: Detection Engineering herstellerneutral

Sigma-Regeln sind für Logs, was Snort-Signaturen für Netzwerkverkehr und YARA-Regeln für Dateien sind: ein offenes, herstellerneutrales Format, in dem sich eine Erkennung einmal beschreiben und dann in die Abfragesprache jedes SIEM übersetzen lässt. Wer heute Detection Engineering betreibt, kommt daran nicht vorbei, weil die Community in diesem Format mehrere tausend fertige Regeln pflegt und weil eine Erkennung, die nur in Splunk-Syntax existiert, beim nächsten SIEM-Wechsel verloren ist. Dieser Beitrag erklärt den Aufbau einer Sigma-Regel an einem echten Beispiel, die Werkzeuge zur Übersetzung, den Umgang mit der Regelsammlung und den Weg zu Detection as Code.

Was Sigma ist

Sigma wurde 2017 von Florian Roth und Thomas Patzke vorgestellt und wird seither als Community-Projekt unter SigmaHQ weiterentwickelt. Eine Regel ist eine YAML-Datei, die beschreibt, in welcher Logquelle nach welchen Feldwerten gesucht wird und was ein Treffer bedeutet. Die Spezifikation ist gemeinfrei, die Regelsammlung steht unter einer offenen Lizenz, und der Konverter übersetzt eine Regel in Abfragen für Splunk, Elastic, Microsoft Sentinel, QRadar, Wazuh und Dutzende weitere Ziele. Das Entscheidende ist die Abstraktion: Eine Sigma-Regel kennt keine herstellerspezifischen Feldnamen, sondern eine Logquelle wie „Prozesserstellung unter Windows“, und erst bei der Übersetzung wird daraus das Feld, das dein SIEM tatsächlich verwendet.

Der Aufbau einer Sigma-Regel

Ein Beispiel, das eine der häufigsten Angreifertechniken abdeckt: das Nachladen von Werkzeugen mit dem Windows-Bordmittel certutil.

title: Certutil Download From URL
id: 3f2a9c1e-7b4d-4e1a-9c2b-5d8e6f7a1b2c
status: test
description: Erkennt certutil.exe mit Download-Parametern und einer URL, ein
  verbreiteter Weg, Werkzeuge ohne eigene Schadsoftware nachzuladen.
references:
  - https://attack.mitre.org/techniques/T1105/
author: Blue Team
date: 2026-09-12
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\certutil.exe'
    CommandLine|contains|all:
      - 'urlcache'
      - 'http'
  filter_admin_share:
    ParentImage|endswith: '\ccmexec.exe'
  condition: selection and not filter_admin_share
falsepositives:
  - Administrative Skripte, die Zertifikate per URL beziehen
level: high

Die Blöcke im Einzelnen. Metadaten: Titel, eine eindeutige ID, Status (experimental, test, stable), Beschreibung, Quellen, Autor, Datum. Tags: die Zuordnung zu MITRE ATT&CK, hier Taktik und Technik, später die Grundlage für die Abdeckungskarte. Logsource: die abstrakte Quelle, hier Prozesserstellung unter Windows, was je nach Umgebung Event 4688 oder Sysmon Event 1 bedeutet; die Regel muss das nicht wissen. Detection: eine oder mehrere Selektionen mit Feldnamen und Werten, Modifikatoren wie contains, endswith, startswith, all oder re für reguläre Ausdrücke, optional Filter für bekannte Ausnahmen, und die Bedingung, die alles verknüpft. Falsepositives und Level: was den Alarm fälschlich auslösen könnte und wie schwer ein Treffer wiegt, von informational bis critical.

Die Feldnamen in der Selektion folgen einer Konvention, die sich an Sysmon orientiert: Image, CommandLine, ParentImage, TargetFilename, DestinationIp. Die Übersetzung bildet sie auf das ab, was in der jeweiligen Quelle steht, etwa NewProcessName in Event 4688 oder process.executable in Elastic. Deshalb funktioniert dieselbe Regel auf Sysmon-Daten und auf den nativen Windows-Ereignissen, sofern die Befehlszeile in beiden vorhanden ist.

Von der Regel zur Abfrage

Die Übersetzung übernimmt pySigma mit dem Kommandozeilenwerkzeug sigma-cli. Zwei Bausteine sind dabei zu wählen: das Backend, also die Zielsprache, und die Pipeline, also das Datenmodell der Umgebung. Ein Aufruf wie sigma convert -t splunk -p sysmon regel.yml erzeugt eine Splunk-Abfrage für Sysmon-Felder; mit -t elasticsearch und der passenden Pipeline entsteht eine Lucene-Abfrage für Elastic. Backends und Pipelines sind als Plugins organisiert, sodass nur installiert wird, was gebraucht wird. Wer erst einmal sehen will, was aus einer Regel wird, nutzt den webbasierten Konverter auf sigconverter.io: Regel einfügen, Ziel wählen, Abfrage kopieren.

Die Pipeline ist der Teil, der in der Praxis Arbeit macht. Sie bildet die Sigma-Feldnamen auf die Felder ab, die in deinem SIEM tatsächlich ankommen, und die hängen von Agent, Parser und Namenskonvention ab. Die mitgelieferten Pipelines decken die üblichen Kombinationen ab; für eigene Quellen oder umbenannte Felder schreibst du eine kleine Pipeline in YAML, einmal, und alle Regeln übersetzen sich danach korrekt.

Ein zweites Beispiel: eine Regel auf dem Security-Log

Nicht jede Regel braucht Sysmon. Die folgende arbeitet auf dem nativen Windows-Security-Log und meldet RDP-Anmeldungen von Konten, die nicht zur Administratorgruppe gehören, eines der Muster mit dem besten Verhältnis von Trefferqualität zu Fehlalarmen:

title: RDP Logon By Non-Admin Account
id: 8c1f4d2a-3e6b-4a7c-9d0e-1f2a3b4c5d6e
status: test
description: Erfolgreiche RDP-Anmeldung (Anmeldetyp 10) durch ein Konto,
  das nicht zur Gruppe der Administratoren gehoert. Haeufig ein Zeichen
  fuer seitliche Bewegung mit kompromittierten Benutzerkonten.
references:
  - https://attack.mitre.org/techniques/T1021/001/
author: Blue Team
date: 2026-09-13
tags:
  - attack.lateral_movement
  - attack.t1021.001
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 10
  filter_admins:
    TargetUserName|startswith:
      - 'adm-'
      - 'svc-rdp'
  filter_jumphosts:
    Computer|endswith: '-jump01'
  condition: selection and not 1 of filter_*
falsepositives:
  - Helpdesk-Konten ohne Namenskonvention, Benutzer mit legitimem RDP-Zugang
level: medium

Zwei Dinge sind hier anders als im ersten Beispiel. Die Logquelle ist service: security statt category: process_creation, und die Felder heißen so, wie sie im Ereignis stehen: EventID, LogonType, TargetUserName, Computer. Die Filter zeigen, wie Tuning in der Regel selbst dokumentiert wird: Admin-Konten nach Namenskonvention und der Sprunghost sind ausgenommen, und die Bedingung not 1 of filter_* nimmt alle Filter zusammen, ohne dass sie einzeln aufgezählt werden müssen. Wer eine neue Ausnahme braucht, fügt einen Filter hinzu, mit einem Kommentar, warum.

Korrelation: mehrere Ereignisse verknüpfen

Ein einzelner Fehlschlag bei der Anmeldung ist nichts, zwanzig verschiedene Konten von einer Adresse in zehn Minuten sind Password Spraying. Solche Muster beschreibt die Sigma-Spezifikation seit Version 2 mit Korrelationsregeln, die auf eine oder mehrere Basisregeln verweisen. Das Beispiel besteht aus zwei Dokumenten in einer Datei:

title: Failed Logon
name: failed_logon
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
  condition: selection
---
title: Password Spraying - Many Accounts From One Source
id: 2b7e9a4c-5d1f-4e8a-b3c6-7d9e0f1a2b3c
status: test
tags:
  - attack.credential_access
  - attack.t1110.003
correlation:
  type: value_count
  rules:
    - failed_logon
  group-by:
    - IpAddress
  timespan: 10m
  condition:
    field: TargetUserName
    gte: 20
level: high

Die Basisregel bekommt einen Namen, die Korrelationsregel zählt pro Quelladresse die verschiedenen Zielkonten im Zeitfenster und schlägt ab zwanzig an. Neben value_count kennt die Spezifikation event_count für die reine Anzahl, temporal für das gemeinsame Auftreten mehrerer Regeln im Zeitfenster und temporal_ordered für eine feste Reihenfolge, etwa die Serie von Fehlschlägen gefolgt von einer erfolgreichen Anmeldung. Ob und wie ein Backend Korrelationen übersetzt, ist unterschiedlich; Splunk, Elastic und Sentinel unterstützen die Zähl- und Zeitfenstertypen, bei anderen Zielen bleibt die Korrelation eine Aufgabe der SIEM-eigenen Regel-Engine.

Pipeline und Validierung

Wenn die Felder im eigenen SIEM anders heißen als in der Sigma-Konvention, ist eine eigene Pipeline die Lösung, nicht das Umschreiben der Regeln. Eine Pipeline ist eine YAML-Datei mit Transformationen, die vor der Übersetzung angewendet werden. Das Beispiel bildet die Felder des Security-Logs auf ein Elastic-Schema ab und gilt nur für Regeln mit genau dieser Logquelle:

name: Windows Security nach ECS
priority: 20
transformations:
  - id: security_fields
    type: field_name_mapping
    mapping:
      EventID: winlog.event_id
      LogonType: winlog.event_data.LogonType
      TargetUserName: user.name
      IpAddress: source.ip
      Computer: host.name
    rule_conditions:
      - type: logsource
        product: windows
        service: security

Der Aufruf lautet dann sigma convert -t elasticsearch -p eigene-pipeline.yml regel.yml, und dieselbe Pipeline gilt für alle Security-Log-Regeln, die je übersetzt werden. Vor der Übersetzung prüft sigma check regel.yml die Regel gegen die Spezifikation: fehlende Pflichtfelder, ungültige Modifikatoren, Bedingungen, die auf nicht vorhandene Selektionen verweisen. Wer Regeln in einem Repository pflegt, lässt diesen Check bei jeder Änderung automatisch laufen; das SigmaHQ-Repository selbst tut das mit einem eigenen Validierungswerkzeug, das zusätzlich Namenskonventionen und Tag-Formate prüft. Wie aus dieser Praxis ein ganzer Prozess wird, steht im Beitrag zu Detection Engineering. Eine Regel, die den Check besteht, läuft syntaktisch. Ob sie trifft, zeigt erst der Test mit der Technik.

Die Regelsammlung: nutzen, nicht kippen

Das SigmaHQ-Repository enthält mehrere tausend Regeln in drei Gruppen: die Kernsammlung für den Produktivbetrieb, Regeln für Threat Hunting mit höherer Fehlalarmquote und Regeln zu aktuellen Bedrohungen wie bestimmten Kampagnen oder Schwachstellen. Der Fehler, den fast jeder einmal macht: alle Regeln übersetzen und im SIEM aktivieren. Das Ergebnis ist eine Alarmflut, die das SOC nach zwei Tagen ignoriert. Der bessere Weg in vier Schritten:

1. Nach Logquelle filtern. Nur Regeln für Quellen, die tatsächlich im SIEM sind. Eine Regel für Sysmon Event 10 ohne Sysmon erzeugt nichts, aber sie steht im Weg.
2. Nach Level und Status filtern. Zuerst stable und test mit Level high und critical. Das sind einige hundert Regeln, nicht tausende.
3. Zwei Wochen im Beobachtungsmodus. Treffer zählen, nicht alarmieren. Regeln mit Dauerfeuer bekommen Filter für die eigene Umgebung, so wie der Filter für die Softwareverteilung im Beispiel oben, oder werden deaktiviert.
4. Testen. Für jede aktivierte Regel einmal die Technik ausführen, im Homelab oder in einer Purple-Team-Übung. Eine Regel, die nie einen echten Treffer gesehen hat, ist eine Hypothese.

Eigene Regeln schreiben

Die meisten eigenen Regeln entstehen aus drei Quellen: aus einem Vorfall, bei dem eine Technik unentdeckt blieb, aus einem Threat-Hunting-Ergebnis, das dauerhaft überwacht werden soll, und aus den Detection Strategies, die ATT&CK seit Version 18 pro Technik liefert. Der Weg ist immer derselbe: das Verhalten beschreiben, nicht das Werkzeug. Eine Regel auf den Dateinamen mimikatz.exe fängt niemanden, eine Regel auf den Zugriff auf lsass.exe mit bestimmten Rechten fängt jedes Werkzeug, das dasselbe tut. Die Regel bekommt eine ID, ATT&CK-Tags, dokumentierte Fehlalarme und einen Test, mit dem sie sich reproduzieren lässt. Für Erkennungen, die mehrere Ereignisse verknüpfen, etwa fünf fehlgeschlagene Anmeldungen und eine erfolgreiche, sieht die Spezifikation Korrelationsregeln vor; deren Unterstützung hängt vom Backend ab und ist bei einfachen Zähl- und Zeitfenster-Korrelationen inzwischen verbreitet.

Detection as Code

Weil Sigma-Regeln Textdateien sind, lassen sie sich wie Software behandeln: in einem Git-Repository, mit Änderungshistorie, Review vor der Freigabe, automatischer Validierung gegen die Spezifikation und automatischer Übersetzung und Verteilung ins SIEM. Die Einstiegsdokumentation von SigmaHQ beschreibt genau diesen Aufbau. Der Gewinn ist nicht nur Ordnung: Wenn das SIEM gewechselt wird, ändert sich das Backend, nicht die Regeln. Wenn ein Analyst geht, bleibt seine Erkennungslogik lesbar. Und wenn die Frage kommt, welche Techniken abgedeckt sind, beantworten die Tags der Regeln sie auf Knopfdruck.

Grenzen

• Die Übersetzung ist nur so gut wie die Pipeline. Falsche Feldzuordnungen erzeugen Regeln, die syntaktisch laufen und nie treffen. Jede neue Pipeline wird mit einer bekannten Technik getestet.
• Nicht jede Erkennung passt in eine Regel. Statistische Ausreißer, Baselines und Verhaltensmodelle bleiben Sache des SIEM oder eigener Skripte.
• Community-Regeln kennen deine Umgebung nicht. Sie sind ein Startpunkt, kein Produkt. Ohne Tuning erzeugen sie in jeder Umgebung Fehlalarme.

Fazit

Sigma macht Erkennungslogik zu einem Wert, der der Organisation gehört statt dem SIEM-Hersteller. Die Regelsammlung gibt jedem Blue Team einen Vorsprung von Jahren, sofern es sie filtert, tunt und testet statt sie zu kippen. Und wer eigene Regeln als Code pflegt, mit ATT&CK-Tags, Fehlalarm-Notizen und Tests, hat am Ende das, was die meisten SOCs nie bekommen: eine nachvollziehbare Antwort auf die Frage, was sie eigentlich erkennen.