IntermediatePatch Management

Disable legacy protocols that no longer require patches — because they never get them

SMBv1 — the protocol exploited by EternalBlue, WannaCry, and NotPetya — had known vulnerabilities for years before the Shadow Brokers leak made exploitation trivial. Microsoft had provided a patch, but also offered a better solution: disable SMBv1 entirely, since no modern system requires it. The same principle applies to TLS 1.0/1.1, SSLv3, Telnet, and FTP. The safest patch for a protocol that has no legitimate current use is removal. Audit your network for legacy protocol usage and disable any that cannot be justified by a specific named business requirement.

More in Patch Management

All guides

beginnerfeatured

Treat CVSS 9.0+ vulnerabilities as a 72-hour emergency, not a scheduled task

Equifax's catastrophic breach was caused by a vulnerability that had a published patch available 78 days before attackers exploited it. The Apache Struts vulnerability had a CVSS score of 10.0 — the maximum. At that severity, every day of delay is a calculated risk exposure. Establish a clear policy: CVSS 9.0 and above triggers an emergency patching process with a maximum 72-hour window from discovery to production deployment. Lower severities follow a normal cycle. This distinction alone would have prevented the Equifax breach.

See: Equifax BreachPatch Management

beginner

Run a continuous asset inventory — you cannot patch what you do not know exists

One of the most common root causes of successful vulnerability exploitation is an unmanaged, forgotten system that never received patches. The Equifax breach involved an application that security teams did not know was internet-facing. The Fortinet VPN zero-days were exploited on appliances that network teams had lost track of. A continuously updated asset inventory — covering servers, virtual machines, cloud instances, network appliances, and containers — is the foundation of any patch programme. Scan your network weekly for new assets. Any new internet-facing asset must be tracked and added to the patch programme before deployment.

See: Fortinet VPN Zero-DaysPatch Management

beginner

Prioritise patching internet-facing systems first, then internal systems

Not all systems carry equal risk. An internet-facing web application, VPN concentrator, email server, or API gateway can be exploited by anyone on the internet without prior access. Internal systems require the attacker to already be on your network. Apply patches to externally exposed systems first, within your 72-hour window for critical vulnerabilities. The Exchange ProxyLogon vulnerabilities were exploited by 10 separate threat actors within 24 hours of the patch being released — the gap between patch availability and deployment on internet-facing Exchange servers was measured in hours, not days.

See: Exchange ProxyLogonPatch Management