Eye on Oracle

Mar 4 2009   2:24PM GMT

Many still holding off on Oracle database CPUs

Barney Beal Barney Beal Profile: Barney Beal

Remember a month or so ago, when we asked whether Oracle’s critical patch updates (CPU) were all that critical?

The answer from many (outside of Oracle) was no. In fact, many DBAs considered it too much trouble. Responses ranged from “security ‘experts’ drumming up business through paranoia” to questions about when 11g will be hotpatchable as promised. Some even said, “we believe these patches ARE critical.”

Well, according to a release of the latest survey of the Independent Oracle Users Group (downloadable as a .pdf), many others are holding off on those patches. Now, the survey was co-sponsored by Oracle and we tend to take results from vendor-sponsored studies with a grain of salt, but it does offer some interesting insights. Of the 150 survey respondents, only 26% said CPUs were applied systematically across the entire environment when they’re released by Oracle. Another 19% reported that their organizations do not have any specific requirements for the application of vendor supplied security patches. In fact, 36% require some sort of justification for security patches and favor a risk analysis over a cost/benefit analysis.

The results came as little surprise to Pete Finnigan and he addressed them over on his Oracle security weblog.

He writes:

I always say two things. 1) CPU’s are only part of the problem of securing an Oracle database – that is to be secure you cannot just apply a CPU, you must do all of the other work to secure the database, configuration, privileges, access, audit…. much, much more and 2) at the end of the day; taking out all of the issues, you can either apply a CPU or not, its simple. Well its simple to say but in practice, psycologically, reallity[sic], its often hard to do for lots of reasons, mostly availability, performance, downtime, stability.

Certainly, database security remains a critical topic for organizations. According to a new database security report from Forrester Research (available free with registration), database attacks are at an all-time high. My colleague Shayna Garlick sat down for a podcast with Forrester’s Noel Yuhanna to discuss the results of his research. While Yuhanna asserts that Oracle has the most comprehensive database security, he also advises companies look to independent security providers. After all, most organizations are not Oracle only, they run heterogeneous shops.

So, while Oracle certainly seems to be paying attention to database security, it seems not everyone is listening. What does Oracle need to do to convince you to apply CPUs? Release them more often? Less often? Or are you content to parse through the relevant information to determine for yourself what’s “critical” and what can wait? Are your internal corporate processes adequate for the job?

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Bfedorko
    Database security is an all-too-often neglected facet of Database administration. We DBAs often feel a false sense of security, having the data stores locked behind a firewall, or somewhere on an internal network. However, the more I read about organizations neglecting to take even the most basic steps at shoring up their data store's security posture, the more odd, out-of-step excuses I seem to run into: - "We're on our own server, behind a firewall - No one can get in" Oddly, this article mentions the Forrester Research report detailing "database attacks are at an all-time high". - "We can't afford the downtime" But you can't afford a DR failover site? That would also allow you to roll out the CPUs without downtime. - "We can't risk introducing a bug" You don't have a testbed? Of any sort? How do you test your Recovery? Nothing in your architecture ever changes? Really? - "We do not have any specific requirements for the application of vendor supplied security patches" So unless you are mandated by an outside agency or organization to protect your data, you simply refuse to? I also do not buy the 'Risk Analysis' excuse. Although some CPUs admittedly don't patch critical security holes, about 50% do. What type of mitigation is needed during Risk Analysis to not patch security holes that allow privileged user access without credentials? It would have to be incredibly compelling. As a DBA, I have never been in an organization that did not value efforts to harden their data stores, so I am going to place this responsibility on our doorstep. As a DBA, you are the subject matter expert for the DBMS - If security is lacking in this area, we should step up or be prepared to be accountable for the results. Brian Fedorko
    60 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: