A continuation of Two Books for the Price of One
In the last post, I jumped straight to the top of the spire — the AI Security Automation capstone, where a SIEM triage agent, a vulnerability remediation agent, and an orchestrator come together into a guardrailed, AI-assisted SOC reporting pipeline. It's the most exciting thing in the supplemental download, so it earned its own write-up.
But a capstone, by definition, sits on top of something. You can't appreciate the spire if you've never seen the cathedral. So this post walks back down to ground level and shows you the rest of that "second book" or "secret menu"— the full lab curriculum in the Chapter 9 supplemental download, the part that sets the foundation that everything to the capstone later orchestrates.
If the first post answered "what's the most impressive thing I get when I buy the book?", this one answers the more honest question: "what am I actually going to spend my weekends doing?"
The half of the book that doesn't fit on a shelf
Quick recap for anyone arriving here first. The Cybersecurity Architect's Handbook, Second Edition — An Architect's Guide to Designing, Building, and Defending the Modern Enterprise, published by Packt — runs to nearly 700 pages in print. That's the framework: how to think like an architect, how to translate strategy into controls, how to carry a design from a whiteboard to a defensible, governed reality.
The companion GitHub repository holds 700+ more pages of hands-on material that never fit between two covers. Page counts, editorial schedules, and the unforgiving arithmetic of print publication force difficult choices, and a great deal of context, nuance, and depth ends up on the cutting-room floor. The supplemental downloads are where I put it back. Two books' worth of material for the price of one: the reasoning in print, the doing online.
And the doing is deliberately structured. There's a Sun Tzu line I keep returning to in the chapter — "He will win who, prepared himself, waits to take the enemy unprepared." The security marketplace doesn't suffer from a shortage of tools; it suffers from an excess of them. Architects don't build programs by accumulating products — they build them by making deliberate choices. A control that cannot be operated effectively is not a control. It is overhead. The labs exist to give you the operational fluency to tell the difference.
Why an architect's book teaches the fundamentals
Here's a fair objection: why does a book for cybersecurity architects spend time standing up a Linux box and explaining version control?
Because the role draws people from networking, software development, systems administration, governance, and beyond — and no two paths cover exactly the same ground. The architect who came up through GRC may have never compiled a kernel module; the one who came up through pentesting may have never written a policy. The early labs deliberately establish a shared starting point so that wherever you're coming from, the later exercises land.
So before any security tooling appears, the curriculum builds the bench:
- Version control with Git and GitHub. Almost every lab produces files — rule sets, configs, scripts, saved output — and you'll change them repeatedly. Git records the history, shows you exactly what changed, and lets you get back to a working state. It's a guide you can skip if you live in Git already, and one you'll be glad exists if you don't.
- Choosing a hypervisor. A clear-eyed Type 1 vs. Type 2 decision framework — Proxmox VE, Hyper-V, XCP-ng, vSphere on the dedicated side; VirtualBox, VMware Workstation/Fusion, Parallels on the desktop side — plus the things people forget, like enabling VT-x/AMD-V, nested virtualization, and the reality that RAM is almost always the bottleneck.
- Installing and hardening Debian 13 "Trixie" as a server. Nearly every other lab begins "on a fresh Debian 13 host…", so this one builds that host properly, exactly once: minimal install, key-based SSH, a default-deny nftables firewall, fail2ban, unattended security upgrades, kernel and account hardening, and an automated audit to confirm the result. Hardening the base OS isn't a side task that precedes the "real" lab. In a defense-in-depth model, it is the real lab — because the weakest layer wins, and a SIEM sitting on a soft host is a high-value target with the front door open.
- Installing Docker Engine v29 on Debian 13. The current container baseline, from the official repository rather than the perpetually-behind distro package, with the architectural context (OCI, containerd, runc) an architect needs to reason about container platforms rather than just run them.
None of this is filler. It's the difference between a reader who follows the labs and one who understands them.
The eight operational domains
With the foundation in place, the curriculum organizes the security toolset into eight categories — the same deliberate-selection discipline the chapter argues for, applied hands-on:
- Category 1 — Threat Modeling and Risk Assessment
- Category 2 — Network Security Controls
- Category 3 — Security Monitoring and Analytics
- Category 4 — Access Control and Data Protection
- Category 5 — Vulnerability and Configuration Management
- Category 6 — Incident Response and Investigation
- Category 7 — Application Security Testing
- Category 8 — Enterprise and Cloud Security
Every lab opens with a Technology Overview that answers three questions before the first command runs: what the tool is, why practitioners use it, and what it actually delivers in a security context. That's intentional. The practitioner who understands why a control exists will configure it more accurately than one who's simply following a numbered list.
Open source that teaches the enterprise
Every lab is built around free, open-source tooling that runs on commodity hardware — Snort, Graylog, Greenbone (OpenVAS), Wazuh, ClamAV, Velociraptor, Vault, Terraform, OPNsense, Ansible, and more. That's not a budget compromise. It's a teaching strategy.
These tools are the conceptual ancestors of the commercial platforms you'll meet in the enterprise. Snort's rule language is mirrored in commercial IDS products. Graylog's pipeline and search syntax maps onto Splunk and Elastic. Greenbone's NVT-based scanning is the foundation Qualys and Tenable built their services on. Get fluent in the open-source version and you've earned the vocabulary to evaluate, deploy, and operate the commercial equivalent — without depending on a vendor's training track to do it. Each lab notes its commercial counterpart for exactly that reason, because evaluating vendor claims and building the business case is core architect work.
And because every lab is built and tested against real Debian virtual machines running genuine tooling, the failures, version quirks, and "why won't this connect" moments are baked into the instructions rather than glossed over. You learn the way you'll actually work: by getting it wrong, reading the error, and fixing it.
One caution runs through all of it. Open source is not a miracle cure. The recent wave of supply-chain attacks — the npm compromises, SolarWinds before them — has shown that threat actors increasingly find it easier to embed themselves in the development process than to break down the front door. Verify your repositories. Use your lab to do it. Trust, but verify.
How it all comes together
Now the capstone makes sense in context. Security Automation with AI Agents isn't yet another standalone tool — it's the point where the curriculum folds back on itself. The SIEM you stood up in the monitoring labs. The scanner you deployed in the vulnerability-management labs. The hardened hosts, the credentials, the network paths. The capstone treats all of it as raw material and asks you to orchestrate it into an automated, AI-assisted SOC reporting mechanism — read-only by design, with secrets redacted before anything leaves the host, hostile input assumed, and least-privilege controls throughout.
That's why the foundations matter. You can't automate a SOC you haven't built. The eight categories are the SOC; the capstone is what happens when an architect's judgment is applied on top of it. If you want that whole story — the guardrails, the orchestrator, the daily brief that lands in your inbox — the previous post covers it in detail.
Two books, one purpose
The print edition gives you the architectural reasoning. The supplemental download gives you the hands to act on it — a complete, evolving lab suite that takes you from an empty hypervisor to a working, AI-assisted security operation, entirely on hardware you can pick up secondhand and tooling that costs nothing but your attention.
Grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon
Then clone the repo, stand up that first Debian box, and start building. If you finish a category — or break one in an interesting way — I'd genuinely like to hear about it. You'll find me at secdoc.tech.
