Making a Case For Comprehensive Patch Management

The Security Manager's Journal at Computerworld had a good, "real life" story about the effort required to implement a comprehensive patch management program and to have management sign off. J.F. Rice (a pseudonym created to protect the manager and the company) says he used a two-pronged attack to get support and raise awareness by meeting with system administrators and business leaders, and writing policy statements that would show upper management signed off and supported the program.My favorite quote from the story reinforces the exact behavior I see regularly: "I honestly don't know how any experienced systems administrator in this day and age can put up resistance to a comprehensive patching program. The dangers of leaving systems unpatched overwhelm me, but they don't seem to bother a lot of our sysadmins very much." This is truer than most people realize, or at least are willing to accept.

As an incident responder and forensic investigator, I'm most often asked these same three questions: Was there sensitive data on the compromised host? Did an attacker access the data? Was the system patched? The first two questions I've talked about before in regard to their importance due to legislation and regulation, but the latter question is the one that leaves us security professionals shaking our heads.

The two primary ways I see machines compromised are through user interaction, such as tricking a user into infecting himself, and an unpatched vulnerability in an application that could be a service, client-side application, or Web application. Social engineering is always going to be a problem no matter how much awareness we push, but vulnerabilities do get patched.

The argument I most often hear against patching is the level of testing that must be done to make sure it's safe for a particular environment; while partially valid, it's most often just an excuse not to patch. Implementing a multitier patching program would alleviate this, coupled with the understanding that vendors, most notably Microsoft, will often provide free support if their patches break something.

The first tier of patching could include "power users" and IT staff the day the patch is released. The second tier could be all desktops within two to three days after the patch is released. Servers could get patched within seven days or less if testing is completed quickly.

In this day and age of exploits being released within hours of a patch being made public, or patches being released because exploits are already being seen in the wild, there really is no excuse for not having a patch management program. Take a lesson from Mr. Rice. Put together a plan, work with sysadmins so they understand why the plan needs to be implemented, and seek upper management's approval. I'll admit that I really, really enjoy incident response and forensics, but it loses a little excitement when I can point to the problem being the sysadmins' fault for not regularly patching their machines.

John H. Sawyer is a Senior Security Engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.