SIEM-Tuning: False-Positives reduzieren ohne echte Alerts zu verlieren
Wie Sie in Wazuh gezielt False Positives reduzieren, ohne echte Bedrohungen zu übersehen – mit Regelbeispielen, CDB-Listen und Tuning-Strategien.
SIEM-Tuning: False-Positives reduzieren ohne echte Alerts zu verlieren
Key Takeaways
- False Positives sind das größte Produktivitätsproblem in jedem SIEM-Betrieb – aber blindes Stummschalten ist gefährlicher als das Rauschen selbst
- Wazuh bietet mehrere Schichten für gezieltes Tuning: lokale Regelüberschreibungen, CDB-Listen, Alert-Level-Anpassungen und zeitbasierte Ausnahmen
- Strukturiertes Tuning erfordert einen dokumentierten Prozess – keine Ad-hoc-Änderungen
- Jede Unterdrückung muss nachvollziehbar und zeitlich überprüft werden – das ist auch eine NIS-2-Anforderung
Das eigentliche Problem mit False Positives
Ein SIEM, das zu viel warnt, wird ignoriert. Ein SIEM, das zu wenig warnt, übersieht echte Angriffe. Dieses Dilemma kennt jeder, der ein SIEM länger als zwei Wochen betreibt.
In der Praxis sieht das oft so aus: Nach der Erstinstallation von Wazuh generiert ein mittelgroßes Netzwerk mit 50 Endpunkten, einem Exchange-Server und Microsoft 365 problemlos 2.000 bis 5.000 Alerts pro Tag. Davon sind in der ersten Woche vielleicht 15 % tatsächlich relevant. Der Rest ist legitimer Betrieb, den Wazuh korrekt erkennt, aber falsch bewertet.
Das Ergebnis: Das Sicherheitsteam – oder die einzelne Person, die nebenbei auch noch für Netzwerk und Helpdesk zuständig ist – schaltet Alerts ab. Pauschal. Ohne Dokumentation. Manchmal auch unbewusst, indem Alarme einfach ungelesen archiviert werden.
Das ist der gefährlichste Zustand, in dem ein SIEM sein kann.
Warum pauschales Stummschalten gefährlich ist
Ein Angreifer, der sich lateral durch ein Netzwerk bewegt, erzeugt genau die Arten von Events, die erfahrungsgemäß als Rauschen abgestempelt werden: fehlgeschlagene Logins, ungewöhnliche Zugriffszeiten, neue Prozessausführungen. Wer diese Kategorien pauschal deaktiviert, blendet sich selbst aus.
Die Alternative ist strukturiertes Tuning: Man reduziert Alerts nicht kategorisch, sondern kontextbezogen. Nicht „SSH-Fehler ignorieren
Häufige Fragen
Wie oft sollte ich meine Wazuh-Tuning-Regeln überprüfen?
Mindestens einmal pro Quartal. Umgebungen ändern sich: neue Server, neue Dienste, neue Backup-Agenten. Eine Regelausnahme, die vor sechs Monaten sinnvoll war, kann heute eine echte Bedrohung maskieren. Empfehlenswert ist ein kurzes Review-Protokoll in der local_rules.xml selbst – mit Datum, Begründung und geplantem Review-Termin als Kommentar über jeder Regeländerung.
Welche Wazuh-Regelgruppen sind typischerweise die größten False-Positive-Quellen?
In mittelständischen Umgebungen sind es meistens: SSH-Authentifizierungsfehler von Monitoring-Systemen und Backup-Agenten, Syscheck-Events während Backup-Fenster, Windows-Eventlog-Alerts durch Software-Deployment-Tools (SCCM, Intune) sowie Microsoft-365-Sign-in-Events von Azure-Diensten wie Azure AD Connect oder dem App Proxy. Diese vier Bereiche decken erfahrungsgemäß über 60 % des False-Positive-Volumens ab.
Wie stelle ich sicher, dass Tuning keine echten Angriffe maskiert?
Drei Maßnahmen helfen: Erstens immer kontextbezogen tunen – nie eine gesamte Regelgruppe deaktivieren, sondern immer auf spezifische Quell-IPs, Hostnamen oder Zeitfenster einschränken. Zweitens vor jeder Produktivsetzung mit ossec-logtest prüfen, ob die Regeländerung das gewünschte Ergebnis liefert. Drittens nach dem Tuning die Alert-Metriken mindestens zwei Wochen beobachten: Wenn bestimmte Angriffsklassen komplett aus dem Dashboard verschwinden, ist das ein Warnsignal.