Let's be smart about patching databases

* Ryan Naraine is traveling.

Guest editorial by Slavik Markovich

Every quarter, around the time of the Oracle Critical Patch Update (CPU) or the Microsoft "Patch Tuesday," rituals take place – some behind closed doors, others in the media. Web sites report of the latest vulnerabilities, so-called experts (myself included) provide analysis of the risk posed by those vulnerabilities, industry analysts and security gurus urge everyone to patch their databases. At the same time, in some organizations, teams of DBAs and security analysts hunker down to start applying the patches, a process they would sometime finish just in time for the next patching cycle. However, most users, as was reported here and elsewhere, will ignore the patches or perhaps install them ad hoc and without any rigorous prioritization.

Why are people not patching? There many legitimate reasons.

Application certification, for example, is a real obstacle. Enterprises have applications running on top of the database, and those applications are only certified for a specific version and release of the database. Patch the database, and any problems caused in the application are not covered in your maintenance agreement.

[ SEE: Rothman: Breaking the zero-day habit ]

Database downtime, on the other hand, has a cost of business interruption and labor which should be weighed against the benefit of patching – i.e. the reduction in risk. The same is true for staffing constraints: If you consider the risk of not patching frequently intolerable to your business, you would find the personnel to handle it, but if you feel the risk does not outweigh the cost, you could resign yourself to patching less frequently.

The issue is that few organizations actually take this as a calculated risk. Rather, they just can’t manage the mammoth patching process and cross their fingers. So not only are most organizations not “doing the right thing” – they’re hardly doing anything.

I’ll go out on a limb here and say this: Telling organizations that they must apply all patches as soon as those come out when reality is that it is not feasible, not practical or not cost-effective to do so, is like telling Paris Hilton she should get a PhD in Philosophy. It’s just not going to happen no matter what you say.

It's time to think of patching in a different way. We need a feasible, repeatable framework that would enable each organization to patch as much as possible whilst optimizing cost vs. risk reduction.

[ SEE: Oracle ships emergency workaround for zero-day flaw ]

I would suggest taking the following steps:

1. Review the configuration of all databases, and uninstall features and packages you don’t need. For instance, Oracle features such as Spatial and APEX often have vulnerabilities and are not needed for many applications. Removing them and all other unnecessary features reduces the attack surface and immediately eliminates the necessity of numerous patches.
2. Assign each database a risk score – databases that hold highly sensitive information pose a high risk and should be patched as often as possible.
3. Also score databases according to the cost of downtime and application issues (certification issues included).
4. Databases with a high risk / low cost score should obviously be patched frequently. The issue is of course with high risk / high cost, and here is where the real cost/benefit analysis should be done, with no magic wand that I can offer. However, by taking the previous steps we've narrowed the playing field significantly.
5. Finally, use compensating measures all around. Virtual patching or host-based intrusion detection/prevention is one such measure that can greatly reduce the risk of an exploit.

I believe that taking such steps can simplify the patching conundrum and reduce the bulk of the risk, which many organizations are taking blindly at the present.

* Slavik Markovich is the co-founder and CTO at Sentrigo. He is a renowned authority on Oracle and JAVA/JavaEE technologies, has contributed to open source projects such as Spring Framework Toplink integration (later incorporated by Oracle), and is a regular speaker at industry conferences.