The fifth in a series on what you actually get when you buy the book. Earlier entries: Two Books for the Price of One, Foundations Before Firepower, Many Calculations Before the Battle, and Know the Ground.
Category 2, network controls, ended on a small surprise: the DNS resolver we'd stood up as a filter had quietly become the best-positioned sensor on the network. Every query a device makes is a statement of intent — what it wanted to reach, when, and how often — and once you're logging them, you're no longer just blocking bad names. You're watching behavior. This is the pivot the post turns on. Network controls block what we can recognize as bad. This category — Category 3, Security Monitoring and Analytics — is about everything else: the signals our infrastructure already produces, and the work of collecting, correlating, and interrogating them until they mean something.
Sun Tzu put the principle plainly twenty-five centuries ago. What lets the wise general move and conquer where ordinary commanders cannot is foreknowledge — not prophecy, but information, gathered and made sense of before the moment it's needed. A SIEM and an EDR are the modern source of that foreknowledge. This category builds both.
The throughline is foreknowledge — and it has to be made
The one idea under the whole category is that the data already exists. Every operating system, application, and network device emits a steady stream of events about who did what and what broke. The problem was never collecting more of it; it's that raw events are noise, and noise is not foreknowledge. Monitoring is the discipline of turning that flood into a small number of meaningful signals — parse it into structured fields, index it so you can ask questions of it fast, and run detection content that surfaces the handful of things actually worth a human's attention. The vendors and the interfaces change; that pipeline — collect, parse, store, detect — does not. Learn it here and you've learned the conceptual surface of every commercial SIEM and EDR anyone will ever sell you.
And there's a reason this matters more than the wall in front of it. Prevention controls get misconfigured, bypassed, or simply outpaced by attacks they were never built to stop. When that happens, the only thing that counts is whether anyone was watching, how much they could see, and how fast they could make sense of it. The field is full of organizations that learned about their own breach from a journalist or the FBI rather than from their own tools — and the gap, almost every time, is not the quality of the firewall. It's monitoring.
Logging and SIEM: Graylog and Wazuh
The first half of the category anchors on two open-source platforms that sit in a genuinely useful sweet spot for learners and small teams. Graylog is the elder of the two — founded in 2009 as centralized log management and grown, over fifteen years, into a full SIEM. The lab installs the Spring 2026 release, 7.1, on a fresh Debian 13 "Trixie" host, standing up the three components it runs on: MongoDB for configuration and metadata, OpenSearch for event storage and search, and the Graylog server itself for collection, parsing, and the UI. Where Graylog casts a wide net over anything that can speak syslog, GELF, or Beats, Wazuh comes at the problem from the endpoint. It started in 2015 as a fork of OSSEC, the venerable host-based IDS, and its defining feature is still the agent — a lightweight thing you put on every monitored host that feeds back logs, file-integrity events, configuration-assessment results, and vulnerability findings, all scored against detection rules mapped to MITRE ATT&CK out of the box. The lab installs Wazuh 4.14 with its single-command assistant, enrolls an agent on the host itself, and trips real alerts: a handful of failed SSH logins, a file touched in /etc, each one landing in the dashboard already mapped to the technique it represents.
Both install on the same kind of fresh Debian box, and I left in the parts that bite — because those are the parts that teach. On Trixie specifically, the old habit of apt-installing Java 17 simply fails; the package is gone from the repositories, and the lab explains why Graylog's bundled JVM is the right answer instead of fighting it. OpenSearch 2.12 and later refuse to install without an admin password handed in inline, and it has to arrive through sudo env, not sudo -E, or APT strips it out, the post-install script aborts half-configured, and you're left repairing directory ownership by hand. None of that is in the vendor quickstart. All of it is what actually happens on Debian 13 — which is the whole point of running the steps on real machines instead of transcribing them from someone else's docs.
The AV half, seen a second way: ClamAV
ClamAV makes its second appearance in the supplement, and the repeat is deliberate. Category 2 used it to teach an architecture lesson — one central scanning daemon serving the whole network instead of an engine installed on every host. Here it anchors the other half of this category, antivirus and EDR, as what it fundamentally is: the canonical open-source signature engine. The lineage is worth a sentence, because it stitches two categories together — Tomasz Kojm wrote ClamAV in 2001, and it's maintained today by Cisco Talos, the same Talos that maintains Snort from Category 2. The lab is short and concrete: install the engine and the clamd daemon, keep signatures current with freshclam, and prove detection works with EICAR — the harmless 68-byte test string every reputable scanner recognizes, and the right way to confirm AV is alive without going anywhere near real malware. ClamAV's honest place in 2026 is server-side scanning of files in transit — mail attachments, uploads, transfers between systems — not desktop protection, and the lab says so plainly. Knowing exactly what a tool is for is half of using it well.
The capstone of the category: from "is this file bad?" to "what is happening here?"
The category saves its most important idea for last, and it's a shift in the question being asked. Antivirus asks: is this file bad? — and answers from a database of known-bad fingerprints, which means it cannot catch what nobody has fingerprinted yet. EDR asks something fundamentally different: what is happening on this endpoint? It continuously records process executions, file modifications, network connections, and parent-child relationships — the full timeline — so that when prevention fails, and over a long enough horizon it always does, you can reconstruct exactly what an attacker did and shut it down.
The lab's tool for this is Velociraptor, and it stands out for a reason that has nothing to do with marketing: it's a genuinely full-featured EDR and DFIR platform that is entirely free, with no trial limits, no community-edition feature gating, and no SaaS-only lock-in. Its lineage is its own recommendation — it was built by Mike Cohen, formerly of Google's GRR Rapid Response project, and is maintained now under Rapid7's sponsorship. Its secret weapon is the Velociraptor Query Language, VQL: a SQL-like language for asking questions of endpoint state — running processes, filesystem contents, persistence artifacts, network connections — across an entire fleet at once. The effect is that hunting and forensics feel less like driving an EDR console and more like querying a database, which happens to be exactly the muscle that transfers to every commercial platform you meet afterward.
The lab installs version 0.76 as both server and client on a single host, enrolls the agent, and runs a first hunt that returns a clean table of every local user. It also includes the kind of detail you only learn by getting it wrong: Velociraptor's GitHub release tag is the minor version, v0.76, while the binary filenames carry the full patch version, v0.76.5 — two different strings, and conflating them is the single most common reason the download 404s. That one line probably saves a reader the evening it cost to discover the first time. The lab is also blunt that this is internet-facing security software with real CVEs in the 0.76 line, so you always run the current patch — an architect's reflex the supplement keeps reinforcing.
Where seeing hands off to fixing
That's the bridge out of the category. Once you can see what's happening — the SIEM correlating events, the EDR recording the timeline — the next question writes itself: what are the weaknesses these tools keep surfacing, and how do you find and close them before someone else does? That's vulnerability and configuration management — scanning, hardening, patching, drift correction — and it's Category 4, where this series goes next.
There's also a longer arc worth naming. The Wazuh stack you stand up here is not a throwaway exercise. It's the same telemetry the AI-powered SOC capstone reaches into at the very end of the supplement — querying the indexer, triaging findings under guardrails, and drafting a daily brief without a human writing it. Build the monitoring layer first; automate the view later. Never the other way around.
The full Category 3 lab — Graylog and Wazuh for logging and SIEM, ClamAV and Velociraptor for antivirus and EDR, all on Debian 13 — is in the supplemental download on the book's GitHub repository, alongside the other seven categories and the AI-powered SOC capstone they build toward.
Grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon
Then stand up Wazuh, put the agent on your own laptop, and trip a few alerts — a couple of bad SSH logins, a file touched in /etc — and watch your own machine narrate itself back to you. It's a quietly clarifying hour. If you build something with it, I'd like to hear about it — you'll find me at secdoc.tech.
