SIEM-Export: MailGuard-Events an Splunk, Sentinel und QRadar streamen
SIEM-Export liefert die MailGuard-Events als normalisierten Stream an Splunk, Microsoft Sentinel, IBM QRadar und Elastic. Cursor-basierte Pull-API und optionaler Webhook-Push, Formate JSON, ECS, CEF und LEEF.
SIEM-Export liefert die Sicherheits- und E-Mail-Events des Gateways als normalisierten Event-Stream an SIEM-Systeme wie Splunk, Microsoft Sentinel, IBM QRadar und Elastic. In der ersten Version stammen die Events aus MailGuard. Zwei Wege stehen bereit: eine cursor-basierte Pull-API als Kern und ein optionaler Webhook-Push.
Die SIEM-Anbindung in den Integrationseinstellungen von MailGuard.
Voraussetzung und Freischaltung
SIEM-Export setzt eine aktive MailGuard-Lizenz voraus und wird pro Mandant freigeschaltet. Wer MailGuard sieht, kann den SIEM-Export nutzen, sobald der Zugang aktiviert ist. Die Konfiguration liegt in den Einstellungen im Bereich Integrationen auf der Karte SIEM-Anbindung.
Pull-API als Kern
Der Kern ist eine Pull-API. Der Endpunkt lautet https://conbool.com/api/v1/siem/events und gibt die Events seitenweise aus. Die Authentifizierung erfolgt per Bearer-Token mit einem API-Schlüssel im Format csk_live_. Die Paginierung ist cursor-basiert und lückenlos, sodass beim erneuten Abruf kein Event verloren geht und keines doppelt erscheint. Das abrufbare Zeitfenster umfasst 30 Tage. Je Zugang gilt ein Rate-Limit von 60 Anfragen pro Minute. Als Zielformat stehen JSON, ECS, CEF und LEEF bereit.
curl -H "Authorization: Bearer csk_live_..." \ "https://conbool.com/api/v1/siem/events?limit=100"
Zwei weitere Endpunkte ergänzen den Abruf. GET /api/v1/siem/health dient als Selbsttest der Anbindung. POST /api/v1/siem/events/replay liefert ein Zeitfenster erneut aus und ist auf eine Anfrage pro Stunde begrenzt.
Event-Typen im Stream
In der ersten Version stammen alle Events aus MailGuard.
- mail.received
- mail.delivered
- mail.deferred
- mail.rejected
- mail.quarantined
- mail.quarantine.released
- mail.sanitized
- mail.sandbox.detonated
- mail.threat.detected
- dlp.incident
- url.click.allowed
- url.click.blocked
Jedes Verdict trägt ein Feld enforcement mit dem Wert audit oder enforce. So erkennt ein SOC, ob eine erkannte Bedrohung nur beobachtet oder tatsächlich blockiert wurde, und deutet einen Treffer im Beobachtungsbetrieb nicht als Blockade. Den Hintergrund dazu liefert der Audit- und Enforce-Modus.
API-Zugänge anlegen und schützen
Ein neuer Zugang legt Zielformat und Beschränkungen fest.
Neuer API-Zugang mit Zielformat und optionaler IP-Beschränkung.
Der API-Schlüssel wird bei der Erstellung einmalig angezeigt und danach nicht mehr eingeblendet. Bestehende Zugänge lassen sich erneuern und sperren. Beim Erneuern gilt eine Übergangsfrist von 30 Tagen, in der alter und neuer Schlüssel parallel gültig bleiben. Optional beschränkt eine CIDR-Allowlist je Zugang die zulässigen Quell-IPs.
Vorgefertigte Connector-Konfigurationen
Für gängige Systeme steht je Zugang eine fertige Konfiguration zum Download bereit, sowohl im Anlege-Dialog als auch in der Zugangsliste. Verfügbar sind Konfigurationen für Filebeat, den Splunk HTTP Event Collector, Microsoft Sentinel, IBM QRadar sowie ein curl-Skript für den Betrieb per Cron. Endpunkt, Cursor-Handhabung und das Parsen des Event-Formats sind darin bereits gesetzt, ergänzt werden nur der API-Schlüssel und das eigene Ziel.
Elastic Cloud und Elastic Serverless rufen die Events nicht selbst ab. Dafür läuft ein schlanker Collector wie Filebeat, der den Endpunkt pollt und die Events als ECS-Dokumente nach Elasticsearch schreibt. Die bereitgestellte Filebeat-Konfiguration bildet genau diesen Ablauf ab.
Datenschutz und Aufbewahrung
Ein PII-Modus je Mandant steuert, wie personenbezogene Felder ausgeliefert werden. Im Modus plain bleiben Betreff und Adressen im Klartext. Der Modus hash ersetzt Betreff und Adressen durch einen SHA-256-Wert. Der Modus redact entfernt diese Felder ganz. Die Aufbewahrung der Exportdaten ist zwischen 7 und 365 Tagen konfigurierbar. Ein Recht auf Vergessenwerden lässt sich gezielt über eine E-Mail-Adresse ausführen.
Webhook-Push
Neben dem Abruf kann der SIEM-Export Events an eine eigene HTTPS-URL zustellen. Jede Zustellung ist per HMAC-SHA256 signiert, gebildet über timestamp.body, mit einem Signing-Secret, das bei der Einrichtung einmalig angezeigt wird. Fehlgeschlagene Zustellungen werden automatisch mit ansteigendem Backoff wiederholt. Nach dauerhaften Fehlern wird der Webhook abgeschaltet.
Rollen und Rechte
Der Zugriff folgt dem Rollenmodell des Mandanten. Owner, Sicherheits-Admin und Mail-Admin dürfen Zugänge einsehen, Zugänge verwalten und die Konfiguration ändern. Die Rolle Auditor darf Zugänge nur einsehen.
Nutzen für Compliance
Werden die Events im eigenen SIEM aufbewahrt und mit anderen Quellen korreliert, stützt das die Nachweispflichten der E-Mail-Sicherheit, unter anderem im Kontext NIS2. Wie die E-Mail-Sicherheit in NIS2 einzuordnen ist, beschreibt NIS2 und E-Mail-Sicherheit.
Weiterführend
Welche Events entstehen, bestimmt der Schutz in MailGuard. Ob ein Verdict beobachtet oder durchgesetzt wird, klärt der Audit- und Enforce-Modus. Zurückgehaltene Nachrichten zeigt die MailGuard-Quarantäne, DLP-Vorfälle stammen aus den DLP-Regeln. Zur Einordnung führen die Produktseite MailGuard und die Lösungsseite SIEM-Export.