Slack

SentinelOne in Wazuh: Warum JSON-Events im Dashboard fehlen, Logtest „nicht erkannt“ meldet und wie du Parsing, Filebeat-Pipeline und Korrelation stabil bekommst Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Die SentinelOne-Integration ist in Wazuh ein klassischer „Datenpipeline“-Use-Case: Events kommen per API oder Syslog an, werden lokal als JSON oder CEF geschrieben, anschließend von Wazuh ingestiert, decodiert, in den hier weiterlesen

Einleitung Wenn in einer Wazuh-Cluster-Architektur plötzlich nur noch Events von einem Worker im Dashboard auftauchen, wirkt es auf den ersten Blick wie ein Indexer-Problem. In der Praxis liegt die Ursache häufig an einer Kette aus Nebenwirkungen: ein kurzfristig voller Datenträger auf dem betroffenen Worker, ein danach „gesund“ wirkender Filebeat – und trotzdem keine ingestierten Dokumente. hier weiterlesen

Einleitung Regelmäßige Betriebssystem- und Applikationsupdates gehören zum Alltag jeder IT-Umgebung. Für Security- und SIEM-Teams stellen diese Wartungsfenster jedoch eine besondere Herausforderung dar: Während Updates laufen, erzeugen Agenten oft eine Vielzahl erwartbarer, aber sicherheitlich irrelevanter Events. Ohne geeignete Maßnahmen kann dies zu Alert-Fluten, unnötiger Belastung des Wazuh-Managers und Alarmmüdigkeit bei Analysten führen. Dieser Artikel zeigt, wie hier weiterlesen

EinleitungCustom Decoder sind in Wazuh ein Standardwerkzeug, um herstellerspezifische Logs (z. B. Sophos Firewall „SFW“) in strukturierte Felder zu überführen. Wenn ein Decoder trotz korrekter Regex scheinbar nicht greift, liegt die Ursache häufig nicht im Regex selbst, sondern im Ingestionsformat: Wazuh decodiert grundsätzlich pro eingehendem Event eine Logmessage – wenn ein Forwarder oder ein Logfile hier weiterlesen

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh) Die Integration von Jamf Protect-Logs in Wazuh zur zentralen Sicherheitsanalyse stellt viele Organisationen vor Parsing-, Decoding- und Rule-Mapping-Herausforderungen. Obwohl die Logs bereits im JSON-Format vorliegen, muss Wazuh sie korrekt einlesen, decodieren und Regeln auslösen, damit sie im Wazuh-Dashboard erscheinen. Dieser Beitrag erklärt, wie Wazuh JSON-Logs aufnimmt, wie passende Regeln geschrieben hier weiterlesen

Einleitung Bei verteilten Wazuh-Installationen mit hoher Agentenzahl ist eine zentrale, ausfallsichere Konnektivität zwischen Agents und Servern entscheidend. Besonders in bestehenden Umgebungen mit 100+ Agents stellt sich die Frage, wie man Agent-Failover so umsetzt, dass sowohl Stabilität als auch Wartbarkeit gewährleistet sind. In diesem Artikel analysieren wir typische Ansätze, zeigen die Grenzen der nativen Wazuh-Mechanismen auf hier weiterlesen

Einleitung Wazuh wird häufig zuerst als „SIEM mit Indexer“ wahrgenommen: Logs werden eingesammelt, indexiert und sind im Dashboard durchsuchbar. Der eigentliche Sicherheitsmehrwert entsteht aber nicht in der Datenbank, sondern im Analyse- und Regelwerk des Wazuh Managers: Rohdaten werden dekodiert, zu Events normalisiert und anschließend über Regeln, Schwellenwerte und Korrelation in Alerts verwandelt. Wer verstehen will, hier weiterlesen

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. hier weiterlesen

Einleitung In produktiven Wazuh-Setups kollidieren zwei Realitäten: Agent-Alerts sind für Detection und Response essenziell, während Firewall-Syslog (z. B. Palo Alto) oft extrem volumenstark ist und andere Aufbewahrungsanforderungen hat. Wer beide Datenströme im gleichen wazuh-alerts-* Index hält, steht schnell vor Problemen bei Retention, Storage-Kosten und Performance. Der naheliegende Ansatz, per Filebeat output.elasticsearch.indices zu routen, funktioniert in hier weiterlesen

Die Einführung der neuen ISO 27001:2022 stellt Unternehmen – insbesondere kleine und mittelständische Betriebe – vor große Herausforderungen. Während die Anforderungen an Informationssicherheit steigen, müssen Organisationen gleichzeitig wirtschaftlich bleiben und ihre Sicherheitsprozesse effizient gestalten. Genau hier setzt Wazuh an: eine leistungsstarke Open-Source-Plattform, die XDR- und SIEM-Funktionen in einem zentralen System vereint. Obwohl Wazuh kein eigenes hier weiterlesen

EinleitungWazuh-Integrationen sind ein zentrales Bindeglied zwischen Detektion und Reaktion. Ob SOAR, DFIR-Plattformen oder externe Ticket- und Alerting-Systeme – viele Umgebungen leiten sicherheitsrelevante Events automatisiert weiter. In der Praxis zeigt sich jedoch immer wieder ein unerwartetes Verhalten: Sobald mehrere Integration-Blöcke auf dasselbe Event zutreffen, gehen Alerts scheinbar „verloren“. Dieser Artikel erklärt die interne Ausführungslogik von wazuh-integratord, hier weiterlesen

Einleitung Sobald Wazuh von „Proof of Concept“ in den produktiven SOC-Betrieb wächst, kippt ein All-in-One-Setup oft genau dort um, wo es weh tut: CPU/RAM-Spitzen durch Analyse und Korrelationsarbeit, I/O-Engpässe in /var/ossec, und vor allem Storage- und Performance-Druck im Indexer durch steigende Datenvolumina und Retention. Mit ~700 Agents plus zusätzlichen Integrationen (z. B. Firewalls via Syslog) hier weiterlesen

Problem:Auf einem Windows Server (z. B. Domain Controller/Active Directory) laufen die Windows User Logoff-Events heiß und erzeugen in Wazuh eine Log-Flut – ohne echten Mehrwert. Ziel ist: Nur relevante Login-Events behalten (z. B. interaktive Logins), den Rest möglichst früh abstellen. Warum das passiert Auf Windows-Systemen entstehen Login/Logout-Events sehr häufig – nicht nur durch „echte“ Benutzer, hier weiterlesen