Kurzfassung: Ein SIEM sammelt die Logs aller Systeme an einer Stelle, normalisiert sie, speichert sie durchsuchbar und wendet Regeln an, die bei verdächtigen Mustern Alarm schlagen. Es verhindert nichts und reagiert nicht von selbst; sein Wert entsteht aus den richtigen Logquellen, laufend gepflegten Regeln und Menschen, die die Alarme bearbeiten. Die Kosten hängen am Datenvolumen pro Tag, deshalb entscheidet die Auswahl der Quellen über Preis und Nutzen zugleich.
Ein SIEM ist das Gedächtnis und das Frühwarnsystem eines Blue Teams: Es sammelt die Logdaten aus der gesamten IT an einer Stelle, macht sie durchsuchbar und schlägt Alarm, wenn Muster auftauchen, die auf einen Angriff hindeuten. Gleichzeitig ist kaum ein Sicherheitswerkzeug so oft gekauft und so selten richtig betrieben worden. In diesem Beitrag erfährst du, was ein SIEM tatsächlich tut, wo seine Grenzen liegen, welche Logquellen zuerst angebunden gehören und worauf es bei der Einführung ankommt, damit aus dem Werkzeug keine teure Logablage wird.
Was ein SIEM ist und was nicht
SIEM steht für Security Information and Event Management. Der Begriff fasst zwei ältere Produktklassen zusammen: das Sammeln und Aufbewahren von Logs für Nachweise und Analysen (Security Information Management) und die Echtzeit-Korrelation von Ereignissen für Alarme (Security Event Management). Ein SIEM macht heute beides: Es nimmt Logs aus Servern, Endgeräten, Firewalls, Identitätsdiensten und Cloud-Plattformen entgegen, bringt sie in ein einheitliches Format, speichert sie für Monate und wendet Regeln darauf an, die bei bestimmten Kombinationen einen Alarm erzeugen.
Genauso wichtig ist, was ein SIEM nicht ist. Es verhindert keine Angriffe, das tun Firewalls, EDR und saubere Konfiguration. Es reagiert nicht von selbst, das tun Menschen oder eine angebundene Automatisierung. Und es sieht nur, was ihm geliefert wird. Ein SIEM ohne die richtigen Logquellen ist ein Fernglas mit Deckel.
Wie ein SIEM arbeitet
Der Weg eines Ereignisses durch ein SIEM sieht bei allen Produkten ähnlich aus:
- Sammeln. Agenten auf Endgeräten, Syslog von Netzwerkgeräten, API-Abfragen bei Cloud-Diensten. Jede Quelle liefert in ihrem eigenen Format.
- Normalisieren. Das SIEM zerlegt jede Zeile in Felder: Zeitstempel, Quelle, Benutzer, Ziel, Aktion, Ergebnis. Erst danach lässt sich ein Windows-Login mit einem VPN-Login vergleichen.
- Speichern. Die Daten landen in einem durchsuchbaren Speicher. Wie lange, entscheidet die Aufbewahrungsfrist, und die entscheidet über die Kosten.
- Korrelieren. Regeln prüfen laufend, ob Ereignisse zusammen ein Muster ergeben. Ein Beispiel: fünf fehlgeschlagene Anmeldungen und eine erfolgreiche innerhalb von zehn Minuten von derselben Adresse. Jede Zeile für sich ist harmlos, die Kombination nicht.
- Alarmieren. Trifft eine Regel, entsteht ein Alarm mit Schweregrad, der in der Warteschlange des Security Operations Center landet.
Die Regeln sind das eigentliche Kapital eines SIEM. Früher schrieb jedes Team sie in der Abfragesprache seines Herstellers, heute gibt es mit Sigma ein offenes, herstellerneutrales Format, in dem tausende Erkennungsregeln der Community vorliegen und sich in die Sprache des jeweiligen SIEM übersetzen lassen. Wer heute ein SIEM aufbaut, fängt damit nicht bei null an.
Was ein SIEM kann
- Zusammenhänge sichtbar machen. Der Login auf dem Domain Controller, die neue Verbindung vom Fileserver nach außen und der Alarm des Virenscanners auf einem Client gehören zu einem Vorfall. Ohne zentrale Stelle sieht das niemand.
- Zeitlinien bauen. Im Vorfall ist die erste Frage: Was ist wann in welcher Reihenfolge passiert? Mit durchsuchbaren Logs aus allen Quellen lässt sich das in Stunden beantworten statt in Wochen.
- Erkennung skalieren. Eine Regel, einmal geschrieben, prüft jede Nacht tausende Systeme, ohne dass jemand hinsieht.
- Nachweise liefern. Wer nach NIS2, ISO 27001 oder gegenüber Versicherern belegen muss, dass sicherheitsrelevante Ereignisse protokolliert und ausgewertet werden, braucht genau das.
Was ein SIEM nicht kann
- Erkennen, was nicht geloggt wird. Fehlt der Domain Controller, fehlt die Hälfte aller Angriffswege.
- Sofort funktionieren. Mitgelieferte Regeln erzeugen in jeder Umgebung erst einmal Fehlalarme. Jede Regel muss an das angepasst werden, was in deinem Netz normal ist, und das ist dauerhafte Arbeit, kein Projekt. Was passiert, wenn das unterbleibt, beschreibt der Beitrag zu Alert Fatigue.
- Analysten ersetzen. Ein Alarm ist eine Frage, keine Antwort. Jemand muss sie beantworten.
- Beliebig wachsen. Die meisten Hersteller rechnen nach Datenvolumen pro Tag ab. Wer alles einsammelt, zahlt für Debug-Logs, die nie jemand anschaut.
Das BSI bringt diesen Punkt in seinem Mindeststandard auf eine Formel, die für jede Organisation gilt: Mehr Datenquellen oder mehr Detektoren erhöhen das Sicherheitsniveau nicht automatisch. Entscheidend ist, die richtigen Quellen für die wichtigen Bereiche zu wählen.
Welche Logquellen zuerst
Die Reihenfolge richtet sich danach, welche Quellen die meisten Angriffstechniken sichtbar machen. Für eine typische Windows-Umgebung mit Cloud-Anteil sieht die Priorisierung so aus:
| Quelle | Was du damit siehst | Priorität |
|---|---|---|
| Domain Controller (Security-Log) | Anmeldungen, Kontoerstellung, Gruppenänderungen, Kerberos-Tickets: fast jede Bewegung eines Angreifers im Netz | 1 |
| Endgeräte (EDR oder Sysmon) | Prozessstarts, Befehlszeilen, Netzwerkverbindungen pro Prozess, Dateiänderungen | 1 |
| Identitätsdienst in der Cloud (z. B. Entra ID) | Cloud-Anmeldungen, MFA-Ergebnisse, Anmeldungen aus ungewohnten Regionen, App-Berechtigungen | 1 |
| Firewall und Proxy | Verbindungen nach außen, Command-and-Control-Verkehr, Datenabfluss | 2 |
| DNS | Anfragen an neu registrierte oder bekannte bösartige Domains, DNS-Tunneling | 2 |
| Mail-Gateway | Phishing-Wellen, Anhänge, Absender-Spoofing | 2 |
| VPN und Remote-Zugang | Wer kommt von wo ins Netz, und passt das zum üblichen Verhalten? | 2 |
| Server-Anwendungen, Datenbanken, Webserver | Zugriffe auf die Kronjuwelen, Fehlermuster, Web-Angriffe | 3 |
Wer sich an einem formalen Rahmen orientieren will: Der Mindeststandard des BSI zur Protokollierung und Detektion von Cyberangriffen ist für die Bundesverwaltung verbindlich, beschreibt aber ein Vorgehen zur Auswahl von Logquellen und Detektoren, das sich eins zu eins auf Unternehmen übertragen lässt.
Volumen und Kosten: die Rechnung vor dem Kauf
Fast alle Hersteller rechnen nach Datenvolumen pro Tag ab, manche nach Ereignissen pro Sekunde oder nach Anzahl der Systeme; in jedem Fall bestimmt die Menge der Logs den Preis. Wer vor der Produktauswahl nicht weiß, wie viel er erzeugen wird, kauft blind. Die folgenden Werte sind Größenordnungen aus der Praxis und hängen stark von Konfiguration und Nutzung ab; vor dem Kauf misst man sie mit einem Piloten über zwei Wochen.
| Quelle | Größenordnung | Was das Volumen treibt |
|---|---|---|
| Windows-Client mit Sysmon | 5 bis 20 MB pro Gerät und Tag | Die Sysmon-Konfiguration; Netzwerkverbindungen und Datei-Ereignisse ohne Filter vervielfachen die Menge |
| Domain Controller | 0,5 bis 2 GB pro DC und Tag | Kerberos-Ticket-Ereignisse und Objektzugriffe; die Überwachungsrichtlinie entscheidet |
| Windows-Server | 50 bis 300 MB pro Server und Tag | Rolle des Servers; Fileserver mit Objektzugriffs-Audit liegen deutlich darüber |
| Linux-Server mit auditd | 50 bis 500 MB pro Server und Tag | Die Audit-Regeln; Syscall-Protokollierung ohne Filter ist der häufigste Ausreißer |
| Firewall und Proxy | 1 bis 5 GB pro 1.000 Nutzer und Tag | Ob jede Verbindung oder nur Verbindungsaufbau und -ende protokolliert wird |
| DNS-Server | 0,5 bis 2 GB pro 1.000 Nutzer und Tag | Antworten mitloggen verdoppelt, ist aber für die Analyse wertvoll |
| Cloud-Identitätsdienst | Einige hundert MB pro Tag | Anmeldungen und Audit-Ereignisse, klein im Volumen, hoch im Wert |
| Mail-Gateway | 100 bis 500 MB pro Tag | Ob Metadaten oder vollständige Nachrichtenverfolgung geliefert werden |
Ein Beispiel für eine Organisation mit 500 Arbeitsplätzen, drei Domain Controllern, 40 Servern und einem Internet-übergang: Clients rund 5 GB, Domain Controller rund 3 GB, Server rund 6 GB, Firewall und Proxy rund 2 GB, DNS rund 1 GB, Cloud-Identität und Mail zusammen unter 1 GB. Das ergibt etwa 18 GB pro Tag und bei 90 Tagen schneller Aufbewahrung rund 1,6 TB durchsuchbare Daten, dazu ein Jahr kalter Speicher für Nachweise. Mit dieser Zahl lässt sich jedes Angebot vergleichen, und sie zeigt den größten Hebel: die Filterung vor dem SIEM. Sysmon mit einer gepflegten Konfiguration statt Vollprotokollierung, Firewall-Logs ohne die erlaubten Verbindungen zwischen internen Netzen, keine Debug-Logs, keine Erfolgsmeldungen von Backup-Jobs. Wer die zehn lautesten und wertlosesten Ereignistypen vor dem Import verwirft, halbiert das Volumen, ohne eine einzige Erkennung zu verlieren. Die Faustregel für die Gesamtkosten über drei Jahre: Lizenz und Speicher sind selten mehr als ein Drittel, der Rest ist die Arbeitszeit für Anbindung, Tuning und Bearbeitung der Alarme.
SIEM-Lösungen im Überblick
Der Markt teilt sich grob in drei Gruppen. Die großen kommerziellen Plattformen, etwa Splunk, Microsoft Sentinel, IBM QRadar, Google SecOps oder Elastic Security, unterscheiden sich weniger in der Erkennung als in Preismodell, Abfragesprache und Ökosystem. Microsoft Sentinel liegt für Organisationen mit Microsoft-365-Umgebung nahe, weil die Quellen ohne Umwege anzubinden sind. Splunk ist die Referenz für Abfragen und Flexibilität, mit entsprechendem Preis. Daneben stehen Open-Source-Lösungen wie Wazuh oder der Elastic-Stack in der freien Variante, die für kleine Umgebungen und Homelabs ausreichen und im Betrieb vor allem Zeit statt Lizenzgeld kosten. Und drittens das SIEM als Dienstleistung: Ein MSSP betreibt die Plattform, du lieferst die Logs.
Welche Gruppe passt, entscheidet nicht die Funktionsliste, sondern die Frage, wer die Alarme bearbeitet. Ein SIEM, in das niemand hineinschaut, ist in jeder Preisklasse verschwendet.
Worauf es bei der Einführung ankommt
- Use Cases vor Werkzeug. Schreib auf, welche zehn Angriffe du erkennen willst, bevor du ein Produkt auswählst. Kompromittierte Zugangsdaten, Ransomware-Vorbereitung, Datenabfluss, ein neuer Domain-Admin. Daraus ergeben sich die Logquellen, und aus den Logquellen das Datenvolumen.
- Quellen schrittweise anbinden. Erst die Priorität-1-Quellen, dann Regeln darauf, dann Tuning, dann die nächste Gruppe. Wer alles auf einmal anbindet, ertrinkt am ersten Tag.
- Zeit für Tuning einplanen. Rechne mit dauerhaft mehreren Stunden pro Woche für das Nachschärfen von Regeln. Das ist die Arbeit, die aus einem SIEM eine Erkennung macht.
- Klären, wer hinschaut. Eigenes Team, MSSP oder hybrid, in jedem Fall mit Erreichbarkeit außerhalb der Bürozeiten. Angreifer arbeiten bevorzugt freitagabends.
- Datenschutz und Mitbestimmung früh einbinden. Logs enthalten personenbezogene Daten. In Deutschland ist die Auswertung von Mitarbeiterdaten über eine technische Einrichtung mitbestimmungspflichtig; Betriebsrat und Datenschutzbeauftragte gehören deshalb an den Tisch, bevor die erste Quelle angebunden wird, nicht danach.
- Aufbewahrung festlegen. Wie lange Logs vorgehalten werden, bestimmt Kosten und Ermittlungsfähigkeit. Angriffe werden oft erst nach Wochen entdeckt; wer nur 30 Tage speichert, kann den Anfang nicht mehr rekonstruieren.
- Erkennung testen. Ob eine Regel greift, weißt du erst, wenn du die Technik ausführst. Purple-Team-Übungen sind der schnellste Weg, ein neues SIEM von der Theorie in die Praxis zu holen.
Fünf Use-Cases mit Regelskizze
Use-Cases sind die Übersetzung von „ich will Angriffe erkennen“ in Regeln, die ein SIEM ausführen kann. Fünf, mit denen fast jede Organisation anfangen sollte, weil sie die häufigsten Angriffswege abdecken und nur Priorität-1-Quellen brauchen:
| Use-Case | Logquelle | Regelskizze | Tuning gegen Fehlalarme |
|---|---|---|---|
| Password Spraying | Domain Controller (4625, 4771), Cloud-Anmeldeprotokoll | Mehr als 20 verschiedene Konten mit fehlgeschlagener Anmeldung von derselben Quelladresse innerhalb von zehn Minuten | Schwachstellenscanner, VPN-Gateways und Proxys ausnehmen, die viele Benutzer hinter einer Adresse bündeln |
| Neuer privilegierter Benutzer | Domain Controller (4728, 4732, 4756) | Jede Aufnahme in Domain-Admins, Enterprise-Admins, Schema-Admins oder lokale Administratoren auf Servern | Kein Tuning: Diese Regel darf laut sein. Stattdessen Abgleich mit dem Change-Ticket als Bearbeitungsschritt |
| Verschleierte PowerShell | Endgeräte (4104 Script Block, 4688 oder Sysmon 1) | Befehlszeile mit -enc oder -EncodedCommand, oder Skriptblock mit FromBase64String, IEX und DownloadString in Kombination | Bekannte Verwaltungsskripte nach Pfad und Signatur ausnehmen, nicht nach Benutzer |
| Beaconing | Proxy oder Firewall | Ein interner Host verbindet sich über Stunden in gleichmäßigen Abständen mit derselben externen Adresse, geringe Streuung der Intervalle, kleine Datenmengen | Update-Dienste, Telemetrie und Monitoring-Ziele auf eine Erlaubnisliste, die regelmäßig geprüft wird |
| Datenabfluss | Proxy oder Firewall, Cloud-Audit | Ausgehendes Volumen eines Hosts pro Stunde übersteigt das Fünffache seines Durchschnitts, Ziel außerhalb der Erlaubnisliste oder ein Cloud-Speicher, den die Organisation nicht nutzt | Backup-Ziele, Sync-Clients und Videokonferenz-Dienste ausnehmen; Schwelle pro Systemklasse statt global |
Zu jedem dieser Use-Cases gibt es fertige Sigma-Regeln aus der Community, die den Einstieg abkürzen; der Tuning-Teil bleibt trotzdem eigene Arbeit, weil er von der Umgebung abhängt. Wie eine solche Erkennung im Detail gebaut wird, zeigt die Serie „Angriff erkennen“, beginnend mit Kerberoasting erkennen. Wie stark Korrelation über Quellen hinweg ist, zeigt das E-Mail-Bombing: Die Mailspitze aus dem Mail-Gateway und der Start von Quick Assist am Endpunkt sind einzeln laut, zusammen beim selben Benutzer fast eindeutig. Und zu jedem gibt es einen Test: Password Spraying lässt sich im Homelab in fünf Minuten nachstellen, eine Base64-kodierte PowerShell in einer. Eine Regel, die noch nie durch einen Test ausgelöst wurde, ist eine Vermutung.
SIEM, EDR, XDR und NDR: eine kurze Einordnung
EDR sieht tief in den einzelnen Endpunkt und kann dort eingreifen. NDR sieht den Netzwerkverkehr, auch von Geräten ohne Agent. XDR ist das Versprechen eines Herstellers, mehrere seiner Quellen unter einer Oberfläche zu korrelieren. Das SIEM ist die Ebene darüber: herstellerunabhängig, mit allen Quellen, mit langem Gedächtnis. In der Praxis ergänzen sie sich, das SIEM ersetzt keines davon und wird von keinem ersetzt. Was ein Blue Team davon braucht, hängt von Größe, Umgebung und Budget ab; die ausführliche Abgrenzung steht im Beitrag EDR, XDR, NDR: Abgrenzung, Einsatz und was wirklich zusammengehört.
Häufige Fragen zum SIEM
Was ist der Unterschied zwischen SIEM und Logmanagement?
Logmanagement sammelt, speichert und macht durchsuchbar. Ein SIEM tut das auch und wendet zusätzlich Regeln an, die in Echtzeit Alarme erzeugen, korreliert Ereignisse über Quellen hinweg und reichert sie mit Kontext wie Threat Intelligence an. Viele Organisationen fangen mit Logmanagement an und merken beim ersten Vorfall, dass ihnen die Alarme fehlen.
Wie lange sollten Logs aufbewahrt werden?
Mindestens 90 Tage schnell durchsuchbar, weil Angriffe oft erst nach Wochen entdeckt werden und der Anfang rekonstruierbar bleiben muss. Ein Jahr in günstigem Kaltspeicher für Nachweise und späte Untersuchungen. Regulierte Branchen und Versicherungsverträge können längere Fristen verlangen, der Datenschutz verlangt umgekehrt eine Begründung für jede Frist.
Was kostet ein SIEM?
Die Lizenz hängt am Datenvolumen pro Tag und reicht von null bei Open-Source-Lösungen bis zu sechsstelligen Jahresbeträgen bei großen Umgebungen. Die eigentlichen Kosten sind die Arbeitszeit: Anbindung der Quellen, Regelpflege und die Bearbeitung der Alarme, rund um die Uhr, wenn es ernst gemeint ist. Wer nur die Lizenz budgetiert, hat zwei Drittel der Kosten übersehen.
Cloud-SIEM oder eigener Betrieb?
Ein SIEM aus der Cloud spart den Betrieb der Plattform, skaliert mit dem Volumen und liegt bei Cloud-lastigen Umgebungen nahe. Eigener Betrieb lohnt sich bei sehr hohem Volumen, bei Vorgaben zur Datenhaltung oder wenn das Team die Plattform ohnehin beherrscht. Die Erkennung ist bei beiden gleich gut oder gleich schlecht; sie hängt an Quellen und Regeln, nicht am Standort.
Reicht ein Open-Source-SIEM wie Wazuh?
Für kleine und mittlere Umgebungen mit einem Team, das den Betrieb übernimmt, ja. Die Grenzen liegen bei komplexer Korrelation über viele Quellen, bei der Skalierung und beim Fallmanagement, das dazugebaut werden muss. Was das konkret bedeutet, steht im Beitrag zu Wazuh.
Wie lange dauert es, bis ein SIEM etwas erkennt?
Die ersten Alarme kommen am ersten Tag, die ersten brauchbaren nach Wochen. Realistisch sind drei bis sechs Monate, bis die Priorität-1-Quellen angebunden, die wichtigsten Use-Cases umgesetzt und die Regeln so weit abgestimmt sind, dass das Team den Alarmen vertraut. Wer das kürzer plant, plant das Tuning nicht ein.
Fazit
Ein SIEM ist die zentrale Sicht auf alles, was in deiner IT passiert, und die Grundlage jeder Erkennung, die über einen einzelnen Endpunkt hinausgeht. Es funktioniert aber nur mit drei Dingen, die kein Hersteller mitliefert: den richtigen Logquellen, laufend gepflegten Regeln und Menschen, die die Alarme bearbeiten. Wer diese drei einplant, bekommt ein Frühwarnsystem. Wer nur das Werkzeug kauft, bekommt eine Rechnung für Speicherplatz.