Appendix F: Hardening Checklists

A freshly installed system is configured for a vendor's convenience, not your security, and the dangerous attack surface is mostly intended behavior you have not switched off (Chapter 11). Hardening is the deliberate reduction of that surface against a benchmark. This appendix is a set of prioritized, actionable checklists — in the spirit of the CIS Benchmarks — for the platforms a defender most often hardens: Windows, Linux, macOS, network devices/firewalls, cloud accounts, and web servers. They map to the host-hardening discipline of Chapter 11 and the cloud-security discipline of Chapter 15.

These checklists summarize and point to authoritative sources — they do not reproduce them. The definitive, exhaustive standards are the CIS Benchmarks (Center for Internet Security), the DISA STIGs (for U.S. government systems), vendor security baselines (Microsoft, Apple, AWS, Azure, GCP), and NIST SP 800-123 (general server security). Each of those is a long, version-specific document maintained by a community of practitioners; this appendix is a prioritized starting map, not a substitute. Always work from the current benchmark for your exact platform version, because settings and identifiers change between releases — and never enforce a benchmark blind. The Chapter 11 discipline governs all of it: adopt the benchmark, test it against your real workloads in a non-production environment, document every deliberate deviation and its business reason, enforce the result as your baseline, and then audit against that baseline (a standard nobody verifies is a standard nobody follows). A Level 2 setting that disables a legacy protocol can take down a banking application on a Monday morning — harden boldly, deploy carefully.

How to read these checklists. Each platform's items are grouped by theme — Accounts & authentication, Patching, Services & attack surface, Logging & monitoring, Encryption, Network — roughly in priority order within and across themes (the highest-leverage controls first). Use the checkboxes as a literal worklist. CIS profile Levels are noted where they matter: Level 1 = strong security with minimal functional impact (most systems); Level 2 = stricter, for high-security hosts, may break functionality and needs testing. Choosing a level per system role is itself a risk decision (Chapter 11).

⚖️ Authorization & Ethics: Apply hardening only to systems you own or administer. These are configuration changes to your assets; test them before enforcing on production, and keep an out-of-band record of what you changed and why so an audit (and your future self) can follow it.

F.1 Windows Server / endpoint

Windows dominates the enterprise and is correspondingly the most-attacked platform; the controls below are the ones that would have neutralized Meridian's breach-opening file server (Chapter 11, §11.2). Enforce at scale with Group Policy / security baselines (which also correct drift) — hardening fifteen hundred machines by hand is not the job; configuring policy that configures them is.

Accounts & authentication - [ ] Deploy LAPS (Local Administrator Password Solution) so every machine's local admin password is unique, random, and rotated — kills pass-the-hash/pass-the-password lateral movement. - [ ] Disable the built-in local Administrator account (use LAPS-managed access); rename it where required by policy. - [ ] Set LAN Manager auth level to "Send NTLMv2 only; refuse LM & NTLM" — blocks downgrade to weak, crackable legacy auth. - [ ] Enforce a strong password/passphrase policy and account lockout (e.g., ≥14-char minimum, lockout threshold). - [ ] Require MFA for remote access and privileged accounts (phishing-resistant where possible — Chapters 1, 16). - [ ] Restrict who can log on locally and via RDP; "Deny log on through RDP" for local Administrators on member servers (blocks the stolen-local-admin → RDP hop). - [ ] Apply least privilege: minimize Domain Admins; tier administrative accounts; no day-to-day work from privileged accounts (Chapter 19).

Patching - [ ] Run patch management as a process with risk-based timelines (fastest for KEV-listed, internet-facing, critical flaws) and deployment rings (pilot → broad → critical) to catch a bad patch early. - [ ] Verify installation (re-scan), not just deployment — measure installed coverage and chase the unpatched tail. - [ ] For systems that cannot be patched on demand, apply compensating controls (segmentation, restricted access, intensified monitoring) and a documented, expiring risk acceptance.

Services & attack surface - [ ] Disable SMBv1 (client and server) — removes the WannaCry/NotPetya-class lateral-movement protocol. - [ ] Set PowerShell execution policy to AllSigned (and consider Constrained Language Mode); disable Windows Script Host where not required. - [ ] Disable AutoRun/AutoPlay on all drives — neutralizes USB- and share-borne auto-execution. - [ ] Remove or disable unneeded roles, features, and services (least functionality). - [ ] Deploy application allowlisting (AppLocker or, preferably, WDAC) — default-deny for code execution; start with servers (stable software set). - [ ] Enable Microsoft Defender ASR rules (block Office child processes, LSASS credential theft, executable content from email, etc.) and Tamper Protection (so an attacker cannot quietly disable the defenses).

Logging & monitoring - [ ] Enable PowerShell Script Block Logging, module logging, and transcription. - [ ] Enable process-creation auditing (Event ID 4688) with command-line capture. - [ ] Deploy Sysmon fleet-wide with a tuned config (process, network, image-load telemetry); forward all of the above to the SIEM (Chapter 21). - [ ] Deploy EDR everywhere (the behavioral sensor that catches novel/fileless/living-off-the-land attacks — Chapter 11).

Encryption - [ ] Enable BitLocker full-disk encryption, with keys escrowed/recoverable centrally and sealed to the TPM. - [ ] Enable Secure Boot (UEFI) so only validly signed boot components load — closes the gap below the OS (bootkits/rootkits). - [ ] Require TLS for management interfaces and disable legacy protocols (SSLv3/TLS 1.0/1.1).

Network (host) - [ ] Set the host-based firewall to default-deny inbound, permitting only required ports by exception. - [ ] Restrict and monitor remote management (RDP/WinRM) — limit source, require MFA, prefer a bastion/jump host.

Source map: CIS Microsoft Windows Server / Windows Benchmarks; Microsoft Security Baselines (Security Compliance Toolkit); DISA Windows STIGs. Audit with CIS-CAT, the Microsoft Security Compliance Toolkit, or osquery (Appendix C).

F.2 Linux server

Linux is leaner than Windows by default but still ships listening services and permissive settings; it also offers something structurally powerful — mandatory access control that confines even root-owned processes (Chapter 11, §11.3).

Accounts & authentication - [ ] No direct root login over SSH (PermitRootLogin no); administrators escalate via sudo so every privileged action is attributable. - [ ] Key-based SSH only (PasswordAuthentication no) — defeats password-spraying/credential-stuffing against internet-facing SSH. - [ ] Limit SSH to a single group (AllowGroups) and set MaxAuthTries low; change defaults thoughtfully. - [ ] Enforce a strong password/passphrase policy and lockout (PAM); audit sudoers for over-broad grants. - [ ] Audit setuid/setgid binaries and world-writable files — both are privilege-escalation magnets; remove what is unneeded. - [ ] Disable or lock unused accounts; ensure no accounts have empty passwords.

Patching - [ ] Apply security updates on risk-based timelines (fast for KEV/internet-facing/critical); enable security-update channels. - [ ] Verify patch state across the fleet (e.g., osquery) and track the unpatched tail.

Services & attack surface - [ ] Enumerate listening sockets (ss -tulpn) and disable/mask every service the role does not require; remove unneeded packages (a removed binary cannot be abused — stronger than disabling). - [ ] Remove compilers/interpreters not needed in production where feasible. - [ ] Apply least functionality broadly — minimal install profile, no unused daemons.

Mandatory access control & sandboxing - [ ] Keep SELinux in enforcing mode (RHEL family) or AppArmor profiles loaded and enforcing (Ubuntu/SUSE) — confines a compromised service to its policy even if it gains root. Never setenforce 0 as a debugging reflex — read the denial and grant the specific access instead. - [ ] Benefit from seccomp via container runtimes and systemd SystemCallFilter= to narrow the kernel interface.

Logging & monitoring - [ ] Enable and tune auditd (system calls, file access, command execution) for forensic-grade host logging. - [ ] Centralize logs to the SIEM; protect logs from tampering (ship off-host). - [ ] Deploy EDR/HIDS (e.g., Wazuh agent) with file-integrity monitoring on critical paths.

Encryption - [ ] Enable full-disk encryption (LUKS) on systems holding sensitive data; manage keys/recovery. - [ ] Require TLS for services; disable weak protocols/ciphers (validate with testssl.sh/SSLyze — Appendix C). - [ ] Enable Secure Boot where supported.

Network (host) - [ ] Set the host firewall (nftables/firewalld/iptables) to default-deny inbound; permit only required ports. - [ ] Restrict management access by source; prefer a bastion/jump host; disable unused network-facing kernel features.

Source map: CIS Distribution Independent Linux Benchmark and per-distro CIS Benchmarks (Ubuntu, RHEL, etc.); DISA Linux STIGs; NIST SP 800-123. Audit with OpenSCAP/SCAP Security Guide, Lynis, or CIS-CAT (Appendix C).

F.3 macOS

macOS is well-engineered for security out of the box; in the enterprise the failure is almost never the platform and almost always the management gap (Chapter 11, §11.4). The single most important decision is to manage Macs centrally in the first place, via Mobile Device Management (MDM), bringing them under the same baseline, patch, and monitoring regime as everything else.

Management & accounts - [ ] Enroll every Mac in MDM — the mechanism that turns "defaults a user might have changed" into an enforced, provable baseline and gives the SOC visibility. - [ ] Enforce standard (non-admin) user accounts for daily use; restrict local admin; require strong passwords and screen-lock with short timeout. - [ ] Require MFA for corporate sign-in/SSO; integrate with identity provider.

Patching - [ ] Enforce automatic security updates and a managed update policy via MDM; track compliance and the unpatched tail.

Services, integrity & application control - [ ] Keep System Integrity Protection (SIP) enabled (kernel-enforced protection even from root) — a request to disable it is a red flag. - [ ] Keep Gatekeeper enabled so only signed/notarized software runs by default; restrict user bypass via MDM. - [ ] Disable unneeded sharing services (screen sharing, file sharing, remote login) unless required and controlled. - [ ] Treat XProtect as built-in baseline malware blocking, not a substitute for enterprise EDR.

Logging & monitoring - [ ] Deploy EDR on every Mac, reporting to the same SOC console as the rest of the fleet. - [ ] Forward unified logs / endpoint telemetry to the SIEM where supported; refuse to have an unmonitored class of endpoint.

Encryption - [ ] Enforce FileVault full-disk encryption via MDM, with recovery keys escrowed centrally (or you will eventually be unable to recover one). - [ ] Use the Secure Enclave/hardware-backed key storage; enable firmware password/recovery protections per the baseline.

Network (host) - [ ] Enable the built-in application firewall; restrict inbound services. - [ ] Manage VPN/SSO and certificate trust through MDM; remove standing trust for unmanaged profiles.

Source map: CIS Apple macOS Benchmark; Apple Platform Security guide and macOS Security Compliance Project (mSCP, with NIST 800-53 mappings); DISA macOS STIG. Audit via MDM compliance reporting and Lynis (Appendix C).

F.4 Network devices and firewalls

Routers, switches, and firewalls are the connective tissue of the network and a high-value target — compromise one and an attacker controls traffic flow and visibility. These harden the infrastructure behind the segmentation and default-deny of Chapters 6 and 7.

Accounts & authentication - [ ] Change all default credentials and remove vendor/default accounts — default creds on network gear are a top, continuously-scanned weakness. - [ ] Use centralized authentication (TACACS+/RADIUS) with individual admin accounts (attributable), and MFA for administrative access. - [ ] Enforce role-based access and least privilege for device administration; separate read-only from change roles. - [ ] Disable unused local accounts; set strong enable/privileged-mode secrets.

Management plane & services - [ ] Disable insecure management protocols (Telnet, HTTP, SNMPv1/v2c) — use SSH, HTTPS, and SNMPv3 only. - [ ] Restrict management access to a dedicated management network/VLAN and specific source addresses (out-of-band management plane); never expose admin interfaces to the internet. - [ ] Disable unused services and interfaces (least functionality); turn off source-routing and other legacy/abusable features per vendor hardening guides.

Firewall rule hygiene (Chapter 7) - [ ] Enforce default-deny — permit only explicitly required traffic; deny and log the rest. - [ ] Review rules regularly; remove stale/overly-broad rules; eliminate any any/any permits and any management ports exposed to untrusted zones. - [ ] Implement network segmentation (zones/DMZ, Chapter 6) and least-privilege flows between segments. - [ ] Keep IDS/IPS signatures (Suricata/Snort) current and tuned; ensure logging of denies and alerts.

Patching & integrity - [ ] Keep firmware/OS updated on a risk-based schedule; subscribe to vendor advisories (network-gear CVEs are heavily exploited). - [ ] Verify firmware integrity (vendor signatures) and back up configurations securely; protect configs from tampering.

Logging & monitoring - [ ] Send syslog/NetFlow to the central SIEM/collector; ensure NTP is configured so timestamps correlate. - [ ] Alert on configuration changes and administrative logins to network devices.

Encryption - [ ] Use strong, current ciphers for management (SSH/HTTPS) and for any VPN/site-to-site tunnels; retire weak/legacy crypto.

Source map: CIS Benchmarks for Cisco/Juniper/Palo Alto/etc.; DISA Network STIGs; vendor hardening guides. The firewall-rule and segmentation discipline is Chapters 6–7.

F.5 Cloud accounts (AWS / Azure / GCP baseline)

In the cloud, most breaches are self-inflicted misconfigurations of the layers you control — public storage and over-broad IAM (Chapter 15). The highest-leverage controls are guardrails that make the dangerous state structurally impossible, backed by continuous CSPM detection. This is a provider-agnostic baseline; map each item to your provider's equivalent.

Identity & access (identity is the new perimeter) - [ ] Protect and stop using the root/global-admin account — enable MFA on it, remove its access keys, and operate through least-privilege roles/identities instead. - [ ] Require MFA for all human users (phishing-resistant where possible); enforce via policy/conditional access. - [ ] Apply least-privilege IAM — no "Action": "*" / "Resource": "*" policies; right-size with the provider's access analyzer; treat every wildcard as a finding to justify or remove. - [ ] Prefer roles and short-lived credentials over long-lived access keys; forbid long-lived keys in code (scan with Gitleaks/TruffleHog — Appendix C). - [ ] Add policy conditions (require MFA, restrict by network) on sensitive actions.

Guardrails (preventive — the most powerful control here) - [ ] Enable account-wide block-public-access for object storage (e.g., S3 Block Public Access) so a public bucket is impossible regardless of any single engineer's setting. - [ ] Use organization-wide guardrails (AWS Service Control Policies / Azure Policy / GCP Org Policy) to deny disabling logging, opening security groups to 0.0.0.0/0, or creating resources outside approved regions — un-overridable even by an account admin. - [ ] Apply policy-as-code on infrastructure-as-code (OPA/Conftest, Checkov, tfsec) to reject public buckets and wide-open rules before they are applied (Chapter 31).

Storage, data & encryption - [ ] Default object storage and databases to private and encrypted at rest; make the secure state the default. - [ ] Enable encryption at rest explicitly (it is a shared responsibility — available but often off until you turn it on) and manage keys. - [ ] Require TLS in transit and reject plaintext; audit for any public/unencrypted data stores.

Network - [ ] No security-group/NSG/firewall rule opening a sensitive port (22, 3389, database ports) to 0.0.0.0/0 — restrict source to app subnets or a bastion. - [ ] Harden the instance metadata service (e.g., enforce IMDSv2) to break the SSRF → credential-theft chain (Chapter 15). - [ ] Segment with VPCs/subnets and least-privilege flows.

Logging & detection - [ ] Enable the cloud audit log in all regions (AWS CloudTrail / Azure Activity & Entra logs / GCP Cloud Audit Logs) — the cloud records every API call if you turn it on. - [ ] Protect the log from deletion — deliver to a separate, locked-down account/bucket with object-lock; an erasable log is theater. - [ ] Wire high-value detections to alerts: a bucket becoming public, an IAM policy granting *, a 0.0.0.0/0 rule, logging being disabled (StopLogging/DeleteTrail — a top-priority alert), root usage, new access keys, impossible-travel logins. - [ ] Run CSPM continuously (Prowler/ScoutSuite or native — Appendix C) against the CIS cloud benchmark, with public-exposure and logging-disabled findings routed to the SOC; run CWPP for running workloads.

Source map: CIS AWS / Azure / GCP Foundations Benchmarks; AWS/Azure/GCP Well-Architected security pillars and provider security baselines; the shared-responsibility model. Remember: you must evidence the customer side of the line yourself (Chapter 15).

F.6 Web servers

Web servers are internet-facing by definition and among the most-probed assets; hardening them shrinks the surface that automated scanners and exploit traffic hit continuously (Chapters 9, 13). This covers the server and its configuration; the application's own code security is the OWASP-driven subject of Chapters 12–13.

Accounts & process - [ ] Run the web server as a dedicated, non-privileged (non-root) user — so a compromise of the service is confined (and MAC/AppArmor confines it further, F.2). - [ ] Restrict file-system permissions so the web user can read only what it must serve and write only where it must. - [ ] Secure and restrict administrative access to the server host (see F.1/F.2).

Attack surface & configuration - [ ] Disable unneeded modules, handlers, and HTTP methods (e.g., TRACE); remove default sites, sample apps, and documentation. - [ ] Suppress version/banner disclosure (server tokens) so you do not advertise software/version to scanners. - [ ] Disable directory listing; ensure error pages do not leak stack traces or internal paths. - [ ] Remove or restrict any administrative/status endpoints; do not expose them publicly.

TLS & encryption - [ ] Serve HTTPS only; redirect HTTP→HTTPS and enable HSTS. - [ ] Use TLS 1.2/1.3, disable SSLv3/TLS 1.0/1.1 and weak ciphers; keep certificates valid and monitored for expiry (cert_days_left, Chapter 20). Validate with testssl.sh/SSLyze (Appendix C). - [ ] Use strong key sizes and modern cipher suites per current guidance.

Security headers & app-layer protections - [ ] Set security response headers: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy. - [ ] Place a Web Application Firewall (WAF) in front for the common app-layer attack classes (Chapter 13) — a layer in depth, not a substitute for secure code. - [ ] Validate input and encode output at the application layer (OWASP Top 10, Chapters 12–13) — the WAF assumes the app will have flaws.

Patching - [ ] Keep the web server, modules, runtime, and dependencies patched on a fast, risk-based schedule (internet-facing → tight SLA); scan images/dependencies (Trivy/Grype — Appendix C) for the Log4Shell-class vulnerable dependency.

Logging & monitoring - [ ] Enable access and error logging; forward to the SIEM; ensure NTP for correlatable timestamps. - [ ] Alert on attack indicators (scanner signatures, WAF blocks, auth failures) and unexpected configuration changes.

Network - [ ] Place the server in a DMZ/segmented zone (Chapter 6); expose only 443 (and 80 for redirect) to the internet; restrict origin/back-end traffic. - [ ] Apply rate-limiting and DDoS protections appropriate to exposure.

Source map: CIS Benchmarks for Apache HTTP Server, NGINX, and Microsoft IIS; OWASP guidance and the OWASP Top 10 (Chapters 12–13); vendor hardening guides.

F.7 Using these checklists

Four principles carry across every platform:

1. Adopt, test, document, enforce, audit. The checklist is the what; the Chapter 11 discipline is the how. Start from the current authoritative benchmark for your exact version, test it against real workloads, document every deviation and its reason, enforce the result as your baseline — and then audit against the baseline continuously (bluekit's audit_baseline; CIS-CAT/OpenSCAP/osquery), because drift from baseline is one of the most useful things a defender can detect.
2. Patched is not hardened. Patching closes known holes in code; hardening closes exposed functionality that works as designed. You need both — a fully patched server with default services and shared credentials is current, not secure (Chapter 11's threshold concept).
3. Prevention pairs with detection. Notice how every checklist removes surface (disable, remove, default-deny) and records behavior (logging, EDR, SIEM forwarding). Defense in depth assumes prevention fails (Theme 4), so the logging half is not optional — it is what catches the attack that defeats the controls.
4. Compliance is the floor. Meeting CIS Level 1 or passing an audit is the minimum, not the goal (Theme 5). Real security pushes high-value hosts toward Level 2, applies compensating controls where a benchmark cannot be met, and treats the benchmark as a baseline to build on — not a finish line.

These checklists are a map of what to harden and roughly in what order. The authoritative, current, exhaustive standard for any platform is its CIS Benchmark, STIG, or vendor baseline — use them as the source of truth, and use this appendix to orient and prioritize when you sit down in front of a real system you are responsible for defending.