Am Anfang jedes SIEM-Projekts steht dieselbe Frage: Was schließen wir an? Und fast immer dieselbe Antwort: erst mal alles, filtern können wir später.
Das ist nachvollziehbar und trotzdem der teuerste Fehler in der Einführungsphase. SIEM-Lizenzen rechnen praktisch durchgehend nach aufgenommenem Datenvolumen ab. Wer alles einsammelt, zahlt für alles: auch für die neunundneunzig Prozent der Zeilen, die im Ernstfall niemand ansieht.
Der brauchbare Maßstab ist nicht Vollständigkeit, sondern Erkennungswert pro Gigabyte.
Die Quellen, mit denen ein Deployment startet
Diese fünf Gruppen binden wir in der Regel an. Sie decken die Wege ab, über die reale Angriffe tatsächlich laufen.
1. Server-Systeme: Windows Event Logs
Die Basis. Anmeldungen, Rechteänderungen, Dienst- und Task-Anlage, Prozessstarts, Zugriffe auf Freigaben.
Was sichtbar wird: Privilege Escalation, laterale Bewegung, persistente Mechanismen. Der Großteil dessen, was ein Angreifer nach dem ersten Zugang tut, hinterlässt hier eine Spur, vorausgesetzt, die Auditierung ist überhaupt eingeschaltet. Das ist regelmäßig der erste Befund eines Deployments: Die Logs, die man einsammeln will, werden auf dem System gar nicht erst erzeugt.
2. EDR-Lösungen
Endpoint Detection and Response sieht, was auf dem Endpunkt passiert, in einer Tiefe, die Betriebssystem-Logs nicht liefern: Prozessbäume, verdächtige Elternprozesse, Speicherzugriffe, blockierte Ausführungen.
Im SIEM wird daraus mehr als eine zweite Konsole. Erst in der Korrelation mit Identity- und Netzwerkdaten ergibt der einzelne Endpunktbefund ein Bild: Derselbe Benutzer, dieselbe Stunde, drei Systeme.
3. Syslog: Firewalls, Netzwerk- und Security-Devices
Verbindungsdaten, geblockte und erlaubte Sessions, VPN-Einwahlen, Änderungen an Regelwerken.
Was sichtbar wird: Command-and-Control-Kommunikation, Datenabfluss, Zugriffe aus unerwarteten Netzen und Geografien und Konfigurationsänderungen an genau den Geräten, die den Perimeter durchsetzen sollen.
4. Microsoft 365
Anmeldungen und deren Bedingungen, MFA-Ereignisse, Rollen- und Berechtigungsänderungen, Postfachregeln, Freigaben, administrative Aktionen.
Diese Quelle hat in den letzten Jahren an Bedeutung gewonnen wie keine zweite: dazu gleich mehr.
5. Weitere Cloud-Dienste
Alles, was geschäftskritisch ist und eine Audit-Schnittstelle hat. Backup-Systeme gehören ausdrücklich dazu: Wer Ransomware ernst nimmt, muss sehen, wenn jemand Aufbewahrungsfristen verkürzt, Jobs deaktiviert oder Wiederherstellungspunkte löscht. Diese Aktionen sind kein Nebenschauplatz, sondern typischerweise die Vorbereitung des eigentlichen Schadens.
Warum Identity heute zuerst kommt
Wenn Sie die Reihenfolge nach Wirkung statt nach Aufwand priorisieren, steht Identity vorn.
Der klassische Angriff platzierte Schadcode auf einem Endpunkt. Der heute häufigere Angriff meldet sich einfach an. Kompromittierte Zugangsdaten, ein umgangener oder ermüdeter zweiter Faktor, danach Zugriff auf Postfächer, Dateiablagen und verbundene Dienste: ohne dass jemals Code auf einem Endpoint landet.
Ein EDR sieht davon nichts, weil es nichts zu sehen gibt. Sichtbar wird so ein Verlauf ausschließlich in Anmelde- und Aktivitätsdaten: eine Anmeldung aus einem unerwarteten Land, eine neu angelegte Postfach-Weiterleitung, ein Berechtigungssprung, eine Massenfreigabe.
Genau deshalb ist ein rein endpunktzentriertes Detection-Setup unvollständig, egal wie gut das eingesetzte EDR ist.
Die entscheidende Frage: Lässt sich darauf überhaupt eine Regel schreiben?
Es gibt immer Quellen, für die sich nur schwer sinnvolle Detection-Regeln formulieren lassen. Entweder weil das Format zu unstrukturiert ist, weil das Ereignis keinen Angreiferkontext trägt, oder weil sich normales von auffälligem Verhalten schlicht nicht trennen lässt.
Unser Maßstab dafür ist einfach: Wenn sich auf eine Quelle keine belastbare Regel schreiben lässt, muss sie nicht zwingend in die Detection-Schicht. Es sei denn, sie soll aus Compliance-Gründen über einen längeren Zeitraum aufbewahrt werden. Dann gehört sie ins Archiv, nicht in die Korrelation.
Diese Unterscheidung ist wichtiger, als sie klingt. Sie trennt zwei völlig verschiedene Zwecke, die regelmäßig vermischt werden:
| Detection-Schicht | Archiv | |
|---|---|---|
| Zweck | Angriffe erkennen | Nachweisen und rekonstruieren |
| Auswahlkriterium | Lässt sich eine Regel schreiben? | Besteht eine Aufbewahrungspflicht? |
| Kosten | hoch, volumenabhängig | gering |
| Zugriff | in Echtzeit korreliert | bei Bedarf durchsuchbar |
Typische Kandidaten für das Archiv statt für die Korrelation:
- Verbose Applikations- und Debug-Logs. Wertvoll für die Fehlersuche und für die Rekonstruktion nach einem Vorfall, fast nie Grundlage einer Detection-Regel.
- Health-Checks und Load-Balancer-Zeilen im Sekundentakt. Hohes Volumen, konstanter Inhalt, kein Angreiferkontext.
- Redundante Weiterleitungen. Dieselben Ereignisse zweimal, weil zwei Systeme sie melden.
Der Umgang damit heißt also nicht „weglassen“, sondern richtig einsortieren. Beides ist notwendig. Beides muss nicht dasselbe kosten.
Der Fehler in beide Richtungen kostet: Wer alles in die Detection-Schicht schiebt, zahlt für Korrelation, die nie stattfindet. Wer eine Quelle ganz weglässt, weil sich keine Regel dafür schreiben lässt, stellt womöglich fest, dass genau diese Daten in einer Untersuchung oder gegenüber einer Aufsicht gebraucht worden wären.
Detection-Schicht
Aufnahme in die Korrelation. Echtzeit-Auswertung, Alerting, Tuning. Teuer, weil volumenabhängig abgerechnet und diese Kosten sind gerechtfertigt, weil sie Erkennung erzeugen.
Weiter zu Frage 2
Kein Ausschluss, sondern eine zweite Prüfung. Fehlende Regelbarkeit heißt nicht, dass die Daten wertlos sind: nur, dass sie keinen Alarm erzeugen werden.
Archiv
Günstiger Speicher, bei Bedarf durchsuchbar. Zweck ist Nachweis und Rekonstruktion, nicht Erkennung. Aufbewahrungsdauer richtet sich nach der Pflicht, nicht nach dem Detection-Bedarf.
Nicht aufnehmen
Weder Erkennungswert noch Nachweispflicht. Diese Quelle erzeugt Kosten und Rauschen, aber keinen Nutzen. Sie gehört bewusst nicht in den Scope.
↻Die Entscheidung ist nicht endgültig. Neue Angriffsmuster machen Quellen regelbar, die es vorher nicht waren, und geänderte Nachweispflichten verschieben die zweite Frage. Beide Fragen gehören in die regelmäßige Überprüfung des Scope.
Retention: 90 Tage als Ausgangspunkt
In unseren Engagements liegt die Standard-Aufbewahrung bei 90 Tagen, bei Bedarf deutlich mehr.
90 Tage sind kein Zufallswert. Die entscheidende Größe ist die Zeit zwischen Erstzugang und Entdeckung und die wird in der Praxis regelmäßig in Wochen gemessen, nicht in Stunden. Wenn eine Untersuchung im Dezember beginnt und der Erstzugang im Oktober lag, entscheidet die Retention darüber, ob Sie den Verlauf rekonstruieren können oder raten müssen. Logdaten, die zum Untersuchungszeitpunkt bereits gelöscht sind, kann niemand nachliefern.
Mehr als 90 Tage sind sinnvoll, wenn:
- regulatorische Nachweispflichten längere Zeiträume verlangen,
- Sie Angriffsmuster über längere Zeiträume hinweg auswerten wollen,
- oder Ihre Branche mit langlaufenden, leisen Kampagnen rechnen muss.
Für regulierte Unternehmen kommt ein Zeitfaktor von der anderen Seite dazu: NIS2 verlangt eine Frühwarnung binnen 24 Stunden und eine Vorfallsmeldung binnen 72 Stunden und beide müssen inhaltlich belastbar sein. Belastbar heißt: Evidenz aus Logdaten, die noch existieren. Welche Anforderungen aus NIS2 und DORA durch welche Leistung abgedeckt sind, steht unter NIS2 & DORA.
Welche Plattform
Sumo Logic ist unsere primäre Plattform. Wir sind aber nicht auf sie festgelegt und arbeiten ebenso auf anderen Stacks (etwa CrowdStrike), wenn beim Kunden bereits eine Investition besteht oder aus anderen Gründen dafürspricht.
Diese Offenheit ist keine Nebensächlichkeit. Wer eine funktionierende Plattform ablösen soll, nur weil der Dienstleister nur eine bedienen kann, zahlt eine Migration für einen Nutzen, der beim Dienstleister anfällt und nicht bei ihm.
Die gefährlichste Quelle ist die, von der niemand erzählt hat
Zum Schluss der Punkt, der im Betrieb mehr Schaden anrichtet als jede falsch getunte Regel.
Ein SIEM erkennt nichts auf Systemen, die es nicht kennt. Ein Server, der seit drei Monaten produktiv läuft und in keiner Ingestion-Konfiguration auftaucht, erzeugt keine Alarme und auch keine Fehlermeldung. Er ist einfach unsichtbar. Dasselbe gilt für ein neues Netzsegment, einen zusätzlichen Cloud-Dienst oder eine migrierte Workload.
Deshalb ist die laufende Meldung von Veränderungen im Scope keine Formalie, sondern eine echte Betriebspflicht auf Kundenseite. Wie wir diese Aufgabenteilung konkret regeln, steht in Co-Managed SIEM: Wer macht was.
Fazit
Die Frage ist nicht, wie viele Quellen Sie anschließen, sondern welche und in welcher Reihenfolge. Server-Logs, EDR, Netzwerk- und Security-Devices, Microsoft 365 und geschäftskritische Cloud-Dienste decken die Wege ab, über die reale Angriffe laufen. Identity gehört dabei nach vorn, weil sich moderne Angreifer häufiger anmelden als einbrechen.
Und die beste Quellenauswahl nützt nichts, wenn die Aufbewahrung zu kurz ist, um den Verlauf zu rekonstruieren, oder wenn ganze Systeme dem SIEM nie gemeldet wurden. Erkennung ist eine Betriebsdisziplin, kein Beschaffungsvorgang.