If you look at the past, patch management was not a cybersecurity issue; rather, it was an IT issue. And it wasn’t until the emergence of Code Red in 2001 when Microsoft started issuing patches to plug security vulnerabilities in its software. Patch management as security came to prominence again with the massive Internet worms of 2009, 2011, and 2012, including WannaCry in 2017, which would shock entire enterprise networks. These incidents would set the stage for widespread adoption of regular patch management cycles among enterprises. Until then, there were only sporadic security incidents, but nothing large in scale where you would see viruses and malware spreading across geographies.
As these large-scale attacks that infected entire networks across geographies became more prevalent, the industry moved toward developing a system to catalogue and track these vulnerabilities. The first, created back in 1999, was first used by US federal agencies on the recommendation of the National Institute of Standards and Technology, which published the “Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme” in 2002 and then updated it in 2011. However, its widescale use wasn’t until 2011, with the development of the first National Vulnerability Database (NVD).
NVD, which serves as a comprehensive cybersecurity vulnerability database that integrates all publicly available US government vulnerability resources, provides references to industry resources. It is synchronized with, and based on, the CVE List, which uses a scoring system to rate the severity of risk. The NVD became an effective tool for security organizations to track vulnerabilities and determine which ones to prioritize based on their risk score.
From 2011 on is when patch management started to evolve into a security best practice throughout the industry. However, as the volume of vulnerabilities in the database continued to grow, and the complexity of the IT infrastructure increased, patch management would become not such an easy task. It’s not always as simple as updating a piece of software. Some systems are mission-critical and cannot afford disruption. Some organizations don’t have the dedicated resources in either budget or talent to apply a test, deploy, and install patches on a regular basis.