Key Takeaways: Operating System Security
A one-page reference. Reread before an exam or before moving on. Dense by design.
Core vocabulary (memorize cold)
| Term | One-line definition |
|---|---|
| Hardening | Deliberately configuring a system to reduce attack surface and raise cost of compromise |
| Attack surface reduction | Systematically removing exposed services/ports/accounts/interpreters/protocols |
| CIS Benchmark | Consensus configuration standard for a specific platform (CIS); Level 1 vs Level 2 |
| Baseline configuration | Your org's documented, approved settings for a system type (derived from a benchmark) |
| Patching / patch management | Applying vendor fixes / the process of doing so reliably across a fleet |
| EDR | Endpoint agent that records behavioral telemetry and detects techniques; isolates/kills on response |
| Application allowlisting | Default-deny for program execution: only approved apps run |
| SELinux / AppArmor | Linux mandatory access control: system policy confines processes (even root) |
| seccomp | Kernel filter restricting which system calls a process may make |
| Group Policy | Windows mechanism to centrally enforce + re-apply config across a domain (corrects drift) |
| Host-based firewall | Per-machine firewall controlling traffic to/from that host |
| Secure Boot | UEFI feature verifying the signed boot chain; blocks pre-OS malware (boot/rootkits) |
| TPM | Hardware chip storing keys + boot measurements; a hardware root of trust (seals disk-encryption keys) |
Threshold idea: patched ≠ hardened. Patching fixes known code flaws; hardening removes exposed configuration (services, accounts, protocols, logging) that is working as designed. A patched box with SMBv1 on, a shared local-admin password, and no logging is current, not secure.
Hardening checklists by platform
Windows | Control | Does | |---|---| | Group Policy / Microsoft security baselines | Enforce config at scale; auto-correct drift | | LAPS | Unique, random, rotated local-admin password per host → kills shared-credential lateral movement | | Disable SMBv1, Print Spooler (where unused), AutoRun; PowerShell AllSigned + Constrained Language | Remove attack surface | | Defender ASR rules + Tamper Protection | Block technique-classes; stop attacker silencing Defender | | Script-block logging (4104), process creation (4688)+cmdline, Sysmon | Telemetry for the SOC |
Linux
| Control | Does |
|---|---|
| ss -tulpn → mask/remove unneeded services & packages | Least functionality (remove > disable) |
| sshd_config: PermitRootLogin no, PasswordAuthentication no, MaxAuthTries, AllowGroups | Harden the front door |
| SELinux enforcing (not permissive/disabled) / AppArmor | MAC: confine processes incl. root |
| seccomp (via runtimes/containers) | Narrow the syscall interface |
| auditd, ship logs off-box; audit setuid bins, no world-writable files | Evidence + surface |
macOS (enterprise) | Control | Does | |---|---| | MDM enrollment | The key decision — enables/enforces everything below + visibility | | FileVault (with central key escrow) | Full-disk encryption at rest | | Gatekeeper + SIP enforced | Only signed/notarized code; protect system files even from root | | EDR (XProtect is not enough) | Behavioral detection, same SOC console as the rest |
CIS Levels — when to use what
| Level 1 | Level 2 | |
|---|---|---|
| Intent | Improve security, minimal functionality impact | High-security; may break things; needs testing |
| Use for | Most systems; general workstations/servers | Sensitive hosts (e.g., CDE / cardholder data) |
| Rule | Adopt → test against real workloads → document deviations → enforce as baseline → audit for drift |
EDR vs. Antivirus
| Antivirus | EDR | |
|---|---|---|
| Detects by | Known-bad signatures | Behavior / techniques + telemetry |
| Catches | Known malware files | Novel + fileless + living-off-the-land |
| Gives you | A verdict (block/quarantine) | Process timeline + hunt data + alerts |
| Response | Remove file | Isolate host, kill process, investigate |
| > Modern tools (e.g., Defender for Endpoint) include both. Application allowlisting (default-deny | ||
| > for code) is the strongest preventive against unknown malware — servers first (stable software set). |
Patch management — risk-based timelines (illustrative)
| Condition | Target |
|---|---|
| Critical, exploited in the wild (CISA KEV) | Emergency: 24–72 h |
| Critical/High, internet-facing | 7 days |
| High/Medium, internal | 30 days |
| Low | Next monthly cycle |
- Deployment rings: pilot → broad → critical (catch a bad patch on a few machines first).
- Verify installed, not sent — report coverage % and age of oldest missing critical patch.
- Can't patch on demand? → compensating controls (segment, restrict, monitor) + a risk acceptance with an expiry. (Full prioritization — CVSS/EPSS/KEV/context — and SLAs are Chapter 23.)
When to use what (decision aids)
- Stop lateral movement via shared local admin? → LAPS.
- Confine a compromised service (even if it's root)? → SELinux/AppArmor enforcing.
- Catch novel/fileless malware? → EDR (behavior) and/or allowlisting (default-deny).
- Stop config from drifting back to defaults? → enforce via Group Policy / config mgmt / MDM (they re-apply).
- Protect below the OS / prove a trusted boot? → Secure Boot + TPM.
Mapped frameworks
| Concept | CIS Controls v8 | NIST | CompTIA Security+ | (ISC)² CISSP |
|---|---|---|---|---|
| Secure config / baselines | Control 4 (Secure Configuration) | SP 800-123; SP 800-70 | 2.0 / 4.0 (hardening) | Security Architecture & Engineering |
| Patch management | Control 7 (Continuous Vuln Mgmt) | SP 800-40 | 4.0 | Security Operations |
| Application allowlisting | Control 2 (Software Inventory) | SP 800-167 | 4.0 (app control) | Security Architecture & Engineering |
| Audit logging / EDR | Control 8 (Audit Logs) / 10 (Malware Defenses) | SP 800-92 | 4.0 (EDR) | Security Operations |
| Least functionality / MAC | Control 4 | SP 800-53 CM-7, AC-3 | 3.0 | Security Architecture & Engineering |
Project additions this chapter
- Meridian program: host hardening standards — per-platform baselines (Windows/Linux/macOS) from CIS Benchmarks, level by role, enforcement mechanism, required agents (EDR, allowlisting on servers), LAPS, host patch timelines, and a drift audit.
bluekittoolkit:harden.py—audit_baseline(settings, baseline)reports configuration drift, turning a written baseline into an auditable verdict.
Common pitfalls
- Believing "fully patched" = "hardened" (it isn't — the surface is mostly intended, unswitched-off behavior).
- Applying a CIS Benchmark blindly and breaking production (test + document deviations + deploy in rings).
setenforce 0/ leaving SELinux permissive in production (you disabled your strongest containment).- Shared local-admin password from a gold image (one recovered key opens the fleet → use LAPS).
- Treating macOS as "not our problem" (unmanaged = unmonitored attack surface; enroll in MDM).
- Reporting patches deployed, never verifying installed (the unpatched tail is where breaches start).
- The "it's just a test box" exemption (the forgotten, unhardened, internet-exposed host is the foothold).