Appendix C: Defensive Tool Reference

Tools do not make you secure — process, architecture, and people do (Theme 1). But a defender who cannot name the right tool for a job wastes hours building by hand what a free, mature project already does well. This appendix is a categorized field reference to the open-source and freely available tools a blue team actually reaches for, organized by the function they serve and mapped to the chapter that teaches the concept behind them. It is deliberately biased toward open-source: not because commercial tools are inferior — several are excellent — but because the open tools are the ones a student can install in a lab tonight, and because understanding the open version teaches you what the commercial dashboard is doing underneath.

Every tool here is a defensive tool: it analyzes, audits, monitors, hardens, or investigates. We do not catalog offensive tooling — exploitation frameworks, credential-dumpers, C2 servers — because this is the defender's volume. A handful of tools below (nmap, the vulnerability scanners, the secrets scanners) are dual-use: the same scanner that an attacker runs to find your weaknesses is the one you run to find them first. For those, treat the Authorization column as load-bearing, not decorative.

⚖️ Authorization & Ethics: Scanning, probing, and credential-searching are defensive only when the target is yours or you have explicit written authorization to test it (a signed scope, a penetration-test agreement, a bug-bounty program's rules). Pointing any scanner — port, vulnerability, web, or secrets — at a system you do not own or are not authorized to test is, in most jurisdictions, a crime, regardless of your intent. Inventory your network. Scan your code. Audit your cloud account. The tooling is identical; the authorization is what separates a defender from an intruder.

A note on versions: this reference deliberately does not pin version numbers, because they change faster than print and the wrong number is worse than none. Install the current release from the project's official source, and verify download integrity (checksums or signatures) before running anything — a supply-chain lesson from Chapters 29 and 31 that applies to your own toolkit too.

C.1 Network analysis and visibility

The defender's first question in almost any investigation is what is actually on the wire, and what is talking to what? These tools answer it. They map to the network-security spine of Part II — fundamentals and monitoring (Chapters 6 and 10), the firewall/IDS/IPS layer (Chapter 7), and DNS/email/web defenses (Chapter 9).

Wireshark and tcpdump are for packet-level questions; Zeek is for connection-level questions at scale (you do not grep terabytes of PCAP — you query Zeek's logs). Suricata/Snort add known-bad detection on top of that traffic. The pattern from Chapter 10 holds: full packet capture is the ground truth but is expensive to keep; network metadata (Zeek logs, flow records) is the affordable, query-friendly layer you actually live in day to day.

🔗 Connection: nmap is the canonical dual-use tool. The penetration tester in the offensive companion volume uses it to find a way in; you (Chapters 6–7) use it to discover the host nobody documented and to verify that your default-deny firewall actually denies — scanning your own perimeter from outside and confirming only the intended ports answer. Same tool, opposite chair, and the authorization is the difference.

C.2 SIEM, log management, and analytics

Logs are the ground truth (a conviction threaded from Chapter 1). A Security Information and Event Management (SIEM) platform centralizes, normalizes, correlates, and alerts on them. These tools build the SOC's nervous system of Chapter 21 and feed the detection and hunting of Chapter 22. They are described here neutrally — choice depends on scale, budget, and existing stack, not on any ranking.

The right way to read this table is not "which SIEM is best?" but "which centralization and query layer fits my data volume and team?" The skills transfer: the normalization, correlation-rule, and alert-tuning concepts of Chapter 21 are the same whether the query language is SPL, KQL, Lucene/EQL, or SQL. Learn the concept (Chapter 21's normalize/correlate logic), and you can drive any of these.

⚠️ Common Pitfall: Buying or deploying a SIEM and treating the dashboard as the work. An unwatched SIEM with no tuned detections and no analyst to act on alerts is the failure mode called out in Chapters 1, 15, and 21 — technology with no process and no people. The tool in C.2 is the substrate for detection-as-code (C.10); it is not detection by itself.

C.3 Endpoint and EDR telemetry

The host is where a foothold becomes a disaster, and where the richest investigative telemetry lives (Chapter 11's EDR-versus-antivirus argument). These open tools generate or query that telemetry — they are the sensors that feed Sections C.2 and C.10.

The crucial pairing from Chapter 11 recurs here: you constrain what the host permits (hardening — Section C.6) and you record what happens anyway (Sysmon, osquery, auditd, EDR). The second category is what a SOC analyst lives in during an investigation; the Sysmon-plus-SIEM combination is the most common free starting point for Windows behavioral detection.

C.4 Vulnerability scanning

The most reliably exploited vulnerabilities are known flaws with patches available that nobody deployed yet (Chapter 11's patch-management argument; Chapter 23's prioritization). These scanners find them so you can fix them in priority order — for authorized assets only.

Note the two families. Network/remote scanners (OpenVAS, Nuclei, Nikto) probe from the outside and require authorization because they actively touch a target. Local/artifact scanners (Trivy, Grype, Lynis) inspect your own images, filesystems, and hosts and are safe to run constantly in your own pipeline. The Chapter 23 lesson — prioritize by CVSS and real-world exploitation (KEV) and exploit-prediction (EPSS) and asset context, not by raw count — applies to the output of all of them: a scanner that produces 4,000 findings nobody triages is the SIEM pitfall in another form.

🔗 Connection: The Log4Shell pattern (CVE-2021-44228) from Chapters 12, 23, and 29 is exactly what Trivy and Grype exist to catch before it becomes your 3 a.m. emergency — a vulnerable dependency buried deep in a build, found by scanning the image and the SBOM rather than waiting for the exploit traffic to find you.

C.5 Cloud security posture

In the cloud, most breaches are self-inflicted misconfigurations of the layers you control — public storage and over-broad IAM (Chapter 15). These tools audit your own cloud accounts against secure baselines, implementing Cloud Security Posture Management (CSPM) for the always-yours configuration layers.

The Chapter 15 hierarchy is the way to use these: prevent with guardrails (OPA, Checkov, tfsec — catch it in the IaC before it exists), detect with CSPM (Prowler, ScoutSuite, native — catch what slipped through), and protect the running workload with CWPP (the runtime/vulnerability tooling of C.3/C.4 adapted to cloud). All of them are read-only or pipeline-side and run against your accounts — there is no authorization ambiguity when you are auditing infrastructure you own.

C.6 Hardening and configuration auditing

Hardening is attack-surface reduction against a benchmark (Chapter 11). These tools either apply a hardened baseline or audit a system against one — the "is this running system actually compliant?" question that bluekit's audit_baseline (Chapter 11) models in miniature.

The discipline behind every tool here (Chapter 11): adopt the benchmark, test it against real workloads before enforcing, document every deliberate deviation, then enforce and audit. A standard nobody verifies is a standard nobody follows — these are the verification half.

C.7 Incident response and digital forensics

When prevention fails (it will — Theme 4), these tools preserve evidence and reconstruct what happened, implementing the forensic discipline of Chapter 25 and supporting the response lifecycle of Chapter 24. Order-of-volatility and chain-of-custody (Chapter 25) govern how you use them.

The Chapter 24/25 partnership shows here: incident response (Chapter 24) stops the bleeding — isolate, disable, block — while forensics (Chapter 25) establishes the truth — what was touched, how they got in, what left. KAPE and Velociraptor serve the urgent triage; Volatility, Autopsy, and Plaso serve the deep reconstruction. Acquire in order of volatility (memory before disk), work on copies, and hash everything (bluekit's evidence_hash, Chapter 25) so the evidence holds up.

⚖️ Authorization & Ethics: Forensic tools read everything — deleted files, browser history, private messages. Use them only on systems and data you are authorized to investigate (your organization's assets, with appropriate HR/legal involvement for employee devices), preserve chain of custody, and treat what you find with the discretion an investigation demands. The lost-device and insider-threat playbooks in Appendix D flag exactly where legal must be in the loop.

C.8 Cryptography and TLS testing

Cryptography is only as good as its configuration (Chapters 4 and 5). These tools generate, inspect, and test cryptographic material and TLS deployments — verifying that the encryption protecting your own services is actually strong.

testssl.sh and SSLyze answer the practical, audit-facing question "is the TLS on this service actually strong, and is the certificate about to expire?" — the kind of finding bluekit's cert_days_left (Chapter 20) automates. Hashcat and John are dual-use: the same engine that cracks passwords for an attacker is what a defender runs, under authorization, to prove that the organization's password policy resists cracking — pairing with Chapter 16's strength and breached-password checks.

C.9 Secrets scanning

A long-lived credential committed to source control is the single most common serious cloud finding (Chapter 15) and the core of Chapter 20's secrets-management discipline. These tools find secrets before an attacker does — in your own repositories.

The Chapter 20/31 lesson: scanning is the backstop, not the fix. The real solution is to never put the secret in the code at all — use a secrets manager or vault and short-lived, rotatable credentials (the roles-over-long-lived-keys argument from Chapter 15). Run bluekit's scan_secrets concept (Chapter 20) and these tools as pre-commit hooks and CI gates so a secret is caught before it lands in history, where rotating it (not deleting the commit) becomes the only safe remediation.

⚠️ Common Pitfall: Deleting a leaked secret from the latest commit and assuming it is gone. Git history is forever and is mirrored across every clone and fork; a secret committed even once must be treated as compromised and rotated, not merely removed. Secrets scanners search history precisely because the secret you deleted yesterday is still in the log.

C.10 Detection-as-code

The highest-leverage shift in modern defense is treating detections as version-controlled, testable, shareable code (Chapter 22). These formats and tools let you write, share, and run detection logic portably — the detection content layer that sits on top of the SIEM (C.2) and endpoint telemetry (C.3).

This is where Chapters 21 and 22 converge into practice. Sigma decouples your detection logic from your SIEM vendor, so the rules survive a platform migration and can be shared across the community mapped to ATT&CK. YARA does the same for file/memory indicators. Atomic Red Team closes the loop — you write the Sigma/YARA rule, run the corresponding atomic test in your lab, and confirm the alert actually fired, turning detection from hope into a tested control. Coverage is measured against MITRE ATT&CK (Chapter 22's attack_technique; Chapter 36's coverage metric), so the framework, the format, and the validation tool form one workflow.

🔗 Connection: Detection-as-code is the same engineering discipline the whole book argues for, applied to detections: version-controlled, peer-reviewed, tested, and measured against a framework (ATT&CK). It is what turns the SIEM of Chapter 21 from a log bucket into a maturing detection capability, and it is the content that the metrics of Chapter 36 (mttd, coverage) actually measure.

C.11 Choosing and combining tools

A defender does not need every tool here — they need the right combination for their environment and the discipline to operate it. A pragmatic open-source starter stack for a small team, mapped to the functions above:

• Visibility: Zeek + Suricata on a network tap (C.1); Sysmon + osquery on the hosts (C.3).
• Centralization: Wazuh or the Elastic/OpenSearch stack as the SIEM (C.2).
• Detection content: Sigma rules (converted to your SIEM) + YARA, validated with Atomic Red Team (C.10).
• Posture: Lynis/OpenSCAP for host hardening audits (C.6); Prowler/ScoutSuite for cloud (C.5); Trivy + Gitleaks in CI (C.4, C.9).
• Response: Velociraptor + KAPE for triage, Volatility + Autopsy + Plaso for deep forensics (C.7).

Three closing principles carry across every category:

1. The tool is the substrate; the process is the security. A SIEM with no tuned detections, a scanner whose findings nobody triages, a CSPM dashboard nobody acts on — each is the recurring failure of "technology without process and people." Every tool here serves a process taught in the chapters; the tool does not replace it (Theme 1).
2. Authorization is non-negotiable for anything that probes. Port scanners, vulnerability scanners, web scanners, secrets scanners, and password auditors are defensive only against assets you own or are explicitly scoped to test. The same nmap, OpenVAS, or Hashcat is a defender's asset on your network and a crime on someone else's. When in doubt, do not scan.
3. Verify your own supply chain. Download tools from official sources, check signatures or checksums, and keep them updated — the Chapter 29/31 lesson applied to your toolkit, because a defender compromised through a backdoored tool is no defender at all.

The authoritative, current source for any tool is its own project documentation; treat this appendix as a map of what exists and what it is for, not as installation instructions. The chapters teach the concepts; these tools are how you practice them, in your own lab, on your own systems, under your own authorization.