Part III: System and Application Security

"The default install is the attacker's best friend. Hardening is just the long, unglamorous work of taking that friend away."

Network controls shape where traffic can go, but the traffic always arrives somewhere — a Windows server, a Linux host, a web application, a phone, an S3 bucket. Those endpoints are where attackers actually achieve their goals: where code runs, where data sits, where a foothold turns into a breach. Part III is about defending the things the network delivers to. A firewall that lets a connection through to a hardened, patched, least-privileged host is doing its job; the same firewall in front of a default-configured server with a vulnerable dependency is a speed bump. This part closes that gap.

The unifying idea is attack-surface reduction at scale. Every running service, every default credential, every unvalidated input, every over-broad cloud permission is a door. Hardening is the discipline of closing the doors you do not need and watching the ones you do. We work through it in widening circles: first the operating systems that everything runs on, then the applications written on top of them, then the perennial web vulnerabilities that refuse to die, then the explosion of mobile and IoT devices that now outnumber humans, and finally the cloud, where the boundary itself moves and "identity is the new perimeter." Across all of it, the defender's posture is the same — assume the layer in front has failed, reduce what an attacker can reach, and instrument what remains.

Two anchor stories thread this part. Log4Shell (CVE-2021-44228) arrives in Chapter 12 as the universal-dependency nightmare — proof that you are running code you did not write and may not know you have. And the cloud misconfiguration epidemic runs through Chapter 15, where a single public bucket or over-broad IAM policy has ended more companies than zero-days ever did. Both make the same point: in modern systems, the dangerous mistakes are usually configuration and composition, not exotic exploitation.

What you will learn

Chapter 11 — Operating System Security. Apply CIS-benchmark hardening to Windows, Linux, and macOS; manage patching, services, and least-privilege accounts; and deploy EDR, application allowlisting, host firewalls, and SELinux/AppArmor.
Chapter 12 — Application Security. Explain and prevent the OWASP Top 10; apply input validation and output encoding; integrate SAST, DAST, and SCA; and reason about the software supply chain (setting up Chapters 29 and 31).
Chapter 13 — Web Application Security. Defend against SQL injection, XSS, CSRF, and SSRF with parameterized queries, CSP, and security headers; deploy a WAF as defense in depth; and detect exploitation attempts in logs.
Chapter 14 — Mobile and IoT Security. Secure mobile fleets with MDM/UEM and app vetting, assess IoT weaknesses (default credentials, unpatched firmware, shadow devices), segment and monitor device fleets, and set a BYOD policy.
Chapter 15 — Cloud Security. Apply the shared-responsibility model, prevent the top cloud misconfigurations, use CSPM/CWPP and cloud-native logging, and secure IaaS/PaaS/SaaS and containers.

Advancing the Meridian program

Part III turns Meridian's hosts and apps from liabilities into defensible assets. Chapter 11 establishes hardening standards and golden baselines for the bank's servers and endpoints. Chapter 12 writes a secure-SDLC policy and reviews Meridian's loan-application code; Chapter 13 hardens the online-banking portal against the web attacks that target financial institutions daily. Chapter 14 inventories and segments Meridian's ATMs and branch IoT — devices that are computers in everything but name. Chapter 15 reviews the bank's AWS footprint and writes its cloud-security baseline. The bluekit toolkit gains real defensive utility here: harden.py (audit_baseline), appsec.py (scan_dependencies, plus the illustrative taint_demo), iotinv.py (device inventory and default-credential flags), and cloudpost.py (s3_public, iam_overbroad). These are the modules an analyst actually reaches for on a bad day.

Prerequisites

Read Parts I and II first. You will lean constantly on Chapter 3 (defense in depth, least privilege, control taxonomy) and Chapter 6 (the network stack and segmentation that host and cloud controls plug into). Within Part III the dependencies cross-link: Chapter 13 builds directly on Chapter 12; Chapter 14 assumes both Chapter 11 (host hardening) and Chapter 15 (cloud); and Chapter 15 assumes Chapters 6 and 11. If time is tight, do not skip Chapter 11 — operating-system hardening is the substrate the rest of the part stands on.

Time investment

Chapter	Title	Estimated hours
11	Operating System Security	6–7
12	Application Security	6–7
13	Web Application Security	6–7
14	Mobile and IoT Security	5–6
15	Cloud Security	7
Part III total		30–34

Engineering-track readers are home here — every chapter is build-heavy, and Chapters 11 and 15 reward deep, hands-on lab work. SOC-track readers should still master Chapters 13 and 15 (web and cloud attacks dominate real alert queues), and GRC-track readers will want Chapter 14 for the BYOD and device-policy material.

Where this leads

Hardened systems and applications are only as trustworthy as the accounts allowed to touch them. The most thoroughly hardened server in the world is wide open to anyone holding valid admin credentials. Part IV turns to identity — who gets access to what, how they prove it, and how you protect the keys to the kingdom.