Wazuh gilt vielen als reine IT-Lösung: Agenten für Windows, Linux und macOS. Aber lässt sich damit auch die Produktionsumgebung überwachen? Die Antwort ist ja, allerdings nicht über den klassischen Wazuh-Agenten, sondern in Kombination mit einer spezialisierten OT-Appliance wie Rhebo oder Nozomi Networks. Wie sich beide Welten technisch sauber verbinden lassen, zeigt dieser Beitrag: von der Architektur über die Integrationsvarianten bis zur eigentlichen IT/OT-Korrelation im SOC.
Warum ein IT-SIEM allein für OT nicht reicht
Wazuh-Agenten lassen sich auf Windows-, Linux- und macOS-Systemen problemlos installieren. Auf einer SPS, einem Feldgerät oder einer proprietären SCADA-Steuerung geht das in aller Regel nicht: Die Systeme sind für Fremdsoftware nicht ausgelegt, oft sicherheitszertifiziert, und jede Änderung stellt ein Risiko dar. Für die Überwachung des OT-Netzwerks braucht es deshalb eine spezialisierte Lösung, die den industriellen Netzwerkverkehr passiv mitliest und Protokolle wie Modbus, Profinet oder OPC UA versteht, etwa eine OT-NDR-Appliance von Anbietern wie Rhebo oder Nozomi Networks.
Der eigentliche Mehrwert entsteht aber nicht dadurch, dass diese Appliance isoliert vor sich hin alarmiert, sondern dadurch, dass ihre Meldungen mit dem verknüpft werden, was ohnehin schon im IT-SIEM läuft: Endpoint-Events, Benutzeraktivität, Netzwerkflüsse, Asset-Informationen. Genau diese Korrelationsebene übernimmt Wazuh.
Architektur: OT-Appliance und Wazuh im Zusammenspiel
Dahinter steckt ein einfaches Grundprinzip: Die OT-Appliance bleibt zuständig für Asset Discovery, Anomalieerkennung und Threat Intelligence im industriellen Netz. Wazuh sammelt diese bereits qualifizierten OT-Security-Events zusammen mit den vorhandenen IT-Daten, normalisiert sie, verarbeitet sie über Regeln und stellt sie im Dashboard dar.
Drei Wege der Integration
Für die Anbindung der OT-Appliance an Wazuh gibt es im Wesentlichen drei Varianten mit unterschiedlichem Aufwand und Reifegrad.
Am schnellsten kommt man mit der direkten Übertragung von Syslog- oder CEF-Events an den Wazuh-Manager zum ersten Ergebnis. Nozomi Networks dokumentiert diesen Weg als Standard-Integration, Rhebo Industrial Protector meldet Sicherheitsereignisse ebenfalls im CEF-Format an gängige SIEM-Systeme. Wazuh nimmt die Events über einen konfigurierten Remote-Listener entgegen. Für einen Proof-of-Concept reicht das meist aus.
Für den produktiven Betrieb empfiehlt sich ein zentraler Syslog-Relay als Zwischenschritt, etwa mit rsyslog oder syslog-ng. Er entkoppelt OT-Appliance und Wazuh-Manager, puffert Events bei Ausfällen, ermöglicht Filterung sowie Transportabsicherung per TLS und lässt sich besser skalieren, wenn weitere OT-Standorte hinzukommen.
Bevorzugt eine Appliance den Export über REST-API oder JSON, bietet sich als dritte Variante die API- oder Webhook-basierte Integration an. Sie ist flexibler, erfordert aber eine eigene kleine Integrationskomponente und damit mehr Aufwand als der Syslog/CEF-Weg.
Vom Rohereignis zum verwertbaren Alert
Ein Event kommt aber nicht automatisch als brauchbarer Alert im Dashboard an. Dafür müssen Decoder zunächst die relevanten Felder aus dem Rohereignis extrahieren: Vendor, Product, Event Type, Severity, Quell- und Ziel-IP, betroffenes Asset, OT-Zone und Beschreibung. Normalisiert sieht ein solches Event dann etwa so aus:
{
"vendor":"Nozomi Networks",
"product":"N2OS",
"event_type":"Suspicious OT Activity",
"severity":8,
"srcip":"10.10.20.15",
"dstip":"10.10.20.30",
"asset":"PLC-01",
"ot_zone":"Production"
}Auf dieser Struktur bauen die eigentlichen Wazuh-Regeln auf, etwa für kritische OT-Alerts, ungewöhnliche Engineering-Aktivitäten, unerwartete PLC-Schreibzugriffe oder bislang unbekannte Kommunikationsbeziehungen im Netz. Fehlt der passende Decoder, bleibt selbst das beste OT-Event ein unstrukturierter Log-Eintrag: im Dashboard sichtbar, aber ohne Regel, die ihn auslöst.
Der eigentliche Mehrwert: IT/OT-Korrelation
Für sich genommen wirkt ein einzelnes OT-Ereignis oft harmlos. Erst im Zusammenspiel mit IT-Daten entsteht ein belastbares Bild. Ein typischer Ablauf: Wazuh erkennt eine verdächtige PowerShell-Aktivität auf einer Engineering-Workstation. Kurz darauf meldet die OT-Appliance eine ungewöhnliche Kommunikation genau dieser Workstation mit einer SPS und registriert anschließend einen unerwarteten Schreibzugriff auf die Steuerung. Erst wenn Wazuh diese drei Ereignisse korreliert, wird daraus ein priorisierter IT/OT-Incident mit einem plausiblen Angriffspfad vom kompromittierten IT-System bis in die Produktion. Einzeln betrachtet wären alle drei Meldungen im SOC vermutlich unauffällig geblieben.
Wichtig dabei: Die Priorisierung sollte die Kritikalität des betroffenen Assets berücksichtigen. Ein Alert auf einer Testumgebung ist etwas anderes als derselbe Alert auf der SPS einer laufenden Fertigungslinie, auch wenn beide technisch identisch bewertet werden. Asset-, Zonen- und Kritikalitätsinformationen aus der OT-Appliance gehören deshalb mit ins Event.
Was gehört ins SIEM und was nicht
Nicht jedes Rohdatenpaket aus dem OT-Netz muss im SIEM landen. Sinnvoll sind Security-Alerts und Anomalien, Policy-Verstöße und ungewöhnliche Kommunikation, neu erkannte oder unbekannte Assets sowie verdächtige Zugriffe jeweils mit Kontextfeldern wie Timestamp, Quelle, Ziel, Protokoll und Severity. Das Ziel ist ein qualitativ hochwertiger Security-Event-Stream, nicht die vollständige Kopie des OT-Netzwerkverkehrs im Indexer. Das würde Speicher und Regel-Engine unnötig belasten, ohne die Erkennungsqualität zu verbessern.
Der Einstieg in der Praxis
Bevor der erste PoC startet, lohnt sich eine kurze technische Bestandsaufnahme: Welche OT-Appliance und welche Version sind im Einsatz, und welche Exportformate stehen zur Verfügung? Syslog, CEF, JSON, API? Welche Severity-Stufen und Event-Typen liefert sie, und welche Asset- und Kontextfelder liegen dabei vor? Wie ist die OT-Zone vom IT-Netz segmentiert, und soll der Transport über TCP, UDP oder TLS-verschlüsselt laufen? Ist ein Syslog-Relay von Anfang an sinnvoll, oder reicht für den PoC die direkte Anbindung? Und: Welche IT-Events sollen für die Korrelation zur Verfügung stehen, und welche Eskalations- und Reporting-Anforderungen hat der SOC-Prozess dahinter?
Diese Fragen vorab zu klären spart in der Umsetzung deutlich mehr Zeit, als es kostet. Ohne sie endet die Integration erfahrungsgemäß in derselben Falle wie bei vielen anderen Log-Quellen: Die Daten kommen an, aber ohne passenden Decoder erzeugen sie keine verwertbaren Alarme.
Fazit
OT-Appliances und Wazuh ergänzen sich gut: Die Appliance liefert spezialisierte Sichtbarkeit und Detection im industriellen Netz, Wazuh schafft die zentrale Ebene für Sammlung, Regelverarbeitung, Korrelation und SOC-Auswertung gemeinsam mit den IT-Daten. Für den Einstieg ist Syslog/CEF meist der pragmatischste Weg. Entscheidend für den langfristigen Erfolg sind danach die Qualität der Decoder, Regeln, Asset-Anreicherung und IT/OT-Korrelation. Erst damit wird aus einem isolierten OT-Alert ein kontextreicher, priorisierter Security-Incident statt nur einer weiteren Meldung im Rauschen.
OT-Security-Monitoring mit Wazuh
Sie betreiben bereits eine Wazuh-Umgebung und möchten wissen, wie sich Ihre Produktionsumgebung sauber anbinden lässt? Wir unterstützen Sie bei Ihrer Wazuh-Implementierung und beraten Sie zu den technischen Voraussetzungen für die IT/OT-Integration.
