SOP-06 · Order of volatility in practice

Live response and volatile data collection

Collecting memory and running-state data from a powered system in a defined order, with trusted tools, minimal footprint and a log of every action.

01Purpose and scope

To preserve evidence that would be lost at shutdown, while documenting the changes the collection itself introduces.

Workstations and servers that are powered on when encountered, where authority and the risk assessment justify live collection. Mobile devices are covered by SOP-05.

02Prerequisites

  • Known-good tools on write-protected external media, with their hashes recorded in advance.
  • Sterile destination media of sufficient capacity for a full memory image.
  • A decision, recorded, that live collection is justified (encryption, remote-wipe risk, running malicious process, questions that need running state).

03Steps

  1. Photograph and note the state

    Screen content, displayed clock against the reference clock, visible applications, network indicators. Do not press Enter or the power button.

    RecordPhotographs; clock offset.

  2. Decide on network isolation

    Unplugging the cable stops exfiltration and remote wipe but ends live sessions and may trigger scripts. Record the decision and the time; if isolating, prefer disconnecting at the switch so the interface state on the host is preserved.

    RecordIsolation decision and time.

  3. Capture memory first

    Run the memory acquisition tool from the external media, writing to the destination media. Record tool, version, start and end time, output size and hash. Note that the tool's own process is now in the image.

    RecordMemory acquisition record.

  4. Collect running-state data

    In order: system time and uptime, logged-on users, process list with command lines and parents, network connections and listening ports, ARP and routing tables, open files and handles, loaded drivers, mounted volumes and encryption status, clipboard. Each command's output is written to the destination media with the command, time and hash.

    RecordCommand log with hashes.

  5. Preserve encryption state where lawful

    If encrypted volumes are mounted and the authority permits, image the logical volume while it is accessible, or record the recovery information through the operating system's documented management interface. Store keys with the case record, never in the image or the report.

    RecordEncryption state and actions.

  6. Shut down or hand over

    Controlled shutdown if the system can be seized, or documented hand-over to the system owner for continued operation with the collected data preserved. Then proceed with SOP-04 for the storage media.

    RecordShutdown or hand-over line.

04Records produced

  • State photographs and clock offset
  • Decision log (live collection, isolation)
  • Memory acquisition record with hash
  • Command log with per-output hashes

05Pitfalls

  • Running tools from the suspect system's own disk uses its binaries, which may be compromised, and writes to the evidence.
  • Collecting running-state data before memory lets the collection overwrite memory that mattered.
  • A memory image without a recorded OS build cannot be reliably parsed later.
  • Keys or credentials found in memory are not a licence to access other systems or accounts.

06Forms

07Standards

  1. RFC 3227 — Guidelines for Evidence Collection and Archiving
  2. NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response
  3. ISO/IEC 27037:2012 — Identification, collection, acquisition and preservation of digital evidence
  4. The Volatility Foundation — Volatility 3 documentation