Wazuh 5.0: Sysmon-Regeln von XML auf Sigma-basiertes YAML migrieren

Einleitung

Mit Wazuh 5.0 ändert sich die Methodik zur Entwicklung eigener Erkennungsregeln grundlegend. Während Wazuh 4.x benutzerdefinierte Regeln als XML-Dateien verarbeitet, setzt Wazuh 5.x auf YAML-Regeln mit Sigma-orientierter Erkennungslogik. Gleichzeitig werden Ereignisnormalisierung, Regelauswertung und die Verwaltung von Detection Content stärker voneinander getrennt.

Für Betreiber umfangreicher Sysmon-Regelwerke bedeutet das: Bestehende XML-Regeln lassen sich nicht einfach in eine Wazuh-5.0-Installation kopieren oder importieren. Sie müssen fachlich analysiert, auf das Wazuh Common Schema abgebildet und als neue YAML-Regeln implementiert werden.

Stand 26. Juli 2026 liegt Wazuh 5.0 als Beta 4 vor. Da es sich weiterhin um eine Vorabversion handelt, sollten produktive Migrationsprojekte die endgültige Dokumentation und mögliche Änderungen bis zur stabilen Veröffentlichung berücksichtigen.

Ausgangslage / Problemstellung

In einer bestehenden Wazuh-4.14-Umgebung werden Sysmon-Ereignisse von Windows-Endpunkten erfasst und über benutzerdefinierte XML-Regeln ausgewertet. Typische Regeln erkennen beispielsweise:

verdächtige PowerShell-Aufrufe,
ungewöhnliche Parent-Child-Prozessketten,
Prozessinjektion,
das Anlegen geplanter Tasks,
verdächtige Netzwerkverbindungen,
Änderungen an sicherheitsrelevanten Registry-Schlüsseln,
den Zugriff auf LSASS oder andere sensible Prozesse.

Die Regeln befinden sich üblicherweise in Dateien wie:

/var/ossec/etc/rules/local_rules.xml
/var/ossec/etc/rules/custom_sysmon_rules.xml

Eine klassische Wazuh-4.x-Regel kann beispielsweise so aufgebaut sein:

<group name="sysmon,sysmon_process_creation,">
  <rule id="100101" level="12">
    <if_group>sysmon_event1</if_group>

    <field name="win.eventdata.image" type="pcre2">
      (?i)\\powershell\.exe$
    </field>

    <field name="win.eventdata.commandLine" type="pcre2">
      (?i)(-enc|-encodedcommand)
    </field>

    <description>
      Sysmon: PowerShell with encoded command
    </description>

    <mitre>
      <id>T1059.001</id>
    </mitre>
  </rule>
</group>

Diese Regel hängt von mehreren Eigenschaften der Wazuh-4.x-Architektur ab:

Der Sysmon-Decoder stellt Felder wie win.eventdata.image und win.eventdata.commandLine bereit.
Die Regel erbt über if_group den Kontext einer vorherigen Sysmon-Regel.
Die numerische Regel-ID identifiziert die Detection.
Das numerische Level steuert die Einstufung und Alarmierung.
Reguläre Ausdrücke werden direkt in XML-Elementen hinterlegt.

Genau diese Mechanismen ändern sich mit Wazuh 5.0. Eine XML-Datei aus Wazuh 4.x kann deshalb nicht unverändert in Wazuh 5.x hochgeladen werden. Nach aktuellem Entwicklungsstand existiert auch kein automatisches Konvertierungswerkzeug, das ein vollständiges XML-Regelwerk zuverlässig in produktionsfähige Wazuh-5-Regeln überführt.

Technische Analyse

Neue Verarbeitungskette in Wazuh 5.0

Wazuh 4.x verbindet Decoding und Rule Matching eng im zentralen Analyseprozess. Ein eingehendes Ereignis wird dekodiert, gegen XML-Regeln geprüft und bei einem Treffer als Alert ausgegeben.

Wazuh 5.x trennt diese Aufgaben deutlicher:

Die Wazuh Engine empfängt das Rohereignis.
Decoder und Normalisierungslogik übertragen die Daten in das Wazuh Common Schema.
Das normalisierte Ereignis wird in einen wazuh-events-v5-*-Index geschrieben.
Security-Analytics-Detektoren prüfen die Ereignisse gegen Sigma-basierte YAML-Regeln.
Bei einem Treffer entsteht ein Finding im entsprechenden wazuh-findings-v5-*-Index.

Der bisherige Begriff „Alert“ wird in diesem Detection-Workflow weitgehend durch „Finding“ ersetzt. Ein Finding enthält neben dem normalisierten Ereignis auch Informationen zur passenden Regel, zu MITRE ATT&CK, Compliance-Zuordnungen, Agent, Host und ursprünglicher Logzeile.

XML-Dateien werden durch verwalteten Detection Content ersetzt

In Wazuh 4.x werden Regeln als Dateien auf dem Dateisystem abgelegt. Änderungen erfordern normalerweise ein Neuladen oder einen Neustart des Managers.

In Wazuh 5.x werden Regeln, Decoder, Integrationen und Key-Value-Datenbanken über das Content-Management-System verwaltet. Regeln werden als Dokumente gespeichert und einer Integration zugeordnet.

Benutzerdefinierter Content durchläuft dabei drei Bereiche:

Draft → Test → Custom

Draft: Entwicklung und Bearbeitung.
Test: Validierung mit Log Test, ohne produktive Auswertung.
Custom: Für produktive Detektoren freigegebener Content.

Dieser Lebenszyklus verhindert, dass eine noch nicht validierte Regel unmittelbar auf produktive Ereignisse angewendet wird.

Sigma-Syntax allein reicht nicht aus

Die Wazuh-5-Regeln orientieren sich am Sigma-Format und verwenden typische Sigma-Konstrukte wie:

detection:
  selection:
    process.name: powershell.exe
  condition: selection

OpenSearch Security Analytics unterstützt ebenfalls Sigma-basierte Detection Rules in YAML und bietet Funktionen zum Importieren, Duplizieren und Anpassen solcher Regeln. Die OpenSearch-Dokumentation ist daher hilfreich, um das grundlegende Sigma-Modell zu verstehen.

Für eine Wazuh-Migration reicht eine syntaktisch gültige Sigma-Regel jedoch nicht aus. Zusätzlich müssen insbesondere folgende Wazuh-spezifische Anforderungen berücksichtigt werden:

Zuordnung der Regel zu einer Integration,
Verwendung gültiger WCS-Felder,
Auswahl der richtigen Integrationskategorie und Ereignisindizes,
Promotion über Draft, Test und Custom,
Aktivierung über einen Detector,
strukturierte MITRE- und Compliance-Zuordnungen.

Die Wazuh-Dokumentation ist deshalb die maßgebliche Referenz für den produktiven Einsatz.

Das Wazuh Common Schema ist die zentrale Migrationshürde

In Wazuh 4.x kann ein Decoder prinzipiell beliebige Feldnamen erzeugen. Eine Regel verweist anschließend direkt auf diese Felder:

<field name="win.eventdata.commandLine">

Wazuh 5.x verwendet dagegen das geschlossene und validierte Wazuh Common Schema. Typische normalisierte Feldnamen sind beispielsweise:

event.action
event.code
event.outcome
process.name
process.executable
process.command_line
parent.process.name
source.ip
destination.ip
user.name
host.name

Ein altes Decoder-Feld wie sysmon.image oder win.eventdata.commandLine kann nicht ungeprüft in die YAML-Regel übernommen werden. Unbekannte Felder werden bereits beim Anlegen der Regel abgelehnt.

Der entscheidende Arbeitsschritt ist daher nicht die Umwandlung von XML in YAML, sondern die Abbildung der alten Felder auf das tatsächlich erzeugte WCS-Dokument. Die autoritative Quelle dafür ist ein repräsentatives Ereignis im Wazuh Log Test. Dessen Normalisierungsausgabe zeigt, welche Feldpfade die Regel verwenden muss.

Regelverkettung wird nicht direkt übernommen

Viele umfangreiche Wazuh-4.x-Regelwerke verwenden Abhängigkeiten wie:

<if_sid>...</if_sid>
<if_group>...</if_group>
<if_level>...</if_level>
<if_matched_sid>...</if_matched_sid>

Diese Verkettung lässt sich nicht eins zu eins in eine Wazuh-5-Regel übertragen. Eine YAML-Regel muss ihre eigentliche Erkennungslogik grundsätzlich selbst enthalten.

Eine Wazuh-4.x-Struktur wie:

Sysmon-Grundregel
  └── Process-Create-Regel
      └── PowerShell-Regel
          └── Encoded-PowerShell-Regel

wird deshalb nicht als identische Regelhierarchie nachgebaut. Stattdessen prüft die neue Regel direkt die normalisierten Eigenschaften des Ereignisses:

detection:
  selection:
    event.code: "1"
    process.executable|endswith: "\\powershell.exe"
    process.command_line|contains: "-encodedcommand"
  condition: selection

Reine Parent-, Gruppierungs- oder noalert-Regeln aus Wazuh 4.x müssen häufig überhaupt nicht migriert werden. Relevant sind vor allem die Leaf Rules, die tatsächlich einen sicherheitsrelevanten Alert erzeugen.

Korrelationsregeln erfordern ein neues Design

Besonders sorgfältig müssen Regeln behandelt werden, die in Wazuh 4.x folgende Funktionen verwenden:

frequency
timeframe
same_*
different_*
if_matched_sid
if_matched_group
global_frequency

Diese Funktionen gehören nicht zur eigentlichen Sigma-Regellogik von Wazuh 5.x. Eine einzelne YAML-Regel wertet primär ein normalisiertes Ereignis aus. Mehrere Ereignisse, Zeitfenster und zusammenhängende Aktivitäten müssen über separate Korrelations-, Detector- oder Query-Mechanismen abgebildet werden.

Eine Regel wie „fünf fehlgeschlagene Anmeldungen derselben Quell-IP innerhalb von zwei Minuten“ ist deshalb keine einfache Formatkonvertierung. Sie muss als Korrelations-Use-Case neu entworfen werden.

Weitere Konstrukte ohne direkte Entsprechung

Auch folgende XML-Funktionen können nicht unverändert übernommen werden:

Wazuh 4.x	Wazuh 5.x
Numerische Rule-ID	Vom System verwaltete UUID
Level 0–16	`informational`, `low`, `medium`, `high`, `critical`
`<match>` auf Rohtext	WCS-Feld, `keywords` oder `event.original`
`<regex>`	Feld mit `\|re`-Modifier
`negate="yes"`	`selection and not filter`
CDB-Listen über `<list>`	KVDB während der Normalisierung
`<group>` für Compliance	Strukturierter `compliance`-Block
`<mitre><id>`	Taktik-, Technik- und Subtechnik-Arrays
`overwrite="yes"`	Aktualisierung eines eigenständigen Content-Dokuments
`<time>` und `<weekday>`	Externe zeitbasierte Logik
`<options>`	Separate Routing-, Suppression- oder Indexkonfiguration

Insbesondere bei CDB-Listen ist zu beachten, dass KVDBs in Wazuh 5.x während der Decodierung und Normalisierung verwendet werden. Sie sind kein direkter Ersatz für einen Lookup innerhalb der Detection Rule.

Lösung / Best Practices

1. Regelbestand und Abhängigkeiten inventarisieren

Vor der eigentlichen Migration sollte das vorhandene XML-Regelwerk vollständig erfasst werden:

find /var/ossec/etc/rules/ \
  -name "*.xml" \
  -exec grep -l '<rule ' {} \;

Zusätzlich sollten überschriebene Standardregeln gesucht werden:

grep -R 'overwrite="yes"' /var/ossec/etc/rules/

Für jede Regel sollten mindestens folgende Informationen dokumentiert werden:

Alte Regel-ID
Beschreibung
Level
Sysmon Event ID
Verwendete Decoder-Felder
Parent-Regeln und Gruppen
Reguläre Ausdrücke
Negationen und Ausnahmen
MITRE-ATT&CK-Zuordnung
Compliance-Zuordnung
CDB- oder Lookup-Abhängigkeiten
Frequenz- und Zeitbedingungen
Beispielereignisse
Erwartetes positives Ergebnis
Erwartete False Positives

Parent-Regeln, die ausschließlich der Strukturierung dienen, sollten getrennt von den tatsächlich alarmierenden Leaf Rules betrachtet werden.

2. Repräsentative Sysmon-Ereignisse sichern

Für jede zu migrierende Regel werden positive und negative Testereignisse benötigt.

Mindestens gesichert werden sollten:

ein Ereignis, das die Regel auslösen muss,
ein ähnliches Ereignis, das nicht auslösen darf,
bekannte administrative oder legitime Varianten,
Ereignisse mit unterschiedlichen Windows- und Sysmon-Versionen,
Ereignisse mit fehlenden optionalen Feldern.

Ohne diese Testdaten ist eine zuverlässige Feldzuordnung und Regressionserkennung kaum möglich.

3. Wazuh 5.0 parallel bereitstellen

Wazuh 5.x ist kein klassisches In-place-Upgrade von Wazuh 4.x. Die empfohlene Vorgehensweise besteht darin, eine neue Wazuh-5.x-Umgebung bereitzustellen und unterstützte Konfigurationen kontrolliert neu anzulegen.

Bestehende Wazuh-4.x-Indizes und Snapshots können aufgrund geänderter Schemas und Mappings nicht in Wazuh 5.x wiederhergestellt oder reindexiert werden. Werden historische Daten weiterhin benötigt, sollte die alte Umgebung für einen definierten Zeitraum schreibgeschützt erhalten bleiben.

Ein sinnvoller Übergang sieht daher so aus:

Wazuh 4.x
  ├── produktive Erkennung
  ├── historische Alerts
  └── Referenz für bestehende Use Cases

Wazuh 5.x
  ├── neue Integrationen
  ├── normalisierte Testereignisse
  ├── migrierte YAML-Regeln
  └── neue Findings

Erst wenn die Detection Coverage und False-Positive-Rate ausreichend verglichen wurden, sollte die alte Erkennung außer Betrieb genommen werden.

4. Benutzerverwaltete Sysmon-Integration vorbereiten

In Wazuh 5.x gehören Regeln zu einer Integration. Die Integration bündelt die für eine Logquelle benötigten Decoder, Regeln und optionalen KVDBs.

Benutzerdefinierte Regeln werden in einem benutzerverwalteten Bereich angelegt. Standard-Content ist grundsätzlich nicht für direkte Änderungen vorgesehen. Für ein eigenes Sysmon-Regelwerk muss deshalb eine passende Custom Integration vorhanden sein, deren Decoder die benötigten Sysmon-Daten in WCS-Felder normalisieren.

Der Titel der Integration ist besonders wichtig: logsource.product muss exakt mit dem Integrationstitel übereinstimmen.

5. Alte Felder über Log Test auf WCS abbilden

Ein Sysmon-Ereignis sollte in den Test-Bereich übernommen und mit Log Test verarbeitet werden.

Der Ablauf lautet:

Security Analytics
  → Log test
  → Sysmon-Ereignis einfügen
  → Normalization prüfen
  → WCS-Felder dokumentieren
  → Detection-Ergebnis prüfen

Alternativ kann der Log Test über die API aufgerufen werden:

curl -sk -u admin:admin \
  -X POST \
  "https://localhost:9200/_plugins/_content_manager/logtest" \
  -H "Content-Type: application/json" \
  -d '{
    "integration": "<INTEGRATION-UUID>",
    "space": "test",
    "queue": 1,
    "location": "EventChannel",
    "event": "<SYSMMON-EREIGNIS>"
  }'

Entscheidend ist der Bereich normalization.output. Nur die dort vorhandenen Feldpfade sollten in der Regel verwendet werden.

Eine Feldmapping-Tabelle kann beispielsweise so aussehen:

Wazuh-4.x-Feld	Möglicher WCS-Zielpfad
`win.system.eventID`	`event.code`
`win.eventdata.image`	`process.executable`
`win.eventdata.commandLine`	`process.command_line`
`win.eventdata.parentImage`	`parent.process.executable`
`win.eventdata.user`	`user.name`
`win.eventdata.destinationIp`	`destination.ip`
`win.eventdata.destinationPort`	`destination.port`

Diese Zuordnungen dürfen nicht pauschal angenommen werden. Maßgeblich ist immer die Normalisierungsausgabe der eingesetzten Integration.

6. XML-Erkennungslogik als eigenständige YAML-Regel formulieren

Die frühere XML-Regel für encoded PowerShell könnte nach erfolgter WCS-Prüfung beispielsweise in folgende Richtung migriert werden:

enabled: true
status: experimental
level: high

metadata:
  title: Encoded PowerShell command detected
  author: Security Team
  description: >-
    Detects PowerShell or PowerShell Core processes that use an
    encoded-command parameter. This behavior is frequently associated
    with script obfuscation but can also occur during legitimate
    administration.
  references:
    - "Migrated from Wazuh 4.x rule 100101"

logsource:
  product: custom-sysmon
  service: sysmon

detection:
  selection_process:
    event.code: "1"
    process.executable|endswith:
      - "\\powershell.exe"
      - "\\pwsh.exe"

  selection_argument:
    process.command_line|re|i: >-
      (^|\s)(-|/)(enc|encodedcommand)(\s|:|$)

  filter_known_automation:
    parent.process.executable|endswith:
      - "\\approved-automation-agent.exe"

  condition: >-
    selection_process and selection_argument
    and not filter_known_automation

mitre:
  tactic:
    - TA0002
  technique:
    - T1059
  subtechnique:
    - T1059.001

tags:
  - attack.execution
  - attack.t1059.001
  - sysmon.process-create

falsepositives:
  - Legitimate software deployment
  - Approved administrative automation
  - Security validation and penetration testing

Das Beispiel ist bewusst als Migrationsvorlage zu verstehen. Vor dem Einsatz müssen insbesondere diese Punkte anhand der tatsächlichen Normalisierung verifiziert werden:

event.code
process.executable
process.command_line
parent.process.executable
logsource.product
logsource.service

Die UUID der Regel wird beim Anlegen durch das Content-Management-System verwaltet. Exportierte oder versionsspezifische Beispiele können zusätzlich ein id-Feld enthalten.

7. Präzise Feldvergleiche vor Rohtextsuche bevorzugen

Die Reihenfolge der bevorzugten Detection-Methoden sollte sein:

Exakter Vergleich eines normalisierten WCS-Feldes.
Vergleich mit contains, startswith oder endswith.
Regulärer Ausdruck auf einem konkreten WCS-Feld.
Keyword-Suche über mehrere Felder.
Suche in event.original als letzte Option.

Beispiel für einen präzisen Feldvergleich:

detection:
  selection:
    process.executable|endswith: "\\rundll32.exe"
    process.command_line|contains: "javascript:"
  condition: selection

Fallback auf den Rohtext:

detection:
  selection:
    event.original|contains: "javascript:"
  condition: selection

Der Rohtext-Fallback ist weniger stabil, weil Formatierungsänderungen, zusätzliche Leerzeichen oder unterschiedliche Event-Provider die Erkennung beeinflussen können.

8. Ausschlüsse mit Sigma-Filtern umsetzen

Eine XML-Negation wie:

<field name="win.eventdata.user" negate="yes">
  SYSTEM
</field>

wird als eigener Filter formuliert:

detection:
  selection:
    event.code: "1"
    process.executable|endswith: "\\example.exe"

  filter_system:
    user.name: "SYSTEM"

  condition: selection and not filter_system

Ausschlüsse sollten möglichst eng gefasst werden. Ein vollständiger Pfad, ein bestimmter Signer, ein erwarteter Parent-Prozess oder ein definierter Service Account ist meist belastbarer als eine breite Ausnahme für einen Prozessnamen.

9. Severity, MITRE und Compliance bewusst neu bewerten

Die numerischen Level aus Wazuh 4.x werden nicht einfach als Zahlen übernommen. Als Orientierung gilt:

Wazuh 4.x	Wazuh 5.x
1–3	`informational`
4–6	`low`
7–9	`medium`
10–13	`high`
14–16	`critical`

Diese Abbildung sollte nicht mechanisch erfolgen. Die Migration ist eine gute Gelegenheit, die tatsächliche Aussagekraft und betriebliche Priorität jeder Regel neu zu bewerten.

Auch MITRE ATT&CK wird strukturierter erfasst:

mitre:
  tactic:
    - TA0002
  technique:
    - T1059
  subtechnique:
    - T1059.001

Eine Subtechnik allein genügt nicht. Die zugehörige Technik und Taktik sollten ebenfalls angegeben werden.

10. Regel über Draft, Test und Custom ausrollen

Der empfohlene Ablauf für jede Regel lautet:

1. Integration und Regel in Draft erstellen
2. Content nach Test promoten
3. Positive und negative Ereignisse mit Log Test prüfen
4. Normalisierung und Rule Match kontrollieren
5. Regel nach Custom promoten
6. Detector für Integration und Event-Index erstellen
7. Findings im Dashboard kontrollieren
8. False Positives und Laufzeitverhalten beobachten

Ein Detector ist der geplante Job, der die ausgewählten Regeln auf die Ereignisse eines passenden Index oder Alias anwendet. Ohne korrekte Zuordnung von Integration, Index, Space und Regel wird aus einer vorhandenen YAML-Regel keine kontinuierlich aktive Detection.

11. Agent-Migration getrennt planen

Die Migration der zentralen Wazuh-Komponenten und die Aktualisierung der Agents sind getrennte Arbeitspakete.

Beim Übergang müssen Agents neu eingeschrieben und ihren Gruppen explizit zugeordnet werden. Die Beta-Dokumentation zeigt außerdem ein Remote-Upgrade eines Agents von 4.14.5 auf 5.0.0. Direkte Agent-Upgrades von 4.14.0 oder älter auf 5.0.0 werden nicht unterstützt; diese Agents müssen zuerst auf eine aktuelle 4.14.x-Version gebracht werden.

Für Sysmon-Use-Cases sollte nach jeder Agent- oder Manager-Änderung geprüft werden:

Werden die konfigurierten Event Channels weiterhin erfasst?
Erreichen die Sysmon-Ereignisse den neuen Manager?
Werden alle relevanten Felder normalisiert?
Ist die Ereignisrate plausibel?
Erzeugen die Detektoren die erwarteten Findings?

Lessons Learned / Best Practices

Detection Engineering statt Formatkonvertierung

Die Migration sollte als vollständiger Detection-Engineering-Prozess behandelt werden. Eine automatische Ersetzung von XML-Tags durch YAML-Schlüssel berücksichtigt weder WCS-Feldmapping noch Regelabhängigkeiten, Korrelationen oder False-Positive-Ausnahmen.

Auch KI-gestützte Konvertierung kann nur einen Ausgangsentwurf liefern. Sie kann nicht zuverlässig wissen:

welche WCS-Felder die konkrete Integration erzeugt,
ob eine Parent-Regel ausschließlich der Gruppierung dient,
welche betrieblichen Ausnahmen notwendig sind,
ob eine Regex noch dieselbe semantische Bedeutung besitzt,
ob mehrere XML-Regeln eigentlich eine Korrelation darstellen,
wie sich eine Regel auf Datenvolumen und Finding-Anzahl auswirkt.

Jeder erzeugte Entwurf muss deshalb gegen reale Ereignisse validiert werden.

Detection-as-Code etablieren

Obwohl die Regeln in Wazuh 5.x über das Content-Management-System verwaltet werden, sollten die YAML-Quellen zusätzlich versioniert werden.

Empfohlene Repository-Struktur:

detections/
├── sysmon/
│   ├── process-create/
│   ├── network-connect/
│   ├── registry/
│   └── process-access/
├── tests/
│   ├── positive/
│   └── negative/
├── mappings/
│   └── wazuh4-to-wcs.csv
└── documentation/
    └── migration-register.md

Jede Regel sollte mindestens enthalten:

Fachliche Beschreibung
Datenquelle und Sysmon Event ID
WCS-Felder
MITRE-ATT&CK-Zuordnung
Bekannte False Positives
Testereignisse
Änderungshistorie
Verantwortliches Team
Ursprüngliche Wazuh-4.x-Regel-ID

Regeln nach Risiko priorisieren

Nicht jedes historische Regelwerk muss vollständig migriert werden. Sinnvoll ist eine Priorisierung nach:

kritischen Angriffstechniken,
aktiven Incident-Response-Playbooks,
regulatorisch relevanten Erkennungen,
häufig ausgelösten und gut abgestimmten Regeln,
Regeln mit vorhandenen Testdaten,
experimentellen oder kaum genutzten Regeln.

Veraltete, redundante oder dauerhaft deaktivierte Regeln sollten nicht ungeprüft übernommen werden.

Korrelationen früh identifizieren

Regeln mit frequency, timeframe, if_matched_sid oder same_* sollten bereits während der Inventarisierung markiert werden. Sie sind in der Regel die aufwendigsten Bestandteile der Migration und benötigen ein separates Korrelationsdesign.

Wer diese Abhängigkeiten erst beim YAML-Umbau entdeckt, unterschätzt den Projektumfang und riskiert eine unbemerkte Verschlechterung der Detection Coverage.

Parallelbetrieb mit messbaren Abnahmekriterien

Der Erfolg der Migration sollte nicht anhand der Anzahl konvertierter Regeln gemessen werden. Relevanter sind:

Abdeckung definierter Angriffsszenarien
Anzahl korrekt erkannter Testereignisse
False-Positive-Rate
Finding-Volumen
Zeit bis zur Erkennung
Vollständigkeit der Kontextfelder
MITRE-ATT&CK-Abdeckung
Auswirkung auf Indexer und Detector-Laufzeiten

Für wichtige Use Cases sollten identische Angriffssimulationen gegen Wazuh 4.x und Wazuh 5.x ausgeführt und die Ergebnisse miteinander verglichen werden.

Beta-Version nicht wie eine stabile Produktionsversion behandeln

Da Wazuh 5.0 derzeit noch als Vorabversion veröffentlicht wird, können sich Feldnamen, APIs, Benutzeroberflächen und Content-Management-Abläufe bis zur stabilen Version verändern. Migrationsskripte und Regelvorlagen sollten deshalb versioniert und nicht ausschließlich auf manuelle Dashboard-Schritte ausgerichtet werden.

Fazit

Bestehende Sysmon-Regeln aus Wazuh 4.x können nicht direkt als XML-Dateien in Wazuh 5.0 importiert werden. Die Regeln müssen als Sigma-basierte YAML-Detections neu erstellt und an die Architektur von Wazuh 5.x angepasst werden.

Der wichtigste Migrationsschritt ist nicht die Änderung des Dateiformats, sondern die fachliche Übertragung der Detection:

Alte Decoder-Felder → Wazuh Common Schema
Regelketten → eigenständige Detection-Logik
Numerische Level → semantische Severity
XML-Gruppen → Tags, MITRE und Compliance
CDB-Lookups → KVDB-basierte Normalisierung
Zeitbasierte Regeln → separate Korrelation
Dateibasierte Regeln → Draft-, Test- und Custom-Workflow
Alerts → Events und Findings

Eine belastbare Migration benötigt deshalb ein vollständiges Inventar, repräsentative Sysmon-Testdaten, eine parallele Wazuh-5-Umgebung und einen kontrollierten Detection-as-Code-Prozess. Werden XML-Regeln lediglich syntaktisch in YAML übertragen, besteht das Risiko, dass formal gültige Regeln fachlich unvollständig sind oder relevante Angriffe nicht mehr erkennen.