Wed 22 Aug 2007
Oracle CPUs – Do We Care?
Posted by Slavik under compliance, DBA, Oracle, patching
[5] Comments
I promised to blog a bit about my traveling, so here I go:
I was visiting customers in India and the US and giving presentations to Oracle user groups in the US. Amazingly, the state of US airports is just getting worse every month. Flying from Israel to India and from India to NY went without any problems. However not did a 35 minute flight from NY to Boston take 3 hours, but they managed to lose my suitcase in the process. Every flight I had in the US in the previous week was late.
Enough moaning and back to Oracle security… I would like to share with you some insights I had while giving presentations. First, it looks as if database security is getting more and more attention from both DBAs as well as IT managers. By show of hands at the presentations, I could see that at least some of the DBAs are handling security issues as part of their day-to-day job. But still, DBAs are not hearing the following from their managers – “last year you met your MBOs because no database breach had occurred. Here is your bonus…” – though many have heard the bonus speech for HA or performance MBO achievements.
Second, almost no one had deployed the July 2007 Critical Patch Update from Oracle. From a crowd of about 50, only 2 raised their hands.
Third and most startling of all, only about a third of the DBAs have ever deployed an Oracle CPU. Let me repeat that again – more than two thirds of DBAs in this small but significant sample have never deployed an Oracle CPU. Ever.
So this got me thinking – do we care about Oracle CPUs at all? Oracle was getting a lot of heat from security researchers for not providing security patches or providing them with irregular intervals. Finally, Oracle is stepping up to the plate with the patches. They provide them on regular basis, they announce the the patch before issuing it so organizations can prepare for them. They are improving coding techniques and code vulnerability scanning tools. And after all that, customers are still not protected. The reason for this is that the database is an extremely complicated piece of software and is the life-line of the organization. An enterprise will need to test the CPU thoroughly before deploying and testing takes a lot of time (months). This is further complicated by the fact that many organizations have applications running on top of Oracle databases, and those applications are not “forward compatible” and certified by their vendors to run on future Oracle versions.
Ironically, from a security standpoint the situation after a CPU is announced is actually worse than before it is announced: The hackers get a road-map of all the vulnerabilities while most organizations have not yet plugged those holes. This is a similar notion to hacking IPS software in order to retrieve vulnerabilities (see this black hat presentation).
I’m not saying that Oracle should stop providing CPUs. Quite the contrary, I’m saying that organizations must deploy CPUs as quickly as possible to keep this sensitive period short. Even considering the objective difficulties in applying patches, it seems that enterprises are not taking database vulnerability seriously enough. Also, organizations must have other solutions to mitigate the threat in post-CPU release period. Those solutions must not change the Oracle software at all or else they will fall into the same trap of interdependency, stability issues and so forth. They must provide virtual patches to externally test for attacks and plug the security holes from the outside.
I am curious to know other people’s experiences and views on this topic – so fire away…
5 Responses to “ Oracle CPUs – Do We Care? ”
Trackbacks & Pingbacks:
-
[...] fragt sich: Oracle CPUs – Do We Care? […] do we care about Oracle CPUs at all? Oracle was getting a lot of heat from security [...]
-
The Reality Gap (1) – Software Maintenance…
It’s so long now since the OUG Scotland Conference and I ended up leaving early because I wasn’t feeling too good so I’m not going to attempt a review of the day. I asked a few others what they thought afterwards and the general view was that the …
Hi,
I did a user group presentation about applying CPUs earlier in the year. I think its fair to say that the numbers would have been similar at that group as they were for yours.
My recommendation, for what its worth, was, and is, that the DBA agrees a CPU patching strategy with one or more of the following:
- their boss,
- the individual business owners
- the security team
…and gets this agreed to in writing.
These people, depending on the organization, should all have a say in weighing up the risks of patching (or not patching), versus the work involved. This is a lot easier to achieve, I think, since the CVSS has been adopted.
The strategy could be to:
- apply all relevant CPUs
- apply no CPUs
- apply relevant CPUs with a certain CVSS score
If you have an agreed strategy and something goes wrong – i.e. either the CPU mucks up your database, or you get hacked – then its not just the DBA who carries the can.
Cheers
Matt
Hi Matt, thanks for your insightful comment. It’s certainly not an all-or-none decision whether to apply or not apply CPUs and when. Given the genuine difficulty in performing any kind of upgrade to a production database, I think that your approach can certainly result in better security with minimal business disruption. It may require some education, however, since people tend to ignore threats they don’t understand (until the threats have materialized…)
I tend to work in more secure environments where the CPUs are not optional. Our approach is to do an analysis of the CPU based on the CVSS score and security controls in place in the particular environment that may mitigate the vulnerabilities. This gives us a priority for which components to patch first but all are eventually patched. In generally, we consider ourselves successful if we can complete the CPU before the next one comes out. Not exactly a high bar for success but about the best we can do when confronted with HA requirements and, oh yeah, doing the real work of the company.
We struggle with the E-Business Suite patches not being cumulative. You cannot fall behind and catch-up on the next CPU.
A place we seen a little improvement is the quality of the patches for “stand-alone” components. Obviously from a security perspective you should only install what’s needed. So if you only need Web Cache or Apache (OHS) just install the stand-alone components rather than the full app server. The CPU’s failed on a regular basis for these environments but have been better of late. It looks like Oracle is now doing a better job of testing the CPUs for the stand-alone components.