"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