Log-Management und Aufbewahrung: Fristen, Kosten, Manipulationsschutz

Log-Management und Aufbewahrung ist das Thema, das in fast jedem Beitrag dieser Seite als Nebensatz auftaucht, „das gehört ins SIEM“, und das doch eine eigene Betrachtung verdient, weil an ihm die Wirtschaftlichkeit und die forensische Tauglichkeit einer ganzen Erkennungsstrategie hängen. Zu wenig Aufbewahrung, und der Angriff, der erst nach Monaten auffällt, lässt sich nicht mehr rekonstruieren. Zu viel vom Falschen, und das Budget ist verbraucht, bevor die erste Regel greift. Ungeschützte Logs, und der Angreifer löscht die Spuren, bevor jemand hinsieht. Dieser Beitrag behandelt die drei Entscheidungen, die jedes Blue Team treffen muss: was aufbewahrt wird und wie lange, wie man die Kosten über Speicherstufen im Griff behält, und wie man Logs manipulationssicher macht. Dazu die gesetzlichen Fristen, die den Rahmen setzen.

Wie lange, und warum diese Dauer

Die Aufbewahrungsdauer ergibt sich aus zwei Anforderungen, die sich überlagern. Die erste ist forensisch: Angreifer sind oft länger im Netz, als man denkt (diese Verweildauer messbar zu machen, behandelt der Beitrag zu Dwell Time und SOC-Kennzahlen), bevor sie entdeckt werden, und wenn die Logs aus der Zeit des Einbruchs bereits überschrieben sind, lässt sich der Vorfall nicht mehr vollständig aufklären. Als praktischer Richtwert haben sich mindestens 90 Tage für die volle Durchsuchbarkeit und mindestens ein Jahr für die Archivierung etabliert; für Umgebungen mit erhöhtem Risiko oder langer Angreiferverweildauer entsprechend länger. Die zweite Anforderung ist rechtlich: Verschiedene Regelwerke schreiben Aufbewahrungsfristen vor. Die Details hängen von Branche und Rechtsrahmen ab und gehören mit der Rechts- oder Datenschutzabteilung geklärt, nicht allein in der IT entschieden; als Orientierung dienen die Vorgaben aus NIS2 und dem BSI-Grundschutz, sektorspezifische Regeln etwa im Finanzbereich, und bei personenbezogenen Logdaten die datenschutzrechtliche Pflicht, nicht länger als nötig aufzubewahren. Diese beiden Anforderungen ziehen in unterschiedliche Richtungen: Die Forensik will lange aufbewahren, der Datenschutz will löschen. Die Auflösung liegt in der Differenzierung, welche Logs wie lange gebraucht werden, und genau dazu dienen die Speicherstufen.

Speicher in Stufen: heiß, warm, kalt

Der teuerste Fehler ist, alle Logs gleich zu behandeln: alles sofort durchsuchbar, alles gleich lange, alles auf dem schnellen Speicher. Das treibt die Kosten, ohne den Nutzen entsprechend zu erhöhen. Die Lösung ist ein Stufenmodell, das die Zugriffsgeschwindigkeit an den tatsächlichen Bedarf koppelt.

Stufe	Zeitraum	Zugriff	Zweck
Heiß	etwa 7 bis 30 Tage	Sofort durchsuchbar, im SIEM	Alarmierung, laufende Analyse, aktuelle Vorfälle
Warm	etwa 30 bis 90 Tage	Durchsuchbar, aber langsamer und günstiger	Rückwärtssuche bei neu bekannt gewordenen Indikatoren, Threat Hunting
Kalt	1 Jahr und länger	Archiviert, nicht direkt durchsuchbar, muss zurückgeholt werden	Forensik alter Vorfälle, gesetzliche Aufbewahrung, Nachweis

Der Gedanke: Die volle, teure Durchsuchbarkeit braucht man nur für die jüngste Vergangenheit, in der die meiste Analyse stattfindet. Ältere Daten müssen vorhanden und wiederherstellbar sein, aber nicht sofort im schnellen Zugriff. Ein günstiger Archivspeicher, aus dem sich Daten bei Bedarf zurückholen lassen, kostet einen Bruchteil des durchsuchbaren Speichers und erfüllt die Forensik- und Nachweispflicht trotzdem. Wichtig ist, dass die Rückwärtssuche funktioniert: Wird ein Indikator aus der Threat Intelligence heute bekannt, muss sich prüfen lassen, ob er in den letzten Monaten schon auftrat, und dafür reicht die warme Stufe.

Was aufbewahren, und was nicht

Nicht jedes Log ist gleich wertvoll, und das Budget entscheidet sich an der Auswahl. Die Quellen mit der höchsten forensischen Aussagekraft gehören in die volle Aufbewahrung: die Anmelde- und Kontoereignisse, die Prozessdaten mit Befehlszeile, die Kerberos- und Replikationsereignisse, die Verbindungsprotokolle aus Zeek, die Cloud-Control-Plane-Protokolle aus dem Beitrag zur Cloud-Sicherheit. Sehr gesprächige, aber wenig aussagekräftige Quellen, etwa jede einzelne erlaubte Firewall-Verbindung oder Debug-Logs von Anwendungen, treiben das Volumen, ohne im Vorfall viel beizutragen; sie werden gefiltert, aggregiert oder kürzer aufbewahrt. Die Auswahl ist dieselbe Disziplin wie bei der Regel-Hygiene aus dem Beitrag zur Alert Fatigue: Mehr Daten erhöhen das Sicherheitsniveau nicht automatisch, die Auswahl tut es. Ein Grundsatz aus dem BSI-Umfeld bringt es auf den Punkt: Entscheidend ist nicht die Menge der Quellen, sondern welche man anbindet und wie lange man sie hält.

Logs vor Manipulation schützen

Die erste Handlung vieler Angreifer nach der Übernahme eines Systems ist, die Protokolle zu löschen oder die Protokollierung abzuschalten. Ein Log, das lokal auf dem kompromittierten System liegt, ist deshalb im Vorfall wertlos, weil der Angreifer es kontrolliert. Der Schutz ruht auf mehreren Prinzipien.

• Sofort wegschicken. Logs müssen so schnell wie möglich vom erzeugenden System weg an einen zentralen, geschützten Ort, per Agent oder Weiterleitung. Was schon auf dem SIEM liegt, bevor der Angreifer löscht, ist gerettet. Das lokale Eventlog ist oft nach einem Tag überschrieben, wie im Beitrag zur Event-ID-Referenz beschrieben.
• Nur anhängen, nicht ändern. Der zentrale Logspeicher sollte so konfiguriert sein, dass Einträge nur hinzugefügt, aber nicht nachträglich geändert oder gelöscht werden können (WORM, Write Once Read Many). Das verhindert, dass ein Angreifer, der bis zum SIEM vordringt, dort aufräumt.
• Getrennte Rechte. Wer die überwachten Systeme administriert, sollte nicht zugleich die Logs löschen dürfen. Die Trennung von Administration und Logspeicher ist dieselbe Idee wie die Tiered Administration aus dem Beitrag zur Active-Directory-Härtung.
• Auf das Löschen alarmieren. Das Löschen des Sicherheitsprotokolls (Event 1102), das Ändern der Überwachungsrichtlinie und in der Cloud das Stoppen der Protokollierung sind sofortige Alarme, weil sie fast nie einen legitimen Grund haben und ein starkes Zeichen für einen laufenden Angriff sind.
• Integrität nachweisen. Wo Logs als Beweismittel dienen könnten, sichert ein Verfahren zur Integritätsprüfung, etwa kryptografische Prüfsummen, dass sie seit der Erfassung nicht verändert wurden. Das ist für die forensische Verwertbarkeit entscheidend.

Die Kostenfrage ehrlich stellen

Viele SIEM-Lizenzmodelle rechnen nach Datenvolumen, und genau deshalb ist Log-Management auch eine Budgetfrage. Wer alles ungefiltert in die heiße Stufe schickt, zahlt für jedes Debug-Log denselben Preis wie für das entscheidende Anmeldeereignis. Die Hebel sind klar: an der Quelle filtern, bevor die Daten das SIEM erreichen; gesprächige Quellen aggregieren; die Aufbewahrung nach Stufen staffeln; und die volle Durchsuchbarkeit auf die Quellen und Zeiträume beschränken, die sie wirklich brauchen. Der Beitrag zum SIEM enthält dazu eine Volumen- und Kostenrechnung nach Quelle. Die ehrliche Rechnung über drei Jahre, inklusive der wachsenden Datenmenge, gehört an den Anfang jeder SIEM-Einführung, nicht ans Ende, wenn das Budget schon aufgebraucht ist.

Fazit

Log-Management ist die unscheinbare Grundlage, an der eine Erkennungsstrategie wirtschaftlich und forensisch tauglich wird oder scheitert. Drei Entscheidungen tragen das Ganze: die Aufbewahrungsdauer aus Forensik und Recht, die Staffelung nach heißem, warmem und kaltem Speicher, um die Kosten zu beherrschen, und der Schutz der Logs vor Manipulation, weil ein gelöschtes Protokoll die Erkennung wertlos macht. Wer diese drei bewusst trifft, statt alles gleich zu behandeln, hat ein SIEM, das im Vorfall die Antworten liefert und dabei bezahlbar bleibt. Für ein Blue Team ist die Aufbewahrung damit keine reine Speicherfrage, sondern die Entscheidung darüber, ob der Vorfall in sechs Monaten noch aufklärbar ist.