comment 0

Reflecting on Software Patch Management

Please keep in mind this is a ad-hoc post, rather than something considered carefully beforehand. It’s a reflection on my experience and something I’m dealing with frequently today. This post is geared towards the practicing information security community.

Reflecting on software patch management…
Simply put, patch management is an unwanted, expensive chore. We would rather be spending our time building elegant, layered, effective defenses against unwanted computer activity. Going back and following up with vendors for every bit of code in your production environment to see if there are any glaring security vulnerabilities is time consuming and expensive – and dull!

To make matters worse, every now and again you’ll hit a patch which does more harm than good. Depending on the policy of your enterprise, you may or may not catch a bad patch in your QA test process. In many cases, you bypass QA for the critical patches and cross your fingers. The QA process adds some tough hurdles to your patch management strategy, namely forcing you to prioritize patches and to negotiate with tough political roadblocks. You’re also leveraging your expertise to decide whether a vulnerability claimed “moderate” by the vendor isn’t really something more critical.

In my experience through three major enterprises over the past eight years, a practical software patch management scheme – and one that won’t kill the small information security team – is one that relies heavily on automation, standardization, enforceable policy with upper management support, and a strong asset management system.

For many enterprises, asset management, policy and standardization are elusive. You usually have a technical support team or a purchasing team doing double-duty with an asset management package. Upper management has no idea what your IT Security policies look like much less supporting them. And you’re either faced with every user as administrator and/or multiple divisions of your enterprise with different “independent” IT organizations.

We’ve all been there, most are still there. Information Security for the distributed computing has only begun to mature in the recent past. Information Security for the centralized world – the glass houses of yesteryear is mature and offers several great lessons – but lacks the scaleability of distributed computing.

So to start with, for the organization that has no asset management, and few standards, and only the most basic computer use policies, start by drafting a computer patch policy – something you can integrate with a larger security policy later, or amend your existing policy.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s