Manage Learn to apply best practices and optimize your operations.

Database patch denial: How 'critical' are Oracle's CPUs?

A recent survey found that a considerable number of users are outright rejecting Oracle's Critical Patch Updates, perhaps suggesting database administrators feel comfortable with their security defenses or find Oracle's patches to be more of a nuisance than a necessity. Database administrator and security expert Michael Cobb explains why most database and security pros ignore Oracle's CPUs at their own peril.

There are some databases that are never accessible to unauthorized users. However, be quite sure that is the case before blithely rejecting all patches.
Michael Cobb

Gathering data from many of last year's Oracle users group meetings, security firm Sentrigo Inc. found that two-thirds of the 305 database administrators, consultants and developers surveyed had never installed Oracle's Critical Patch Updates. Oracle describes these CPUs as "the primary means of releasing security fixes for Oracle products to customers with valid support contracts," and the updates are released quarterly.

Some respondents expressed doubt about the importance of Oracle patches. One reader from a blog post, for example, wrote about why Oracle database administrators shouldn't waste time applying patches. Here's an excerpt:

"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, I worry the CPU patch will break some of the bug fixes we have installed and require yet another merge patch."

On the face of it, the survey results may seem alarming from a security perspective. After all, one of the security professional's mantras is: "make sure you have the latest patches installed." Obviously, some folks feel that their databases are safe as long as their organization has good network defenses preventing unauthorized external access. But is this a reasonable position?

The case for not patching
Speaking as the administrator for a number of SQL databases, I don't install all patches on all my databases, and I have two main reasons for that. For one, I'm not using the features that my un-deployed patches are designed to protect; skipping the patch saves downtime and testing. Also, I share the above-cited blogger's fears that installing a patch will break something, including a previously installed bug fix.

However, there are some serious caveats with dismissing any Oracle CPUs. Those working in a development environment may perceive little benefit to installing patches. Yet downtime is not an issue as it is with a production database. Furthermore, there is the question of synchronization between development and production environments; software developed on an unpatched system may not run on a fully patched production system.

For some databases, the analogy to protecting car radio stations may hold true; there are some databases that are never accessible to unauthorized users. However, be quite sure that is the case before blithely rejecting all patches. What about patches that fix holes exploitable by insiders? Are all the people who can get to the database via internal systems trusted? Perhaps in a small company, but otherwise it's important to have some access controls installed. Naturally, apply any relevant patches to those controls to make sure they keep out untrusted insiders.

Questioning the data and the decision
Some have questioned whether the Sentrigo survey is a representative sample of Oracle administrators. However, even if the number of respondents installing zero updates was 33% and not 66%, it would be cause for concern; the results suggest an outright rejection of the updates. It is hard to imagine that many databases don't need any of the patches included in those updates.

More information
Learn about the importance of patches in a Java Runtime Environment.

An attack code for a Windows TCP/IP flaw: Patchworthy or PR stunt?

And one has to wonder who is signing off on the decision to skip them. Is this decision in writing? Does it include a list of the patches and an explanation of why specific patches are not needed, to create an audit trail and assign accountability?

Depending on the type of organization, the need for such documentation may be imputed from compliance requirements such as requirements like ISO/IEC 27002, Sarbanes-Oxley and HMG InfoSec Standard No. 2. The manager in charge of the administrator who handles Oracle patch deployments would be wise to consider documenting when patches go undeployed in case the rationale needs to be justified later.

The price of bad patching practices
Many CIOs and CISOs assume their companies' database administrators are doing their part to assure the security of their databases; in many organizations, that may be the case. But in some cases, administrators may ignore patches because they falsely believe their databases are inaccessible to the outside world. Such statements are what outside penetration firms are routinely tasked to test.

While it's entirely possible that the database administrator of a small firm may be in a position to make such a statement categorically, the penalties for error on this point are considerable. Consider a case involving the Federal Trade Commission and Guess?, Inc. It makes for cautionary reading.

The company's website was found to be vulnerable to a SQL injection attacks for which patches and other fixes were known to be available. Guess? had to therefore submit to a settlement imposed by the FTC. Not that the settlement results ruined the company, but you can bet things were uncomfortable in the IT department for quite some time because an expensive problem could have been easily avoided.

If you're the kind of Oracle administrator who has the power to approve or deny, and thus know about every connection to every database; and if you keep up with the work of Oracle experts like David Litchfield, author of The Oracle Hackers Handbook, and thus know about new developments like the lateral SQL injection as soon as the bad guys did, then you might be comfortable declaring your databases safe and Oracle updates unnecessary.

If you are not in that position, then you might want to consider instituting procedures to evaluate Oracle updates and install all that apply to your architecture. If you're not deploying all of the patches, document when and why they are not installed.

Anyone in charge of patching anything as complex as Oracle databases certainly has our sympathy. Sympathy, however, is likely to be in short supply if your company suffers a security breach through a hole that could have been patched with a published update.

About the author
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several Security Schools and, as a site expert, answers user questions on application security and platform security.

Next Steps

January 2016 Critical Patch Update the largest to date

This was last published in June 2008

Dig Deeper on Microsoft Patch Tuesday and patch management