Detection-Engineering ohne Vendor-Lock: Wazuh-Stack 2026

8 Min. Lesezeit

Die SIEM-Verträge der grossen Anbieter werden in den nächsten zwei Jahren in vielen DACH-Security-Teams neu verhandelt. Wer den Renewal-Termin als Anlass nimmt, schaut sich nicht nur nach einem günstigeren Vendor um, sondern auch nach einer Architektur, die ohne Vendor-Lock auskommt. Wazuh, Sigma und Shuffle sind kein Marketing-Stack, sondern eine ernsthafte Option, sofern das Team die Trade-offs ehrlich auf den Tisch legt.

VerwandtNIS2-Audit: Vendor-Liste zerbricht in 2h  /  Adaptive MFA: NIS2-Druck als Hebel

Warum Vendor-Lock im SIEM-Markt zum Operations-Risiko wird

SIEM-Renewals in DACH-Mittelständlern und Konzernen haben in den letzten 18 Monaten ein Muster. Die Lizenzkosten steigen zweistellig, die EPS-Limits werden enger, das Logging-Volumen wächst durch Cloud-Workloads schneller als das Budget. Wer 2018 einen Vertrag unterschrieben hat, zahlt 2026 oft das Doppelte für nominell dieselbe Architektur.

Vendor-Lock ist dabei nicht nur eine Kostenfrage. Wer einmal in einer proprietären Query-Sprache 2.000 Detection-Regeln gepflegt hat, kann nicht ohne Reibung wechseln. Genau das macht Detection-Engineering zur Disziplin, die im Operating-Modell verankert sein muss, und nicht in einem Vendor-Vertrag. Wer das verschiebt, zahlt im Renewal das Versäumnis von drei Jahren.

Hybrid Cloud ist kein Architektur-Muster, sondern die Konsequenz, wenn zwei Teams nicht rechtzeitig miteinander gesprochen haben. Vendor-Lock im SIEM ist die Konsequenz, wenn niemand die Detection-Regeln als eigenständigen Asset behandelt.

Der Stack im Überblick: Wazuh, Sigma, Shuffle, DFIR-IRIS

Der hier diskutierte Open-Source-Stack besteht aus vier Komponenten, die unterschiedliche Funktionen abdecken. Sie sind aufeinander abstimmbar, aber sie sind keine integrierte Plattform im Sinne eines kommerziellen SIEMs. Genau das ist die Stärke und gleichzeitig die Hürde.

Wazuh bildet die Detection-Plattform. Es kombiniert HIDS-Funktionalität, Log-Analyse und Compliance-Reporting auf Elasticsearch-Basis und liefert eine Web-UI für Alert-Triage. Sigma ist der Detection-Rule-Standard, der Plattform-unabhängig formuliert ist und in Wazuh-Regeln, Elastic-Detection-Rules oder Splunk-Queries übersetzt werden kann. Shuffle ist die SOAR-Komponente, die Workflows zwischen Detection, Anreicherung und Response orchestriert. DFIR-IRIS ist das Case-Management-Tool für Incident-Response-Workflows.

Wer das Wort „agentic-AI-fähig“ hört, sollte vorsichtig sein. Die Komponenten haben Integrationspunkte für LLM-basierte Anreicherung, das macht den Stack aber noch nicht zu einer autonomen Security-Plattform. Wer KI-Agenten in Shuffle-Workflows einsetzt, übernimmt damit auch die Halluzinations-Verantwortung, die jeder Agent mitbringt. Wer KMS-Keys als Dropdown behandelt, hat entweder noch kein Audit erlebt oder kein gutes. Dasselbe gilt für AI-Agenten in der Detection-Pipeline.

Vor- und Nachteile in der ehrlichen Tabelle

Der ehrliche Vergleich zwischen kommerziellem SIEM und einem Wazuh-zentrierten Open-Source-Stack hat klare Trade-offs, die in den meisten Marketing-Decks fehlen. Wer die Tabelle vor dem Renewal-Termin auf den Tisch legt, gewinnt zumindest die Diskussionsgrundlage.

Die Tabelle hat eine wichtige Konsequenz. Open-Source-Stacks lohnen sich nicht primär finanziell, sondern strategisch. Wer Vendor-Lock als grösseres Risiko einschätzt als FTE-Bindung, hat eine Antwort. Wer Vendor-Support höher gewichtet als Portabilität, hat eine andere Antwort. Beide sind legitim, beide haben ihre Konsequenz.

Drei Zahlen, die der CISO im Steering vorbringen sollte

Im Steering-Committee scheitert die Open-Source-Diskussion oft an einer einzigen Zahl, die niemand sauber kalkuliert hat. Drei nüchterne Werte helfen, die Realität klarer zu zeichnen.

Die Zahlen sind keine Studie, sie sind Erfahrungswerte aus produktiven Migrationen. Wer sie im eigenen Setup nicht messen kann, hat keinen belastbaren Vorschlag für das Steering. Das ist die unangenehme Wahrheit. Der Unterschied zwischen „security by design“ und „security by incident“ ist ungefähr eine Woche Schlaf. Der Unterschied zwischen „wir denken über Open-Source nach“ und „wir migrieren in 12 Monaten“ sind drei belastbare Zahlen.

Was Sigma als Regel-Standard verändert

Die wichtigste konzeptionelle Verschiebung ist nicht Wazuh, sondern Sigma. Detection-Regeln werden zu einem portablen Asset, nicht zu einem Vendor-Artefakt. Ein Team, das Sigma-First arbeitet, kann seine Detection-Logik in Wazuh, Elastic, Splunk oder Sentinel laufen lassen, ohne 80 Prozent der Arbeit wiederholen zu müssen.

Praktisch bedeutet das eine Pflege-Disziplin. Detection-Regeln werden in Sigma-YAML versioniert, in Git verwaltet, mit CI-Pipelines gegen Test-Logs validiert, und erst danach in die jeweilige Plattform-Sprache übersetzt. Diese Pipeline gibt es bei klassischen SIEM-Stacks selten, weil sie nicht nötig erscheint. Sie wird nötig, sobald der Vendor wechselt.

„Wir haben das Playbook zweimal umgeschrieben, weil der erste Wurf bei 03:40 Uhr klingt wie etwas, das eine Marketingabteilung erfunden hat. Sigma-Regeln versuchen wir nur noch einmal zu schreiben.“

Senior Detection Engineer, DACH-Industriekonzern, 2026

Wann sich der Stack lohnt, wann nicht

Der Stack lohnt sich aus der Praxis betrachtet in drei Konstellationen. Erstens: bei Security-Teams ab drei Senior-Engineers, die Detection als Disziplin praktizieren wollen und nicht nur als Tooling-Frage betrachten. Zweitens: bei Mittelständlern, die Cloud-heavy-Logging haben und unter SIEM-EPS-Caps ersticken. Drittens: bei Konzernen, die Lieferanten-Diversifikation als strategisches Ziel ausgegeben haben und nicht für jede Tool-Kategorie auf einen Vendor angewiesen sein wollen.

Er lohnt sich nicht, wenn das Team unter zwei Senior-Engineers liegt, wenn die Audit-Anforderungen einen schlüsselfertigen Compliance-Report verlangen, der mit vier Klicks erzeugbar sein muss, oder wenn das Operating-Modell Detection als reine Vendor-Lieferung versteht. Wer das vergisst, baut sich eine zweite Vollzeit-Aufgabe, die im Steering nicht beauftragt war.

Häufige Fragen

Reicht Wazuh als alleiniges SIEM für NIS2-Pflichtige?

Technisch ja, mit der nötigen Eigenleistung. Wazuh erfüllt die meisten Detection-, Logging- und Compliance-Anforderungen. Die NIS2-Konformität entsteht aber nicht durch das Tool, sondern durch den dokumentierten Prozess: Audit-Trail, Reporting-Kadenz, Incident-Eskalation. Wer das ohnehin schon hat, gewinnt Geld. Wer es noch nicht hat, sollte den Vendor-Wechsel nicht mit dem Prozess-Aufbau verbinden.

Wie aufwändig ist die Sigma-Regel-Pflege im Vergleich zu kommerziellem SIEM?

Initial deutlich aufwändiger, weil die CI-Pipeline und das Test-Logging aufgebaut werden müssen. Nach 6–9 Monaten ist der laufende Pflegeaufwand vergleichbar, weil die Test-Coverage Regressionen früher fängt als der Vendor-Update-Zyklus.

Was kostet ein realistischer Wazuh-Stack im Betrieb?

Bei mittleren Setups (5.000 EPS, 50 Sensoren) liegen die Infrastrukturkosten bei 30–60.000 Euro pro Jahr, plus 3 FTE Detection-Engineering. Vergleichbares kommerzielles SIEM liegt oft im niedrigen sechsstelligen Lizenzbereich, plus 1–2 FTE. Die Rechnung kippt zugunsten des Open-Source-Stacks, sobald das EPS-Volumen oder die Audit-Tiefe steigt.

Welche Rolle spielt DFIR-IRIS gegenüber kommerziellen Case-Management-Tools?

DFIR-IRIS deckt 80 Prozent dessen ab, was ein Mid-Market-Case-Management leistet. Die fehlenden 20 Prozent sind oft Reporting-Templates und vorkonfigurierte SLA-Logik. Für Konzern-Setups mit harten Audit-Anforderungen bleiben kommerzielle Tools im Vorteil, für Mittelständler ist DFIR-IRIS sehr produktiv.

Lassen sich Shuffle-Workflows mit kommerziellen SOAR-Tools kombinieren?

Ja, über REST-APIs auf beiden Seiten. In der Praxis macht das aber selten Sinn – die hybride Architektur erzeugt mehr Eskalations-Paths, als sie spart. Entweder das Team entscheidet sich für Shuffle als primäres SOAR, oder es bleibt beim kommerziellen Tool. Hybrid ist eine Übergangsphase, keine Ziel-Architektur.

Titelbild und Infografik: KI-generiert (Mai 2026)

Titelbild und Infografik: KI-generiert (Mai 2026)

Titelbild und Infografik: KI-generiert (Mai 2026)

Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik