Patching, Vulnerability Mgmt & Baselines

Real-world analogy

What is it?

Vulnerability management + patching + baselines is the largest portion of real defensive work. It’s unglamorous. It’s what actually keeps organizations out of the news.

Real-world relevance

A new critical vulnerability in a widely-used library hits the CISA KEV list. You query vulnerability scan reports for affected assets, identify 12 servers, raise emergency changes, patch 9, apply compensating controls to 3 (isolated legacy apps), and report progress daily. No incident, no headlines.

Key points

• Vulnerability management lifecycle — Discover assets → scan for vulnerabilities → prioritize (CVSS + exploitability + asset value) → remediate (patch/config/compensating control) → verify → report. Tools: Nessus, Qualys, Rapid7, Defender Vulnerability Management.
• CVSS and real priority — CVSS scores vulnerabilities 0–10. But score alone isn’t priority: ‘internet-facing + actively exploited + high impact + easy exploit’ always beats ‘high CVSS + lab-only + no exploit.’ Context matters.
• CVE, CISA KEV, vendor advisories — CVEs identify vulnerabilities. CISA KEV (Known Exploited Vulnerabilities) catalog lists what’s actively exploited in the wild — a highly practical priority list.
• Patch vs mitigate — Patching is ideal. When patching isn’t immediately possible (legacy, risk, SLA), apply mitigations: disable the service, firewall off, configure workarounds. Document the exception and set an expiry date.
• Baselines and secure configuration — CIS Benchmarks and vendor hardening guides define what ‘secure’ looks like for an OS/service. Deviations become findings. Even partially adopting them is a big leap from default installs.
• Endpoint hygiene for juniors — EDR healthy, OS patched, encryption on, MFA, screen lock, removable-media policy respected, admin rights minimized. Fix these across the fleet and you beat most mass threats.
• Patch windows and rollback — Never patch during business hours without approval. Every patch cycle has test → stage → prod, a change ticket, a rollback plan, and a verification step. This discipline is what regulated industries hire for.
• Reporting to non-technical stakeholders — Execs don’t care about CVE numbers. They care about risk trends: ‘we reduced critical vulnerabilities by 60% this quarter, internet-facing exposure is near-zero, 3 legacy systems are on mitigation until Q3.’ Learn to speak this language.

Code example

// Monthly patch cycle (simplified)

Week 1:
  - Review vendor advisories (MSRC, RHSA, vendor blogs)
  - Pull vulnerability scan results
  - Score with CVSS + exploit status (CISA KEV, EPSS)
  - Propose patch batch and exceptions for the month

Week 2:
  - Approve batch in CAB (Change Advisory Board)
  - Deploy to test ring (dev + pilot users)
  - Collect telemetry (crashes, regressions)

Week 3:
  - Roll to staging ring
  - Validate critical apps still function
  - Decide go/no-go for production

Week 4:
  - Production rollout in approved windows
  - Post-patch verification
  - Update asset inventory + vulnerability dashboards
  - Close tickets with KB references

Line-by-line walkthrough

1. 1. Monthly cycle heading
2. 2. Week 1 — intel + scoring
3. 3. Vendor advisories
4. 4. Scan results
5. 5. Score with CVSS + exploitability
6. 6. Propose batch + exceptions
7. 7. Blank separator
8. 8. Week 2 — test ring
9. 9. CAB approval
10. 10. Pilot deployment
11. 11. Telemetry collection
12. 12. Blank separator
13. 13. Week 3 — staging
14. 14. Staging deployment
15. 15. App validation
16. 16. Go/no-go decision
17. 17. Blank separator
18. 18. Week 4 — production
19. 19. Rollout in windows
20. 20. Post-patch verification
21. 21. Inventory + dashboards
22. 22. Ticket close with KB

Spot the bug

Policy: 'Patch only when something breaks. Speed matters, process is for bureaucrats.'

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• CISA Known Exploited Vulnerabilities (CISA)
• CIS Benchmarks (Center for Internet Security)
• MSRC Security Update Guide (Microsoft)