IT-Sicherheit
Bei einem Sicherheitsvorfall ist die zentrale technische Frage häufig nicht nur, was beobachtet wurde, sondern in welcher Reihenfolge Ereignisse stattfanden, welche Systeme betroffen waren und welche Erklärungen die vorhandenen Spuren tragen. Eine Rekonstruktion verbindet mehrere Evidenzquellen, ohne Lücken durch Vermutungen zu füllen.
Kurzantwort
Zuerst werden Zeitraum, Systeme und verfügbare Evidenz festgelegt. Anschließend werden Logs, Authentisierungsereignisse, Netzwerkdaten, Konfigurationsänderungen und betroffene Artefakte zeitlich korreliert. Gegenhypothesen und Datenlücken werden ausdrücklich dokumentiert. Eine technische Rekonstruktion ist keine automatische Attribution eines Angreifers.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Untersuchungsumfang und Zeitfenster bestimmen
Vor der Analyse wird geklärt, welches Ereignis den Untersuchungsanlass bildet und welche Systeme technisch betroffen sein könnten. Ein zu enges Zeitfenster kann Vorbereitung oder Folgewirkungen ausblenden; ein zu weites erzeugt unnötige Datenmengen.
Die Zeitbasis der Quellen wird dokumentiert. Serverzeit, UTC, lokale Zeitzonen und synchronisierte oder nicht synchronisierte Uhren können zu scheinbaren Widersprüchen führen.
NIST SP 800-61 Rev. 3 ordnet Incident Response in das übergreifende Cybersecurity-Risikomanagement ein. Für die Begutachtung bleibt entscheidend, welche konkreten technischen Spuren im Einzelfall verfügbar sind.
2. Evidenzquellen korrelieren
Typische Quellen sind Authentisierungslogs, Applikationslogs, Netzwerkereignisse, Endpoint-Telemetrie, Cloud-Auditlogs, Repository- und Deploymentdaten sowie Konfigurationsänderungen.
Ein einzelner Logeintrag kann mehrdeutig sein. Erst die Korrelation unabhängiger Quellen kann einen Ablauf stützen. Dabei wird festgehalten, welche Quelle einen Befund direkt trägt und welche nur Kontext liefert.
Retention, Filter, Sampling und fehlgeschlagene Logübertragung begrenzen die Vollständigkeit. Das Nichtvorhandensein eines Ereignisses in einem Log beweist daher nur unter bekannten Erfassungsbedingungen sein Fehlen.
3. Timeline und Ereignisketten
Ereignisse werden in eine nachvollziehbare Reihenfolge gebracht. Wo Zeitstempel unsicher sind, können kausale Beziehungen, Sequenznummern oder Systemzustände zusätzliche Ordnung liefern.
Die Timeline sollte zwischen beobachtetem Ereignis und Interpretation unterscheiden. „Anmeldung von IP X“ ist ein technischer Befund; „Angreifer meldete sich an“ enthält bereits Attribution und möglicherweise eine nicht belegte Personen- oder Rollenannahme.
Widersprüchliche Zeitstempel oder fehlende Segmente werden sichtbar gelassen und als Unsicherheit behandelt.
4. Gegenhypothesen und alternative Ursachen
Ungewöhnliche Zugriffe können Angriff, legitime Administration, Automatisierung, Fehlkonfiguration oder einen kompromittierten Dienst repräsentieren. Solche Alternativen werden anhand weiterer Artefakte geprüft.
Auch die angenommene Eintrittsstelle sollte nicht vorschnell festgelegt werden. Ein später beobachteter Prozess kann Folge eines früheren Ereignisses sein, das außerhalb der vorhandenen Retention liegt.
Technische Attribution zu einer konkreten Person oder Organisation erfordert eine eigene belastbare Evidenzbasis und ist von der Rekonstruktion des Systemgeschehens zu unterscheiden.
5. Ergebnis und Aussagegrenzen
Der Bericht fasst gesicherte Ereignisse, technisch plausible Zusammenhänge, offene Alternativen und Datenlücken getrennt zusammen. Maßnahmenempfehlungen können sich auf nachgewiesene technische Schwächen beziehen, ohne nicht belegte Ursachen als Tatsache darzustellen.
Besonders wichtig ist die Angabe, welche Logs oder Systeme nicht verfügbar waren. Dadurch bleibt nachvollziehbar, ob ein fehlender Befund auf tatsächliches Nichtauftreten oder auf fehlende Beobachtbarkeit zurückgehen kann.
Eine gute Rekonstruktion ist daher nicht die längste Timeline, sondern diejenige, deren einzelne Aussagen auf überprüfbare Evidenz zurückgeführt werden können.
6. Konfidenzstufen, Beweissicherung und Rekonstruktionsgrenzen
Für längere Timelines ist eine Konfidenzkennzeichnung nützlich. Ereignisse können etwa als direkt belegt, durch mehrere Quellen gestützt, technisch plausibel oder ungeklärt eingeordnet werden. Diese Kategorien sollten vor der Auswertung definiert und im Bericht konsistent verwendet werden.
Die Sicherung der Evidenz beeinflusst die spätere Aussagekraft. Rotierende Logs, kurzlebige Cloud-Daten und flüchtige Zustände können schnell verloren gehen. Das BSI empfiehlt im Kontext der IT-Forensik, Datenquellen und Sicherungsreihenfolge vorab festzulegen und flüchtige Daten entsprechend zu priorisieren.
Auch eine lückenlose Timeline beweist nicht automatisch die Identität eines handelnden Menschen. Konten, IP-Adressen, Geräte und Prozesse sind technische Identifikatoren. Eine weitergehende Attribution benötigt zusätzliche Evidenz und eine eigenständige Begründung.
Wie werden fehlende Logereignisse bewertet?
Zuerst wird geprüft, ob das betreffende Ereignis überhaupt protokolliert werden konnte: War die Quelle aktiviert, vollständig übertragen und für den Zeitraum aufbewahrt?
Erst wenn die Beobachtbarkeit bekannt ist, besitzt das Fehlen eines Eintrags stärkere Aussagekraft. Ohne diese Prüfung kann „nicht im Log“ lediglich „nicht beobachtbar“ bedeuten.
Der BSI-Mindeststandard zur Protokollierung betont die Erfassung sicherheitsrelevanter Vorgänge; NIST SP 800-61 Rev. 3 ordnet Incident Response in das umfassendere Cybersecurity-Risikomanagement ein.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind Untersuchungsumfang und relevantes Zeitfenster nachvollziehbar bestimmt?
- Sind Zeitzonen, Uhrabweichungen und Retention der verwendeten Quellen dokumentiert?
- Sind flüchtige oder rotierende Datenquellen rechtzeitig gesichert worden?
- Ist jede wesentliche Timeline-Aussage auf eine konkrete Quelle rückführbar?
- Wird zwischen direkt belegten, gestützten, plausiblen und ungeklärten Ereignissen unterschieden?
- Sind legitime Administration, Automatisierung und Fehlkonfiguration als Gegenhypothesen geprüft?
- Ist eine etwaige Attribution klar von der technischen Ereignisrekonstruktion getrennt?
Konstruiertes Beispiel
Ein Konto führt nachts mehrere privilegierte Aktionen aus. Authentisierungslog, Cloud-Auditlog und Deploymenthistorie werden korreliert. Ein geplanter Automationsjob erklärt einen Teil der Aktionen, nicht jedoch einen zusätzlichen Rechtewechsel. Der Bericht trennt die erklärten Ereignisse vom verbleibenden ungeklärten Befund.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Amtliche technische Leitlinie NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025. Quelle öffnen.
- Amtliche technische Leitlinie NIST SP 800-53 Rev. 5, insbesondere Audit and Accountability und Incident Response. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- Amtliche technische Leitlinie BSI IT-Grundschutz DER.2.2 „Vorsorge für die IT-Forensik“ zu Sicherungsreihenfolge und Dokumentation. Quelle öffnen.
- Amtliche technische Leitlinie BSI-Mindeststandard zur Protokollierung und Detektion für die Rekonstruktion sicherheitsrelevanter Vorgänge. Quelle öffnen.
Weiterführende Beiträge
- Protokolldaten technisch auswerten
- Schwachstellen technisch untersuchen
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Sicherheit
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Sicherheitsgutachten ansehen