Failing Software Patch Management Initiatives and How to Fix Them

I'm writing this blog following the Gartner Security & Risk Management Summit in London in mid-September.

Looking back at the many sessions I attended, and the conversations I had with peers and analysts, I continue to be intrigued by the fact that we talk so much about advanced IT security solutions while we still neglect the basics of good security. A good example is software patch management.

Remediation of application vulnerabilities (also known as “patch management”) is continually ranked at the top of all the most important guidelines and industry standards for security configuration, including the National Institute of Standards and Technology (NIST) and the SANS 20 Critical Security Controls.

There is plenty of data to support the claim that patch management is the foundation of a strong security strategy. Here are some points:

  • "75% of attacks use publicly known vulnerabilities in commercial software that could be prevented by regular patching." ("Raising the Bar for Cybersecurity", James Lewis, CSIS 2013)
  • 84% of the vulnerabilities disclosed in the 50 most popular programs in 2012 had a fix available the day of disclosure. (Secunia Vulnerability Review 2013)
  • The number of breaches using a particular vulnerability increase exponentially from a few breaches following patch release, to an increase one month later, reaching a peak around 2 months after disclosure. (Microsoft Security Intelligence Report, Volume 11 )

Yet, despite the large amount of resources invested by organizations in security solutions and staffing, we continue to see breaches causing financial losses and damage to the reputations of organizations around the globe. Think of the recent breach that Adobe suffered. According to security specialist Brian Krebs, the vector for the breach could have been a known vulnerability on Adobe's ColdFusion. This vulnerability was disclosed many months ago, and continues to be exploited because, as Krebs explains: "Many networks apparently run outdated versions of the software, leaving them vulnerable to compromises."

Krebs' speculation about Adobe's ColdFusion being the root cause of the breach later prompted Adobe to comment that "the company's investigation is still ongoing, and that "at this time we have not identified the initial attack vector to include or exclude a ColdFusion server.""

So why, despite all the awareness, do we continue to fail with our software patch management initiatives?

I believe that the challenge starts with the understanding of the term itself. Patch management is an IT operations routine. It is understood to be the management of application updates and, as such, fundamentally disconnected from security. Without a security approach or patch management solutions, operations teams are left with the difficult task of guessing which patches to apply, and where.

Here is a picture of their challenge: In 2012 alone, almost 10,000 vulnerabilities were disclosed. And this number is in addition to the number of vulnerabilities also disclosed in previous years. For the majority of these vulnerabilities, fixes become available quickly, and these then need to be deployed with a risk assessment approach. Not to mention general updates. Moreover, IT environments are populated with multiple devices and platforms running thousands of applications. Organizations cannot afford – and do not need – to update all applications in all devices.

Without collaboration and support for visibility, risk assessment and prioritization of remediation efforts, patch management is destined to fail.

The situation brings me back to one of the main points of the opening session at the summit: Organizations must be better at implementing and leveraging the solutions they invest in.

Most patch management solutions and processes fail because of the poor implementation of solutions and internal misalignment. Often organizations are unable to identify the existing capabilities and the add-ons that integrate with their existing solutions to maximize the investment and leverage those capabilities. That is the case with System Center 2012 Configuration Manager. While it is one of the most complete and most adopted solutions for client management in the market, it requires third-party solutions to fill in some of the gaps in its capabilities. One of those gaps is in the patch management of non-Microsoft applications. Configuration Manager offers strong support for patching Microsoft applications, but virtually none for patching third-party apps.

Organizations that are using Configuration Manager and need to improve their patch management capabilities should assess the cost and risks associated with patching non-Microsoft applications, and thus evaluate solutions that can provide support in relation to content, visibility and prioritization. You can read the full Gartner report “Complementary Solutions for System Center 2012 Configuration Manager” here.

Organizations using other tools for patching must evaluate the efficacy of their programs and the resources required to manage such tools; as well as the overall security status of the applications running in the corporate and personal machines used by employees and collaborators.

Either way, the key is to determine the desired (or required) level of security, and evaluate the tools that provide the functionality to achieve the security and operations objectives with efficiency and efficacy.