Module 1: TR1 — Evidence Volatility and the Preservation Hierarchy
Evidence Volatility and the Preservation Hierarchy
Evidence does not wait. Memory contents change with every process allocation. Network connections close as sessions time out. Log files rotate toward overwrite. Cloud session tokens expire on schedules the responder cannot control. The triage responder who understands what disappears first — and how quickly — captures the evidence the investigation team needs. The responder who does not understand volatility captures what is convenient, not what is critical.
This module applies the classical order of volatility (RFC 3227) to the three environments this course covers. Cloud evidence has different volatility patterns than endpoint evidence. Linux volatile artifacts live in different locations than Windows volatile artifacts. Container evidence disappears entirely when the container restarts. The preservation hierarchy taught in this module governs the “preserve” phase of the Triage Trinity from TR0.
What you will learn
- RFC 3227’s order of volatility applied to 2026 environments
- Cloud-specific evidence volatility: session tokens, audit streams, OAuth grants
- Windows-specific evidence volatility: memory, processes, event logs, prefetch
- Linux-specific evidence volatility: /proc, kernel modules, container layers
- The preservation decision tree: when to preserve first vs contain first
- Cross-environment evidence correlation using timestamps and entity mapping
Subsections
TR1.1 The Order of Volatility · TR1.2 Cloud Evidence Volatility · TR1.3 Windows Evidence Volatility · TR1.4 Linux Evidence Volatility · TR1.5 The Preservation Decision Tree · TR1.6 Cross-Environment Evidence Correlation · TR1.7 Interactive Lab: Preservation Priority · TR1.8 Module Summary · TR1.9 Check My Knowledge