Oracle Corp. issues dozens of security patches every quarter, but that doesn't mean database administrators are necessarily implementing them.
In fact, a good two-thirds of all Oracle DBAs appear not to be installing Oracle's security patches at all, no matter how critical the vulnerabilities may be, according to survey results from Sentrigo Inc., a Woburn, Mass.-based vendor of database security products.
The results are "surprising, and to be candid, quite frightening," said Mike Rothman, president of consulting firm Security Incite in Atlanta.
Sentrigo polled 305 Oracle database administrators from 14 Oracle user groups between August 2007 and January 2008. The company basically asked the administrators two questions: whether they had installed the latest Oracle patches, and whether they had ever installed any of Oracle's security updates.
The results, which come even as Oracle is scheduled to release its next batch of quarterly Critical Patch Updates tomorrow, showed that 206 out of the 305 surveyed said they had never applied any Oracle CPUs. Just 31 said they had installed the most recent security update from the company. In total, only one-third said they had ever installed an Oracle CPU.
In an e-mailed statement, Oracle said the company "encourages organizations [to] apply Critical Patch Updates in a timely fashion to maintain their security posture."
"Critical Patch Updates for the Oracle Database are cumulative for the patch set to which they apply, making it easier for customers to keep their systems current with the latest security patch updates," the company said.
The results support what Sentrigo has been hearing anecdotally for sometime, said Slavik Markovich, chief technology officer at Sentrigo. "Some database administrators don't even monitor for Oracle's CPUs. They don't even know when the CPUs come out," he said. "Sometimes, even if their security department tells them to deploy it, they just ignore it," he said.
There are two major reasons for the trend, Markovich said. The first and most important is that most DBAs fear the consequences of installing a patch on a running database, he said.
"To apply the CPU, you need to change the binaries of the database," he said. "You change the database behavior in some ways that may affect application performance," he said. So applying security patches to a database typically involves testing them against the applications that feed off the database, he said. "This is a very long and very hard process to do, especially if you are in enterprises with a large number of databases and applications," he said. Applying these patches means months of labor and sometimes significant downtime, both of which most companies can't afford, he said.
Some application vendors also don't certify Oracle patches to run with their applications, Markovich said. As a result, a database administrator might, for instance, be wary of installing a patch on an Oracle database that is being used by a SAP application because that might be grounds for the application vendor to refuse addressing any disruptions to the application, he said.
Another problem is that companies that want to install the most recent Oracle patches need to first ensure that they have already installed the previous patch set, Markovich said. So companies that fail to keep up with the latest patches keep falling further behind with each patch set release, he said.
The consequences of companies failing to install needed security updates can be severe, Rothman said. While the numbers quoted in the Sentrigo survey seem to be surprisingly high, it's important not to get hung up on the statistics, he said.
"The real message here is that people who are in charge of operating systems and even applications have gotten conditioned into paying attention to updating their systems fairly soon after a patch or a fix comes out," Rothman said. In contrast, many database administrators continue to drag their feet when it comes to implementing needed security fixes, he said.
To a certain extent, it is harder for database administrators to apply a security update to their environment compared to an application or an operating system environment, Rothman said. Even so, database administrators need to schedule maintenance times and implement change control processes to mitigate disruption from patching, he said. Relying on compensating controls, such as tools from security vendors, can help delay the need for patching, he said. But ultimately, companies need to install security patches, he said.
Amichai Shulman, chief technology officer at database security vendor Imperva Inc. in Foster City, Calf., expressed surprise that so many DBAs in the Sentrigo survey claimed not to have ever applied Oracle CPUs. While the number seems overly high, the fact remains that many database administrators do put off implementing Oracle patches because of the complexity involved, Shulman said.
"I understand the delays. Having installed Oracle patches myself, I know the excruciating pain involved. The process is manual and not very straightforward at all," he said. One reason why so many administrators in the survey said they had not implemented Oracle CPUs is because they might have chosen simply to keep moving to newer versions of the operating system periodically instead of applying large patch sets, he said.
Oracle was not immediately available for comment.
Related Items
- Jaikumar Vijayan: DBA's not to blame for Oracle patch application failures?