Patching And Risk Mitigation

I followed an interesting discussion on a DBA chat board this week regarding whether to patch a database. The root issue for the DBA was a minor vulnerability was corrected by a recent patch release, but fear that a multipatch install process could fail halted the upgrade.The fear is not unfounded: Complex patching processes for both point and patch releases, from all vendors, have seen bugs, poorly documented instructions, and minimally tested installer scripts. The trade-off is one of fixing a minor bug at the risk of having the installer fail or, worse, completing a successful installation only to find some days later that you have a new, more damaging bug.

The basic issue of risk aversion is all too common and why we have seen entire industries reluctant to upgrade to a database vendor's latest and greatest patch levels. When Oracle announced version 11G, for example, large percentages of the Asian and central American markets were still running 9.2. Security threats and issues of data security have pushed organizations to patch far more frequently to avoid known vulnerabilities. Still, we have seen recent studies where security patches often lag a year because companies are more afraid of the risk they know and can quantify than the nebulous risk of a security breach.

Most IT professionals figure that having a quality backup prior to a patch installation mitigates the risk of patching, but this is an oversimplification. The problem is not that simple as a failed installation script, where the database fails to restart, resulting in a lot of wasted effort and system downtime. Restoration processes are time-consuming, and while virtualization technologies help, there is still a lot of work to do. In cases where new bugs are discovered after a new revision is up and running, you may not be able to roll back to your previous version because the state of the database has changed. Smaller organization don't have the resources to rigorously test patches prior to deployment, so it becomes "patch and pray."

Database vendors offer announcements of pending patches, prior to availability, which helps IT groups to prepare. Further, they offer some details about what bugs and security threats you can expect to be fixed. But what we don't get from them is decent exploit analysis or workaround options. The database vendors are motivated to have their customers upgrade as often as possible, keeping the community on the latest versions of their software.

In addition, vendors are not eager to divulge details about vulnerabilities, which, quite frankly, makes them look bad. But this is an important vector of information for security professionals and DBAs alike. Understanding how an exploit works aids IT teams to better understand the threat and potential impact to their businesses. The answer may be "no impact," in which case it does not make sense to patch. But there really is not enough information within the vendor patch announcement.

For most security professionals, a workaround is as good as a patch. If they can address the issue through a UTM, WAF, NAC, or whatever tools they have at their disposal, then they really don't care. But without being provided a specific workaround -- other than patching -- they have to dig for answers. For example, if you want to address a remote exploitation of a vulnerability, you cannot implement a firewall rule for the threat without some understanding of the exploit signature. Short of an attack profile, specific instructions for workarounds would accomplish the same goal, but this is absent from database vendor instruction. Your option? Patch.

All in all we have much better information from the vendors regarding security threats and the features of the database that are affected. But we still have a way to go with workarounds and threat analysis to be able to make risk-based decisions on whether to patch, implement a workaround, or do nothing. It's my contention that DBAs would be less likely to do nothing if they were presented some additional information and all available options.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.