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."