Ein SIEM (Security Information and Event Management) sammelt Logdaten aus vielen Quellen zentral, normalisiert sie und korreliert Ereignisse zu Alarmen, die das SOC bearbeitet.
Ein SIEM (Security Information and Event Management) ist die Datendrehscheibe der Verteidigung. Es nimmt Logs und Ereignisse von Servern, Firewalls, Domänencontrollern, Cloud-Diensten und Endpunkt-Agenten entgegen, bringt sie in ein einheitliches Format und wertet sie mit Regeln aus. Treffen mehrere Ereignisse in einem definierten Muster zusammen, etwa eine Anmeldung aus einem ungewöhnlichen Land gefolgt von einer Rechteänderung, entsteht ein Alarm für das SOC.
Neben der Erkennung erfüllt ein SIEM zwei weitere Aufgaben: Es bewahrt Logs revisionssicher für Nachweispflichten auf und dient in der Forensik als Zeitmaschine, um einen Vorfall rückwärts nachzuvollziehen.
So funktioniert ein SIEM
- Sammlung: Agenten, Syslog und APIs liefern Ereignisse; ein Logging-Konzept legt fest, welche Quellen mit welchem Detailgrad angebunden werden.
- Normalisierung: Unterschiedliche Formate werden auf gemeinsame Felder (Benutzer, Quell-IP, Zielsystem, Aktion) abgebildet.
- Anreicherung: Asset-Informationen, Benutzerrollen und IOCs aus Threat-Intelligence-Feeds ergänzen die Rohdaten.
- Korrelation: Regeln, Schwellwerte und zunehmend Verhaltensanalytik (UEBA) erzeugen Alarme.
- Fallbearbeitung: Alarme werden priorisiert, Analysten untersuchen sie und dokumentieren das Ergebnis.
Moderne Plattformen verschmelzen zunehmend mit XDR-Ansätzen, die Telemetrie aus Endpunkt, Identität und Netzwerk herstellerseitig vorkorrelieren.
Bedeutung für Unternehmen
Ein SIEM ist für viele Organisationen Pflicht, etwa über die Anforderungen an Angriffserkennung im BSI-IT-Grundschutz, nach NIS2 oder im Finanzsektor unter DORA. Der häufigste Fehler ist jedoch, die Einführung als abgeschlossen zu betrachten, sobald Daten fließen. Ein SIEM ohne gepflegte Regeln ist ein teurer Logspeicher.
Was wir in Einsätzen sehen: Die relevanten Quellen fehlen. PowerShell-Script-Block-Logging ist nicht aktiviert, Domänencontroller liefern keine Kerberos-Ticket-Ereignisse, Cloud-Audit-Logs sind nicht angebunden. Unsere Angriffsschritte, etwa Kerberoasting oder Lateral Movement über administrative Freigaben, erzeugen dann schlicht keine Ereignisse, die eine Regel treffen könnten. Umgekehrt erzeugen schlecht abgestimmte Regeln so viele Fehlalarme, dass echte Treffer untergehen. Beides fällt erst auf, wenn jemand den Angriff tatsächlich durchführt.
Praxis: Umsetzung und Prüfung
- Quellen nach Angriffspfaden wählen: Leiten Sie die Anbindung aus Ihrem Bedrohungsmodell ab. Domänencontroller, Identitätsprovider, EDR, VPN und E-Mail-Gateway haben Vorrang vor Druckern und Switches.
- Regeln an MITRE ATT&CK ausrichten: Dokumentieren Sie je Technik, ob eine Regel existiert, getestet wurde und wann zuletzt.
- Aufbewahrung festlegen: Bei einer medianen Dwell Time von 14 Tagen (Mandiant M-Trends 2026) reichen wenige Tage Vorhaltung nicht aus, um den Erstzugriff zu rekonstruieren. Planen Sie mehrere Monate ein, für Nachweise länger.
- Regeln gegen echte Technik testen: Im Purple Teaming führen wir eine Technik aus, das Blue Team prüft live, ob das SIEM ein Ereignis, einen Alarm oder gar nichts zeigt, und passt die Regel sofort an.
- Manipulation erschweren: Angreifer löschen Ereignisprotokolle und stoppen Agenten. Ein Alarm auf ausbleibende Logs einer Quelle ist eine der wertvollsten Regeln überhaupt.