Thoughts on Oracle Non-Patching

Thanks to SANS Newsbites (probably the best weekly security round-up around) for pointing me to the story Two-thirds of Oracle DBAs don't apply security patches. They are all citing this Sentrigo press release, which I will quote directly:

Sentrigo, Inc., an innovator in database security software, today announced survey results indicating that most Oracle database administrators do not apply the Critical Patch Updates (CPUs) that Oracle issues on a quarterly basis...

When asked: “Have you installed the latest Oracle CPU?” – Just 31 people, or ten percent of the 305 respondents, reported that they applied the most recently issued Oracle CPU.

When asked: “Have you ever installed an Oracle CPU?” – 206 out of 305 OUG attendees surveyed, or 67.5 percent of the respondents said they had never applied any Oracle CPU.


Of course, Sentrigo has a business reason for reporting these figures:

Sentrigo created Hedgehog, a host-based database activity monitoring and protection software solution, to detect and prevent unauthorized database use by hackers and company insiders. Hedgehog’s unique virtual patching ability immediately protects databases against vulnerabilities that have been discovered, but not yet patched, as well as against zero-day exploits of certain types.

Hedgehog installs on the database server itself, unlike a product such as BlueLane which is network-based.

When I read a story like this, it shows me that Oracle servers in such a configuration have effectively decided to avoid the resistance phase of security operations. (Others call this "protection" or "prevention," but since all such measures are ultimately doomed I prefer using "resistance.") All that's left is detection and response. Somehow I don't think companies that have never installed an Oracle CPU are devoting extra resources to detection and response.

However, I consider it a valid strategy to spend more time on detection and response if the cost of resisting is considered to be too high. (I am probably being generous here.) Detection and response is the only viable strategy when confronting the most advanced and persistent threats, because no degree of resistance will prevent compromise.

In shops where patching is never done, the only event which could possibly convince a database administrator and his/her management to apply patches would be a severe incident. If, however, you don't bother devoting resources to detection, you may never know you were compromised. It's disappointing how that works. At some point your breach may make the papers, but right now there's still a pervasive attitude that "it won't happen to us."

At the end of the day I remain convinced that building visibility in (BVI), then using that visibility to build rapid and skilled detection and response capabilities, is the best we can do. Of course I would like to see the government and commercial building security in (BSI) initiatives make progress, since their success means less work on more routine intrusions for CSIRTs. However, BSI without BVI leaves us in the same state we find ourselves now, except the intrusion methodologies will have moved "up the value chain."

Comments

Unknown said…
Also, Oracle patches are much more difficult to get ahold of than, say Microsoft patches. One must have an Oracle Tech Net / Metalink account, and I could find no direct / easy way through the Oracle site to navigate to the CPU download page. There have been times that, in order to download a patch, I had to input the license number of the Oracle installation that I was running. In large bureacratic organizations, this information may not be immediately available. And finally, it is often difficult to find the patch you need -- 9i vs 10g? 9iAS vs 9i? SPARC or Intel? Is my 9i database still supported? Do I need to drop thousands on an upgrade in order to be secure?

Also I think that buck-passing has a lot to do with this problem. The "it's not my job" mentality is pervasive; a lot of DBAs that I've spoken to want to do nothing more than to keep their database / application up and running.

Which brings me to the next point that there is also the mentality that "if it ain't broke don't fix it". If the application or database is working fine without the patch, and there is even the slightest chance that applying the patch could cause problems, then the DBA will not apply the patch. Many of the DBAs I've met just don't have the in-depth knowledge required to troubleshoot problems that could come up. They know how to add users, create tables, change permissions, perform backups and other maintenance. But if you get outside those lines, you're asking for trouble.
Joe said…
Patching Oracle can be dangerous if you are patching a production database server. No one should be patching a production server though. Patch Oracle QA and test test test.

Patching Oracle is a much slower and meticulous process though.
Mark McKinnon said…
There is alot more that needs to be taken into consideration when patching Oracle Databases then just the database. If you happen to be running Oracle Apps, SAP, Baan or one of the other behemoth Application suites then there might be full system testing in order to get the patch in. Now that can take quite a bit of not only the DBA's time but also Application support and Business process Testing. I certainly will not say that not applying security patches is not important but when you have to get Application Support and Business users involved they tend to shy away from doing the testing as they feel this Patch does not effect them. This can bring the morale of the DBA down as there stuff is not deemed critical and takes the back burner. How many DBA's out there have wanted to upgrade there databases only to be shot down becuase the app people and the business does not want to test. The DBA can do only so much testing on there end to mitigate the risk of patching. This also apply's to DB2 and other Databases as well.

Popular posts from this blog

Zeek in Action Videos

MITRE ATT&CK Tactics Are Not Tactics

New Book! The Best of TaoSecurity Blog, Volume 4