Forensic Readiness: Wenn der Vorfall da ist, entscheidet, was Sie vorher geloggt haben

Der Anruf kommt montags um halb acht. Irgendetwas stimmt nicht: Kunden melden Mails, die sie nie geschickt haben, ein Konto zeigt Anmeldungen aus Übersee, eine Datei ist weg. Und dann stellt jeder dieselben drei Fragen: Was ist passiert? Seit wann? Was ist betroffen? Ob diese Fragen in zwei Stunden oder in zwei Wochen beantwortet werden, entscheidet sich nicht am Montag. Es hat sich Monate vorher entschieden, als jemand festgelegt hat, was geloggt wird, wie lange, und wo.

Forensic Readiness heißt: Die Beweise für einen Vorfall existieren, bevor der Vorfall passiert. Und sie sind so beschaffen, dass man ihnen glauben kann.

Dieser Beitrag ist die Fortsetzung des Beitrags über Monitoring und Observability, mit einer anderen Frage. Dort ging es darum, Fehler zu sehen, bevor sie wehtun. Hier geht es darum, nach dem Vorfall zu wissen, was er war. Sieben Bausteine, aus Vorfällen, Audits und dem eigenen Betrieb, und am Ende die Übung, die fast niemand macht.

Was ein Vorfall von Ihren Logs verlangt

Wer einen Vorfall aufklärt, egal ob eine externe Forensikerin, die Versicherung oder Sie selbst, baut als Erstes eine Zeitlinie: Welches Ereignis kam wann, auf welchem System, ausgelöst von wem. Alles Weitere, die Frage nach dem Einstieg, dem Ausmaß, den betroffenen Daten, hängt an dieser Zeitlinie. Und die Zeitlinie hat vier Anforderungen, die man nicht nachträglich erfüllen kann:

• Vollständigkeit: Die relevanten Quellen müssen überhaupt geloggt haben, und zwar den Zeitraum, um den es geht.
• Korrelierbarkeit: Die Einträge verschiedener Systeme müssen sich in eine Reihenfolge bringen lassen.
• Integrität: Es muss belegbar sein, dass niemand die Logs nachträglich verändert hat, auch nicht der Angreifer.
• Zugänglichkeit: Die richtigen Personen müssen im Ernstfall schnell und ohne das kompromittierte System an die Logs kommen.

Die sieben Bausteine

1. Die Quellen: Was überhaupt loggen muss

Nicht alles, aber die Stellen, an denen Vorfälle sichtbar werden. Für einen Mittelständler ist die Liste überschaubar: Anmeldungen und Fehlversuche auf allen Systemen (Server, VPN, Verzeichnisdienst, Cloud-Konsolen, Webanwendungen). Rechteänderungen und Adminaktionen. Web- und Mailserver mit Absender, Ziel und Ergebnis. Firewall und DNS, denn der Weg nach außen ist oft der erste Beleg. Endpunkte, mindestens Prozessstarts und Verbindungen auf Servern. Und bei Anwendungen mit Kundendaten das Audit-Log der Anwendung selbst: wer hat welchen Datensatz geöffnet, geändert, exportiert. Jede Quelle, die fehlt, ist ein blinder Fleck in der Zeitlinie, und Angreifer bewegen sich in blinden Flecken.

2. Die Zeit: Eine Uhr für alle

Der unscheinbarste Baustein und der, der am häufigsten fehlt. Wenn der Mailserver drei Minuten vorgeht und die Firewall zwei nach, lässt sich nicht sagen, ob die Verbindung vor oder nach der Anmeldung kam. Alle Systeme synchronisieren ihre Zeit über eine definierte, vertrauenswürdige Zeithierarchie. Zeitstempel werden konsistent geschrieben, idealerweise in UTC oder mit eindeutigem Offset. Und Zeitabweichungen werden überwacht und gemeldet, statt darauf zu vertrauen, dass die Synchronisation schon läuft. Das ist wenig Arbeit und der Unterschied zwischen einer Zeitlinie und einer Vermutung.

3. Der Ort: Logs verlassen das System sofort

Ein Angreifer, der einen Server übernommen hat, kann dort die Logs bereinigen. Der kompromittierte Rechner darf nicht die einzige Kopie der Beweise besitzen. Deshalb schickt jedes System seine Logs in dem Moment, in dem sie entstehen, an ein zweites, das der Server nicht kontrolliert: einen zentralen Log-Server, der nur empfängt. Die Übertragung sollte zuverlässig erfolgen, mit lokaler Pufferung und Wiederholung bei Störungen, damit ein Ausfall der Log-Infrastruktur nicht sofort eine Lücke erzeugt. Eine Empfangsbestätigung allein reicht dafür nicht. Bei mir läuft das über einen verschlüsselten Tunnel mit Empfangsbestätigung und lokaler Warteschlange auf einen Server, der außer Logs nichts tut und von den Produktivsystemen aus ausschließlich über den vorgesehenen Log-Eingang erreichbar und nicht administrierbar ist. Das BSI empfiehlt für sicherheitsrelevante Ereignisse ebenfalls eine eigene Protokollierungsinfrastruktur zur zentralen Speicherung und Auswertung. Das ist dieselbe Vertrauensgrenze wie beim Backup, das gezogen wird statt geschoben: Wer die Maschine hat, darf nicht an die Beweise kommen.

4. Die Integrität: Belegbar unverändert

Ein Log, das jemand nachträglich ändern konnte, ist nicht automatisch wertlos, aber seine Beweiskraft wird schwächer, und man muss dann über weitere Quellen, Prüfsummen, Backups oder Kopien im zentralen System plausibel machen, dass es unverändert ist. Das ist im Vorfall die Arbeit, die niemand hat. Deshalb schreibt der Log-Server nur anhängend, mit Nutzern, die lesen, aber nicht löschen dürfen, und bei höherem Schutzbedarf mit Prüfsummen, die den Bestand periodisch versiegeln. Wer Logs als Beweismittel braucht, orientiert sich an der ISO/IEC 27037, die Identifikation, Sammlung, Erfassung und Erhaltung potenzieller digitaler Beweise behandelt: Herkunft, Unversehrtheit und Kette der Verwahrung müssen belegbar sein.

5. Die Aufbewahrung: Länger als die Entdeckung dauert

Vorfälle werden im Schnitt lange nach dem Einstieg entdeckt, oft Wochen, manchmal Monate. Logs, die nach sieben Tagen rotieren, decken den Einstieg nie ab. Meine Faustregel als Ausgangspunkt, nicht als Vorschrift: Anmelde- und Adminlogs in der Größenordnung eines Jahres, Web-, Mail- und Firewall-Logs einige Monate, Anwendungs-Audit-Logs nach dem dokumentierten Zweck der Anwendung, was deutlich kürzer sein kann als die Fachdaten selbst. Ein Datenschutzbeauftragter wird bei einem Jahr nachfragen, zu Recht, denn die Aufsichtsbehörden haben für Protokolldaten teils deutlich kürzere Orientierungswerte im Kopf. Die Frist ist genau dann haltbar, wenn der Entdeckungszeitraum sie erfordert und der Zweck dokumentiert ist: Speicherbegrenzung heißt begründete Frist, nicht kurze Frist. Deshalb stehen die Fristen dokumentiert, mit Begründung, denn sie sind zugleich eine Datenschutzfrage, dazu gleich.

6. Der Zugriff: Wer im Ernstfall lesen darf, und womit

Im Vorfall muss jemand schnell an die Logs, aber nicht mit dem Konto, das gerade übernommen wurde, und nicht über den Server, der gerade kompromittiert ist. Der Log-Server hat eigene Zugänge, unabhängig vom Verzeichnisdienst des Betriebs, mit zweitem Faktor, und mindestens zwei Personen kennen sie. Dazu ein Weg, Logs an eine externe Forensikerin zu geben, ohne ihr das Netz zu öffnen: ein Export nach Zeitraum und System, in einem Format, das sich ohne Spezialwerkzeug lesen lässt.

7. Der Datenschutz: Logs sind personenbezogene Daten

Anmeldelogs enthalten Nutzernamen und Adressen, Web-Logs das Verhalten von Besuchern, Audit-Logs die Arbeit von Mitarbeitern. Forensic Readiness und Datenschutz stehen nicht im Widerspruch, sie brauchen nur dieselbe Sorgfalt: dokumentierter Zweck (Sicherheit und Aufklärung), begründete Aufbewahrung nach Baustein 5, Zugriff nur für die, die ihn brauchen. Werden Mitarbeiteraktivitäten protokolliert, gehören Datenschutz und, soweit einschlägig, die Arbeitnehmervertretung von Anfang an in das Konzept. Sicherheitslogs dürfen nicht stillschweigend zu einem Instrument der Leistungs- oder Verhaltenskontrolle werden. Was dazu in einer Webanwendung wirklich nötig ist, steht im Abschnitt zu Logging-Fehlern im Beitrag über die OWASP Top 10.

Die Übung, die fast niemand macht

Alle sieben Bausteine können auf dem Papier stehen und trotzdem im Ernstfall versagen, weil niemand je geprüft hat, ob sich aus den Logs eine Zeitlinie bauen lässt. Deshalb gehört zur Readiness eine Übung, zweimal im Jahr, eine Stunde: Man nimmt einen fiktiven Vorfall, etwa „Konto von Frau Meyer wurde am Dienstag um 14:00 von einer fremden Adresse benutzt", und versucht, ihn ausschließlich aus den Logs zu rekonstruieren. Von wo kam die Anmeldung? Was hat das Konto danach getan? Auf welchen Systemen? Welche Daten wurden geöffnet?

Beim ersten Mal scheitert die Übung fast immer an einem der Bausteine: Die Firewall loggt keine ausgehenden Verbindungen, die Anwendung hat kein Audit-Log, die Uhren stimmen nicht, der Zugriff auf den Log-Server dauert eine Stunde, weil das Passwort nur einer kennt. Genau das ist der Zweck. Jede Lücke, die in der Übung auffällt, ist eine, die im Ernstfall nicht auffällt, weil dann niemand Zeit hat, sie zu bemerken. Das ist derselbe Gedanke wie der Restore-Test beim Backup: Nicht die Sicherung ist das Produkt, sondern die Wiederherstellung. Nicht das Log ist das Produkt, sondern die Zeitlinie.

Was das für Ihr Unternehmen bedeutet

Ob Sie einen Vorfall aufklären können, ist keine Frage der Reaktion am Montag, sondern der Vorbereitung im Jahr davor. Die sieben Bausteine beginnen bei einem überschaubaren Mittelständler mit einigen Tagen Einrichtung, bei komplexer Infrastruktur entsprechend mehr, und kosten danach vor allem Disziplin: Uhren prüfen, Fristen einhalten, zweimal im Jahr üben. Sie machen aus dem Satz „wir wissen nicht, was passiert ist" den Satz „hier ist die Zeitlinie, das ist betroffen, das haben wir gemeldet". Und der zweite Satz ist der, der über Versicherungsschutz, Meldefristen und das Vertrauen der Kunden entscheidet.

Der Beitrag über die Arbeit nach dem Audit beschreibt, wie man Findings priorisiert. Forensic Readiness ist eines der Findings, die mir in Audits immer wieder begegnen und danach liegen bleiben, weil es erst im Ernstfall zählt. Genau deshalb gehört es nach oben auf die Liste.

Quellen & weiterführende Belege

• BSI IT-Grundschutz, Bausteine DER.2.1 (Behandlung von Sicherheitsvorfällen) und DER.2.2 (Vorsorge für die IT-Forensik): die deutsche Referenz für genau diese Vorbereitung, einschließlich Zeitsynchronisation, zentraler Protokollierung und Übung.
• ISO/IEC 27037: Leitlinien zur Identifikation, Sammlung und Sicherung digitaler Beweise; Grundlage für Integrität und Kette der Verwahrung in Baustein 4.
• NIS2-Richtlinie (EU 2022/2555), Artikel 23, umgesetzt in § 32 BSIG: das deutsche NIS2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten; § 32 BSIG regelt die gestufte Meldung mit früher Erstmeldung (24 Stunden), Meldung mit erster Bewertung (72 Stunden), Zwischenmeldungen und Abschlussmeldung (in der Regel nach einem Monat).
• BSI IT-Grundschutz, Baustein OPS.1.1.5 (Protokollierung): Empfehlung einer zentralen Protokollierungsinfrastruktur für sicherheitsrelevante Ereignisse, Grundlage für Baustein 3.

Zahlen zur durchschnittlichen Entdeckungsdauer von Vorfällen kursieren viele; sie stammen überwiegend aus Anbieterstudien und schwanken stark. Die Aussage dieses Beitrags braucht sie nicht: Logs müssen länger reichen als der für das eigene Risiko realistische Entdeckungszeitraum, und sieben Tage sind dafür in vielen Umgebungen zu kurz.

Verwandt auf die.entwicklerin.net: Logging, Monitoring & Alerts: Webapps im Betrieb sichtbar machen, Logging und Monitoring im laufenden Betrieb, aus Entwicklersicht.

Carola Schulte

Software-Architektin und Network Security Engineer. Baut Logging so, dass es im Ernstfall Antworten gibt statt Fragen.

Beratung anfragen