Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

7/15/2010
12:27 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

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.

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. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
44% of Security Threats Start in the Cloud
Kelly Sheridan, Staff Editor, Dark Reading,  2/19/2020
Zero-Factor Authentication: Owning Our Data
Nick Selby, Chief Security Officer at Paxos Trust Company,  2/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8818
PUBLISHED: 2020-02-25
An issue was discovered in the CardGate Payments plugin through 2.0.30 for Magento 2. Lack of origin authentication in the IPN callback processing function in Controller/Payment/Callback.php allows an attacker to remotely replace critical plugin settings (merchant ID, secret key, etc.) and therefore...
CVE-2020-8819
PUBLISHED: 2020-02-25
An issue was discovered in the CardGate Payments plugin through 3.1.15 for WooCommerce. Lack of origin authentication in the IPN callback processing function in cardgate/cardgate.php allows an attacker to remotely replace critical plugin settings (merchant ID, secret key, etc.) and therefore bypass ...
CVE-2020-9385
PUBLISHED: 2020-02-25
A NULL Pointer Dereference exists in libzint in Zint 2.7.1 because multiple + characters are mishandled in add_on in upcean.c, when called from eanx in upcean.c during EAN barcode generation.
CVE-2020-9382
PUBLISHED: 2020-02-24
An issue was discovered in the Widgets extension through 1.4.0 for MediaWiki. Improper title sanitization allowed for the execution of any wiki page as a widget (as defined by this extension) via MediaWiki's } parser function.
CVE-2020-1938
PUBLISHED: 2020-02-24
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that ...