Order of Volatility
Was ist Order of Volatility?
Order of VolatilityIn RFC 3227 festgelegte Erfassungsreihenfolge, die Incident-Respondern vorschreibt, die fluechtigsten Beweise zuerst zu sichern, bevor sie ueberschrieben oder verloren gehen.
Die Order of Volatility ist ein DFIR-Grundprinzip, in RFC 3227 dokumentiert, das digitale Beweise nach ihrer Veraenderungsgeschwindigkeit sortiert. Die kanonische Reihenfolge: CPU-Register und Cache, Kernel- und Prozessspeicher, Netzwerkzustand und ARP-Caches, laufende Prozesse, temporaere Dateisysteme, persistenter Speicher, Remote-Logging- und Monitoring-Daten, schliesslich physische Konfiguration und Archivmedien. Responder muessen volatile Quellen vor Abschaltung oder Neustart erfassen, da RAM, Netzwerksitzungen und Routing-State beim Shutdown verloren gehen. In moderner Windows-IR bedeutet das typischerweise Speichererfassung mit WinPmem oder DumpIt und Triage volatiler Artefakte via KAPE oder Velociraptor vor dem geordneten Shutdown.
● Beispiele
- 01
Erfassung von Memory-Dump und netstat-Output, bevor ein beaconender Host vom Netz getrennt wird.
- 02
Sicherung aktueller TLS-Session-Keys aus dem RAM, bevor sie beim Logout verworfen werden.
● Häufige Fragen
Was ist Order of Volatility?
In RFC 3227 festgelegte Erfassungsreihenfolge, die Incident-Respondern vorschreibt, die fluechtigsten Beweise zuerst zu sichern, bevor sie ueberschrieben oder verloren gehen. Es gehört zur Kategorie Forensik und Incident Response der Cybersicherheit.
Was bedeutet Order of Volatility?
In RFC 3227 festgelegte Erfassungsreihenfolge, die Incident-Respondern vorschreibt, die fluechtigsten Beweise zuerst zu sichern, bevor sie ueberschrieben oder verloren gehen.
Wie funktioniert Order of Volatility?
Die Order of Volatility ist ein DFIR-Grundprinzip, in RFC 3227 dokumentiert, das digitale Beweise nach ihrer Veraenderungsgeschwindigkeit sortiert. Die kanonische Reihenfolge: CPU-Register und Cache, Kernel- und Prozessspeicher, Netzwerkzustand und ARP-Caches, laufende Prozesse, temporaere Dateisysteme, persistenter Speicher, Remote-Logging- und Monitoring-Daten, schliesslich physische Konfiguration und Archivmedien. Responder muessen volatile Quellen vor Abschaltung oder Neustart erfassen, da RAM, Netzwerksitzungen und Routing-State beim Shutdown verloren gehen. In moderner Windows-IR bedeutet das typischerweise Speichererfassung mit WinPmem oder DumpIt und Triage volatiler Artefakte via KAPE oder Velociraptor vor dem geordneten Shutdown.
Wie schützt man sich gegen Order of Volatility?
Schutzmaßnahmen gegen Order of Volatility kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Order of Volatility?
Übliche alternative Bezeichnungen: Volatility-Reihenfolge, RFC-3227-Reihenfolge.
● Verwandte Begriffe
- forensics-ir№ 787
pagefile.sys
Die Windows-Auslagerungsdatei fuer virtuellen Speicher auf dem Systemvolume; sie kann Fragmente von Prozessspeicher enthalten, etwa Credentials, Schluessel, Kommandozeilen und entschluesselte Payloads.
- forensics-ir№ 474
hiberfil.sys
Komprimierte Windows-Ruhezustandsdatei mit einem fast vollstaendigen Snapshot des physischen Speichers zum Zeitpunkt des Hibernate; ermoeglicht forensischen RAM-Zugriff auf einem ausgeschalteten System.
- forensics-ir№ 043
Amcache.hve
Windows-Registry-Hive, die detaillierte Metadaten (inkl. SHA-1) zu jedem auf dem System gelaufenen oder vorhandenen Executable speichert und damit auf modernem Windows starken Nachweis fuer Programmausfuehrung liefert.
- forensics-ir№ 677
MFT (Master File Table)
Die zentrale Metadatenstruktur von NTFS, die fuer jede Datei und jedes Verzeichnis einen 1024-Byte-Eintrag speichert und fast jede Windows-Dateisystem-Forensik traegt.
- forensics-ir№ 001
$UsnJrnl ($J)
Das NTFS-Update-Sequence-Number-Aenderungsjournal protokolliert jede Dateisystemoperation und liefert Forensikern eine hochaufloesende Timeline von Erstellung, Aenderung und Loeschung.