Manage Learn to apply best practices and optimize your operations.

Building the business case for a formal patch management program

Delaying security patches is a huge risk. Michael Cobb explains how to build the business case for a formal patching program for a variety of systems.

I'm building the business case that we should patch our production database more frequently; we patch only once...

a year, and even then only "critical" issues. What's the best way to make the case?

Data is the main target of any network attack, and poorly patched systems are a major attack vector for data theft.

However, patching a production database is a stressful process; database patches tend to introduce not only security fixes, but also behavioral changes. This is why so many administrators delay patching of databases that sit behind mission-critical or revenue-generating processes, even if they are known to be insecure. A case for more frequent database patching can include plenty of real-life examples of data breaches caused by unpatched databases, but key stakeholders will want assurances that more frequent updates can be accomplished without putting the business at risk. This is the part of the business case that will probably decide whether or not it's approved.

It is important to present a patch management program with robust change control processes that show everything eventually is covered. Explain the patch release process operated by the relevant database vendors and how associated vulnerabilities will be assessed; vulnerability criticality is key for calculating a patch's significance. The threat posed by a particular vulnerability may be within stakeholders' risk tolerance, and some patches won't be relevant to their environment. Be sure to show that there will be no need to install every available patch to alleviate stakeholders' fears of constant and excessive downtime. Also, aging databases that regularly cause problems whenever changes are made should probably be left on an annual patch schedule until they can be migrated or upgraded to a more robust system.

Maintaining a parallel test environment to deploy and test patches is critical, so a budget will be needed for this. Testing will better replicate the actual environment in which the patch will be deployed and help prevent issues in the enterprise. Consider using virtualization, as it offers the ability to deploy multiple test configurations to mirror live production environments without impacting or endangering the production database.

Plan how stakeholders will agree on a date for deploying patches so that all resources will be available and normal operations will be least affected. Schedule less urgent patches to be tested and deployed when time is available. It is also important to have a well-documented process to ensure tasks are executed in an orderly and predictable manner and that none are forgotten or left incomplete. Have ready contact lists of whom to reach and how in case a problem arises, and explain how the rollback or backup response plan will work.

Any case for improving patch management should look for increased funding. Database security is a specialist area, so these administrators need training to learn and do the job properly. Back in 2000, the IT Process Institute looked at what distinguished a high-performing and secure IT operation from a poor one. Needless to say, top performers allocated more budget to security as a percentage of total IT operational expense -- three times, in fact.

Ask the Expert!
Have a question about application security? Send it via email today! (All questions are anonymous.)

This was last published in July 2014

Dig Deeper on Microsoft Patch Tuesday and patch management