CEO's Connection
The Patching Dilemma
by Rob Gardos, CEO

Data security is a critical initiative for any organization that manages sensitive data, and if you are involved in data security, you are probably familiar with the frustrating and, oftentimes, futile process of database patch deployment.

Does this sound familiar? Oracle or Microsoft releases a new security patch update, something they both do frequently. Now, you must test and deploy this patch on all of your databases. And don't forget any new databases you may be deploying. You'll need to check all of those to make sure they have the new patch as well. And before you can even complete this process, another security patch will be released.

This process might begin to look completely useless, like a total waste of time. However, you'll probably change your tune when news surfaces of another data breach or when you hear about a HIPAA/Sarbanes Oxley violation that cost your counterpart at another company their job. Then you start to rethink giving up on the patching dilemma.

For better or for worse, auditors are fully within their rights to demand that you get your databases patched to the latest security update, and it's not hard for them to track this either. However, actually implementing those security updates is another story.

While patching might be only one component of your broader security plan, its all-consuming nature has limited database folks from doing anything else. Many people consider perimeter security to be the answer to this problem, but considering the profound negative impact compromised data could have on your company and the fact that most attacks come from within anyway, perimeter security is clearly not enough. Companies need a real solution for their patching dilemma so they can secure data both from an access perspective and an encryption perspective.

The answer to your patching dilemma is the tandem of automation and ongoing configuration reconciliation. To take the first step in taming this beast, you need to define patches and their associated set of workflow events. From there, you can automatically deploy those patches to your hundreds, if not thousands, of databases. Of course, dynamic environments require real time configuration management. Just because you patched a database at a given time doesn't mean it still has that patch. And how do you ensure new databases provisioned are patched according to your company standards? Database environments must be constantly analyzed to ensure compliance.

It's time to stop the patching madness and start spending your time actually securing your data. While auditors just care whether or not you are using the latest patch set, you need to be thinking about that vulnerability around the corner that's just waiting to be exploited.

Robert Gardos
President and CEO

<< back