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

12:53 PM
Connect Directly

Few Oracle Customers Have Official Database Patching Policies

Joint survey by the Independent Oracle User Group and Oracle finds database patching practices weak

Most organizations running Oracle databases don't require the application of the database vendor's Critical Patch Updates -- in fact, only 26 percent need them, according to a new report .

"What I found interesting in the results, only about 1/3 of the respondents has organizational policies requiring regular applications of the CPU. Another 1/3 need to justify the patch, and the last 1/3 has no policy to apply Oracle security patches (or other vendors')," blogged Michelle Malcher, a database administrator and member of the Independent Oracle User Group, which, along with Oracle, conducted a joint online survey of customers' patching practices.

The survey, which included 150 respondents polled between May and August of last year, highlighted what many security experts long have said -- that many organizations either do not patch their Oracle databases or just can't keep up with them.

Around 19 percent of respondents said their organizations don't have specific policies for requiring security-patching for any applications, and 11 percent said their patching policies do not include Oracle database patching. According to the report, 30 percent have no official policies for CPUs, and 36 percent said they have to justify any Oracle patching. Around 6 percent only patch mission-critical databases.

Oracle shops are having trouble keeping up with the patch cycles, too. More than half (55 percent) said they are one or two patch cycles behind. Around 30 percent said they install updates before the next CPU is released; 25 percent are one CPU behind (three to six months), while 10 percent are two CPUs behind (six to nine months), 8 percent are three CPUs behind (nine to 12 months), and another 8 percent are more than 12 months behind in their patching. Another 11 percent said they never apply CPU patches.

Even so, the respondents said they were mostly satisfied with the CPU as a way to protect their databases. Around 42 percent said the process was effective or extremely effective in securing their database environments, and 45 percent said it was "somewhat" effective. Around 13 percent said the CPU process was ineffective.

When asked what would help institute more timely and consistent patching of Oracle CPUs, one-third said organizational policies, while another one-third said enhanced tools and documentation. Around 16 percent said a massive malware infection would improve patching, and 10 percent said they didn't need to change their patching behavior.

"Our database environments tend to be more complex with several different applications accessing several databases," Malcher blogged. "Applying patches tends to bring the fear of what is going to break, so having organizational patching policies would help offset having to justify the patching. In addition, having documentation or tools to better be able to test changes to the environment before the actual deployment of the CPUs would help reduce the risk of outages, and possibly reduce the cost and time required to implement a security patching policy."

Oracle, meanwhile, plans to explore ways to better educate its users about security patching, and will enhance its CPU documentation "in order to help customers determine which areas need to be tested in their environment prior to the deployment of Critical Patch Updates against production systems," according to the Oracle/Independent Oracle User Group report.

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

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
US Sets $5 Million Bounty For Russian Hacker Behind Zeus Banking Thefts
Jai Vijayan, Contributing Writer,  12/5/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
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
PUBLISHED: 2019-12-11
Tableau Server 10.3 through 2019.4 on Windows and Linux allows XSS via the embeddedAuthRedirect page.
PUBLISHED: 2019-12-11
Yabasic 2.86.1 has a heap-based buffer overflow in the yylex() function in flex.c via a crafted BASIC source file.
PUBLISHED: 2019-12-11
On Moxa EDS-G508E, EDS-G512E, and EDS-G516E devices (with firmware through 6.0), denial of service can occur via PROFINET DCE-RPC endpoint discovery packets.
PUBLISHED: 2019-12-11
The VisualEditor extension through 1.34 for MediaWiki allows XSS via pasted content containing an element with a data-ve-clipboard-key attribute.
PUBLISHED: 2019-12-11
MediaWiki through 1.33.1 allows attackers to bypass the Title_blacklist protection mechanism by starting with an arbitrary title, establishing a non-resolvable redirect for the associated page, and using redirect=1 in the action API when editing that page.