eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Last week, the Independent Oracle Users Group reported that most organizations are not keeping up-to-date with patches for the Oracle database. That news did not come as a surprise to most due to the challenges of testing patches.
Still, with so many databases out-of-step with the latest patch, the findings pose a key question: What do we do about it?
For its part, Oracle has reportedly committed to enhancing the CPU (Critical Patch Update) documentation to help customers determine what areas need to be tested in their environment prior to patch deployment. Company officials did not respond immediately to an inquiry about what would be added. However, bolstering the CPU documentation may be a good place to start.
“Since the patches come out with minimal information about the actual vulnerabilities, and understandably so, it is very hard for an organization to understand the priority of patching and the risk involved in not patching,” said Slavik Markovich, CTO of Sentrigo, adding that organizations can obviously draw some conclusions from the CVSS score.
Having a standard set of applications or scripts to test and validate a patch also helps when it comes time to assess the risk of patch deployment, and can possibly shorten the amount of time needed for testing, said Michelle Malcher, director of special interest groups for the IOUG.
“There was also a recent article in the IOUG Select Journal by Arup Nanda, ‘DBA Best Practices from the Field,” that talked about having two Oracle Homes for the implementing of patches, which helps with recoverability as well as minimizing downtime for patching,” she added.
Planning ahead and having good policies is also important. Enterprises should have a policy of identifying their most critical databases so they can be tested and patched first, Markovich said.
Similarly, Imperva CTO Amichai Shulman said organizations need to incorporate patches into their standard application update cycles. For example, if an organization is planning to deploy a new version of an application in August and their quality assurance process starts in June, the organization should plan to incorporate the April patch as part of the August application update, Shulman said.
However, many organizations lack a policy altogether when it comes to the Oracle updates. According to IOUG, 30 percent of the respondents said their organizations have no guidelines whatsoever regarding Oracle’s CPUs, and just 26 percent require that the updates be applied systematically across the entire environment when they are released by Oracle.
“It’s one thing to have a policy saying, -We only install patches once a year, after each patch has been tested in QA for at least two months,'” Shulman said. “It’s a totally different thing to have no policy at all, which usually results in an organization delaying patch installations for extended periods of time or installing the wrong patches first.”
When asked how quickly they apply CPUs, 30 percent reported they typically apply the patches before the next one is released. The next largest group-25 percent-indicated that they were typically three to six months behind. Eleven percent said they had never applied a CPU.
For help understanding the vulnerabilities, administrators can turn to Oracle Metalink and look to independent sources for additional information.
“In general, during the first few weeks after a critical patch is released, independent researchers publish full details about the vulnerabilities that have contributed to the patch,” Shulman noted. “Reading this information greatly helps security professionals to understand the vulnerabilities and potential workarounds … [S]ome database security experts understand how to read between the lines of the Oracle Risk Matrix released with a patch and are able to interpret and explain more precisely the risk associated to specific environments.”