Patch Management: Stop Killing the Database to Save It

Opinion: Instead of racing to provide new features, database vendors should take the time to upgrade patch management tools.

With all the recent public disclosures of data-privacy breaches, the spotlight is shining brightly on database security. Databases are clearly under direct attack from hackers on an ever-increasing basis. To paraphrase a famous exchange, "Why do you hack into databases?"

"Because thats where the data is!"

In recent years we have seen an increasing number of alerts concerning vulnerabilities in database software. Of course, the most visible vendors are Microsoft and Oracle, and part of the reason is that they make up the majority of database systems installed.

Hackers understand market share as well as the next guy. As the number of reported severe vulnerabilities has risen, vendors have responded with patch-release schedules. The hope was to simplify the process for administrators and mitigate the impact on end users.

The difficulty is that the data in a database must be both available to those who are supposed to use it and unavailable to those who are not. Moving to a quarterly schedule of patch releases, as Microsoft and Oracle have done, simply means that end users get to schedule their outages.

/zimages/5/28571.gifRead Larry Loebs commentary here on how to improve Microsofts patch system.

Yes, folks, database patches almost always equal unavailability. So the solution to keeping our databases available only to authorized personnel … is to make the database unavailable to everyone.

Certainly, users are very concerned by the impact on business operations and personnel costs, both real and intangible.

The real costs concern the need to increase database administrative staff for larger IT organizations so that work weeks that already average 50 hours a week do not increase beyond the breaking point.

Intangibles include the cost of staff turnover due to burn out from the previously mentioned long hours, as well as the increased chance of extended outages caused by errors by overworked administrators working on the complex and very manual task of applying the patches.

Now, vendors are legitimately trying to balance the impact of applying these patches against the impact on a customer whose database gets hacked. Having said that, lets be honest: The database vendors have something to protect as well. Their brands! So why are they not doing more to help this process?

Many users still feel abandoned by their vendors, especially if they are still running critical systems on older versions of the database. Their only recourse is to upgrade to the newest version, which, of course, means more downtime for the end users.

The market would love to see a moratorium on new features, and more time spent by vendors on delivering robust patch management tools. Why not stop new feature development for 6-12 months and focus all development efforts on addressing a better patch management feature?

Next Page: Features for better patch management.