Fehlende Prozesse erkennen in Wazuh: Warum Rules allein nicht reichen – und welche Ansätze wirklich funktionieren

von

Einleitung

Ein häufiges Ziel im Security Monitoring ist nicht nur das Erkennen verdächtiger Aktivitäten, sondern auch das Erkennen von Abweichungen vom Sollzustand: Ein wichtiger Prozess läuft nicht (mehr), ein Agent ist „blind“, oder eine sicherheitsrelevante Komponente wurde deaktiviert. In Wazuh ist die Versuchung groß, dafür einfach Regeln auf Syscollector-Prozessdaten zu bauen. In der Praxis stößt man dabei aber schnell an eine grundsätzliche Grenze: Wazuh-Regeln analysieren Events – nicht deren Abwesenheit.

Dieser Beitrag erklärt, warum „Alert, wenn Prozess nicht gefunden wird“ mit Syscollector-Eventregeln so nicht direkt möglich ist, und zeigt drei praxistaugliche Alternativen: SCA (Compliance/State Checks), Agent-seitige Prüfung mit Log-Erzeugung, sowie query-basierte Flatline-Detektion über das Alerting-Plugin.

Ausgangslage / Problemstellung

In einer Umgebung werden Prozessinformationen per Syscollector erhoben (z. B. PowerShell-Prozesse unter Windows oder bestimmte Services/Daemons unter Linux). Bereits existierende Regeln lösen Alerts aus, wenn Syscollector Prozess-Events erzeugt.

Die Anforderung lautet jedoch:

  • Alarm auslösen, wenn ein definierter Prozess NICHT gefunden wird (also „läuft nicht“ / „wurde nicht gestartet“ / „ist verschwunden“).

Das Problem: Beim „Nicht-Finden“ entsteht in der Regel kein Event, das eine klassische Regel auswerten könnte.

Technische Analyse

Syscollector arbeitet inventarbasiert und erzeugt Events für Änderungen zwischen Scans (Delta), z. B. wenn Prozesse neu auftauchen, beendet werden oder sich Eigenschaften ändern. Wazuh kann somit zuverlässig erkennen, dass ein Prozess nicht mehr läuft, wenn er im vorherigen Scan vorhanden war – aber nicht, dass ein Prozess „nie gestartet wurde“ oder „im aktuellen Scan fehlt“, wenn dafür kein Änderungsereignis generiert wird.

Wichtig ist die Konsequenz für das Wazuh-Regelwerk (analysisd):

  • Regeln triggern auf Ereignisse, die eintreffen.
  • „Abwesenheit“ ist kein Ereignis.
  • Ein „Sollzustand“ muss daher entweder explizit geprüft oder über Query/Statistik abgeleitet werden.

Lösung / Best Practices

Je nach Ziel (Security Detection vs. Compliance/Operations) haben sich drei Muster bewährt:

1) Best Fit für „Sollzustand“: SCA-Policy mit Prozess-Check

Wenn es darum geht, dass ein Prozess dauerhaft vorhanden sein muss (oder nicht vorhanden sein darf), ist das konzeptionell Compliance bzw. Baseline-Überwachung. Genau dafür ist Wazuh Security Configuration Assessment (SCA) gedacht: Policies definieren Prüfungen, die regelmäßig laufen und bei Abweichung Findings/Alerts erzeugen.

Beispiel: Custom SCA Policy (Linux/Unix) – Prozess muss laufen
Datei z. B. /var/ossec/etc/shared/sca/my_process_baseline.yml (Deployment je nach Architektur: lokal am Agent oder zentral verteilt):

policy:
  id: "my-process-baseline"
  file: "my_process_baseline.yml"
  name: "My Process Baseline"
  description: "Ensure critical processes are running"
  references:
    - "internal-baseline"

checks:
  - id: 10001
    title: "Critical process must be running"
    description: "Verify that the process is present"
    rationale: "If the process is missing, security controls might be inactive."
    remediation: "Start the service/process and investigate why it stopped."
    condition: all
    rules:
      - "p:powershell"     # Beispielname; unter Linux entsprechend anpassen

Warum das funktioniert:
SCA prüft den Zustand aktiv in festen Intervallen und kann deshalb „Fehlen“ als Verstoß melden – ohne dass dafür ein Syscollector-Change-Event existieren muss. Beispiele für Prozess-Checks (p:) finden sich auch in bestehenden Wazuh-SCA-Policies als Muster. (Konzept und Aufbau: )

Praxis-Tipp: Für Windows-basierte Anforderungen (PowerShell, spezielle Agentenprozesse) ist SCA häufig der stabilste Ansatz, weil er unabhängig von kurzlebigen Prozessereignissen ist. Je nach Prozess kann es aber sinnvoll sein, statt eines Prozessnamens lieber den zugehörigen Service zu prüfen (wenn vorhanden), um Flapping zu vermeiden.

2) Agent-seitige Prüfung + lokales Log (Event erzeugen, wenn Prozess fehlt)

Wenn Sie das Ganze bewusst als Event Detection behandeln wollen (z. B. „jede Abweichung sofort als Security Event“), dann erzeugen Sie ein Event genau dann, wenn der Prozess fehlt:

  • Cronjob (Linux) oder Task Scheduler (Windows) prüft zyklisch, ob Prozess existiert
  • Wenn nicht vorhanden: Eintrag in eine Logdatei (oder Windows Event Log / Syslog)
  • Wazuh-Agent sammelt diese Logquelle (localfile) und eine Regel erzeugt den Alert

Vorteile:

  • Sehr flexibel (auch komplexe Logik möglich: Startzeitfenster, Wartungsmodus, Abhängigkeiten)
  • Sofortige Alerts möglich, unabhängig von Syscollector-Delta

Nachteile:

  • Script-/Job-Betrieb muss sauber abgesichert werden (Berechtigungen, Tamper-Schutz, Monitoring des Jobs selbst)

Dieses Muster ist besonders sinnvoll, wenn „Prozess fehlt“ nur in bestimmten Zeitfenstern relevant ist (z. B. während Geschäftszeiten) oder wenn die Prozessdefinition nicht zuverlässig über SCA abbildbar ist.

3) „Dark Detection“: Query-basierte Flatline-/Gap-Erkennung über Alerting

Für fortgeschrittene Use Cases kann man Abwesenheiten auch indirekt erkennen: Wenn normalerweise regelmäßig bestimmte Alerts/Events auftreten und plötzlich bleiben sie aus, ist das ein Signal (Flatline). Das lässt sich mit query-basierten Monitoren umsetzen, die in OpenSearch/Wazuh-Indexer laufen (Alerting-Plugin) und Daten im Index statistisch auswerten.

Beispiele für sinnvolle Flatline-Detektionen:

  • „Von Host X kamen 15 Minuten keine Events mehr“ (Agent down / Logpipeline gestört)
  • „Seit N Minuten kein Heartbeat/kein bestimmter Eventtyp“
  • „Prozess-Inventory-Events bleiben aus“ (indirekt, je nach Datenlage)

Wichtig: Das ist nicht immer ideal für „Prozess läuft nicht“, weil Prozesse nicht zwingend periodische Events erzeugen. Für „Prozess muss laufen“ ist SCA in der Regel klarer und wartungsärmer.

Lessons Learned / Best Practices

  • Rules ≠ State Monitoring: Wazuh-Regeln sind eventgetrieben – für Abwesenheiten braucht es State/Compliance oder Query-Logik.
  • SCA für Baselines: Wenn ein Prozess „immer laufen muss“, ist SCA meist der beste Fit (klarer Soll-/Ist-Vergleich, wiederholbar, auditierbar).
  • Script/Log für dynamische Logik: Wenn Zeitfenster, Wartungsmodi oder komplexe Abhängigkeiten relevant sind, erzeugen Sie gezielt ein Logevent.
  • Flatline für Pipeline/Visibility: Nutzen Sie query-basierte Monitore für „Datenfluss ist weg“ und andere Visibility-Probleme.
  • Flapping vermeiden: Prozesse können kurzlebig sein – definieren Sie Toleranzen (z. B. mehrfaches Fehlen in Folge) oder prüfen Sie lieber Services statt Prozesse, wo möglich.

Fazit

Ein Alert „wenn Prozess nicht gefunden wird“ lässt sich mit Syscollector-Regeln allein nicht zuverlässig abbilden, weil Syscollector Änderungen und Wazuh-Regeln nur eingehende Events auswerten. Für echte „Sollzustand“-Überwachung sind Custom SCA Policies der sauberste Ansatz. Wo mehr Flexibilität nötig ist, erzeugt ein Agent-seitiger Check ein explizites Logevent. Und für „Daten bleiben aus“-Szenarien ergänzt query-basierte Flatline-Detektion das Monitoring um eine wichtige Dimension.

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/p1770382010167039