Warum in Wazuh nicht alle AWS-CloudTrail-Events erscheinen

Einleitung

Bei der Integration von AWS CloudTrail in Wazuh erwarten viele Administratoren, dass jedes CloudTrail-Ereignis automatisch als Alert im Wazuh Dashboard erscheint. In der Praxis ist das nicht immer der Fall. Wazuh verarbeitet CloudTrail-Logs zwar aus S3, aber die Standardregeln entscheiden, welche Events tatsächlich als Alerts erzeugt und indexiert werden.

Ausgangslage / Problemstellung

Nach der Einrichtung der AWS-Integration gemäß Wazuh-Dokumentation werden CloudTrail-Events aus einem S3-Bucket abgeholt. Trotzdem erscheinen in Wazuh deutlich weniger Events als in der CloudTrail-Ansicht der AWS-Konsole. Zusätzlich wirkt es so, als ob das konfigurierte Abfrageintervall von einer Minute nicht eingehalten wird, weil neue Events nur alle 10 bis 20 Minuten sichtbar werden.

Typische Symptome sind:

CloudTrail zeigt Events, die in Wazuh nicht auftauchen.
Wazuh erzeugt Alerts nur für bestimmte AWS-Aktionen.
Das aws-s3-Modul ist auf ein kurzes Intervall konfiguriert, aber Events erscheinen verzögert.
Nach Anpassung der Regel erscheinen plötzlich deutlich mehr Events als in der CloudTrail-Konsole.

Technische Analyse

Die Ursache liegt in zwei unterschiedlichen Ebenen der Verarbeitung.

Erstens liest Wazuh CloudTrail-Daten nicht aus der CloudTrail-Konsole, sondern direkt aus den Logdateien im S3-Bucket. Die AWS-Konsole ist daher nicht zwingend eine vollständige 1:1-Referenz für das, was Wazuh verarbeitet. Filter, Ansichten, Event-History-Grenzen oder Suchparameter in der Konsole können dazu führen, dass dort weniger oder andere Events sichtbar sind als in den eigentlichen S3-Logdateien.

Zweitens bedeutet „Log wurde von Wazuh gelesen“ nicht automatisch „Alert wurde erzeugt“. Für CloudTrail ist die Wazuh-Regel 80202 relevant. Diese Standardregel filtert CloudTrail-Events anhand bekannter AWS-Eventnamen aus der CDB-Liste:

/var/ossec/etc/lists/amazon/aws-eventnames

Ist ein bestimmter Wert aus aws.eventName nicht in dieser Liste enthalten, kann das Event zwar grundsätzlich eingelesen werden, erzeugt aber unter Umständen keinen Alert über diese Regel. Das ist kein Decoder-Fehler, sondern Teil der Standardklassifizierung im Wazuh-Ruleset.

Das beobachtete Zeitverhalten hat eine weitere Ursache: Das <interval> im aws-s3-Wodle steuert nur, wie häufig Wazuh den S3-Bucket prüft. Es steuert nicht, wann AWS die CloudTrail-Logdateien in S3 bereitstellt. Eine Verzögerung von mehreren Minuten zwischen API-Ereignis, Ablage in S3 und Verarbeitung durch Wazuh ist daher erwartbar.

Lösung / Best Practices

Der erste Schritt sollte immer der Vergleich des fehlenden CloudTrail-Events mit der CDB-Liste sein. Dafür wird der Wert aus aws.eventName geprüft:

grep -x "EventNameHierEintragen" /var/ossec/etc/lists/amazon/aws-eventnames

Fehlt der Eventname, gibt es zwei saubere Optionen.

Die konservative Variante ist, die CDB-Liste gezielt zu erweitern. Das ist sinnvoll, wenn nur bestimmte AWS-Aktionen zusätzlich alerten sollen. So bleibt die Alert-Menge kontrollierbar.

Die breitere Variante ist ein Override der CloudTrail-Regel 80202, damit alle Events mit aws.source = cloudtrail einen Alert erzeugen. Dazu wird in /var/ossec/etc/rules/local_rules.xml folgende Regel hinterlegt:

<group name="amazon,aws,">
  <rule id="80202" level="3" overwrite="yes">
    <field name="aws.source">cloudtrail</field>
    <options>no_full_log</options>
    <description>AWS Cloudtrail: $(aws.eventSource) - $(aws.eventName).</description>
    <group>aws_cloudtrail,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,pci_dss_10.6.1,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>

Anschließend muss der Wazuh Manager neu gestartet werden:

systemctl restart wazuh-manager

Diese Anpassung sorgt dafür, dass CloudTrail-Events unabhängig von der Eventname-CDB-Liste als Alerts erscheinen, sofern sie korrekt als AWS-CloudTrail-Event dekodiert wurden.

Die Nebenwirkung ist wichtig: Die Alert-Menge kann stark steigen. Das belastet Speicher, Indexer, Dashboards, Retention und gegebenenfalls Benachrichtigungen. In produktiven Umgebungen sollte diese Änderung daher mit Index-Lifecycle-Management, Retention-Planung und gezielten Dashboard-Filtern kombiniert werden.

Lessons Learned / Best Practices

CloudTrail-Integration in Wazuh sollte nicht ausschließlich über die AWS-Konsole validiert werden. Die belastbarere Referenz sind die tatsächlich im S3-Bucket gespeicherten CloudTrail-Dateien.

Für Troubleshooting empfiehlt sich diese Reihenfolge:

1. Prüfen, ob CloudTrail das Event in S3 abgelegt hat.
2. Prüfen, ob das aws-s3-Modul den Bucket korrekt liest.
3. Prüfen, ob das Event dekodiert wird.
4. Prüfen, ob eine Wazuh-Regel einen Alert erzeugt.
5. Prüfen, ob Dashboard-Filter oder Index-Patterns das Event ausblenden.

Ein globaler Override der Regel 80202 ist technisch wirksam, aber nicht immer die beste Betriebsstrategie. Für produktive SIEM-Umgebungen ist oft ein abgestuftes Modell besser:

Level 3: vollständige CloudTrail-Sichtbarkeit für Audit- und Hunting-Zwecke
Level 5–7: relevante administrative Änderungen
Level 8+: sicherheitskritische Aktionen wie IAM-, KMS-, CloudTrail-, GuardDuty- oder Root-Account-Aktivität

So bleibt die Sichtbarkeit erhalten, ohne dass alle AWS-API-Aufrufe als gleich wichtig behandelt werden.

Fazit

Wenn in Wazuh weniger CloudTrail-Events erscheinen als erwartet, liegt die Ursache häufig nicht an der AWS-Integration selbst, sondern an der Standardregel-Logik und der CDB-Liste für bekannte AWS-Eventnamen. Wer vollständige CloudTrail-Sichtbarkeit benötigt, kann Regel 80202 überschreiben und alle CloudTrail-Events alerten lassen. Dabei sollte jedoch bewusst mit höherem Datenvolumen, mehr Alerts und zusätzlicher Indexer-Last gerechnet werden.