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.

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*

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

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.

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…