SCA-Ergebnisse in Wazuh Dashboards visualisieren: Windows Screen Saver Compliance korrekt abbilden

Einleitung
Security Configuration Assessment (SCA) ist eines der wirkungsvollsten Module in Wazuh, um Konfigurationsabweichungen auf Endpunkten frühzeitig zu erkennen. Gerade bei Windows-Systemen sind scheinbar einfache Einstellungen wie ein aktiver, passwortgeschützter Bildschirmschoner sicherheitsrelevant, da sie direkten Einfluss auf physische Zugriffsmöglichkeiten haben. In der Praxis entsteht jedoch häufig Verwirrung, wenn Administratoren versuchen, diese SCA-Ergebnisse in einem eigenen Wazuh-Dashboard tabellarisch darzustellen. Dieser Artikel zeigt, warum klassische Dashboards auf Basis von wazuh-alerts-* hier an Grenzen stoßen – und welche sauberen Lösungsansätze es gibt.

Ausgangslage / Problemstellung
Eine eigene SCA-Policy überprüft Windows-Registry-Keys wie ScreenSaveActive, ScreenSaverIsSecure und ScreenSaveTimeOut. Die Policy funktioniert korrekt, die Ergebnisse sind im Bereich Configuration Assessment sichtbar, und einzelne Abweichungen erzeugen Alerts.

Das Ziel ist ein Dashboard, das pro Agent klar anzeigt:

Ist der Screen Saver aktiv?
Ist er passwortgeschützt?
Welche Agenten sind compliant, welche nicht?

Der naheliegende Ansatz ist, im Wazuh Dashboard eine Tabelle auf Basis des Indexpatterns wazuh-alerts-* zu erstellen und dort nach SCA-Feldern zu filtern. Genau hier liegt jedoch der zentrale Denkfehler.

Technische Analyse

Wie SCA in Wazuh tatsächlich arbeitet

Wazuh SCA ist zustandsbasiert, nicht ereignisbasiert. Das bedeutet:

Agents führen periodische Scans aus.
Nur Änderungen gegenüber dem letzten bekannten Zustand werden an den Manager gesendet.
Ein Check, der einmal fehlgeschlagen ist und sich nicht ändert, erzeugt keine weiteren Alerts bei späteren Scans.

Dieses Verhalten ist bewusst so implementiert, um Log-Flut zu vermeiden und sich auf sicherheitsrelevante Änderungen zu konzentrieren. Die offizielle Dokumentation beschreibt dieses Prinzip explizit als „diff-based reporting“.

Konsequenz:
Der Index wazuh-alerts-* enthält keinen vollständigen Snapshot des aktuellen SCA-Zustands aller Agenten, sondern nur historische Änderungsereignisse.

Warum Dashboards auf `wazuh-alerts-*` in die Irre führen

Ein Data Table mit Filtern wie:

rule.groups: sca
data.sca.policy: windows_autolock
data.sca.check.id: 99000 OR 99001

zeigt lediglich:

Wann ein Check seinen Zustand geändert hat
Nicht, wie der aktuelle Zustand eines Agents aussieht

Ein Agent, dessen Screen Saver vor 30 Tagen deaktiviert war und seither unverändert ist, taucht im Dashboard schlicht nicht mehr auf. Das Dashboard wirkt „leer“ oder unvollständig, obwohl die SCA-Policy korrekt läuft.

Lösung / Best Practices

Option 1: Dashboard nur für „letzte Änderungen“ (eingeschränkt sinnvoll)

Wenn das Ziel ausschließlich ist, Konfigurationsänderungen sichtbar zu machen, kann ein Dashboard auf wazuh-alerts-* legitim sein.

Empfohlene Konfiguration:

Visualize → Data table
Index pattern: wazuh-alerts-*
Filter:
- rule.groups: sca
- data.sca.policy: windows_autolock
Buckets:
- Split rows: agent.name oder agent.id
- Sub-bucket: data.sca.check.id oder data.sca.check.title
Spalte: data.sca.check.result

Das Ergebnis zeigt nur Agents mit kürzlichen Änderungen – nicht den Gesamtstatus.

Option 2: Aktuellen SCA-Status über die Wazuh API abrufen (empfohlen)

Für eine korrekte Compliance-Übersicht ist die Wazuh API der technisch saubere Weg. Die API liefert den aktuellen Zustand aller Checks pro Agent, unabhängig davon, wann sie sich zuletzt geändert haben.

Beispiel (konzeptionell):

GET /sca/{agent_id}/checks/windows_autolock

Oder gefiltert:

GET /sca/{agent_id}/checks/windows_autolock?result=failed&q=id=99000

Typischer Architekturansatz:

Periodischer API-Abruf (z. B. per Script)
Übergabe der Ergebnisse an:
- ein externes BI-Tool
- ein eigenes Indexpattern
- oder ein CMDB-/Compliance-Reporting-System

Damit lassen sich Dashboards bauen, die tatsächlich „Agent X: Screen Saver aktiv = Ja/Nein“ anzeigen.

Option 3: Forcierte SCA-Resets (Workaround, nicht offiziell empfohlen)

Einige Administratoren erzwingen täglich vollständige SCA-Ergebnisse, indem sie:

die lokale SCA-Datenbank der Agents zurücksetzen
oder den Manager-Cache leeren

Dadurch werden alle Checks bei jedem Scan erneut als „neu“ bewertet und in wazuh-alerts-* geschrieben.
Achtung:

Nicht offiziell dokumentiert
Erhöht Log-Volumen massiv
Potenziell riskant bei großen Umgebungen

Diese Methode eignet sich höchstens für kleine, stark kontrollierte Setups.

Lessons Learned / Best Practices

SCA ist State-Based, nicht Event-Based – Dashboards müssen dieses Modell berücksichtigen.
wazuh-alerts-* ist kein Compliance-Snapshot-Index.
Für Management-Reports und Compliance-Übersichten ist die Wazuh API der korrekte Datenlieferant.
Dashboards auf Alerts eignen sich primär für Change Detection, nicht für Ist-Zustände.
Eine klare Trennung zwischen „Detection“ und „Compliance Reporting“ vermeidet falsche Erwartungen.

Fazit
Ein Wazuh-Dashboard, das zuverlässig anzeigt, ob Windows-Agents einen aktiven und sicheren Screen Saver haben, lässt sich nicht korrekt allein auf Basis von wazuh-alerts-* umsetzen. Das ist kein Konfigurationsfehler, sondern eine direkte Folge des diff-basierten SCA-Designs. Wer den aktuellen Compliance-Status sehen will, muss die Wazuh API einbeziehen oder bewusst mit den Einschränkungen eines Alert-basierten Dashboards leben. Dieses Verständnis ist entscheidend, um SCA-Daten korrekt zu interpretieren – und Fehlentscheidungen im Security-Betrieb zu vermeiden.

Quellen / weiterführende Dokumentation