SIEM (Security Information and Event Management) ist eine zentrale Sammelstelle für sicherheitsrelevante Ereignisse aus einer IT-Umgebung. Die Plattform zieht Protokolldaten (Logs) aus Servern, Arbeitsplatzrechnern, Netzwerkgeräten, Cloud-Diensten und Anwendungen zusammen, bringt sie in ein einheitliches Format und prüft sie auf verdächtige Muster, etwa einen Login aus einem ungewöhnlichen Land in Kombination mit einem massenhaften Datenabruf. Erkennt das SIEM ein solches Muster, löst es einen Alarm aus und öffnet einen Vorfall (Incident), den das Sicherheitsteam bearbeitet. Der Begriff entstand Mitte der 2000er aus dem Zusammenwachsen von Security Information Management (langfristige Log-Speicherung für Nachweise) und Security Event Management (Echtzeit-Auswertung und Alarmierung).
Was leistet ein SIEM?
Ein SIEM nimmt Protokolldaten aus sehr unterschiedlichen Quellen entgegen: vom klassischen Server-Log (Syslog, Windows Event Log) über Cloud-Audit-Trails und Anwendungs-Logs bis zu Daten aus Endpoint-Schutz-Software (EDR) und aus dem Identity-Provider, also dem System, das Nutzerkonten und Anmeldungen verwaltet. Diese unterschiedlich strukturierten Daten werden in ein gemeinsames Format überführt. Darauf laufen drei Kernaufgaben: die Erkennung von Angriffen über Korrelationsregeln in Echtzeit, die Aufklärung von Vorfällen über Such- und Forensik-Werkzeuge sowie die revisionssichere Aufbewahrung von Logs für Nachweispflichten (etwa ISO 27001, PCI DSS, BSI IT-Grundschutz, DORA).
Typische Marktbeispiele sind Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar und Elastic Security. Die Plattformen unterscheiden sich in Datenmodell, Pricing (Volumen vs. Workload), Erkennungsbibliotheken und Integrationen, teilen aber das Grundmuster: zentrale Aggregation, Korrelation, Alerting, Retention.
Abgrenzung zu Audit Logs, System Tables und SOAR
SIEM wird häufig mit benachbarten Bausteinen vermischt, weil alle drei mit Audit- und Event-Daten arbeiten, aber unterschiedliche Aufgaben erfüllen.
| Begriff | Aufgabe | Abdeckung |
|---|---|---|
| Audit Logs (Plattform-nativ) | Aufzeichnung von Aktionen innerhalb einer Plattform (Login, Query, GRANT, Job-Run) | eine Plattform, oft mit Verzögerung |
| System Tables (Databricks) | abfragbare Tabellen über plattform-eigene Audit- und Usage-Daten | Databricks-Workspace, Mikro-Batch-Latenz |
| SIEM | Aggregation, Korrelation und Alerting über viele Quellen hinweg | gesamte Umgebung, Near-Real-Time |
| SOAR | Automatisierte Reaktion auf erkannte Incidents (Playbooks, Ticketing, Containment) | nachgelagert zum SIEM |
Audit Logs und System Tables liefern den Roh- und Nachvollzugs-Layer einer einzelnen Plattform. Sie eignen sich, um nachträglich zu klären, wer wann welchen GRANT gesetzt oder welche Tabelle abgefragt hat. Für Echtzeit-Erkennung, Cross-System-Korrelation (etwa Login-Anomalie im Identity-Provider in Kombination mit ungewöhnlichem Datenzugriff in Databricks) und 24/7-Alerting fehlen ihnen Korrelations-Engine, Alert-Pipeline und SOC-Anbindung. Diese Lücke schließt ein SIEM. SOAR setzt eine Stufe später an: Sobald das SIEM einen Incident geöffnet hat, übernimmt SOAR die automatisierte Reaktion, etwa das Sperren eines Accounts oder das Erzeugen eines Tickets im ITSM.
SIEM im Databricks-Kontext
In Databricks-Umgebungen wird das SIEM als externer Verbraucher der Plattform-Audit-Daten angebunden. Zwei Wege sind üblich. Erstens der Audit-Log-Export aus den System Tables, insbesondere system.access.audit: Databricks liefert die Logs als Dateien in den konfigurierten Cloud-Storage (S3, Azure Storage, GCS), von wo der SIEM-eigene Forwarder oder Connector sie einliest. Microsoft Sentinel bietet dafür einen Databricks-Connector, Splunk konsumiert die Dateien über den Splunk Add-on for Databricks oder über S3-/Blob-Inputs. Zweitens der API-Pfad, bei dem ein Collector die Audit-Logs über die Databricks-Account-API zieht und an das SIEM weiterleitet.
Für das SIEM-Tuning relevant sind vor allem die Event-Typen aus Unity Catalog (GRANT, REVOKE, Workspace-Assignments, Service-Principal-Aktivität), aus der Workspace-Ebene (Login, Token-Erstellung, Cluster-Konfiguration) und aus Jobs/Pipelines (Failed Runs mit sicherheitsrelevantem Kontext). Auf diesen Events laufen im SIEM die Korrelationsregeln, die etwa massenhafte GRANT-Änderungen ausserhalb von CI/CD, Service-Principal-Logins ausserhalb von Pipeline-Fenstern oder gehäufte Failed-Logins erkennen. Die Plattform-eigenen System Tables bleiben daneben bestehen und werden für Ad-hoc-Audits und Compliance-Reports innerhalb von Databricks genutzt; das SIEM übernimmt die übergreifende Detection und Alarmierung.
SIEM (Security Information and Event Management) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.