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.

Vulnerabilities / Threats

4/23/2013
09:58 PM
50%
50%

Prioritizing Your Database Security Patches

Patching databases can be painful, but the presence of critical vulnerabilities can make closing security holes quickly necessary

Prioritizing patches is tricky enough when organizations are not thinking about the downtime that can result from taking down a production database. When that comes into play, however, the patching process can slow down -- so much so that databases can be months behind in critical updates.

Solving this issue, in part, means properly prioritizing what vulnerabilities need to be fixed -- a process that starts with the relevance of a particular patch to the organization and its severity. For example, notes Imperva CTO Amichai Shulman, a vulnerability in a package that is not deployed on the database does not justify patching. Neither necessarily does a vulnerability that can be mitigated by shutting down a service that is unneeded for a specific organization.

That last point may have particular bearing on how organizations approach a recent vulnerability patched in the Oracle database. Tucked inside the massive critical patch update Oracle released last week is a fix for a vulnerability with a criticality ranking of 10.0 -- the highest CVSS score vulnerabilities can get. The vulnerability exists in the Workload Manager component and can be exploited over the Web (HTTP) by an unauthenticated attacker to gain full control of the database.

By simply shutting down HTTP access, the database can be secured, Shulman says. However, if those services are essential for a specific database server, patching or a Web application solution that detects any type of attack through the HTTP protocol is required.

As with any patching strategy, organizations need to have a plan in place to ensure they are able to test and deploy updates to their live systems as quickly as possible, observes Richard Henderson, security strategist at Fortinet's FortiGuard Threat Research and Response Labs.

"No business wants or can afford unexpected downtime on their applications that are reliant on their data stores, but the black eye of a penetration and data exfiltration is much, much worse," he says. "Maintaining a parallel test environment to deploy and test patches is critical, as is having the people in place to make that deployment their top priority."

"Simply put," Henderson says, "organizations need to have a preplanned and easily executable strategy to test both the applications they create internally and the systems they patch. Using automated testing tools on a regular basis is critical -- not only when new patches are deployed, but in between patches."

That many organizations are failing to properly meet the challenge of patching their databases promptly seems hardly in dispute. According to a 2012 Independent Oracle Users Group survey on security, about 19 percent of the 350 respondents applied Oracle database updates within one to three months of their release, while another one-fifth said they do it within a three- to six-month timeframe. About 10 percent said they have either never done it or that it takes more than a year for them to do so.

"As with other security prioritization exercises, enterprises should take a risk-based approach to executing on resources," says Rob Ben-Natan, vice president and CTO for data security, compliance, and optimization at IBM. "Therefore, organizations need to understand first what resources are available, categorize them -- including risk tolerance levels -- and then find out where the vulnerability gaps are and the nature of these vulnerabilities."

Risk levels depend on the level of sensitivity of the data and severity of the vulnerability, Ben-Natan added.

"Because warehouses often aggregate a lot of data that is used for business decisions, they almost always have a high degree of data sensitivity," he says. "They may not have data, such as intellectual property, but they will have customer data, supplier data, employee data, patient data, etc. Therefore, many risk-based programs often place great emphasis on warehouses."

However, organizations should not lose sight of the likelihood of a vulnerability actually being exploited when they consider their database patching strategies as well.

"On the one hand, some of the vulnerabilities disclosed with the patch are of high severity," Schulman says. "However, databases are mostly threatened by insiders, and they have lower technical skills. So even the relatively easier to exploit vulnerabilities won't be used by your ordinary insider. I don't recall yet a database breach that was attributed to an actual exploit of a database vulnerability. I think that for highly secured organizations in which there is a higher chance of a trained insider, patching should be of a high priority."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Brian Prince is a freelance writer for a number of IT security-focused publications. Prior to becoming a freelance reporter, he worked at eWEEK for five years covering not only security, but also a variety of other subjects in the tech industry. Before that, he worked as a ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Human Nature vs. AI: A False Dichotomy?
John McClurg, Sr. VP & CISO, BlackBerry,  11/18/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: -when I told you that our cyber-defense was from another age
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
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-2011-3350
PUBLISHED: 2019-11-19
masqmail 0.2.21 through 0.2.30 improperly calls seteuid() in src/log.c and src/masqmail.c that results in improper privilege dropping.
CVE-2011-3352
PUBLISHED: 2019-11-19
Zikula 1.3.0 build #3168 and probably prior has XSS flaw due to improper sanitization of the 'themename' parameter by setting default, modifying and deleting themes. A remote attacker with Zikula administrator privilege could use this flaw to execute arbitrary HTML or web script code in the context ...
CVE-2011-3349
PUBLISHED: 2019-11-19
lightdm before 0.9.6 writes in .dmrc and Xauthority files using root permissions while the files are in user controlled folders. A local user can overwrite root-owned files via a symlink, which can allow possible privilege escalation.
CVE-2019-10080
PUBLISHED: 2019-11-19
The XMLFileLookupService in NiFi versions 1.3.0 to 1.9.2 allowed trusted users to inadvertently configure a potentially malicious XML file. The XML file has the ability to make external calls to services (via XXE) and reveal information such as the versions of Java, Jersey, and Apache that the NiFI ...
CVE-2019-10083
PUBLISHED: 2019-11-19
When updating a Process Group via the API in NiFi versions 1.3.0 to 1.9.2, the response to the request includes all of its contents (at the top most level, not recursively). The response included details about processors and controller services which the user may not have had read access to.