My employers or customers have regularly installed the patches since the practice began, so here’s one vote in the minority. What the survey fails to specify is whether or not the respondents had responsibility for managing the patches. Yes, I haven’t done the patches for years — but also yes, someone else has done them.
Ravi Krish |
In my last job as DBA for a huge IT consulting multinational I was leading a half yearly CPU patch application project for all the clients. We used to apply if not regularly at least half yearly the CPU patches. Quarterly is a bit too frequent and requires way too much time and effort considering there were hundreds of databases on multiple clients.
In my current job for a govt agency there has not been a single CPU applied. I’m proposing to apply one now and in future look forward to applying as they are released. There are only about 5-6 databases here and it’s not too time consuming to apply for about 5 databases every quarter.
All of our Oracle technology is inaccessible to the outside world so applying these patches is analogous to protecting the pre-set stations on a car radio in case it gets broken into. Plus, the pessimist in me believes it is partially a ploy to get us to move up to the latest release of Oracle so they can keep their support costs down. Plus I worry the CPU patch will break some of the bug fixes we have installed and require yet another merge patch.
Jeroen van den Brink |
In my current job, cpu patching is part of database administration. As soon a cpu is available, the impact must be done in one day and if applicable, the cpu will be applied on the Oracle Ecosystem (hundred databases and a few application servers). The latest years I guess secrurity is more an issue than a few years ago. In my recent dba jobs there was no CPU patching whatsoever. I think the servey gives an accurate view.
Ravinder Bahadur |
This is a tricky part and a survey of just 305 DBA’s may not be a right point. I as a DBA have worked with many clients. Some of my major clients who had 100′s of DB’s running including the Dev and UAT environments did not initially follow the rule but since they outsourced the IT dept to vendors they have become particular about it but not as much that they follow it up every Quarter.
Every Quarter is a bit too much for any company with a large base.
Some of my clients dont have proper DBA’s so they have got the work done by their System Admin guys. ( Yes in many places the System Admin doubles up as a DBA too)
Darryl’s comment is seems on par with what I’ve run into.
The general thought process is that since it’s only on the inside that:
1. It’s safe because there are 1 or more firewalls between it and the big bad internet. Or better yet, it’s inside an internal DMZ so users can’t directly hit the database.
2. If you make it onto the internal network, we have no good security controls in place, so what difference does it make?
Of course, when I point out the reality of the threat landscape, people usually fall back on “well, it hasn’t happened to us, so it couldn’t be that big of a risk…”
Oracle is ripe for the picking for the next worm or mass hack. Oracle needs to own up and release patches that are less of a burden for DBAs to test and apply on a widespread basis.
CPU patches are not as thoroughly tested by Oracle, compared to full patchsets. Consequently there are risks in installing CPUs. You have to balance the risks to service in installing a CPU against your perception of the threat to security of not installing the CPU.
CPU patches are truly a pain, and the whole patching process leaves much to be desired – especially in the area of regression testing. However, due to Sarbannes-Oxley, any publicly traded company should be at least reviewing every quarterly security patch to determine risk and vulnerability. We do not apply every patch – we have many databases, and to apply every patch to every environment and test, would mean we wouldn’t have time/resources to do the rest of our job. We do review each CPU though, and so far we have applied 3 of the patches across the board, and have applied some of other CPU patches in a targeted manner (specific applications/vulnerabilities).
We rarely patch according to the critical patchsets. We do have the luxury of sitting behind firewalls without any outwardly facing interfaces though. Historically we have had no end of problems with Oracle patches fixing problems we don’t have only to create new bugs in areas which we use. Patching requires testing and regularly testing dozens of apps and hundreds of databases isn’t justifiable where I work. We patch what is broken and fully patch at upgrade time. In between we patch as required.
Seth Miller |
We have over 250 different database that we are responsible for all over the country. We tell our clients that the patches are available and we will administer them in the maintenance window if they schedule it and choose to do so. Currently we have three customers that regularly request the patch. If it ain’t broke…
1- if all your apps are handled by 3rd party applications, totally outside of the Oracle db sphere,
2- if none of your apps allows for direct SQL entry or command line use – they all use proper front-end technology instead of “shopping cart” dementia,
3- if all your Intranet is protected by multiple external firewalls,
4- if all your desktops are protected with anti-virus and other monitoring tools,
5- does anyone know of any major sites where the above is not true?
can someone then please explain to me why is Oracle foaming at the mouth that dbas don’t install CPUs?
Because quite frankly: if NONE OF THE PROBLEM CONDITIONS they cover are present in a site, WTH would anyone waste time and resources to install/test them?
Do CPUs cover bugs as well? Can anyone then afford to re-test all their applications every three months just because someone at Oracle wants a bug fix installed as part of a security fix?
Does anyone install these CPUs WITHOUT re-testing their apps?
Now that we’ve come down to earth, can we please stop talking about unrealistic patch release schedules and get on with life?
Why do I pay for medical care if I’m not ill? Why do I have paid a lot of times for assurance if I have never had an accident (and probably I’ll never have one)?
Why do you care if it is nearly imposible?
Just because IT IS NOT IMPOSIBLE. Does a firewall grant security? Yes… or not. It depends on the firewall administration, bugs in the firewall firmware (and there are a lot, trust me). A firewall with 5 thousand rules it is not so secure, we all now that, and there are a lot of firewalls out there with a large number of rules.
I have to tell you sincerely something, I thouhgt I will never have to read what I’m reading in this blog.
Please, DBAs, come back to earth and install the patches in those database were my name, birthdate, address, sex medical issues, bank account number, PIN hash, credit card number and many other personel things are. And if you can’t get on with your life, it’s your problem. Please, for good, change your work carreer.
Thank you (so called DBAs-that-do-not-intall-patches-were-my-personel-data-is-stored).
the number of databases that store personal data is VERY small indeed.
It’s probably a good idea to stop the “pending doom” argument to force dbas to install silly patches…
For those Oracle dBA’s that do not patch, Thank you. I am a security assessor and Penetration tester for a company that is required to adhere to PCI-DSS. Every single Oracle instance we have ever tested has been like butter to go through.
The dBA’s have used every single argument in their arsenal to avoid patching. What they don’t realize is that is there is ever a breach, regardless of other network controls like Firewalls, they are the first to be on the sacrificial slab.
What many dBA’s fail to understand is that applications that access these databases can be very buggy or vulnerable, allowing someone to use them as a platform to exploit all the Oracle vulnerabilities they so loudly proclaim are not a problem.
keep it up, my fees for post forensics investigations are safe.