4.5.2. Hardware Hardening and Patch Management
💡 First Principle: Hardware hardening extends the principle of minimal attack surface to the physical layer. Unused physical ports are access points; an unprotected BIOS can be reconfigured to boot from attacker-controlled media; outdated firmware contains known vulnerabilities. Physical hardening closes these vectors.
Hardware Hardening Steps
| Action | Why |
|---|---|
| Disable unneeded hardware | Unused NICs, storage controllers, and expansion slots are potential attack vectors |
| Disable unneeded physical ports | USB, CD/DVD, serial ports can be used to boot from malicious media or extract data |
| Set BIOS/UEFI password | Prevents unauthorized firmware reconfiguration |
| Configure secure boot order | Prevents booting from external media; forces boot from authorized OS |
| Enable Secure Boot (UEFI) | Cryptographically verifies bootloader integrity; prevents rootkit installation |
Patch Management
Patching is one of the most effective security controls—the majority of breaches exploit known vulnerabilities for which patches already exist.
Patch Management Process
- Testing: All patches must be tested in a non-production environment before production deployment. Patches can break applications or services—testing catches this without user impact.
- Deployment: Deploy during approved change windows, one system type at a time, with rollback procedures ready.
- Change management: Every patch deployment is a change—document it, get approval, record the outcome.
Patch Management Tools
- WSUS (Windows Server Update Services): Microsoft's internal patch distribution server. Administrators control which patches are approved and deployed.
- SCCM (System Center Configuration Manager, now Microsoft Configuration Manager): Broader Microsoft management tool that includes patch management alongside software deployment, inventory, and configuration management.
- Third-party tools: Ansible, Puppet, Chef can also manage patching across heterogeneous environments.
⚠️ Exam Trap: Never deploy patches directly from a vendor website to production servers without testing. Even critical/emergency patches should go through testing—"emergency" means test quickly, not skip testing.
Reflection Question: A critical security patch is released for your web server OS. Your patch testing lab is currently in use for another project. What should you do, and what is the risk of each option?
