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
The Cold Truth about Cyber Insurance
Chris Kennedy, CISO & VP Customer Success, AttackIQ,  11/7/2019
Black Hat Q&A: Hacking a '90s Sports Car
Black Hat Staff, ,  11/7/2019
The State of Email Security and Protection
Mike Flouton, Vice President of Email Security at Barracuda Networks,  11/5/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprise
Assessing Cybersecurity Risk in Today's Enterprise
Security leaders are struggling to understand their organizations risk exposure. While many are confident in their security strategies and processes, theyre also more concerned than ever about getting breached. Download this report today and get insights on how today's enterprises assess and perceive the risks they face in 2019!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18881
PUBLISHED: 2019-11-12
WSO2 IS as Key Manager 5.7.0 allows unauthenticated reflected XSS in the dashboard user profile.
CVE-2019-18882
PUBLISHED: 2019-11-12
WSO2 IS as Key Manager 5.7.0 allows stored XSS in download-userinfo.jag because Content-Type is mishandled.
CVE-2019-18873
PUBLISHED: 2019-11-12
FUDForum 3.0.9 is vulnerable to Stored XSS via the User-Agent HTTP header. This may result in remote code execution. An attacker can use a user account to fully compromise the system via a GET request. When the admin visits user information under "User Manager" in the control panel, the pa...
CVE-2019-18874
PUBLISHED: 2019-11-12
psutil (aka python-psutil) through 5.6.5 can have a double free. This occurs because of refcount mishandling within a while or for loop that converts system data into a Python object.
CVE-2019-18862
PUBLISHED: 2019-11-11
maidag in GNU Mailutils before 3.8 is installed setuid and allows local privilege escalation in the url mode.