Wazuh 5.0 baut die Open-Source-SIEM- und XDR-Plattform grundlegend um. Mit dem ersten Release Candidate (RC1) stehen eine neue Detection Engine, das Wazuh Common Schema (WCS), Sigma-Unterstützung und automatisch aktualisierte Threat Intelligence zur Verfügung. Auch die Architektur und die Verwaltung von Detection-Inhalten werden modernisiert.
Für Bestandskunden besonders wichtig: Ein In-Place-Upgrade von 4.x auf 5.x gibt es nicht. Die Umstellung erfordert eine Migration in eine neu aufgebaute Umgebung.
Dieser Beitrag zeigt die wichtigsten Neuerungen, erklärt die technischen Unterschiede zu Wazuh 4.x und beleuchtet, was Administratoren und Security-Teams bei der Migration beachten müssen.
Hinweis: Wazuh 5.0 RC1 ist eine Vorabversion für Tests und Evaluierungen. Einzelne Funktionen können sich bis zur finalen Veröffentlichung noch ändern.
1. Die wichtigsten Neuerungen im Überblick
| Bereich | Neuerung in Wazuh 5.0 | Praktischer Nutzen |
| Detection Engine | Neue Engine und neues Ruleset auf Basis des Wazuh Common Schema (WCS) | Einheitliche Event-Verarbeitung und wiederverwendbare Detection Rules |
| Sigma Rules | Sigma-Unterstützung und neue Syntax für Rules und Decoder | Bestehende Detection Use Cases einfacher übernehmen |
| Wazuh CTI | Automatische Updates für Rules und Decoder sowie IoCs, Vulnerability Intelligence und Geo-IP-Kontext | Aktuelle Detection-Inhalte und zusätzliche Bedrohungsinformationen |
| Content Manager | Zentrale Verwaltung von Rules, Decodern, Integrations und KVDBs | Detection-Inhalte entwickeln, testen und kontrolliert bereitstellen |
| AI Assistant* | KI-Assistent im Dashboard | Sicherheitsinformationen in natürlicher Sprache untersuchen |
| Incident Investigations* | Integrierte Sicherheitsuntersuchungen | Security Incidents direkt in Wazuh nachverfolgen |
| Architektur | Filebeat entfällt, HTTPS als Standard | Vereinfachte Datenpipeline und modernisierte Agent-Kommunikation |
| Compliance* | Erweiterte Zuordnungen, unter anderem ISO 27001 und NIS2 | Unterstützung bei regulatorischen Nachweispflichten |
| Migration | Kein In-Place-Upgrade, eingeschränkte Unterstützung älterer Agents | Geplante Migration statt klassischem Versionsupgrade |
Die mit einem Stern gekennzeichneten Neuerungen werden in der RC1-Release-Ankündigung beschrieben, sind in der verfügbaren RC-Dokumentation jedoch noch nicht vollständig technisch dokumentiert.
2. Neue Detection Engine: Wazuh Common Schema und Sigma Rules
Mit dem Wazuh Common Schema (WCS) führt Wazuh eine standardisierte Struktur für Security Events ein. Bisher liefern unterschiedliche Logquellen häufig unterschiedlich aufgebaute Ereignisse. Windows, Linux und Firewalls verwenden beispielsweise unterschiedliche Feldbezeichnungen für Quell-IP-Adressen, Benutzernamen oder Aktionen. WCS normalisiert diese Informationen und stellt sie in einer einheitlichen Feldstruktur bereit.
Das bietet drei wesentliche Vorteile:
- Einfachere Detection Rules: Regeln können auf standardisierte Felder zugreifen, unabhängig vom ursprünglichen Logformat.
- Bessere Korrelation: Ereignisse verschiedener Systeme lassen sich anhand gemeinsamer Informationen leichter miteinander verknüpfen.
- Konsistentere Analysen: Security-Analysten arbeiten mit einheitlicheren Event-Strukturen.
Technisch interessant ist die neue Aufgabenverteilung: Der Wazuh Manager normalisiert die eingehenden Events, während der Wazuh Indexer die Sigma-basierte Detection ausführt.
Sigma-Unterstützung und neue Rule-Syntax
Mit dem Wazuh Common Schema (WCS) führt Wazuh eine standardisierte Struktur für Security Events ein. Bisher liefern unterschiedliche Logquellen häufig unterschiedlich aufgebaute Ereignisse. Windows, Linux und Firewalls verwenden beispielsweise unterschiedliche Feldbezeichnungen für Quell-IP-Adressen, Benutzernamen oder Aktionen. WCS normalisiert diese Informationen und stellt sie in einer einheitlichen Feldstruktur bereit.
Das bietet drei wesentliche Vorteile:
- Einfachere Detection Rules: Regeln können auf standardisierte Felder zugreifen, unabhängig vom ursprünglichen Logformat.
- Bessere Korrelation: Ereignisse verschiedener Systeme lassen sich anhand gemeinsamer Informationen leichter miteinander verknüpfen.
- Konsistentere Analysen: Security-Analysten arbeiten mit einheitlicheren Event-Strukturen.
Technisch interessant ist die neue Aufgabenverteilung: Der Wazuh Manager normalisiert die eingehenden Events, während der Wazuh Indexer die Sigma-basierte Detection ausführt.
3. Wazuh CTI: Automatische Updates für Detection und Threat Intelligence
Eine weitere wichtige Neuerung ist die erweiterte Integration von Wazuh Cyber Threat Intelligence (CTI).
Während Wazuh CTI in Version 4.x insbesondere Informationen für die Vulnerability Detection bereitstellte, kommen in 5.0 Rules, Decoder, IoCs und Geo-IP-Kontext hinzu.
- Detection Rules und Decoder: Neue und aktualisierte Erkennungs- und Verarbeitungsregeln
- Indicators of Compromise (IoCs): Informationen über bekannte Bedrohungsindikatoren
- Vulnerability Intelligence: Informationen zu bekannten Schwachstellen
- Geo-IP-Kontext: Geografische Informationen zur Einordnung von IP-Adressen
Wie funktioniert die Synchronisierung?
Der neue Content Manager synchronisiert die Inhalte regelmäßig mit Wazuh CTI. Bei der ersten Synchronisierung wird zunächst ein vollständiger Datenbestand geladen. Anschließend werden nur noch Änderungen übertragen. Die Synchronisierung erfolgt getrennt für Detection Content, Indicators of Compromise und Vulnerability Intelligence. Bei Bedarf kann sie auch manuell ausgelöst werden. Damit lassen sich Detection-Inhalte und Bedrohungsinformationen automatisch aktualisieren, ohne dass Administratoren jede neue Rule oder jeden Decoder selbst recherchieren und einspielen müssen. Für den SOC-Betrieb ist das besonders relevant: Aktuelle Detection Rules und Threat-Intelligence-Daten sind eine wichtige Grundlage, um neue Angriffsmuster zu erkennen.
4. Content Manager: Detection-Inhalte entwickeln, testen und verwalten
Mit Wazuh 5.0 erhält die Plattform einen zentralen Content Manager zur Verwaltung von Rules, Decodern, Integrations, Key-Value-Datenbanken (KVDBs) und Indicators of Compromise.
Besonders interessant ist der neue Entwicklungsworkflow: Draft → Test → Promotion
Detection-Inhalte können zunächst als Entwurf erstellt, getestet und anschließend für den produktiven Einsatz freigegeben werden. Das erleichtert die kontrollierte Entwicklung eigener Detection Use Cases und reduziert das Risiko, ungeprüfte Änderungen direkt produktiv einzusetzen.
Integrations und KVDBs
Der Begriff Integration erhält in Wazuh 5.0 eine neue Bedeutung. Eine Integration bezeichnet die logische Zusammenfassung von Decodern, Rules und KVDBs für eine bestimmte Datenquelle oder ein Produkt, beispielsweise eine Firewall oder einen Webserver. Jeder Decoder gehört dabei zu genau einer Integration. Das unterscheidet sich von klassischen Wazuh-4.x-Integrationen, etwa der Anbindung externer Dienste wie VirusTotal.
Auch bei den Referenzdaten ändert sich das Konzept: Die bisherigen CDB Lists werden durch Key-Value-Datenbanken (KVDBs) abgelöst. Darüber können Rules und Decoder beispielsweise auf bekannte IP-Adressen, Hostnamen oder andere Referenzinformationen zugreifen.
5. AI Assistant und Incident Investigations
Für die tägliche Arbeit im Security Operations Center kündigt Wazuh zwei weitere Funktionen an.
AI Assistant: Der KI-Assistent soll es ermöglichen, Sicherheitsinformationen direkt im Dashboard über natürliche Sprache abzufragen. Security-Analysten können damit beispielsweise Schwachstellen, Security Findings oder Aktivitäten einzelner Agents untersuchen.
Incident Investigations: Sicherheitsuntersuchungen sollen sich direkt im Wazuh Dashboard erstellen und nachverfolgen lassen. Für umfangreiche Incident-Response-Prozesse können spezialisierte Case-Management- und SOAR-Lösungen weiterhin eine sinnvolle Ergänzung sein.
6. Vereinfachte Architektur: Was ändert sich technisch?
Wazuh 5.0 modernisiert wesentliche Bestandteile der technischen Architektur.
Eine der auffälligsten Änderungen: Filebeat entfällt aus der Datenpipeline. Gleichzeitig wird HTTPS zum Standardprotokoll für die Agent-Kommunikation.
Wazuh 4.x vs. Wazuh 5.0
|
Bereich |
Wazuh 4.x |
Wazuh 5.0 |
|
Detection Engine |
Klassische Wazuh Engine |
Neue Detection Engine |
|
Datenmodell |
Unterschiedliche Event-Strukturen |
Wazuh Common Schema |
|
Rules und Decoder |
XML-basierte Konfiguration |
Neue Syntax, Sigma-Unterstützung für Rules |
|
Referenzdaten |
CDB Lists |
KVDBs |
|
Detection Content |
Überwiegend manuelle Verwaltung |
Content Manager und CTI-Synchronisierung |
|
Datenpipeline |
Manager → Filebeat → Indexer |
Manager → Indexer |
|
Agent-Kommunikation |
Bisherige Kommunikationsprotokolle |
HTTPS als Standard |
|
Benachrichtigungen |
E-Mail unter anderem über wazuh-maild |
Notifications- und Alerting-Modul im Indexer |
|
Active Response |
Konfiguration im Manager |
Konfiguration im Dashboard |
Änderungen bei Diensten und Benachrichtigungen
Durch den Wegfall von Filebeat wird eine zusätzliche Komponente aus der Datenpipeline entfernt. Das kann Konfigurations- und Wartungsaufwand reduzieren und die Fehlersuche vereinfachen.
Auch die internen Manager-Dienste wurden überarbeitet. Die bisherigen Daemons wazuh-integratord, wazuh-maild, wazuh-agentlessd und wazuh-csyslogd sind in der neuen Manager-Referenz nicht mehr aufgeführt. Für Benachrichtigungen stehen die Module Notifications und Alerting im Wazuh Indexer zur Verfügung.
Das Notifications-Modul unterstützt unter anderem Slack, Microsoft Teams, Amazon Chime, Amazon SNS, E-Mail über SMTP oder AWS SES sowie eigene Webhooks. Für Slack, Jira, PagerDuty und Shuffle SOAR sind außerdem vorkonfigurierte, zunächst deaktivierte Kanäle vorgesehen.
Das Alerting-Modul wertet definierte Bedingungen zeitgesteuert aus und löst entsprechende Aktionen aus.
Änderungen bei der Konfiguration
Auch die Konfiguration wird deutlicher zwischen Manager, Agent und Dashboard aufgeteilt. Die neue wazuh-manager.conf konzentriert sich auf zentrale Funktionen wie Kommunikation, Authentifizierung, Indexer-Anbindung, Vulnerability Detection und Cluster-Verwaltung.
FIM, SCA, System Inventory und Log Collection werden über die Agent-Konfiguration (ossec.conf) gesteuert.
Active Response wird dagegen im Dashboard unter Explore → Active Responses konfiguriert. Aktionen und Trigger lassen sich dort ohne Neustart des Managers verwalten.
Technisch kann das Alerting-Modul entsprechende Ausführungsanfragen in den Data Stream wazuh-active-responses schreiben. Der Manager verarbeitet diese Anfragen und verteilt die Aktionen an die Agents, auf denen die Skripte ausgeführt werden.
Eine zentrale Verteilung von Agent-Konfigurationen bleibt weiterhin möglich.
7. Erweiterte Compliance-Unterstützung: ISO 27001 und NIS2
Wazuh 5.0 erweitert außerdem die Zuordnung von Security Events zu regulatorischen Anforderungen und Compliance-Frameworks, darunter ISO 27001, NIS2, CMMC und FedRAMP. Für europäische Unternehmen sind insbesondere ISO 27001 und NIS2 relevant.
Funktionen wie FIM, SCA, Vulnerability Detection und zentrale Log-Analysen können dabei helfen, technische Sicherheitsmaßnahmen zu überwachen und entsprechende Nachweise bereitzustellen.
Die konkrete Abdeckung einzelner Anforderungen muss anhand der finalen Version bewertet werden. Wazuh unterstützt die technische Umsetzung und Nachweisführung, ersetzt jedoch keine vollständige Compliance-Prüfung oder Zertifizierung.
8. Bestehende Installationen: Migration statt Upgrade
Für Betreiber bestehender Wazuh-Umgebungen ist eine Besonderheit entscheidend:
Ein direktes In-Place-Upgrade von Wazuh 4.x auf 5.x ist nicht vorgesehen.
Stattdessen wird eine neue Wazuh-5.x-Umgebung aufgebaut. Die bisherige Installation bleibt parallel in Betrieb, bis die Migration abgeschlossen und erfolgreich validiert wurde.
Was muss bei der Migration beachtet werden?
|
Bereich |
Vorgehen |
|
Historische Indexdaten |
Übernahme per Snapshot ab Wazuh 4.4.0 über ein gemeinsames Snapshot-Repository. Die Indizes behalten ihre 4.x-Mappings und dienen ausschließlich dem Zugriff auf historische Daten. |
|
Konfigurationsdateien |
Können nicht direkt übernommen werden. Unterstützte Einstellungen müssen neu eingerichtet werden. |
|
Eigene Rules und Decoder (XML) |
Individuelle XML-Rules und -Decoder müssen im neuen Content Management neu erstellt werden. |
|
CDB Lists |
Bestehende Referenzdaten in das KVDB-Konzept überführen. |
|
Active Response |
Konfiguration und Trigger im Dashboard neu anlegen, eigene Skripte auf die neue Nachrichtenstruktur mit WCS-Feldern prüfen. |
|
Externe Schnittstellen |
Bestehende Anbindungen und Benachrichtigungswege auf Kompatibilität mit der neuen Architektur prüfen. |
|
Benutzer und Rollen |
Security-Konfiguration und Berechtigungen neu einrichten. |
|
Dashboards |
Exportieren und importieren, anschließend verwendete Felder und Abfragen auf WCS-Kompatibilität prüfen. |
|
Agent-Registrierungen |
Bestehende Registrierungen mit IDs und Authentifizierungsschlüsseln migrieren, Agent-Gruppen wiederherstellen. |
Historische 4.x-Indizes werden dabei nicht automatisch in das neue Wazuh Common Schema umgewandelt. Neue Wazuh-5.x-Events werden in separaten Indizes mit dem neuen Datenmodell gespeichert.
Kompatibilität bestehender Wazuh Agents
Wazuh-4.x-Agents können weiterhin mit einem Wazuh-5.x-Manager kommunizieren. Allerdings werden FIM, SCA, System Inventory, Active Response und Vulnerability Detection mit älteren Agents nicht vollständig unterstützt. Für den vollständigen Funktionsumfang empfiehlt Wazuh deshalb ein schrittweises Upgrade auf Agents der Version 5.x.
Empfehlung für bestehende Umgebungen
Unternehmen sollten zunächst eine separate Testumgebung mit Wazuh 5.0 RC1 aufbauen und dort insbesondere eigene Detection Rules, Decoder, Active-Response-Konfigurationen und externe Schnittstellen evaluieren.
Fazit
Wazuh 5.0 verändert grundlegend, wie Security Events verarbeitet und Detection-Inhalte entwickelt und verwaltet werden. Das Wazuh Common Schema, die neue Detection Engine mit Sigma-Unterstützung und die automatische CTI-Synchronisierung bilden dabei die wichtigsten technischen Neuerungen. Der Content Manager ermöglicht zusätzlich eine kontrollierte Entwicklung und Bereitstellung eigener Detection-Inhalte. Auch die Architektur wird vereinfacht: Filebeat entfällt, die Agent-Kommunikation wird modernisiert und zentrale Funktionen werden neu organisiert.
Für bestehende Installationen bedeutet der Versionswechsel allerdings eine geplante Migration statt eines klassischen Upgrades. Insbesondere individuelle Rules, Decoder, Active Response und externe Schnittstellen sollten deshalb frühzeitig geprüft werden.
Wazuh 5.0 mit becon kennenlernen
Als Wazuh Gold Partner unterstützt becon Unternehmen bei der Planung, Implementierung, Integration und dem Betrieb von Wazuh-basierten SIEM- und XDR-Lösungen.
Unsere Wazuh-Experten unterstützen Sie bei der technischen Bewertung, der Einführung neuer Funktionen und der Planung einer möglichen Migration.
becon Blog
Weitere Artikel zu diesem Thema
Kontakt
Kontaktieren Sie uns!
Wir freuen uns von Ihnen zu hören.
Sie haben Fragen oder stehen vor einer besonderen Herausforderung? Unser engagiertes Team steht Ihnen für eine unverbindliche Beratung gerne zur Verfügung.