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
Newest First  |  Oldest First  |  Threaded View
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Intel Issues Fix for 'Plundervolt' SGX Flaw
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5252
PUBLISHED: 2019-12-14
There is an improper authentication vulnerability in Huawei smartphones (Y9, Honor 8X, Honor 9 Lite, Honor 9i, Y6 Pro). The applock does not perform a sufficient authentication in a rare condition. Successful exploit could allow the attacker to use the application locked by applock in an instant.
CVE-2019-5235
PUBLISHED: 2019-12-14
Some Huawei smart phones have a null pointer dereference vulnerability. An attacker crafts specific packets and sends to the affected product to exploit this vulnerability. Successful exploitation may cause the affected phone to be abnormal.
CVE-2019-5264
PUBLISHED: 2019-12-13
There is an information disclosure vulnerability in certain Huawei smartphones (Mate 10;Mate 10 Pro;Honor V10;Changxiang 7S;P-smart;Changxiang 8 Plus;Y9 2018;Honor 9 Lite;Honor 9i;Mate 9). The software does not properly handle certain information of applications locked by applock in a rare condition...
CVE-2019-5277
PUBLISHED: 2019-12-13
Huawei CloudUSM-EUA V600R006C10;V600R019C00 have an information leak vulnerability. Due to improper configuration, the attacker may cause information leak by successful exploitation.
CVE-2019-5254
PUBLISHED: 2019-12-13
Certain Huawei products (AP2000;IPS Module;NGFW Module;NIP6300;NIP6600;NIP6800;S5700;SVN5600;SVN5800;SVN5800-C;SeMG9811;Secospace AntiDDoS8000;Secospace USG6300;Secospace USG6500;Secospace USG6600;USG6000V;eSpace U1981) have an out-of-bounds read vulnerability. An attacker who logs in to the board m...