Detection Engineering: von der Sigma-Regel zum Wazuh-Alarm

/01Was Detection Engineering ist und was nicht

Detection Engineering ist der Teil der Sicherheitsarbeit, der aus einem SIEM etwas anderes macht als ein teures Logarchiv. Jemand überlegt, welche Angreifertechnik im eigenen Netz sichtbar wäre, schreibt die Regel, die genau dieses Muster trifft, prüft sie gegen echte Logs, stellt sie scharf, beobachtet, wie oft sie grundlos anschlägt, schärft nach und mustert sie irgendwann aus. Das ist Ingenieursarbeit mit Rückkopplung, kein Installationsschritt.

Was es nicht ist: das Einspielen des mitgelieferten Regelwerks. Wazuh bringt tausende Regeln mit, und die decken Brute-Force gegen SSH, neue Benutzerkonten oder Änderungen an Systemdateien ordentlich ab. Nur kennt das Regelwerk Ihre Umgebung nicht. Es weiß nicht, dass der Benutzer ansible jede Nacht um drei über zwanzig Server hinweg sudo ausführt, dass Ihre Fachanwendung Dienstkonten mit GID 0 anlegt oder dass das Buchhaltungsprogramm PowerShell startet, als wäre es Schadsoftware. Das Ergebnis ohne Nacharbeit ist bekannt: Nach vier Wochen schaut niemand mehr in den Alarmkanal, weil dort achthundert Meldungen am Tag liegen, von denen keine je ein Vorfall war.

Detection Engineering ist auch nicht Incident Response. Die Regel erkennt, der Mensch danach entscheidet. Wer beides in einer Person vereint, hat meistens keines von beiden besetzt, sondern einen Administrator, der nebenbei auf ein Dashboard schaut. In unserem Beitrag zu den fünf Wazuh-Regeln, die jedes KMU braucht, stehen fertige Regeln; hier geht es darum, wie solche Regeln entstehen und wie sie am Leben bleiben.

/02Sigma: das Regelformat, das keinem Hersteller gehört

Jedes SIEM hat seine eigene Regelsprache. Splunk hat SPL, Elastic hat KQL und EQL, Sentinel hat KQL in einer anderen Ausprägung, und Wazuh hat XML. Wer eine Erkennung für „PsExec-Dienst wurde angelegt" schreibt, schreibt sie also für ein Produkt, und beim Produktwechsel fängt er von vorn an. Sigma löst genau dieses Problem: eine Regel im YAML-Format, die beschreibt, was in welcher Logquelle gesucht wird, ohne festzulegen, in welchem System die Suche später läuft.

Die Spezifikation liegt in Version 2.1.0 vor und ist knapp: Pflicht sind nur title, logsource und detection mit einer condition. Alles andere, von id über author bis falsepositives, ist optional, wird in der öffentlichen Sammlung aber konsequent gepflegt. Das Feld level kennt fünf Stufen von informational bis critical, und die tags tragen die MITRE-ATT&CK-Zuordnung in der Form attack.t1136.001.

Die Sammlung dazu heißt SigmaHQ und liegt öffentlich auf GitHub. Hier eine Regel daraus, wörtlich übernommen und nur um Referenzlinks und Kommentare gekürzt:

title: Privileged User Has Been Created
id: 0ac15ec3-d24f-4246-aa2a-3077bb1cf90e
status: test
description: Detects the addition of a new user to a privileged group such as "root" or "sudo"
author: Pawel Mazur
date: 2022-12-21
modified: 2025-01-21
tags:
    - attack.privilege-escalation
    - attack.persistence
    - attack.t1136.001
    - attack.t1098
logsource:
    product: linux
    definition: '/var/log/secure on REHL systems or /var/log/auth.log on debian like Systems needs to be collected in order for this detection to work'
detection:
    selection_new_user:
        - 'new user'
    selection_uids_gids:
        - 'GID=0,'
        - 'UID=0,'
        - 'GID=10,'
        - 'GID=27,'
    condition: all of selection_*
falsepositives:
    - Administrative activity
level: high

Die Regel ist lesbar, ohne dass man ein Produkt kennt: Sie sucht in Linux-Authentifizierungslogs nach einer useradd-Zeile mit „new user", bei der der neue Benutzer UID 0 hat oder in den Gruppen root, wheel oder sudo landet. Sie sagt, welche Technik das ist, sie sagt, woher Fehlalarme kommen, und sie hat ein Änderungsdatum. Das ist mehr Dokumentation, als die meisten hausgemachten Regeln je bekommen.

/03Warum es kein Sigma-nach-Wazuh-Backend gibt

Die Übersetzung von Sigma in eine Zielsprache erledigt pySigma mit austauschbaren Backends. Die von SigmaHQ gepflegte Liste nennt unter anderem Elasticsearch, Splunk, OpenSearch, Loki, Kusto und SQLite; daneben stehen Community-Backends für QRadar, SentinelOne, Datadog und andere. Ein Wazuh-Backend steht nicht darauf, weder gepflegt noch als Community-Beitrag, Stand 08.09.2026.

Das ist kein Versäumnis, sondern liegt an der Architektur. Sigma beschreibt eine Suche über indizierte Ereignisse; die Backends erzeugen Suchanfragen. Wazuh wertet aber nicht nachträglich im Index aus, sondern im Analyseprozess des Managers, Ereignis für Ereignis, mit Decodern, die Felder extrahieren, und Regeln, die aufeinander aufbauen. Eine Wazuh-Regel hat Eltern (if_sid), Häufigkeitsfenster (frequency, timeframe) und Feldnamen, die der jeweilige Decoder vergibt. Nichts davon kennt Sigma, und deshalb lässt sich eine Sigma-Regel nicht mechanisch in eine Wazuh-Regel gießen, ohne zu wissen, welche Elternregel und welcher Decoder im konkreten Fall greifen.

Zwei Dinge gehen trotzdem. Erstens: Der Wazuh-Indexer und das Dashboard sind aus OpenSearch abgeleitet, und für OpenSearch gibt es ein gepflegtes Backend. Sigma-Regeln lassen sich damit in Lucene-Abfragen übersetzen, die Sie im Dashboard gegen den Alarmindex oder ein Archiv historischer Ereignisse laufen lassen. Das taugt für Threat Hunting und für die Frage „hatten wir das schon einmal", nicht für Alarme in Echtzeit. Zweitens: Sigma ist ein hervorragender Steinbruch. Die Logik, die Feldwerte, die Fehlalarmhinweise und die ATT&CK-Zuordnung sind fertig; was fehlt, ist die Übertragung ins Wazuh-XML, und die zeigt der nächste Abschnitt.

/04Eine SigmaHQ-Regel von Hand nach Wazuh übersetzen

Der erste Schritt ist immer die Frage, welche Wazuh-Regel das Ereignis heute schon trifft. Für useradd-Zeilen ist das im mitgelieferten Regelwerk die Regel 5902 mit Level 8, die auf „new user" oder „new account added" anspricht und bereits T1136 trägt. Sie meldet jeden neuen Benutzer. Die Sigma-Regel will nur die privilegierten. Also wird die Sigma-Regel eine Kindregel von 5902, die den Level anhebt und den Treffer verfeinert:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,syslog,adduser,">

  <!-- Sigma: Privileged User Has Been Created (0ac15ec3-d24f-4246-aa2a-3077bb1cf90e) -->
  <rule id="100210" level="12">
    <if_sid>5902</if_sid>
    <match>UID=0,|GID=0,|GID=10,|GID=27,</match>
    <description>Neuer Benutzer mit root-/wheel-/sudo-Rechten angelegt: $(dstuser)</description>
    <mitre>
      <id>T1136.001</id>
      <id>T1098</id>
    </mitre>
    <group>privilege_escalation,persistence,</group>
  </rule>

</group>

Was hier passiert ist, in Reihenfolge: Die Regel-ID liegt im Bereich 100000 bis 120000, den die Wazuh-Dokumentation für eigene Regeln reserviert. if_sid hängt die Regel unter 5902, sodass sie nur läuft, wenn der Decoder bereits eine useradd-Meldung erkannt hat. match ist in Wazuh eine Teilstringsuche mit | als Oder, und die vier Werte samt Komma stammen unverändert aus der Sigma-Regel. Das Sigma-Level high wird zu Wazuh-Level 12, der Stufe, die die Dokumentation als „high importance event" führt und ab der standardmäßig Mailalarme ausgelöst werden. Die beiden ATT&CK-Tags werden zu zwei <id>-Einträgen.

Getestet wird vor dem Neustart. Wazuh bringt dafür /var/ossec/bin/wazuh-logtest mit, das eine Logzeile durch Decoder und Regeln schickt und zeigt, welche Regel zuletzt gegriffen hat. Eine useradd-Zeile mit UID=0 muss jetzt auf 100210 landen, eine mit UID 1000 und GID 1000 weiterhin auf 5902. Erst wenn beide Fälle stimmen, wird der Manager neu gestartet; laut Dokumentation genügt das Speichern der Datei für den Test, für echte Alarme braucht es den Neustart.

Ehrlich: Die Übersetzung hat zehn Minuten gedauert, die Recherche nach der richtigen Elternregel und dem Feldnamen dstuser im Decoder die halbe Stunde davor. Das ist die realistische Größenordnung pro Regel, wenn die Logquelle bereits sauber dekodiert wird. Fehlt der Decoder, weil die Quelle ein Nischenprodukt ist, wird aus der halben Stunde ein Nachmittag.

/05MITRE ATT&CK in der Wazuh-Regel

Das <mitre>-Element ist mehr als Kosmetik. Wazuh reichert jeden Alarm, dessen Regel eine Technik-ID trägt, um ein mitre-Objekt an, das im Alarm-JSON neben der ID auch den Techniknamen und die zugehörigen Taktiken führt; das Dokumentationsbeispiel zu T1543.003 zeigt "tactic": ["Persistence", "Privilege Escalation"]. Diese Anreicherung speist das ATT&CK-Modul im Dashboard, das Alarme nach Taktik und Technik gruppiert. Aus vierhundert Einzelmeldungen wird so eine Karte: hier häufen sich Zugriffsversuche, dort Persistenzmechanismen, und dort ist seit Monaten nichts, entweder weil nichts passiert oder weil keine Regel hinschaut.

Die Zuordnung ist deshalb auch das Werkzeug für die unbequeme Inventur. Nehmen Sie die Techniken, die in Ihrer Branche typische Ransomware-Ketten bilden, etwa Phishing als Einstieg, gültige Konten, PowerShell, Deaktivieren von Schutzsoftware, Schattenkopien löschen, und prüfen Sie je Technik: Gibt es eine Regel, liefert eine Logquelle die nötigen Ereignisse, und hat die Regel in den letzten neunzig Tagen je gefeuert, auch nur im Test? Drei Ja heißt abgedeckt. Ein Nein heißt Lücke. Diese Tabelle, gepflegt in einem Tabellenblatt oder besser im selben Git-Repository wie die Regeln, ist das ehrlichste Bild Ihrer Erkennungsabdeckung, das Sie bekommen.

/06Fehlalarme: Level, Baselines, Ausnahmen

Die Regel aus Abschnitt 04 wird in der ersten Woche feuern, und zwar zurecht: Ihre Kollegen legen Administratoren an. Ob das ein Fehlalarm ist, entscheidet nicht die Regel, sondern der Prozess dahinter. Gibt es ein Ticket für jeden neuen Admin, ist der Alarm die Bestätigung des Tickets und in dreißig Sekunden geschlossen. Gibt es keins, ist der Alarm ein Fund, auch wenn der Auslöser ein Kollege war. Detection Engineering beginnt also mit einer Baseline: Was ist in dieser Umgebung normal, wer darf was, und woran erkennt eine Regel den Unterschied?

Wazuh gibt dafür drei Stellschrauben. Die erste ist der Level. Die Skala läuft von 0 bis 15; Level 0 bedeutet laut Dokumentation „No action taken. Used to avoid false positives", ab log_alert_level mit Standard 3 landet ein Ereignis im Alarmprotokoll, ab email_alert_level mit Standard 12 geht eine Mail hinaus. Wer alles auf 12 setzt, hat bald einen Posteingang, den niemand liest. Wer Regeln bewusst auf 5 bis 8 legt, sammelt Kontext, ohne zu wecken.

Die zweite Stellschraube ist die Ausnahme als eigene Kindregel. Läuft ein Provisionierungswerkzeug nachts und legt Dienstkonten mit GID 0 an, schreibt man keine Notiz „ignorieren, ist Ansible", sondern eine Regel, die unter 100210 hängt, auf den Hostnamen des Provisionierungsservers und das Zeitfenster prüft und den Level auf 0 setzt. Die Ausnahme ist damit dokumentiert, versioniert, und sie schlägt an, sobald jemand denselben Weg von einem anderen Host aus geht. Die dritte Stellschraube sind Häufigkeitsfenster: frequency und timeframe machen aus acht einzelnen Fehlanmeldungen von einer Adresse binnen 120 Sekunden einen Brute-Force-Alarm, so wie es die mitgelieferte Regel 5712 für SSH bereits tut. Ein einzelner Fehlversuch bleibt auf Level 5, die Serie steigt auf 10.

Was in der Praxis am häufigsten schiefgeht: Ausnahmen werden zu breit. Eine Regel, die den gesamten Admin-Bereich ausnimmt, weil ein Admin-Skript störte, ist eine Regel, die Angreifer mit gestohlenen Admin-Konten nicht mehr sieht. Jede Ausnahme braucht deshalb die engste Bedingung, die den konkreten Fall trifft, und ein Ablaufdatum im Kommentar, nach dem sie überprüft wird.

/07Regel-Lebenszyklus: Staging, Git, Review

Eine Regel, die direkt auf dem produktiven Manager in local_rules.xml editiert wird, ist in dem Moment undokumentiert, in dem der Editor geschlossen wird. Niemand weiß später, warum Zeile 40 den Level auf 0 setzt, und der Kollege, der es wusste, ist im Urlaub. Detection Engineering behandelt Regeln deshalb wie Code, und die Praxis dazu ist unspektakulär.

• Ein Repository für Regeln und Decoder. Das Verzeichnis /var/ossec/etc/rules/ und /var/ossec/etc/decoders/ liegen in GitLab oder einem anderen Git-Dienst. Jede Regel hat im Kommentar Herkunft (Sigma-ID, Vorfall, Auditfinding), Autor und Datum. Der Commit sagt, warum sich etwas geändert hat.
• Test gegen echte Logs. Zu jeder Regel liegen mindestens zwei Beispielzeilen im Repository: eine, die treffen muss, eine, die nicht treffen darf. Ein kleines Skript schickt beide durch wazuh-logtest und vergleicht die Regel-ID im Ergebnis. Das ist der Unit-Test einer Erkennung und läuft in der Pipeline bei jedem Commit.
• Staging-Manager. Ein zweiter Wazuh-Manager, klein dimensioniert, bekommt eine Kopie des Logstroms oder zumindest den Logstrom einer repräsentativen Agentengruppe. Neue Regeln laufen dort eine Woche mit, bevor sie produktiv gehen. Erst dort sieht man, dass die Regel aus Abschnitt 04 wegen eines Backup-Dienstkontos täglich um 02:15 Uhr feuert.
• Review durch eine zweite Person. Ein Merge Request, den ein Kollege liest, fängt die zu breite Ausnahme, die man selbst nicht mehr sieht. Bei zwei Personen im Team ist das die einzige Kontrolle, die es gibt; bei einer Person gibt es sie nicht, und das ist dann ehrlich zu benennen.
• Ausrollen über Konfigurationsmanagement. Das Repository wird per Ansible oder Pipeline auf den Manager verteilt, mit Neustart des Analyseprozesses im Wartungsfenster. Rückweg ist ein git revert, nicht das Wiederherstellen einer Sicherung.
• Ausmustern. Regeln, die in einem Jahr nie gefeuert haben und deren Logquelle es nicht mehr gibt, werden entfernt, nicht auskommentiert. Ein Regelwerk mit vierhundert toten Regeln ist unlesbar.

Der Vergleich zu GitOps liegt nahe, und er trägt: Der gewünschte Zustand steht im Repository, der Manager folgt ihm. Wer das schon für die Firewallregeln oder die Serverkonfiguration macht, hat die Werkzeuge und die Gewohnheiten bereits. Wer es nirgends macht, fängt bei den Erkennungsregeln an, weil hier der Schaden einer verlorenen Änderung am größten ist.

/08Kennzahlen, die eine Regelbasis beurteilen

Ob die Arbeit etwas bringt, lässt sich messen, und die Messung ist wichtiger als die absolute Zahl. Belastbare Werte liefert nur Ihre eigene Umgebung; Branchenzahlen zu Fehlalarmquoten oder Erkennungszeiten schreiben wir hier bewusst nicht hin, weil sie je nach Zählweise beliebig ausfallen.

Zwei Kennzahlen davon reichen für den Anfang: die Fehlalarmquote je Regel und die Abdeckungstabelle aus Abschnitt 05. Die erste sagt, was Sie diese Woche abstimmen sollten; die zweite, was Sie dieses Quartal bauen sollten. MTTD und MTTR sind Begriffe, die in jeder Ausschreibung stehen; messbar werden sie erst, wenn Alarme konsequent in Tickets landen und Übungen stattfinden. Ein Penetrationstest mit angekündigtem Zeitfenster ist die beste Gelegenheit, beide Werte einmal ehrlich zu nehmen: Was hat das SIEM gesehen, wann, und wer hat wann reagiert?

/09Wo Eigenbetrieb endet: die 24/7-Rechnung

Bis hierher war alles mit einer Person machbar, die ein Fünftel ihrer Woche dafür bekommt und Git nicht scheut: Sigma-Regeln übersetzen, Baseline bauen, Fehlalarme drücken, Abdeckung pflegen. Detection Engineering im Mittelstand ist als Nebentätigkeit eines guten Administrators realistisch, wenn der Umfang klein bleibt und die Logquellen Standard sind. Wann ist das die falsche Wahl?

Erstens, wenn niemand den Alarm sieht. Eine Woche hat 168 Stunden. Eine Vollzeitstelle deckt 40 davon. Wer einen Bildschirm rund um die Uhr besetzt haben will, braucht rechnerisch 4,2 Stellen, und das vor Urlaub, Krankheit, Schulung und der Tatsache, dass niemand allein Nachtschicht macht. Erfahrungswert, keine Studie: In der Praxis landet man bei fünf bis sechs Personen für einen einzigen durchgehend besetzten Platz. Kein Betrieb mit 80 Mitarbeitern stellt sechs Sicherheitsanalysten ein, und die Detection-Regel um 03:10 Uhr ist nur so viel wert wie der Mensch, der um 03:12 Uhr reagiert. Die Alternative ist die ehrliche: Erkennung im Haus, Reaktion nur zu Bürozeiten, und das Restrisiko der Nacht schriftlich von der Geschäftsführung getragen. Das ist eine legitime Entscheidung, wenn sie bewusst fällt. Sie ist es nicht, wenn sie durch Unterlassen fällt.

Zweitens, wenn die Logquellen über Linux und Windows Server hinausgehen. Sobald Firewalls verschiedener Hersteller, Active Directory, Microsoft 365, ein EDR-Produkt und Fachanwendungen Logs liefern, wächst der Decoder- und Regelbestand schneller, als eine Nebentätigkeit ihn pflegen kann. Drittens, wenn NIS2 oder ein ISO-27001-Audit Nachweise verlangen, dass Erkennung und Reaktion tatsächlich betrieben werden, mit Protokoll, Runbooks und Nachbetrachtung je Vorfall. Ein Repository mit Regeln belegt die Erkennung; die Reaktion belegt es nicht.

Umgekehrt gilt: Wer ein Managed SOC oder MDR einkauft, gibt die Regelpflege nicht vollständig ab. Der Dienstleister kennt Ihre Angriffsfläche und die typischen Techniken, aber nicht Ihr Provisionierungsskript und nicht Ihre Buchhaltung. Die Baseline, also das Wissen, was bei Ihnen normal ist, bleibt Ihre Zulieferung, und ein guter Anbieter fragt danach, bevor er die erste Regel scharf stellt. Wie sich Managed SOC, MDR und EDR voneinander unterscheiden und was sie leisten, haben wir im Beitrag Managed SOC, MDR oder EDR auseinandergenommen; den Einstieg in Wazuh selbst beschreibt der SIEM-Leitfaden für KMU.

Unsere Empfehlung in einem Satz: Bauen Sie die Regelbasis selbst so weit auf, dass Sie verstehen, was sie erkennt, und geben Sie den Teil ab, für den Sie keine Schicht besetzen können. Wer beides im Haus hält, hat meistens keines von beiden, und wer beides abgibt, kann die Arbeit des Dienstleisters nicht mehr beurteilen.

/10Häufige Fragen