Evidence Volatility and the Preservation Hierarchy

0.1 What is evidence volatility

Evidence volatility is the rate at which digital evidence degrades, changes, or disappears after an incident begins. RFC 3227, published by the IETF in 2002, established the foundational principle: collect the most volatile evidence first, because once it's gone, no tool and no authority can recover it. CPU registers change in nanoseconds. Memory contents shift with every process allocation. Network connections close as sessions expire. Disk artifacts overwrite as the operating system continues normal operations.

The principle is timeless. The evidence landscape is not. RFC 3227 was written for standalone servers. A 2026 incident spans cloud identity logs that expire on vendor-controlled schedules, container layers that vanish on restart, OAuth tokens that rotate hourly, and endpoint memory that rewrites with every scheduled task. The triage responder who treats all three environments — cloud, Windows, and Linux — as a single volatility hierarchy captures the evidence the investigation needs. The responder who collects what's convenient instead of what's volatile hands the investigation team a case file full of gaps.

This module updates RFC 3227 for modern multi-environment incidents. You'll learn what disappears first in each environment, how quickly, and the exact sequence for preserving it. By the end of the module, you'll have a preservation decision tree that connects your triage hypothesis to the specific evidence sources you need to capture — in the right order, before the countdown reaches zero.

0.2 What you will learn

Section 1.1 — The Order of Volatility. RFC 3227's classical hierarchy updated for 2026. Five volatility tiers from nanoseconds (registers, live session tokens) to years (archival media). You'll see what falls into each tier and why the collection sequence matters more than the collection speed.

Section 1.2 — Cloud Evidence Volatility. Entra ID sign-in logs, Unified Audit Log entries, OAuth token state, mailbox content, and Conditional Access evaluation records. Each has a different retention boundary and a different preservation mechanism. You'll learn the specific retention periods, what disappears first, and how to export before the countdown expires.

Section 1.3 — Windows Evidence Volatility. Process memory, network connections, event logs, prefetch, registry hives, and NTFS artifacts. You'll walk through a memory acquisition with WinPMem, see what KAPE collects from disk, and understand why the order you collect Windows evidence determines what survives for investigation.

Section 1.4 — Linux Evidence Volatility. The /proc filesystem, kernel modules, active network sockets, container runtime state, systemd journal, and auth.log. You'll see how Linux volatile evidence differs from Windows, why container evidence is the most fragile class, and the collection sequence that preserves what matters.

Section 1.5 — Memory Acquisition Across Platforms. WinPMem and Magnet RAM Capture on Windows, AVML and LiME on Linux, and the kernel_lockdown constraint that blocks acquisition on Secure Boot systems. Choosing the right tool per environment, preparing for acquisition failures, and understanding the evidence that exists only in physical memory.

Section 1.6 — The Preservation Decision Tree. The decision framework that connects your triage hypothesis to the preservation actions you take. When to preserve first versus contain first. How the attacker's current state — active, dormant, or unknown — determines the sequence.

Section 1.7 — Chain of Custody and Evidence Integrity. SHA256 hashing at every transition, the chain-of-custody log template, evidence storage and transfer procedures, and the documentation that makes evidence defensible for investigation, regulatory compliance, and legal proceedings.

Section 1.8 — Cross-Environment Evidence Correlation. Linking cloud identity events to endpoint process execution to Linux network connections. Timestamp normalisation across UTC-inconsistent sources. Entity mapping that connects a user principal name to a device to an IP to a process — the correlation chain that turns isolated artifacts into an investigation timeline.

Section 1.9 — Live Response Scripting and Automation. Converting manual triage into repeatable scripts — PowerShell for Windows, Bash for Linux. Defender Live Response for remote single-endpoint collection. Velociraptor for fleet-wide evidence acquisition across hundreds of endpoints.

Section 1.10 — Interactive Lab: Preservation Priority. A triage scenario where you decide what to preserve first across cloud, Windows, and Linux environments. The lab tests whether you can apply the volatility hierarchy under time pressure when multiple evidence sources are at risk simultaneously.

0.3 What makes Sentinel and Defender XDR ideal for evidence preservation

Microsoft's security stack gives the triage responder capabilities that didn't exist when RFC 3227 was written. Sentinel ingests sign-in logs, audit logs, and endpoint telemetry into a single queryable workspace with configurable retention. Defender for Endpoint's live response lets you run memory acquisition and evidence collection scripts on remote endpoints without physically touching the machine. Purview eDiscovery places litigation holds on mailboxes with a single compliance action. Microsoft Graph API exposes sign-in records, audit events, and directory state programmatically for automated export.

The platform doesn't eliminate the volatility problem — Entra sign-in logs still expire after 30 days without Diagnostic Settings, and endpoint memory still changes with every process. But it provides the infrastructure to preserve evidence at scale: KQL queries that export cloud logs before retention expiry, live response sessions that capture volatile endpoint state remotely, and compliance holds that freeze mailbox evidence before the purge cycle destroys it. The tools in this module work within that infrastructure.

0.4 How to get the best from this module

Work through the sections in order. Each section builds on the previous one — Section 1.1 establishes the volatility hierarchy that Sections 1.2 through 1.4 apply to specific environments. Section 1.5 covers memory acquisition across platforms. Section 1.6 synthesises the environment-specific knowledge into a preservation decision framework. Section 1.7 adds the chain-of-custody discipline. Section 1.8 teaches the correlation techniques that connect evidence across environments. Section 1.9 converts manual collection into repeatable automation. The lab in Section 1.10 tests all of it under simulated time pressure.

If you have access to a Sentinel workspace or a developer tenant with Defender for Endpoint, run the queries and commands as you encounter them. The evidence collection scripts are designed for practice environments — do not run memory acquisition tools against production systems without authorisation. If you don't have lab access, the annotated output in each section shows you exactly what the commands produce and what the results mean.

0.5 Module structure

• Section 1.1 — The Order of Volatility
• Section 1.2 — Cloud Evidence Volatility
• Section 1.3 — Windows Evidence Volatility
• Section 1.4 — Linux Evidence Volatility
• Section 1.5 — Memory Acquisition Across Platforms
• Section 1.6 — The Preservation Decision Tree
• Section 1.7 — Chain of Custody and Evidence Integrity
• Section 1.8 — Cross-Environment Evidence Correlation
• Section 1.9 — Live Response Scripting and Automation
• Section 1.10 — Interactive Lab: Preservation Priority

Prerequisites

Complete Module 0 (The Triage Problem). Section 1.1 builds on the triage methodology from TR0 — specifically the "preserve" phase of the Triage Trinity. The decision framework in Section 1.6 references the classification and escalation concepts from TR0.7 and TR0.8. If you haven't completed TR0, the volatility hierarchy still makes sense on its own.

Go to Section 1.1 — The Order of Volatility to begin.