DBAs interviewed by SearchSecurity.com in recent days offered mixed reviews on the new bulletin format. Some said it will make deploying patches easier, while others said the changes make little or no difference.
In the big picture, half of those interviewed said, the Redwood Shores, Calif.-based database giant still has a way to go in improving its security process.
Unfortunately, said Arup Nanda, director of database engineering for White Plains, N.Y.-based Starwood Hotels and Resorts, most of Oracle's security holes are discovered by outside research firms such as UK-based Next Generation Security Software Ltd. and Red-Database-Security GmbH in Germany. When these firms bring a problem to Oracle's attention, the company takes longer to issue the patches than it should, he said.
"Some of the vulnerabilities are so severe that one would expect a resolution in a matter of days," Nanda said in an email interview. "Yet they took months, and only after exploits had been lingering around the Internet for a while. So yes, Oracle should beef up their process."
Dissecting the new bulletin
Nanda was among those unimpressed with the new bulletin format, saying that at first blush there's little or no difference from the previous CPU bulletins. Chris Ruel, an Oracle DBA with Perpetual Technologies Inc., an Indiana firm that offers services to companies that don't have an in-house DBA, said he couldn't tell the difference between this bulletin and the last one, either.
"Typically I don't pay much attention to the bulletins," he said. "The patches come out and I'm simply required to apply them. I read the technical details on how to apply it, but to me, they are security flaws that simply must be patched, so I don't get as mired in all the flaw details. I couldn't have told you it was any different than last time."
But other DBAs said they did notice the changes, and that they were helpful. Brian Peasland, a DBA working as a contractor with the U.S. Geological Survey, said he liked that the bulletin now mentions the number of flaws in the description at the top of the page.
"This part of the bulletin is much clearer and makes it easier for me to quickly locate the patch for my specific version and platform," Peasland said in an email interview. "Prior to this bulletin, one had to click on another Metalink note and then make one more click just to find the patch number to download. My opinion is that the October 2006 CPU bulletin is much cleaner than previous ones."
Jon Emmons, an Oracle database consultant and keeper of a blog called Life After Coffee, which focuses on Oracle security and other topics, said he also found the bulletin changes helpful.
"Perhaps the most valuable new feature in the CPU bulletin is the executive summaries," Emmons said in an email interview. "These bulleted lists give a great high-level summary. At one point or another we've all had to explain to our boss why we need to apply these patches and now Oracle has given us the words to do it with."
A long patching process
The DBAs said it's important to have a CPU that clearly outlines the nature of the flaws and the specific products affected because the harder it is to study the bulletin, the longer it takes to start a deployment process that includes several hours of testing and system downtime.
Nanda said the actual task of patching isn't time consuming, usually about 30 minutes. But the testing that precedes it does take a lot of time, and if the bulletin details are fuzzy the testing period is prolonged. There's also the problem of scheduling downtime, he said.
"To apply these patches, you have to shut the database, a task easier said than done," he said. "This makes it extremely difficult to find a window to apply the patch, even after the testing."
As a contractor for the U.S. Geological Survey, Peasland said he is required to have the patches applied on all systems a month after they are released. He typically applies the patches to development and test systems within the first seven to 10 days, and then monitors the systems for another week to ensure that the patch hasn't broken other applications. This can be a tight schedule, he said, and the clearer the information, the quicker the process.
Emmons said that if a company's Oracle systems are simple and seldom used, the DBA can schedule an outage, bring the system down for an hour or two and be back up and running with little or no trouble. But that's rarely the case for most companies, he said.
"Very large Oracle shops will install the CPU in a test environment and test critical features of their product," he said. "If new errors crop up they must then determine if there is a workaround from Oracle or if a local workaround is needed. These workarounds can take minutes or months."
Verdict on Oracle security efforts
In the big picture, half of the DBAs interviewed for this story agreed that Oracle has to do more to make the patching process simpler.
"Oracle security experts like Pete Finnigan have often informed Oracle of a security flaw in their product only to have no action taken," Peasland said. "Oracle wants us to buy their product to serve our corporation's valuable asset, its data." Therefore, he said, Oracle "must take appropriate and timely steps to ensure that the corporation's asset is as protected as it can be."
To that end, Peasland said Oracle has no business sitting on a known vulnerability for over a year, as has happened in the past.
Emmons said the upside to Oracle's quarterly patching process is that administrators know when they're going to have to do an update and can plan around it. The downside is that a vulnerability discovered immediately after an upgrade will go unfixed for at least the three-month period between CPUs.
"Oracle has been fairly good about sharing workarounds to mitigate the risk of high vulnerability security issues until the next CPU is released and that has always satisfied me," Emmons said. "But I can see how some of the big-business customers would be a little more anxious to move forward [more quickly] with patches."
In the final analysis, he said, "It's a balancing act. Too many patches and your administrators won't have time to do anything else. Too few and you leave your customers vulnerable."
In an interview with SearchSecurity.com in June, John Heimann, Oracle's director of security program management, and Darius Wiles, senior manager of security alerts, acknowledged that its patching process can be difficult to follow. They acknowledged that a vast array of platforms and mountains of source code can make for some patching mistakes and for complicated bulletins.