Eye on Oracle

Jan 13 2009   10:54PM GMT

Are Oracle’s Critical Patch Updates really that critical?

Shayna Garlick Shayna Garlick Profile: Shayna Garlick

You most likely saw some of Tuesday’s pressing headlines about Oracle’s latest Critical Patch Update, such as “Oracle planning Patch Tuesday whopper” and “Oracle plans massive update for Tuesday.”

But just how massive — and critical — are these patches, really?

It’s a question that’s been asked before but certainly deserves to be asked again, especially as Oracle continues to grow, acquire more companies and products, and in turn, find more security vulnerabilities

This Critical Patch Update has 41 security fixes. These include fixes for vulnerabilities in products ranging from Oracle 9i to Oracle 11g, including the former BEA WebLogic Server and Portal, Oracle E-Business Suite, Oracle Application Server and JD Edwards Tools. Oracle also recently had a problem with its Cluster Ready Services, spurred by a change in the world’s time standard to adjust for the slowing of the earth’s rotation.

This “Patch Tuesday whopper,” however, seems relatively modest compared to previous patches, such as the 101 fixes in October 2006, and definitely equivalent to recent updates like the 36 fixes just three months ago.

With all these patches also comes the question: Should you apply them?

According to Oracle, yes. In its prerelease announcement to customers this month, “Oracle strongly recommends that customers apply fixes as soon as possible.”

But many DBAs and Oracle experts think differently. When we asked the question last year to see just how much DBAs really care about Oracle’s latest Critical Patch Update, many responses were consistent with a survey that found two-thirds of Oracle users never install the critical patches.

One concern is that while these patches are meant to fix problems, they can also cause some of their own. Oracle expert Don Burleson addressed this just a couple of months ago, when an Oracle user asked him for advice on when and how to apply Oracle Critical Patch Updates.

Burleson’s advice?

“You DON’T have to apply patches, and sometimes patches can CAUSE unplanned issues.  The best practices are always to conduct a full stress in a TEST environment before applying the patches in production… I wait for major releases and re-install at-once, and I only look at patches to fix specific issues.”

What’s your approach with Oracle’s patch updates? Are they worth the time and effort? Have your experiences with these patches changed at all in the last year, or are they still the bane of your existence?   

6  Comments 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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Shayna Garlick
    "bane of my existence"? Not in the least. I simply do not install them. Unless there is something major in any of them. Most are just patches for pretend problems, invented by some security "expert" drumming up business through paranoia. None of our Oracle databases is on a subnet open to the outside world and all of them use middleware in dedicated subnets under strict firewall rules. Anyone hacking into the middleware is the least of our troubles, let alone anyone being able to reach the db servers. In addition, I've got my traps on to detect and warn of unauthorised logins. So why should I spend ANY time patching up for "security holes" that simply are not likely to be a concern in my environment? Furthermore: it's well known that quite a few of the CPUs have caused other problems and instabilities. Which means: no one in his right mind would install them without a full regression test. Here I fully agree with Don's opinions. Now, I don't know who is handling this at Oracle but if they think we are gonna spend the time, resources and money in full regression tests of ALL our db systems every 4 months, then they are dreaming at a very high rate... "bane of my existence"? Not likely...
    0 pointsBadges:
    report
  • Shayna Garlick
    I remember in OOW 2006 Oracle announced 11g will be hot-patchable... is it hotpatchable now? Still the downtime due to the patch upgrade is not always worth the effort, and the fix will be covered by the next patchset, for instance 10.2.0.5.
    0 pointsBadges:
    report
  • Shayna Garlick
    We believe that these patches ARE critical and are fairly easy to apply if you are an experienced Application's DBA. For those DBAs who decide to never apply them, we hope that their management is aware of the potential corporate risk cause by their DBAs who are making "business" decisions on their own. Most DBAs count on firewalls to protect them from these security holes. Gartner and the FBI state that anywhere from 70-80% of all data loss is due to employees inside of firewalls. If you know the vulnerabilities exist (and all Apps DBAs do), then it's a pretty simple process to access any data in the database. John Stouffer Applications DBA
    0 pointsBadges:
    report
  • Shayna Garlick
    There is no right answer, there is only your answer. Each DBA team should review the CPU patches every quarter when they come out, in association with their management and their business. And then make an informed and intelligent decision that applies to their environment. There are good pros and cons listed here already. Walking down a checklist of what is important to your organization is much more important than listening to someone else. My Top 10 CPU questions: 1. What does the CPU patch actually fix? 2. What part of that applies to what I am running? 3. What is the corporate philosophy on patching? (Always, Never, sometime, only if critical?) 4. What is the potential impact and result if I don't patch? (Vulnerabilities, down time, bugs, etc.) 5. What is the potential impact and result if I DO patch? (Problems with patches not working correctly with the rest of the software?) 6. How easy (automated) is it for me to test? 7. How much regression testing can I do right now? 8. How thorough is my regression testing? 9. At the end of the day, what is my risk? 10. At the end of the day, is it cost-effective? Note that none of these questions should be asked & answered ONLY by DBAs -- this is a business impacting decision and should be made in conjunction with the business. But the DBA team is critical in turning the techno-speak in the CPU release into business-impacting statements unique to their business. *Dale*
    0 pointsBadges:
    report
  • Shayna Garlick
    Dale has a great, common-sense guideline for approaching Oracle's Critical Product Updates! It may take a little discipline to keep that process going, but it is thoughtful and solid. I have to disagree with Don Burleson. I have personally applied dozens of CPUs on (literally) hundreds of systems of all flavors. I have yet to see a problem on our production servers that was caused by a CPU. Of course, I have seen a few weeded out through thorough and careful testing beforehand. The problem with simply not assessing and applying these CPUs due to FUD (Fear, Uncertainty, and Doubt) comes when things go badly, or when you need to meet SOX, HIPAA, PCI DSS, FDCC, FISMA,etc. compliance. Even on a closed system, if an insider is able to view/modify/delete sensitive information by exploiting a vulnerability fixed by a CPU, your company will be in a very unenviable legal position, as ignoring security patches is not adequately performing 'due care'. Also, when operating under various compliance standards or on a DoD system, there is rarely an option to avoid applying a CPU, unless you can document a specific problem the application will induce and your plan to mitigate or eliminate the risk. This is where Dale's process, when well-documented would be an excellent solution. If your DBA has a stringent standard of apathy towards Oracle CPUs, it may be an indicator of systemic security problems in your data stores as well, and may warrent some pointed questions: - Are we auditing, at the very least, privilege escalation and access to sensitive objects? - Are we making sure that glogin and the system executables are not being tampered with? - Do we have a benchmark of defined roles and privileges documented? - Are we logging who is connecting and accessing the data, when and from where? If the answers to these are 'no', you wouldn't be aware of a security breach even if it had happened! Turning the key of your database and letting it go can be a very perilous practice despite what the remote database administration service vendors may tell you. If data is the lifeblood of your company, it really should be maintained AND protected as such. No company wants the bad press that follows a data theft.
    0 pointsBadges:
    report
  • "John
    Oracle needs to create management tab/tools for security. just try to change passwords for sys, system, sysman, dbsnmp etc. via commandline for a RAC system and see what happens! -- good luck!
    0 pointsBadges:
    report

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: