What does the order of volatility rank on a compromised host, and why does it set capture order?
answer
- sequencing under a running clock
- sorted by lifetime, not by value
- processor state sits at the top
- socket and ARP tables die on reboot
- archived logs and backups sit last
basics
~20 sIt ranks evidence by how fast it disappears, not by how useful it is. CPU registers and cache decay first, then RAM, then network state such as socket and ARP tables, then disk, then archived logs. Collect shortest-lived first.
solid answer
~50 sThe order of volatility, set out in RFC 3227, ranks evidence sources by lifetime: CPU registers and cache, then RAM, then live system and network state (the socket table, the ARP or neighbour cache, routing tables, loaded kernel modules, tmpfs), then disk, then remote or archived logs and backups. It exists because collection is serial and slow, and the top of the list stops existing on its own while you work. On a Linux server I believe an intruder is still on, the socket table is the only place the current peer address lives; reboot, or simply wait for the process to exit, and it is gone with no way to reconstruct it, while the auditd records on disk will still be there in an hour. The ranking sorts by decay rate only. It never says a socket entry matters more than a disk artefact.
go deeper
Be ready to recite the ranking in order and say in one sentence why it exists: collection is serial, and the top of the list evaporates while you work. Name at least one artefact per rung.
Explain what each rung actually answers on a real host, and what specifically is lost at reboot versus at process exit versus at log rotation. Say plainly that the sort key is lifetime, not value.
Show that you apply it under a running clock on a live compromised host, and that you can say which single artefact you would grab if you had sixty seconds and why that one.
Own the position that a ranking published in an RFC is a default, not a policy. Be ready to say what your responders are expected to have collected before any host is rebuilt, and what you accept losing.
## What the ranking actually is The order of volatility is a sequencing rule for evidence collection. It was written down in RFC 3227 (Guidelines for Evidence Collection and Archiving) and it says roughly this, most volatile first: 1. CPU registers, cache and other processor state 2. Routing table, ARP (neighbour) cache, process table, kernel statistics, memory 3. Temporary filesystems (tmpfs, /tmp on tmpfs, a container's writable layer) 4. Disk 5. Remote logging and monitoring data relevant to the system 6. Physical configuration and network topology 7. Archival media and backups The single idea underneath it: **the list is sorted by expected lifetime, not by evidentiary value**. A register value survives nanoseconds. The kernel socket table survives as long as the process holds the connection and the host stays up. On-disk records survive until retention or someone deletes them. Backups survive for months. Because a responder collects one thing at a time, anything you do not take early may be taken from you by ordinary system behaviour before you reach it. ## What each layer answers, concretely On a running Linux server, each rung answers a different question: - **Registers and cache** answer what the CPU was doing at this instant. In practice a responder never collects them directly; they are on the list to mark the top of the scale. - **RAM** holds the executing code and data. On a host whose implant exists only in memory, RAM is the only place the implant itself exists at all. - **Process and open-file state** (`/proc`, the process table) links a PID to the file it was launched from, its command line, its parent, and the file descriptors it holds open, including a deleted binary that is still mapped. - **The socket table** answers *who is this host talking to right now, and which process owns that conversation*. That mapping exists nowhere else once the connection closes. - **The ARP or neighbour cache and routing table** answer which layer-2 neighbours this host has recently spoken to and which way traffic leaves. Useful for a peer on the same segment, and it ages out in minutes. - **Loaded kernel modules and tmpfs contents** answer whether something was inserted into the kernel or staged in memory-backed storage that a reboot erases. - **Disk** answers what persisted: binaries, configuration, service units, and the on-disk records the audit daemon already wrote. - **Archived and remote logs** answer what the estate saw over time, and they usually survive the host entirely. ## Why sequencing rather than a tool list Interviewers ask this because it separates people who memorised a checklist from people who understand the constraint. The constraint is that collection has a duration and the evidence has a half-life. If your first ten minutes go into a full disk image on a host with a live command-and-control socket, you will finish holding a perfect copy of something that would still have been there tomorrow, and you will have lost the peer address, the owning process, and the connection state, none of which the disk records. ## The two errors this framing prevents The first error is treating a reboot, a shutdown or a rebuild as harmless because the disk is intact. Everything from rungs one to three dies with the running kernel. The second error is the mirror image: assuming volatile means valuable. It does not. The ranking tells you what to grab *first*, not what to conclude *from*. A socket table proves that a connection existed at that moment between a process and a peer address; it proves nothing about what crossed the connection. ## What it is not It is not a legal standard, and it is not a claim about which artefact an investigation will ultimately rest on. It is not tool guidance either: which utility you use, and what footprint that utility leaves behind, is a separate discipline. Order of volatility is only the answer to one question, asked when the clock is running: given that I can collect these things one after another, in what order do I take them so that the fewest of them vanish while I work?
- Where does a host's on-disk audit trail sit in the order, and does that mean it is safe?It sits below live memory and network state, because disk survives a reboot. Safe from ordinary system behaviour, not safe in general. Retention rotation can age it out, and an intruder with root can truncate or delete it. The ranking models natural decay only; it assumes nothing is actively destroying evidence.
- Why is the process table listed above disk when the process was started from a binary on disk?Because they answer different questions. The disk holds the binary; the process table holds the running instance, its command line, its parent, its open descriptors and its start time. If the binary was deleted after launch, the running process still maps it, and that mapping vanishes when the process exits.
- Does the order of volatility tell you whether to collect at all before containing the host?No. It only orders the collection you have already decided to do. Whether you accept any delay before cutting the intruder off, and who authorises that delay, is a separate call made above the responder doing the capture.
It is triage in a burning building: you carry out what will be ash in two minutes before what will still be standing tomorrow, regardless of which item you think is worth the most.
saying these in an interview costs you the question
- Says the ranking orders evidence by importance or by weight in court
- Believes RAM contents survive a graceful shutdown on disk
- Puts disk imaging first because it is the thorough option
- Treats archived logs as the most volatile because they rotate
- Cannot name anything between RAM and disk, skipping all live network state