Software-Inventar-Änderungen und SCA-Deltas in Wazuh als Monatsreport: Baseline, Diff-Logik und E-Mail-Versand

von

Einleitung
Software-Inventar und Konfigurations-Compliance gehören zu den zuverlässigsten Indikatoren für Drift, Shadow-IT und potenziell riskante Veränderungen auf Endpoints. Wazuh bringt dafür zwei wichtige Bausteine mit: System Inventory (Syscollector) für installierte Pakete/Programme und Security Configuration Assessment (SCA) für Policy-basierte Checks. Die häufige Anforderung aus dem Betrieb: „Bitte monatlich per E-Mail eine Übersicht, welche Endpoints vom Baseline-Stand abweichen (Software hinzugefügt/entfernt, SCA-Status geändert).“ Dieser Beitrag zeigt, warum das nicht „out of the box“ als fertiger Monatsreport existiert – und wie man es robust und wartbar umsetzt.

Ausgangslage / Problemstellung
Gesucht ist eine „einfache“ Methode, um:

  1. Software-Inventar: Baseline je Endpoint/OS festlegen und Abweichungen (Install/Remove) erkennen.
  2. SCA: Änderungen und/oder aktuellen Compliance-Stand reporten.
  3. Monatlicher Report per E-Mail: idealerweise als Tabelle oder PDF.

Wichtig ist dabei ein zentrales Detail der Wazuh-Datenflüsse: Sowohl Inventory als auch SCA sind stark auf Änderungsübermittlung optimiert. Das ist gut für Skalierung – kann aber „monatliche Vollständigkeitsberichte“ erschweren, wenn man nur auf Alerts/Events schaut. Syscollector sammelt Inventardaten auf dem Agent und stellt sie zentral bereit. documentation.wazuh.com+1

Technische Analyse

1) Syscollector: Inventar ist verfügbar, aber Reporting ist kein fertiges Feature

Syscollector erfasst Software-/Paket-Inventar und sendet es an den Wazuh-Server zur Speicherung und Auswertung. Die Daten sind grundsätzlich über Wazuh-Komponenten nutzbar (Dashboard/Indexer/API). Wazuh dokumentiert Syscollector als Quelle für Systeminventar und beschreibt auch, wie Inventar-Informationen für Alerting genutzt werden können. documentation.wazuh.com+1

Was es standardmäßig typischerweise nicht liefert, ist ein „monatlicher Baseline-Report per Mail“, der Install/Remove sauber aggregiert. Dafür braucht es eine zusätzliche Logikschicht (Vergleich + Report + Versand).

2) SCA: „Diff-based“ Updates bedeuten: Alerts ≠ vollständiger Ist-Zustand

SCA ist explizit so ausgelegt, dass Agents nur Unterschiede zwischen Scans senden. Wenn es keine Änderung gibt, wird nur eine Zusammenfassung übertragen, um Traffic zu sparen und die SCA-Datenbank aktuell zu halten. documentation.wazuh.com+1
Folge: Wer nur wazuh-alerts-* oder eventbasierte Daten auswertet, baut schnell Reports, die „leer“ wirken, obwohl alles korrekt läuft – weil es im Monat schlicht keine Änderungen gab.

3) Reporting/„Scheduled Reports“: gut für Dashboards, aber nicht automatisch „Baseline-Diff“

Wazuh (bzw. der Indexer/Dashboard-Stack) kennt Report-Mechanismen, bei denen Reports aus vordefinierten Visualisierungen erzeugt werden können – inklusive geplanter Reports. Das ist hilfreich, wenn man bereits eine passende Visualisierung hat. wazuh.github.io
Für Baseline-Diff (Install/Remove gegen Soll-Liste) reicht Reporting allein aber oft nicht, weil zuerst ein konsistenter Datenstand (Baseline vs. Ist) erzeugt werden muss.

Lösung / Best Practices
Im Betrieb haben sich zwei stabile Muster etabliert. Beide können kombiniert werden.

Option A: Baseline-Diff als eigener „State“ (empfohlen)

Ziel: Ein monatlicher Report muss auf einem Zustand basieren (aktueller Inventarstand pro Agent), nicht nur auf Ereignissen.

  1. Daten holen
    • Inventar pro Agent über Syscollector-Daten (z. B. Pakete/Programme). Syscollector ist dafür vorgesehen und liefert die Grundlage. documentation.wazuh.com
    • SCA-Status ebenfalls zustandsbasiert interpretieren; Änderungen sind diff-basiert. documentation.wazuh.com
  2. Baseline definieren
    Zwei übliche Varianten:
    • Allowlist (erlaubte Software je OS/Abteilung/Hostgruppe)
    • Golden Image Snapshot (Baseline = Ist-Stand am Stichtag, danach nur Deltas)
  3. Vergleich & Persistenz
    • Vergleiche monatlich (oder täglich) Ist vs Baseline.
    • Speichere Ergebnisse in einer kleinen DB/JSON (besser: DB), damit Reports reproduzierbar sind.
  4. Report erzeugen
    • „Added“, „Removed“, „Unknown“, „Not allowed“ je Agent.
    • Für SCA: optional „aktueller Status“ plus „Delta seit Vormonat“.
  5. E-Mail Versand
    • Versand via SMTP (Python smtplib) oder System-Mailer (mailx/sendmail), je nach Umgebung.

Warum das robust ist:
Du entkoppelst Reporting von der Event-Frequenz. Auch wenn sich nichts geändert hat, kannst du „0 Abweichungen“ sauber reporten – und zwar vollständig.

Option B: Change-Detection als Alerts (schneller Einstieg, begrenzter Monatsreport)

Wenn du primär „Benachrichtigung bei Änderung“ willst (nicht unbedingt vollständige Monatsübersicht), kannst du Inventar-Daten auch als Trigger für Alerts nutzen. Wazuh beschreibt explizit, wie Syscollector-Informationen für Alerting herangezogen werden können. documentation.wazuh.com

Das ist gut für „Near Real Time“ (Install/Remove → Alert). Für einen Monatsreport musst du dann aber wieder aggregieren (z. B. alle Alerts des Monats pro Agent gruppieren). Das funktioniert, ist aber erfahrungsgemäß ungenauer, wenn Index-Retention/Filter/Noise eine Rolle spielt.

Ergänzung: Monatsreport als Dashboard-Report

Wenn du nach Umsetzung von Option A einen Index/Datensatz mit „Baseline-Diff Ergebnissen“ hast, kannst du darauf Visualisierungen bauen und diese als geplante Reports generieren. Geplante Reports werden automatisch erzeugt, sobald sie konfiguriert sind. wazuh.github.io
Das ist der sauberste Weg, um „monatlich PDF per Mail“ (oder per Abruf) zu industrialisieren – aber der entscheidende Teil ist: erst State erzeugen, dann reporten.

Lessons Learned / Best Practices

  • Baseline-Reports brauchen State, nicht nur Events. SCA sendet Differences; ohne State wirst du Lücken sehen. documentation.wazuh.com
  • Syscollector ist die richtige Quelle für Software-Inventar, aber „monatliches E-Mail Reporting“ ist typischerweise eine zusätzliche Automationsaufgabe. documentation.wazuh.com
  • Trenne „Alarmierung“ von „Reporting“: Alerts reagieren schnell auf Änderungen; Reports liefern Management-/Audit-Sichten.
  • Skalierung: Je größer die Umgebung, desto wichtiger sind Limitierung, Paging, Caching und eine persistente Ablage der Vergleichsergebnisse.
  • Retention & Nachvollziehbarkeit: Monatsreports sollten reproduzierbar sein (DB statt nur „aktueller Stand“).

Fazit
Eine eingebaute „monatliche E-Mail über Software-Baseline-Abweichungen“ ist in Wazuh in der Regel kein fertiger Schalter – aber die notwendigen Bausteine sind vorhanden: Syscollector liefert Inventar, SCA liefert Compliance-Deltas, und der Stack unterstützt Reporting-Workflows. Der verlässlichste Ansatz ist, den Baseline-Vergleich als eigenen Zustand aufzubauen (API/Inventory → Diff → persistieren) und daraus einen Monatsreport per Mail zu generieren oder als geplanten Dashboard-Report zu veröffentlichen. Damit erhältst du vollständige, auditierbare Übersichten – unabhängig davon, ob im Monat viele oder gar keine Änderungen passiert sind. documentation.wazuh.com+2documentation.wazuh.com+2

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1767435598792449