Part of an ongoing series walking domain by domain through the Cybersecurity Architect's Handbook, Second Edition — and the companion labs that ship with it.
If you've been following along, you know the rhythm by now. I've been working through the second edition of the Cybersecurity Architect's Handbook's "secret menu" one domain at a time — taking each of the book's concepts and pairing it with the hands-on labs that live alongside the book, then writing up what that domain is really trying to teach once you stop reading and start typing commands. We've climbed through the rings of the architecture: detection, prevention, monitoring, the automation that ties a SOC together, the innermost ring of identity and encryption, and last time the ground all of them stand on — the vulnerability and configuration management hygiene that decides whether any of the fancier controls ever get a chance to work.
This installment does something different. Every domain we've covered so far — even the unglamorous hygiene loop — was, at bottom, an attempt to keep the bad day from arriving. This one starts the morning after it did.
There's a premise security people say out loud far less often than they should: prevention will sometimes fail. Not might — will. You can architect detection beautifully, harden every host, scan continuously, and someone still gets in. The mature move isn't pretending otherwise. It's making assume-breach operational — having a disciplined plan for what happens after the alarm sounds: contain the damage, understand what occurred, gather evidence that survives scrutiny, eradicate the adversary, restore normal operation, and capture the lessons that harden the architecture against the next attempt. An organization's security maturity is measured less by whether it's ever breached than by how competently it responds when it is.
That's the domain at the heart of Incident Response and Investigation — and it's where the companion labs make you sit in every seat of the SOC instead of just reading about them.
Two Books, One Cover Price
For anyone joining the series here, the same thing is true of this domain as every other one I've covered: the book is only half of what you get.
The printed second edition runs to nearly 700 pages, providing concepts and frameworks that a cybersecurity architect will need to understand and address. That's the framework
But the companion GitHub repository carries another 700-plus pages of step-by-step, build-it-yourself lab content — material that never had to fit inside a print binding and so could go as deep as the hands-on work demanded. The SANS six-step model and the NIST SP 800-61 lifecycle that give incident response its structure, the digital-forensics discipline that sits underneath it, and the reason the two are inseparable — response without forensic rigor destroys the evidence you need to understand the attack, and forensics without a response process produces analysis no one acts on.For this domain alone, that means imaging a disk and recovering a deleted file, carving photographs back out of raw bytes, pulling a typed command out of volatile memory, hunting across a fleet of endpoints, pivoting from a network alert to the actual packets, and wiring the whole response together with automation.
Concepts you can read about in an afternoon. Muscle memory you can only build by typing the commands and watching the system push back.
What the Labs Actually Build
The labs in this domain are deliberately sequenced to walk the full arc of an investigation — from a powered-off disk to live memory, across a fleet of running machines, over the network wire, and through the automation that ties the response together — but each stands on its own if you only need one piece.
The Sleuth Kit and Autopsy — the powered-off disk. The first lab builds the fundamentals of dead-box forensics on Debian 13: create a forensic image with a write-safe workflow, prove it's a faithful copy with a cryptographic hash, walk the file system from the command line, recover a deleted file straight from its inode with icat, and build a MAC-time timeline — then open the same image in Autopsy to do it all again in a GUI and see what the tool is doing underneath. Here's the point I want every reader to internalize: The Sleuth Kit is the engine behind a great deal of commercial forensic tooling. The image-hash-analyze workflow, the inode-level recovery, and the timeline you just built are exactly what EnCase, FTK, and Magnet AXIOM perform commercially. The console changes. The discipline does not.
Foremost, Scalpel, and PhotoRec — when the metadata is gone. Inode recovery works only while the file system preserves the pointers; a modern ext4 delete or a quick format erases them, and then you carve — reconstructing files from their raw content signatures with no help from the file system at all. This lab is built around a real diagnostic lesson rather than a clean demo: why a naive signature carver truncates real camera photos down to their embedded Exif thumbnails, how to prove the full data is still sitting on the disk before you reach for a structure-aware carver, and why a plain text file with no header or footer needs a different recovery technique entirely. Every commercial suite falls back to exactly this header/footer carving for unallocated space and formatted media.
Volatility 3 and LiME — the state that never touches disk. This lab adds the volatile-memory axis: capture physical RAM with LiME, then analyze it with Volatility 3 to surface running processes, recovered shell history, open handles, and live network state that vanish the moment the machine powers off. It doesn't hide the hard part either — on Linux the real skill isn't running the plugins, it's building the symbol table that matches the exact running kernel, and meeting that frustration head-on is the entire point. Capture-then-analyze is exactly what Magnet RAM Capture and the commercial memory suites do; the Volatility engine underpins much of that tooling.
Velociraptor — fleet-wide live response. Where dead-box forensics asks questions of one seized disk, live response asks questions of many running machines at once and gets structured answers back in seconds. This lab stands Velociraptor up, enrolls a host, collects live artifacts, and runs hunts in VQL — the open-source embodiment of the EDR live-response loop that CrowdStrike Falcon, SentinelOne, and Microsoft Defender expect of their operators. Express an investigative question as a query, run it across the fleet, triage the results. The skills transfer directly.
Security Onion — the network wire. A single-VM evaluation install bundles Suricata, Zeek, and the Elastic Stack into a SOC-in-a-box, and the lab walks the network side of an investigation: generate a detection, then practice the single most important instinct in network IR — pivoting from an alert to the session record, the protocol logs, and the full packet capture to decide whether it's a true positive, a false positive, or the first thread of a larger intrusion. The commercial analog to the Zeek core is Corelight, and the alert-to-evidence pivot is exactly what every enterprise SIEM and NDR platform expects.
Shuffle — the connective tissue. The final lab supplies the orchestration layer: an open-source SOAR that ingests an alert, enriches the indicator, branches on a reputation verdict, notifies a human, and stages a containment action — with the approval gate that keeps an automated false positive from quarantining a production host. This ingest-enrich-decide-act pattern is precisely what Cortex XSOAR, Splunk SOAR, and Tines run commercially.
The Architect's-Eye Throughline
What I wanted these labs to teach isn't "how to run Volatility" or "how to build a Shuffle workflow." Tools change. The patterns underneath them don't — and if you've read the earlier posts in this series, you'll recognize the move, because it's the same one every domain rewards:
You analyze the copy, never the original. Forensics lives or dies on evidence integrity: image first, hash to verify, then analyze the duplicate, with chain-of-custody documenting every hand-off. The Sleuth Kit lab makes that discipline tangible, and it's the same principle a write-blocker enforces in front of seized media in a real case.
The bytes are usually still there — you have to know how to bound them. The carving lab's whole lesson is that a small, disappointing carve is rarely "the data is gone." It's a naive carver failing to delimit data that's sitting right there, and the fix is a content grep and a marker count that prove it before you reach for the right tool. That instinct — distrust the tool's first answer, go verify against ground truth — is the difference between an analyst and an alert-clicker.
An alert is a hypothesis, not a conclusion. Network IR is the pivot from the signature that fired to the packets behind it. Memory and live response extend the same move to volatile state and to the fleet. Every one of these labs trains you to chase a claim down to the evidence before you act on it.
The payoff is the one the domain overview names directly: the analyst who has run all of these understands every seat in the response. A capable SOC runs commercial EDR for fleet-wide live response, keeps a dedicated forensic suite for the disk and memory evidence that may end up in court, and drives the whole workflow through a SOAR. These labs map cleanly onto every part of that — Velociraptor mirrors the EDR role, Sleuth Kit and the carvers mirror the forensic suite, Volatility and LiME mirror its memory analysis, Security Onion mirrors the network-monitoring layer, and Shuffle mirrors the SOAR that ties them together. You learn the discipline on tooling you can run for free, and you carry that fluency into whatever your organization standardized on. You cannot design an incident-response capability you have never operated.
Tested on Real Infrastructure
These aren't aspirational walkthroughs — and that, too, has been the through-line of this whole series. Every step was executed on actual Debian 13 "Trixie" hosts and live container stacks: the ext3-versus-ext4 deletion behavior that decides whether icat can even follow an inode's block pointers; the PATH patch the classic Autopsy web front end needs before it'll launch; scalpel returning a single suspiciously small JPEG when you know several multi-megabyte images are on the disk, and the grep and start-marker count that prove the photos are still there; the Linux symbol-table build that is the real obstacle in memory forensics, not the plugins; Security Onion's appetite for resources and its expected self-signed-certificate warning; and the OpenSearch prep Shuffle's stack demands before it'll come up healthy — the UID-1000 ownership, the disabled swap, the raised vm.max_map_count. When something breaks in the real environment, the lab tells you so and tells you why. A small carve that means "thumbnail truncation, not data loss" rather than "the tool failed" is the kind of thing you only learn by running it.
That's the difference between reading about a control and being able to defend it in a design review.
Put Your Hands On It
If you want to actually walk the full arc — image a disk and recover a deleted file, carve a thumbnail-truncated photo back to full size, pull a typed command out of raw memory, hunt across a fleet with Velociraptor, pivot from a Security Onion alert to the packets, and wire the whole response together with Shuffle — that's all waiting in the lab repository, the 700-plus pages that ship alongside the book.
Grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon
And if you build something with these labs — or break it in an interesting way — I'd genuinely like to hear about it. You can find me at secdoc.tech. The series continues with the next domain soon.
