« One Tough Hombre… | Main | Data, Data, Everywhere… »

Get Serious About Patching

By Matthew Zito | September 28, 2007

There’s no question that in today’s security-conscious world, database patching is at the forefront of everyone’s mind. Trade publications breathlessly describe how many vulnerabilities are being patched, and every Oracle critical patch update is discussed. Patching is clearly big news. As a result, we’ve seen a range of personalities and neuroses develop around patching.

The recent attention to database patching has led some organizations to an interesting illness. We’ll call this “Overzealous Patch Syndrome”. These teams lunge towards every patch they find and roll each one out on every database they get their hands on. The patching is done as quickly as possible, with little to no heed as to whether it is stable, tested, appropriate, or even properly planned for that database. Sometimes, of course, these people are innocent victims of security or compliance teams, forced to aggressively roll out patches due to overarching fears of “hackers” and “auditors”.

At the other end of the spectrum, there are the teams that patch rarely, or not at all. They wait for bugs or upgrades to signal the opportunity to roll out any necessary patches. These people sometimes justify their lack of patching as “just being safe” or “risk mitigation” — or even being “too busy” to get the patches on. From their perspective, they’re doing the right thing by not patching right away.

So, which extreme is better? As is true in most cases, the extremes are probably not the right solution for anyone. Certainly, there is one clear deficiency in both of these extremes: There’s no standardization in how or why patching is being performed. Although one team patches everything in sight, and the other patches as little as possible, in each case there is no systematic process for how and when a patch is deployed.

In some ways, this is worse than simply not patching at all, ever. At least when you completely fail to patch you know where you are, but when there’s a lack of that systematic process, it rapidly becomes impossible to know what is going on. There’s no criteria for success or failure, there’s no system for identifying what is eligible, and no testing to know whether the patch is even appropriate.

Obviously, some of these risks can be mitigated with a proper database automation system. For example, if you’ve got a completely consistent set of database configurations, you can have a certain level of confidence that a patch that has been tested in one environment can be safely rolled out in others. In addition, a lot of the risk in patching tends to exist around people making mistakes, or not following the correct procedure, both of which can be removed from the equation when patching is automated. However, the broader process that is necessary is one that dictates, along with all appropriate documentation:

These processes force everyone to think about what a patch does, how critical it might be (a remotely exploitable vulnerability versus a bug where an obscure SQL statement returns an incorrect error), and whether they should be rolling it out in their environment. In addition, these policies can help the security and compliance teams understand why it might be critical to not roll a patch out, and force them to create a paper trail that justifies doing same.

It all comes back to good governance and best practices. Getting serious about patching means recognizing that it is a real and important part of the job, something that needs to be done, and a responsibility that can’t be shirked. The job is not to automatically put every patch the vendor releases on every database; the job is to figure out how to decide if, when, and how that patch should be deployed on a database.

Topics: Patches

Comments