EPSS in Wazuh sauber integrieren: Warum ein eigenes Index-Design und der richtige Trigger über Erfolg oder Frust entscheiden

von

Einleitung

EPSS (Exploit Prediction Scoring System) ergänzt klassische Vulnerability-Programme um eine entscheidende Dimension: die Wahrscheinlichkeit realer Ausnutzung in naher Zukunft. Während CVSS die theoretische Schwere einer Schwachstelle abbildet, priorisiert EPSS nach Exploit-Likelihood – genau das, was im operativen SOC-Alltag oft fehlt. EPSS wird von FIRST bereitgestellt und lässt sich über eine öffentliche API automatisiert abrufen. first.org

In Wazuh liegt der Reiz darin, Vulnerability-Detector-Ergebnisse (CVE-basiert) mit EPSS zu verknüpfen, um Remediation-Queues sinnvoll zu sortieren. Der Community-Thread zeigt dabei zwei typische Stolpersteine: Index-Strategie (wo speichere ich EPSS?) und Ausführungslogik (wann/wie läuft mein Enrichment wirklich automatisch?).

Ausgangslage / Problemstellung

Das Ziel: Vulnerability-Detector-Alerts in Wazuh um EPSS-Felder wie epss.score, epss.percentile und epss.date anreichern und anschließend such- und visualisierbar machen – idealerweise als CVE-zentrierter Zustand, nicht als „Alert-Noise“.

Im Thread wurden bereits folgende Schritte umgesetzt:

  • Ein dediziertes Index wazuh-epss-vulnerabilities wurde im Indexer angelegt (OpenSearch-basiert).
  • Ein Enrichment-Skript ruft EPSS über die FIRST-API ab und schreibt Dokumente in dieses Index.
  • In Wazuh wurde ein <integration>-Block definiert und ein Wrapper-Skript im Integrations-Verzeichnis abgelegt.

Dann kamen die entscheidenden Fragen:

  • „Warum läuft es nicht automatisch – wie sammelt es die Logs, berechnet EPSS und schreibt ins Index?“
  • „Warum sehe ich das neue Index nicht im Discover/bei Visualisierungen?“

Technische Analyse

1) Warum wazuh-alerts-* nicht der richtige Ort für EPSS ist

EPSS-Enrichment ist eine spezifische, CVE-zentrierte Auswertungsschicht. wazuh-alerts-* enthält jedoch heterogene Alert-Typen (Auth, FIM, Malware, Sysmon, etc.). EPSS dort „mitzuschleppen“ führt langfristig zu:

  • unnötig aufgeblähten Alert-Dokumenten
  • komplizierterer Korrelation (Alert-zentriert statt CVE-zentriert)
  • schwierigem Lifecycle-Management (EPSS ändert sich täglich; Alerts sind Ereignisse)

Die robustere Architektur ist ein dediziertes EPSS-Index, das pro CVE den aktuellsten Score als „State“ hält (Upsert nach cve). Das passt auch zum Charakter der EPSS-Daten: täglich aktualisiert, zeitabhängig, CVE-basiert. first.org

Zusätzlich ist das Thema als Feature-Request in der Wazuh-Community seit längerem präsent – ein Hinweis, dass es sich um „Custom Engineering“ handelt, nicht um einen vollständig out-of-the-box Pfad. GitHub

2) Warum das Index zwar existiert, aber im Dashboard nicht erscheint

In Wazuh Dashboard (OpenSearch Dashboards) ist ein Index erst dann bequem nutzbar, wenn ein Index Pattern / Data View existiert, das auf den Indexnamen passt. Ohne das sieht man den Index in Discover/Visualize typischerweise nicht, obwohl er technisch vorhanden ist.

Konzeptionell ist das kein Wazuh-Spezialfall, sondern Standard im OpenSearch-/Kibana-Ökosystem: Index → Pattern → Discover/Visualize.

3) Warum <integration> nicht automatisch „jedes Alert“ an dein Skript übergibt

Hier liegt der Kern des Missverständnisses: Wazuh-Integrations sind primär dafür gedacht, Alerts an externe Systeme (Webhooks, APIs, Tools) zu senden – konfiguriert über ossec.conf mit Filtern wie level, group und rule_id. documentation.wazuh.com+1

Entscheidend ist aber: Dein Skript braucht JSON-Input (ein Alert-Dokument). Das kommt nicht „magisch“ – du brauchst einen Mechanismus, der bei passenden Alerts tatsächlich eine Aktion ausführt und den Alert-Inhalt übergibt.

Genau dafür ist Wazuh Active Response oft der passendere Trigger, weil Active-Response-Skripte den vollständigen Alert über STDIN als JSON erhalten. documentation.wazuh.com+1
Die Active Response selbst wird wiederum über rule_id, level oder rules_group getriggert. documentation.wazuh.com

4) Woher kommt die CVE im Alert – und wie zuverlässig ist das?

Vulnerability-Detection-Alerts enthalten die CVE in der Regel als Feld wie data.vulnerability.cve (und viele weitere Details, z. B. Paketname/Version, CVSS, Status). wazuh-documentation-49-master.readthedocs.io

Das ist wichtig für das Enrichment: Dein Script sollte nicht versuchen, CVEs aus Freitext zu parsen, sondern gezielt aus dem strukturierten Feld zu lesen.

Lösung / Best Practices

Zielbild: CVE-State im eigenen EPSS-Index + Trigger über Regeln/Active Response

A) Index-Design (empfohlen)

  • Index: wazuh-epss-vulnerabilities-* (z. B. pro Umgebung/Tenant)
  • Dokument-ID: cve (Upsert/Overwrite)
  • Felder: epss.score, epss.percentile, epss.date, ingested_at, optional cvss.base_score, package.name, agent.id als Kontext

Warum? EPSS ist zeitvariabel. Die EPSS-API bietet explizit Datumsabfragen und Time-Series. Dadurch ist ein „State“-Index mit Retention/Refresh logischer als eine dauerhafte Alert-Anreicherung in wazuh-alerts-*. first.org

B) Dashboard-Sichtbarkeit herstellen

  • Data View / Index Pattern anlegen, z. B. wazuh-epss-vulnerabilities-*
  • Zeitfeld wählen (z. B. ingested_at), damit Discover und Visualisierungen sauber funktionieren

C) Trigger korrekt bauen: Custom Rule → Active Response

  1. Custom Rule, die Vulnerability-Detection-Alerts matcht (z. B. anhand Rule-Group oder vorhandener Felder)
  2. Active Response, die bei dieser Rule-ID auslöst
  3. Script liest JSON von STDIN, extrahiert data.vulnerability.cve, ruft FIRST EPSS API ab und schreibt Upsert ins EPSS-Index

Wichtig: Active Response ist ein mächtiges Schwert. Für reines Enrichment ohne Host-Aktion empfiehlt sich die Ausführung auf dem Manager (location local) und ohne destructive Actions. Die Doku warnt explizit vor schlechter Umsetzung, weil Fehlkonfigurationen Risiken erhöhen können (z. B. ungewollte Aktionen bei vielen Alerts). documentation.wazuh.com

D) Taktik für „Live“-Updates (wann wird EPSS geholt?)
Es gibt zwei sinnvolle Modelle – je nach Ziel:

  1. On-Alert Enrichment (event-driven)
  • Bei jedem neuen Vulnerability-Alert wird EPSS für diese CVE geholt und ins EPSS-Index geschrieben.
  • Vorteil: schnell, CVE kommt dann, wenn sie relevant wird
  • Nachteil: API-Calls können bei großen Scans explodieren → Caching/Dedupe nötig
  1. Daily Batch Refresh (state-driven, empfohlen)
  • Ein täglicher Job zieht EPSS für alle CVEs, die in den letzten X Tagen „aktiv“ waren, und aktualisiert das EPSS-Index.
  • Vorteil: kontrollierte Last, passt zur täglichen EPSS-Aktualisierung
  • EPSS liefert dafür passende API-Mechanik inkl. Batch-Query für mehrere CVEs. first.org

Praktisch ist oft eine Kombination: event-driven „first seen“ + daily refresh für alle aktiven CVEs.

E) Priorisierung in der Praxis: CVSS + EPSS gemeinsam
Ein verbreiteter, operativ sinnvoller Ansatz ist:

  • CVSS als Baseline-Schwere
  • EPSS als Ausnutzungswahrscheinlichkeit in der Priorisierung
    Damit werden CVEs mit moderater CVSS, aber hoher EPSS oft zu „Patch now“-Kandidaten. SOCFortress Support Portal

Lessons Learned / Best Practices

  • Trenne Alert-Ereignisse von CVE-State: wazuh-alerts-* bleibt Event-Index, EPSS gehört in ein eigenes, CVE-zentriertes Index.
  • Nutze strukturierte Felder: data.vulnerability.cve ist die sauberste Quelle für Enrichment. wazuh-documentation-49-master.readthedocs.io
  • Trigger ist alles: Integrations sind nicht automatisch „Enrichment-Pipelines“. Für „Alert rein → Script läuft → Index raus“ ist Active Response oft der stabilere Mechanismus. documentation.wazuh.com+1
  • Skalierung bedenken: Rate-Limits, Caching und Batch-Abfragen einplanen – EPSS ist API-getrieben. first.org
  • Dashboards brauchen Patterns: Ohne Data View / Index Pattern bleibt der Index „unsichtbar“ in Discover/Visualize.
  • Dokumentiere Custom Engineering: Das Thema ist in der Community bekannt und als Wunsch/Feature diskutiert – setze es wie ein eigenes kleines Produkt auf (Mapping, Retention, Monitoring). GitHub

Fazit

EPSS-gestützte Vulnerability-Priorisierung in Wazuh ist sehr gut machbar – aber nicht durch „ein Feld mehr im Alert-Index“, sondern durch ein sauberes Architekturpattern: Vulnerability-Alerts bleiben Events, EPSS wird als CVE-zentrierter State in einem dedizierten Index geführt. Die Automatisierung hängt am richtigen Trigger: Wer wirklich „automatisch“ enrichen will, braucht eine Regel-basierte Auslösung und einen Mechanismus, der den vollständigen Alert als JSON an das Script übergibt – Active Response ist hierfür oft der pragmatischste Weg.

Damit entsteht ein wartbares System, das EPSS täglich aktuell halten kann und zugleich in Dashboards und Queries sauber korrelierbar bleibt.

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/C07BZJY86G3/p1765968471027799