Cyber Threats, Cloud Trends, and the Latest CVEs You Need to Know

CVSS score (0-10): theoretical severity based on impact/exploitability. Actual risk: is it exploited in wild? are you affected? can you patch quickly? High CVSS but low risk when: CVE affects software you don't use, exploit requires local access (you're remote-first), vendor released patch (apply patch, risk eliminated). Low CVSS but high risk when: exploit code public + actively exploited (ransomware campaigns using it), affects internet-facing system (open to attackers), no patch available (can only mitigate, not fix). Prioritize by: 1) CISA KEV list (actively exploited—patch immediately), 2) Critical CVE in internet-facing systems (patch within 7 days), 3) High CVE in internal systems (patch within 30 days), 4) Everything else (patch in regular cycle). Don't patch based on CVSS alone—factor in exploitability, your exposure, mitigation options.

Critical CVE in internet-facing system: 7 days maximum (actively exploited CVEs: 24-48 hours—CISA says 15 days but that's too slow for critical). High CVE in internal system: 30 days. Medium/Low: 60-90 days or next patch cycle. Exception: zero-days actively exploited (ProxyShell, Log4j): patch immediately or mitigate (take system offline if can't patch in 24-48 hours). Real world: most ransomware exploits known vulnerabilities months old—attackers target unpatched systems. Exploit timeline: CVE published → exploit code public within 7-30 days → widespread scanning for vulnerable systems within 60 days. Race against attackers: patch before exploit code is weaponized (usually have 2-4 weeks). Can't patch everything instantly: prioritize internet-facing and actively-exploited first. Test patches: even critical patches need quick testing (2-24 hours in test environment before production).

Mitigation while waiting for patch: 1) WAF rules (block exploit attempts at firewall—IDS/IPS signatures often available before patch), 2) Workarounds (vendor may suggest config changes to reduce risk), 3) Reduce exposure (block affected port, whitelist access, put behind VPN), 4) Monitor (watch for exploit attempts in logs). If high risk + no mitigation: take system offline (better short outage than breach). Examples: Log4j zero-day → set environment variables to disable JNDI (mitigation until patch available), Exchange ProxyShell → disable external access until patched. Communication: inform users (expect limited access), inform leadership (here's risk, here's our plan). Don't: ignore zero-day because no patch (mitigation reduces risk), keep critical vulnerable system online if no mitigation exists (offline is safer than compromised). Vendors usually release emergency patches for zero-days within days—be ready to patch immediately when available.

Depends on shared responsibility model: SaaS (Salesforce, Google Workspace): vendor patches everything—you don't track CVEs for their infrastructure. PaaS (AWS RDS, Azure App Service): vendor patches underlying infrastructure, you patch your applications. IaaS (EC2, Azure VMs): you patch everything (OS, applications, libraries). Track CVEs for: IaaS VMs (all software), PaaS applications (code you deploy, dependencies, libraries—vendor patches platform), containers (base images, packages you install). Don't track CVEs for: managed services (RDS, DynamoDB—vendor responsibility), SaaS applications. Confusion: AWS patches hypervisor (you don't care), but you patch VMs running on it. Azure patches SQL Database service (you don't patch), but you update connection strings if TLS version changes. Responsibility: if you can SSH/RDP into it, you patch it. If it's managed service, vendor patches it (but check service bulletins for config changes needed).