In switching to a schedule of quarterly patch rollup releases, Oracle Corp. is sparing grateful DBAs and customers from the constant patching of monthly releases, to which the company originally alluded three months ago.
“We began talking about going to a regularly scheduled delivery model for patch delivery over the last year,” Oracle chief security officer Mary Ann Davidson said Thursday in a conference call with journalists.
“We found that customers would prefer to get things on a schedule they can plan around that fixes multiple things, as opposed to patching on, say, a Wednesday or a Thursday, being forced to drop [other tasks], and patching under duress.”
Duress is certainly what customers feel when facing monthly patching, according to Ian Abramson, chief technology officer at Red Sky Data Inc., in Toronto.
“Its a good idea to decrease the frequency,” Abramson said. “[Database administrators] have enough to do now. If they put out a patch every month, theres no way theyre doing anything but installing patches,” what with testing the patch, backing up the system in question and then installing the patch, he said.
When people speak of monthly patch releases, they are of course talking about Microsoft Corp.s patch release schedule. Whereas most agree that copying Microsofts schedule would put an undue burden on already maxed-out DBAs, some say they would encourage Oracle to copy its rival in other ways, such as picking up on the automatic patch update capability and tools built into Microsofts infrastructure.
“Microsoft has spent a lot of time and money making the patching process easy and fast,” said Aaron Newman, database security expert, chief technology officer and co-founder of Application Security Inc., in New York.
“With auto update and tools that make it pretty simple to roll out, you have the facility to roll a patch out to 5,000 servers. Oracle doesnt have the ability to roll out patches to 5,000 servers,” at least not easily, Newman said, given the fact that it takes four to five hours to research a patch, back up the database, test the patch and install it.
Not everybody thinks the click-here scenario is appetizing when it comes to Oracle systems, however. “In theory I like it. … But Im not willing to trust that to a point-and-click scenario,” Abramson said. “You dont want it to be too simple so that anybody who does it may not have the knowledge to do it.
“I would like to see Oracle simplify [patch installation], because it would be nice to just click and get updates, and part of the database installer would be that it just downloads a patch and starts the installer. … But if its just point and click, its a little too easy to install [something like Windows Service Pack 2, about which many complaints have been lodged].
“Things go critically wrong, and your business ends up further behind than they would have been had they been a little more careful with the installation,” he said. “Its too easy to hit yes to continue when you should have hit no.”
Next Page: No further patch details forthcoming.
No More Details
The patch release schedule, due to begin Jan. 18, will encompass patches for all Oracle products, including Application Server, Oracle Database, Oracle E-Business Suite, Oracle Enterprise Manager and Oracle Collaboration Suite. The patches will be available via Oracles MetaLink support site.
Subsequent patches will be issued on April 12, July 12 and Oct. 18, with interim patches possible in the eventuality that serious, critical vulnerabilities arise, Oracle said.
These dates were chosen to maximize customers schedules, avoiding blackout periods when customers are, for example, closing books at the end of a quarter, Davidson said.
The database giant has no plans to increase the amount of detail it gives on patches, however, according to Davidson—an omission that some call regrettable.
Analyst firm Gartner earlier this week issued a report in which it bemoaned Oracles refusal to provide more detail on the consequences for users if they fail to apply security patch 68. According to the research note, Oracle declined to say whether the vulnerabilities affect older, nonsupported versions. “At worst, records in every Oracle database you own could be vulnerable,” the report said.
Davidson defended Oracles policy of keeping details close to the vest, saying that the company is walking a fine line between informing customers and giving hackers the information they need to exploit a given flaw in the wild.
“Our position has always been to strike a balance between providing enough information so customers know what the risk is for not applying a patch, and not giving people information to crack systems,” she said.
“Its certainly true that, as part of our ongoing discussions over the last year on moving to this patch model, we continue to talk about what is the right amount of information and what you need to decide whether you should apply the patch.
“That is not the same level of detail that some in the more technical research community want to see, but our primary focus is serving customers,” Davidson said.
Its true: The more technical security research community would indeed like to see more information freely shared—particularly given that hackers already possess the information, Newman said.
“Unfortunately, all the hackers already know everything about this,” he said. “The hackers are some of the people who found these [vulnerabilities], and the hackers are the ones who reported them to Oracle, and theyre the ones already sharing exploit code on them. Theyre the ones who already have the information.”
Newman said customers have been calling specifically seeking information on whether they should install patch 68 and what the issues are concerning workarounds, for example. “They havent been able to get the information from Oracle,” Newman said.
Gartner backs up Newman on the issue.
“Gartner recognizes that making detailed information public could help hackers and lead to successful exploits,” Gartners note says. “However, providing details of an exploit differs from offering information about the implications of not protecting yourself against that exploit.
“We believe that Oracle is erring by refusing to discuss how vulnerable customers are if they do not apply the patch. System administrators do not have enough information to decide what to do (for example, which servers to prioritize or which data is most vulnerable), and this could delay the implementation of patches.”
They are two fine lines to walk: how often to send out patches, and how much information to reveal. At this point, Oracle is playing it safe on both.