Anomalieerkennung in Wazuh: Ereignisspitzen, Rückgänge und 24-Stunden-Abweichungen zuverlässig erkennen

Einleitung

Dashboards eignen sich gut zur visuellen Kontrolle von Sicherheitsereignissen. Sie ersetzen jedoch keine automatisierte Erkennung. Wer täglich manuell prüft, ob ein Host mehr oder weniger Events als am Vortag erzeugt hat, übersieht zwangsläufig Veränderungen oder bewertet normale Schwankungen als Sicherheitsvorfall.

In einer Wazuh-Umgebung können solche Abweichungen grundsätzlich auf zwei Arten erkannt werden:

1. Adaptive Anomalieerkennung mit dem OpenSearch-Anomaly-Detection-Plugin und dem Random-Cut-Forest-Algorithmus.
2. Deterministische Schwellenwertüberwachung mit einem OpenSearch-Alerting-Monitor, der zwei feste Zeiträume miteinander vergleicht.

Beide Verfahren lösen unterschiedliche Probleme. Der Anomaly Detector eignet sich für unbekannte, dynamische Abweichungen. Ein Query-Level-Monitor ist dagegen die bessere Wahl, wenn exakt definiert werden soll, dass sich die Ereigniszahl gegenüber den vorherigen 24 Stunden beispielsweise um mindestens 30 Prozent verändert haben muss.

Ausgangslage / Problemstellung

Die betrachtete Umgebung sammelt Wazuh-Alerts im Indexmuster wazuh-alerts-*. Für einen bestimmten Host soll automatisiert erkannt werden, ob sich die Anzahl der Events deutlich erhöht oder verringert hat.

Typische Anforderungen sind:

• Vergleich der letzten 24 Stunden mit den davorliegenden 24 Stunden
• Erkennung pro Host oder Event-Kategorie
• Berücksichtigung prozentualer Abweichungen
• Darstellung der Ergebnisse im Dashboard
• Generierung von Alerts oder Benachrichtigungen
• Vermeidung zufälliger oder nicht relevanter Anomalien

Ein erster Anomaly Detector auf Basis der Eventanzahl eines Hosts kann dabei scheinbar zufällige Ergebnisse liefern. Gleichzeitig wird ein bekannter Traffic-Anstieg bei einer historischen Analyse möglicherweise nicht als Anomalie markiert.

Das ist nicht zwangsläufig ein Fehler des Plugins. Es entsteht häufig durch ein Missverständnis darüber, wie Random Cut Forest arbeitet und welche Datenbasis ein Detector benötigt.

Technische Analyse

Wazuh und OpenSearch Anomaly Detection

Wazuh speichert generierte Sicherheitsalerts über den Wazuh Indexer in OpenSearch-Indizes. Das Anomaly-Detection-Plugin verarbeitet daraus aggregierte Zeitreihen. Es analysiert also nicht jedes einzelne Security-Event semantisch, sondern beispielsweise die Anzahl, Summe, den Durchschnitt oder das Maximum eines Feldes innerhalb aufeinanderfolgender Zeitintervalle.

Der eingesetzte Random-Cut-Forest-Algorithmus ist ein unüberwachtes Verfahren. Er erstellt aus den beobachteten Daten ein dynamisches Modell und berechnet für neue Datenpunkte unter anderem:

• einen erwarteten Wert,
• einen Anomaly Grade zwischen 0 und 1,
• einen Confidence-Wert zwischen 0 und 1.

Ein Anomaly Grade größer als 0 bedeutet, dass der Datenpunkt vom gelernten Muster abweicht. Der Confidence-Wert beschreibt die Sicherheit der berechneten Bewertung, ist aber nicht mit der allgemeinen Genauigkeit des Modells gleichzusetzen. Die Confidence steigt typischerweise, nachdem das Modell mehr Daten gesehen hat.

Random Cut Forest führt keinen festen Vortagesvergleich durch

Ein Detector mit einer count()-Funktion beantwortet nicht direkt die Frage:

Ist die Anzahl der letzten 24 Stunden mindestens 30 Prozent größer als die Anzahl der vorherigen 24 Stunden?

Stattdessen beantwortet er sinngemäß:

Ist der aktuelle Datenpunkt beziehungsweise die aktuelle Folge von Datenpunkten ungewöhnlich im Vergleich zum bislang gelernten Verhalten?

Dabei können Trends, wiederkehrende Schwankungen, vorherige Ausreißer und die Reihenfolge aufeinanderfolgender Werte in die Bewertung einfließen. Ein Traffic-Anstieg muss deshalb nicht zwangsläufig als Anomalie erscheinen, selbst wenn er aus menschlicher Sicht auffällig aussieht.

Wurde ein ähnlicher Anstieg bereits mehrfach beobachtet oder befindet er sich innerhalb der vom Modell erwarteten Bandbreite, kann der Anomaly Grade niedrig bleiben. Umgekehrt kann eine technisch kleine Veränderung als auffällig bewertet werden, wenn sie in einem ansonsten sehr stabilen Datenstrom auftritt.

Der Detector benötigt eine ausreichende Baseline

Ein neu gestarteter Detector benötigt Zeit und genügend Datenpunkte, um ein belastbares Modell aufzubauen. OpenSearch kann historische Daten für das Cold-Start-Training verwenden. In aktuellen Versionen können dafür bis zu 10.000 historische Datenpunkte berücksichtigt werden. Bei einem Real-Time-Detector mit einem Intervall von zehn Minuten kann die Initialisierung beispielsweise ungefähr eine Stunde dauern, bis genügend zusammenhängende Datenpunkte vorliegen.

Entscheidend ist dabei die Anzahl der Intervalle, nicht nur die Länge des Kalenderzeitraums.

Ein Beispiel:

• Historischer Zeitraum: 30 Tage
• Detector-Intervall: 24 Stunden
• Verfügbare Datenpunkte: lediglich 30

OpenSearch verlangt für eine historische Analyse mindestens 128 Detector-Intervalle. Ein 30-Tage-Zeitraum mit täglichen Buckets reicht daher nicht aus. Mit einem einstündigen Intervall entstehen im gleichen Zeitraum dagegen bis zu 720 Datenpunkte.

Für eine Tagesanalyse ist deshalb meist ein Intervall von 15 Minuten, 30 Minuten oder einer Stunde sinnvoller als ein einzelner 24-Stunden-Bucket.

Shingle Size und zusammenhängende Daten

OpenSearch verwendet sogenanntes Shingling. Dabei werden mehrere aufeinanderfolgende Aggregationsintervalle gemeinsam betrachtet. Die Standardgröße beträgt acht Intervalle; zulässig sind Werte zwischen 1 und 128.

Bei einem Intervall von einer Stunde bedeutet:

• Shingle Size 8: Kontext der letzten acht Stunden
• Shingle Size 24: ungefähr ein Tagesverlauf
• Shingle Size 48: ungefähr zwei Tagesverläufe

Kleinere Werte reagieren schneller, können aber mehr False Positives erzeugen. Größere Werte glätten kurzfristiges Rauschen, benötigen jedoch mehr Daten und reagieren langsamer. Fehlende Buckets verschlechtern die Bildung zusammenhängender Shingles und damit die Modellqualität.

Eine Shingle Size von 24 kann bei stündlichen Buckets ein sinnvoller Testwert für tagesbezogene Muster sein. Sie führt jedoch weiterhin keinen mathematisch exakten Vergleich zweier 24-Stunden-Fenster durch.

Zu kleine Intervalle erzeugen Rauschen

Ein Detector-Intervall von einer Minute ist nur dann sinnvoll, wenn in nahezu jeder Minute ausreichend viele relevante Events eintreffen.

Bei einem einzelnen Host mit wenigen Alerts entstehen andernfalls Zeitreihen wie:

0, 0, 1, 0, 0, 0, 3, 0, 1, 0

Diese Reihe ist stark von einzelnen Ereignissen geprägt. Der Detector bewertet dann eher das sporadische Auftreten einzelner Alerts als eine aussagekräftige Änderung des Sicherheitsverhaltens.

Für normale Endpoint- oder Server-Alerts sind häufig folgende Startwerte stabiler:

Detector interval: 15 Minuten oder 1 Stunde
Window delay:      2 bis 5 Minuten
Shingle size:      8, anschließend Vergleichstest mit 24
Feature:           count(rule.id)

Der Window Delay muss an die tatsächliche Verzögerung zwischen Eventerzeugung und Indexierung angepasst werden. Ohne ausreichenden Delay verarbeitet der Detector möglicherweise ein noch unvollständiges Zeitfenster. OpenSearch empfiehlt, den Wert am oberen Ende der üblichen Ingestion-Verzögerung auszurichten.

Fehlende Daten sind nicht automatisch null Events

Ein leerer Bucket kann unterschiedliche Ursachen haben:

• Der Host hat tatsächlich keine Alerts erzeugt.
• Der Agent war offline.
• Der Wazuh Manager hat keine Daten erhalten.
• Die Indexierung war verzögert.
• Ein Feld fehlte in den Dokumenten.
• Der ausgewählte Filter hat keine Dokumente erfasst.

Für die Erkennung eines vollständigen Eventausfalls kann in aktuellen OpenSearch-Versionen die Imputation fehlender Werte mit 0 verwendet werden. Das verbessert die Erkennung eines Rückgangs auf null, darf aber nur eingesetzt werden, wenn ein fehlender Bucket fachlich tatsächlich als null Events interpretiert werden soll. Umfangreiche Imputation senkt die Datenqualität und kann den Confidence-Wert beeinträchtigen.

count() sollte auf einem zuverlässigen Feld basieren

Bei einer Value-Count-Aggregation werden nur Dokumente gezählt, in denen das ausgewählte Feld vorhanden ist. Für Wazuh-Alerts sollte daher ein Feld verwendet werden, das in allen relevanten Dokumenten gesetzt ist, beispielsweise rule.id.

Eine Aggregation auf data.srcip würde dagegen nur Alerts zählen, die tatsächlich eine Quell-IP enthalten. Das wäre kein vollständiger Eventzähler für den Host.

Schwellenwert, Anomaly Grade und Confidence sind unterschiedliche Ebenen

In älteren Versionen des Anomaly-Detection-Plugins konnte der interne RCF-Schwellenwert nicht als feste Prozentzahl vorgegeben werden. Auch heute wird die grundsätzliche Anomaly-Bewertung dynamisch durch das Modell erzeugt.

Aktuelle OpenSearch-Versionen bieten jedoch zusätzliche Suppression Rules pro Feature. Damit können Anomalien unterdrückt werden, wenn der tatsächliche Wert beispielsweise nicht mehr als 30 Prozent vom erwarteten Wert abweicht. Außerdem kann festgelegt werden, ob nur Anstiege, nur Rückgänge oder beide Richtungen berücksichtigt werden sollen. Ohne eigene Suppression Rule ignoriert OpenSearch in aktuellen Versionen standardmäßig Abweichungen von weniger als 20 Prozent. Diese Funktion kann in älteren, mit Wazuh ausgelieferten OpenSearch-Versionen fehlen.

Davon getrennt wird im Alerting-Monitor definiert, ab welchem Anomaly Grade und Confidence-Wert eine Benachrichtigung ausgelöst wird. Ein möglicher Startwert ist:

Anomaly Grade > 0,7
Confidence    > 0,7

Diese Werte müssen anhand realer Daten validiert werden. OpenSearch verwendet vergleichbare Bedingungen auch in seiner aktuellen Dokumentation zur Anomaly-Alert-Konfiguration.

Lösung / Best Practices

Variante 1: Adaptiven Anomaly Detector korrekt konfigurieren

Für unbekannte oder dynamische Abweichungen kann der Detector wie folgt aufgebaut werden.

1. Plugin-Version kontrollieren

Der offizielle Wazuh-Beitrag zur Anomalieerkennung basiert auf Wazuh 4.5.3 und OpenSearch Dashboards 2.6.0. Die dort verwendeten Plugin-Dateien dürfen nicht unverändert auf andere Wazuh-Versionen übertragen werden. Wazuh weist ausdrücklich darauf hin, eine zur jeweiligen Wazuh- und OpenSearch-Version passende Dashboard-Komponente zu verwenden.

Die installierten Dashboard-Plugins lassen sich beispielsweise prüfen mit:

sudo -u wazuh-dashboard \
  /usr/share/wazuh-dashboard/bin/opensearch-dashboards-plugin list

Gesucht wird ein Eintrag wie:

anomalyDetectionDashboards@<passende-version>

Vor einer manuellen Installation oder Aktualisierung sollten ein Backup und ein Test in einer nicht produktiven Umgebung erfolgen.

2. Detector definieren

Empfohlene Ausgangskonfiguration:

Name:              wazuh-host-event-volume
Data source:       wazuh-alerts-*
Timestamp field:   timestamp
Filter:            agent.name = HOST-01
Detector interval: 1 Stunde
Window delay:      2 bis 5 Minuten

Die konkreten Feldnamen müssen vorher in Discover oder über das Index-Mapping überprüft werden.

Für einen einzelnen Host ist ein fester Filter meist stabiler als ein High-Cardinality-Detector. Sollen viele Hosts mit einem Detector überwacht werden, kann agent.name als Category Field eingesetzt werden. Dann erstellt OpenSearch praktisch getrennte Modelle pro Entity. Das erhöht jedoch Speicherverbrauch, Modellanzahl und Betriebsaufwand.

3. Mit einer einzelnen Feature beginnen

Als Feature genügt zunächst:

Feature name:       event-count
Aggregation method: count()
Field:              rule.id

Weitere Features sollten erst ergänzt werden, wenn die einzelne Eventanzahl stabil funktioniert. Zu viele oder stark korrelierte Features erschweren die Bewertung und können Precision und Recall verschlechtern. OpenSearch empfiehlt daher, Feature-Sets iterativ zu testen.

4. Erkennungsrichtung und Suppression festlegen

Für Eventvolumen sind unterschiedliche Strategien möglich:

Nur Anstieg:
Geeignet für Brute-Force-Versuche, Scans, Log-Stürme oder fehlerhafte Regeln.

Nur Rückgang:
Geeignet für Agent-Ausfälle, unterbrochene Logquellen oder ausgefallene Integrationen.

Beide Richtungen:
Geeignet für allgemeines Telemetrie- und Verhaltensmonitoring.

Ist die eingesetzte OpenSearch-Version kompatibel, kann zusätzlich eine relative Suppression Rule gesetzt werden:

Abweichungen unter 30 Prozent ignorieren

Diese Regel bezieht sich auf die Differenz zwischen tatsächlichem und erwartetem Feature-Wert. Sie ist kein exakter Vergleich mit dem Vortag.

5. Historische Analyse sinnvoll dimensionieren

Für eine 30-Tage-Analyse mit stündlichem Detector-Intervall stehen maximal 720 Intervalle zur Verfügung. Das ist wesentlich aussagekräftiger als 30 tägliche Buckets.

Empfohlener Testablauf:

1. 30 Tage historische Daten auswählen.
2. Detector-Intervall auf 1 Stunde setzen.
3. Zunächst Shingle Size 8 testen.
4. Anschließend Shingle Size 24 testen.
5. Bekannte normale Lastspitzen markieren.
6. Bekannte Incidents und Telemetrieausfälle vergleichen.
7. False Positives und False Negatives dokumentieren.

Ein bekannter Traffic-Anstieg muss dabei nicht zwingend erkannt werden. Die historische Analyse dient der Bewertung und Feinabstimmung des Modells, nicht dem Nachweis, dass jeder manuell ausgewählte Peak als Anomalie klassifiziert wird.

6. Alerting-Monitor ergänzen

Der Detector erzeugt Ergebnisse, aber eine operative Benachrichtigung benötigt zusätzlich einen Alerting-Monitor.

Der Monitor sollte mindestens auf folgende Felder prüfen:

detector_id
anomaly_grade
confidence
execution_end_time
entity

Eine mögliche Trigger-Bedingung lautet sinngemäß:

max_anomaly_grade > 0.7 && confidence > 0.7

Der Monitor sollte nicht häufiger laufen als der Detector. OpenSearch empfiehlt für Anomaly-Detection-Monitore typischerweise einen Monitor-Zeitplan von mindestens dem Doppelten des Detector-Intervalls, da Detector-Ergebnisse erst indexiert und anschließend suchbar werden müssen. Wird das Detector-Intervall geändert, muss der Monitor separat angepasst werden.

Bei einem stündlichen Detector wäre beispielsweise ein Monitor-Intervall von zwei Stunden sehr konservativ. Für zeitkritischere Szenarien kann mit überlappenden Suchfenstern gearbeitet werden, sofern die zusätzliche Last berücksichtigt wird.

Variante 2: Exakter Vergleich zweier 24-Stunden-Fenster

Wenn die fachliche Anforderung lautet, eine fest definierte prozentuale Abweichung zwischen zwei Zeiträumen zu erkennen, ist ein Query-Level-Monitor die transparentere Lösung.

OpenSearch-Query-Level-Monitore können eine Query DSL ausführen und das Ergebnis anschließend mit einem Painless-Skript bewerten.

Beispielabfrage

Die folgende Extraction Query vergleicht die letzten 24 Stunden mit den unmittelbar davorliegenden 24 Stunden:

{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "agent.name": "HOST-01"
          }
        },
        {
          "range": {
            "timestamp": {
              "gte": "{{period_end}}||-48h",
              "lt": "{{period_end}}",
              "format": "epoch_millis"
            }
          }
        }
      ]
    }
  },
  "aggs": {
    "current_24h": {
      "filter": {
        "range": {
          "timestamp": {
            "gte": "{{period_end}}||-24h",
            "lt": "{{period_end}}",
            "format": "epoch_millis"
          }
        }
      }
    },
    "previous_24h": {
      "filter": {
        "range": {
          "timestamp": {
            "gte": "{{period_end}}||-48h",
            "lt": "{{period_end}}||-24h",
            "format": "epoch_millis"
          }
        }
      }
    }
  }
}

Je nach Mapping kann für den Hostnamen statt agent.name ein Keyword-Unterfeld erforderlich sein. Das muss anhand des tatsächlichen Wazuh-Index-Mappings geprüft werden.

Trigger für eine Abweichung von mindestens 30 Prozent

def current = ctx.results[0].aggregations.current_24h.doc_count;
def previous = ctx.results[0].aggregations.previous_24h.doc_count;

if (previous == 0) {
    return current >= 100;
}

double deviation =
    Math.abs(current - previous) * 100.0 / previous;

return deviation >= 30.0
    && Math.max(current, previous) >= 100;

Diese Bedingung löst aus, wenn:

• die Abweichung mindestens 30 Prozent beträgt und
• mindestens eines der beiden Fenster 100 Events enthält.

Der Mindestwert verhindert, dass eine Veränderung von einem auf zwei Events wegen einer rechnerischen Steigerung von 100 Prozent einen Alarm erzeugt.

Soll nur ein Anstieg erkannt werden, kann die Bedingung angepasst werden:

def current = ctx.results[0].aggregations.current_24h.doc_count;
def previous = ctx.results[0].aggregations.previous_24h.doc_count;

if (previous == 0) {
    return current >= 100;
}

double increase =
    (current - previous) * 100.0 / previous;

return current > previous
    && increase >= 30.0
    && current >= 100;

Für einen Rückgang wird die Berechnung entsprechend umgekehrt.

Rolling Window oder abgeschlossene Kalendertage

Ein Monitor, der alle 15 Minuten läuft, vergleicht zwei rollierende Zeitfenster:

Jetzt minus 24 Stunden bis jetzt
gegen
Jetzt minus 48 Stunden bis jetzt minus 24 Stunden

Das eignet sich für eine kontinuierliche Überwachung.

Sollen dagegen zwei abgeschlossene Kalendertage verglichen werden, sollte der Monitor einmal täglich nach Mitternacht laufen. Dabei ist eine einheitliche Zeitzone festzulegen. UTC vermeidet unerwartete 23- oder 25-Stunden-Tage durch Sommerzeitumstellungen.

Kombinierter Betrieb

Die belastbarste Lösung kombiniert beide Verfahren:

Query-Level-Monitor:
Überwacht bekannte, verbindliche Grenzwerte.

Anomaly Detector:
Findet unbekannte Muster, Trends und ungewöhnliche Sequenzen.

Der Query-Level-Monitor beantwortet nachvollziehbar, warum ein Alarm ausgelöst wurde: Die Eventanzahl ist um einen konkret berechneten Prozentsatz gestiegen oder gefallen.

Der Anomaly Detector kann zusätzlich Veränderungen erkennen, die unterhalb des statischen Schwellenwerts liegen, im Kontext des bisherigen Verhaltens aber ungewöhnlich sind.

Visualisierung im Wazuh Dashboard

Der Anomaly-Detection-Bereich stellt bereits folgende Informationen bereit:

• tatsächlicher Feature-Wert
• erwarteter Feature-Wert
• Anomaly Grade
• Confidence
• Zeitpunkt der letzten Anomalie
• Feature Contribution
• Heatmap bei Category Fields
• Drill-down zu den zugrunde liegenden Events

OpenSearch zeigt Live-Anomalien, historische Ergebnisse und eine Feature-Aufschlüsselung direkt in der Detector-Ansicht an.

Für ein zentrales Security-Dashboard sind zusätzlich folgende Panels sinnvoll:

1. Eventanzahl pro Stunde und Host
2. Tatsächlicher Wert gegenüber erwartetem Wert
3. Anomaly Grade als Zeitreihe
4. Confidence als Zeitreihe
5. Aktive Alerting-Monitore
6. Top Hosts nach prozentualer Abweichung
7. Hosts ohne Events im erwarteten Zeitraum
8. Tabelle mit Host, aktuellem Wert, Vergleichswert und Abweichung
9. Drill-down auf rule.id, rule.groups und data.srcip

Dabei sollte der Dashboard-Zeitraum dem Detector-Intervall und dem Alerting-Fenster entsprechen. Andernfalls können Dashboard und Alert unterschiedliche Zahlen anzeigen, obwohl beide technisch korrekt arbeiten.

Lessons Learned / Best Practices

Anomalieerkennung nicht mit Schwellenwertüberwachung verwechseln

Ein Machine-Learning-Modell ist nicht automatisch die beste Lösung für eine klar formulierte mathematische Regel. Ein fester 24-Stunden-Vergleich gehört primär in einen Query-Level-Monitor. RCF ergänzt diese Logik um adaptive Erkennung.

Baseline und Datenqualität sind wichtiger als Modellparameter

Ein Detector kann nur Muster aus den Daten lernen, die tatsächlich und rechtzeitig indexiert wurden. Vor der Feinabstimmung sollten deshalb folgende Punkte geprüft werden:

• Sind alle erwarteten Hosts im Index vorhanden?
• Gibt es Lücken in den Zeitreihen?
• Kommen Events verspätet an?
• Ist das Timestamp-Feld korrekt?
• Zählt die Feature-Aggregation wirklich alle relevanten Dokumente?
• Werden Wartungsfenster und geplante Lasttests berücksichtigt?
• Ändern sich Regeln oder Decoder während der Trainingsphase?

Mit einer einfachen Feature starten

Ein Detector mit einer sauber definierten Eventanzahl ist leichter zu validieren als ein Modell mit fünf unterschiedlichen Features. Zusätzliche Features sollten nur aufgenommen werden, wenn sie einen klaren fachlichen Mehrwert bieten.

Eventvolumen allein ist kein Incident

Ein Anstieg kann durch einen Angriff entstehen, aber ebenso durch:

• neue Wazuh-Regeln,
• geänderte Log-Level,
• Software-Rollouts,
• Vulnerability-Scans,
• Backfills,
• doppelte Logweiterleitung,
• fehlerhafte Decoder,
• einen ausgefallenen Filter.

Ein Rückgang kann auf eine ruhigere Umgebung hinweisen, aber auch auf:

• einen gestoppten Agent,
• eine unterbrochene Logquelle,
• einen ausgefallenen Manager,
• Indexierungsprobleme,
• gelöschte oder manipulierte Logs,
• deaktivierte Audit- oder Syslog-Konfiguration.

Die Alarmmeldung sollte deshalb immer Host, Zeitraum, aktuellen Wert, erwarteten beziehungsweise vorherigen Wert und Abweichung enthalten.

Mindestvolumen und Cooldown einsetzen

Prozentuale Schwellenwerte benötigen ein Mindestvolumen. Zusätzlich sollte ein Cooldown beziehungsweise Alert-Throttling konfiguriert werden, damit eine länger anhaltende Abweichung nicht bei jedem Monitorlauf erneut gemeldet wird.

Änderungen versionieren

Folgende Konfigurationen sollten dokumentiert und versioniert werden:

• Detector-Filter
• Features
• Detector-Intervall
• Window Delay
• Shingle Size
• Imputation
• Suppression Rules
• Monitor-Query
• Trigger-Skript
• Benachrichtigungsvorlage
• Dashboard-Objekte

Nach Änderungen an Wazuh-Regeln, Decodern, Logquellen oder der Infrastruktur muss die Baseline erneut bewertet werden.

Detector- und Monitor-Last beobachten

Viele Category Fields, kurze Intervalle und mehrere Features erhöhen den Ressourcenbedarf des Wazuh Indexers. Neue Detectoren sollten daher schrittweise eingeführt und hinsichtlich CPU, Heap, Suchlatenz und Indexierungsleistung überwacht werden.

Fazit

Anomalieerkennung lässt sich in Wazuh sinnvoll über die OpenSearch-Komponenten ergänzen. Zufällig wirkende Ergebnisse entstehen häufig durch zu kleine Intervalle, unzureichende historische Daten, fehlende Buckets, verspätete Indexierung oder eine zu komplexe Feature-Konfiguration.

Für adaptive Erkennung sollte ein Detector mit einer einfachen, stabilen Feature, ausreichender Baseline, passendem Window Delay und einem separaten Alerting-Monitor aufgebaut werden. Ein historischer Zeitraum von 30 Tagen ist nur dann aussagekräftig, wenn das Detector-Intervall genügend Datenpunkte erzeugt.

Für die konkrete Anforderung, zwei 24-Stunden-Zeiträume anhand einer festen Prozentgrenze zu vergleichen, ist dagegen ein Query-Level-Monitor die präzisere und besser nachvollziehbare Lösung. In produktiven SIEM-Umgebungen empfiehlt sich die Kombination aus deterministischen Schwellenwerten und adaptiver Anomalieerkennung.

Quellenverweise

Wazuh: Enhancing IT security with anomaly detection in Wazuh
https://wazuh.com/blog/enhancing-it-security-with-anomaly-detection/

OpenSearch: Anomaly detection
https://docs.opensearch.org/latest/observing-your-data/ad/

OpenSearch: Configuring anomaly alerting
https://docs.opensearch.org/latest/observing-your-data/ad/managing-anomalies/

OpenSearch: Per query and per bucket monitors
https://docs.opensearch.org/latest/observing-your-data/alerting/per-query-bucket-monitors/

OpenSearch: Alerting triggers
https://docs.opensearch.org/latest/observing-your-data/alerting/triggers/

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …

https://wazuh.slack.com/archives/C07CNG3M11N/p1781160965098319