The Top Five Challenges In Securing Oracle Databases

[Excerpted from "Database Security: Oracle Offers New Tools To Counter Threats," a new report posted this week on Dark Reading's Database Security Tech Center.]

It’s not easy to secure any relational database, let alone one as enormous and feature-rich as Oracle. The product’s massive and diverse deployments and legacy installations make it virtually impossible to identify and defend against every potential threat. Its connectivity to Web apps brings open-source and third-party variables into the mix, making the end-user organization even more vulnerable.

However, it is possible to tame the Oracle beast, especially with some new tools the company recently launched. Let's take a look at some of the security challenges Oracle database users face, and some of the methods of handling them.

Challenge 1: Patching
In the past, Oracle was terrible about creating timely patches for vulnerabilities brought to its attention. Highly publicized vulnerability disclosures and customer outcries have altered the company’s approach. Oracle still lags in meaningful disclosure of vulnerability risks, and it certainly does not communicate risk in a language its customers understand, nor does it typically provide workarounds. Nevertheless, it does release security patches in a much timelier fashion than it did just a couple of years ago.

But any Oracle DBA will tell you installation of Oracle patches is difficult, especially since systems often require rebooting after patching; the database is a hub around which many business functions revolve.

And taking the database offline to patch is not the only issue; changes to database functions cause side effects to ripple through the entire organization. Most DBAs have endured a major database crash after installing a patch and have suffered through the subsequent cleanup process.

Challenge 2: Deployment Complexity
Organizations from midsize companies to the largest enterprises have embraced virtualization to improve service and increase flexibility and redundancy while reducing operating costs. Grid systems push scalability and load balancing to new levels. And cloud installations, with Oracle databases provided as a service, are a reality.

Each of these new deployment models creates threat vectors. Multinode, virtual, and replicated installations make it much more difficult to verify configurations settings. It is far more difficult to verify patches, access control settings, and identify misconfigured machines.

What’s more, many attackers surreptitiously alter configuration settings in ways that don’t take effect until the database is restarted. The changes and the subsequent attack are extremely difficult to discover, much less link to each other.

Challenge 3: Web Applications
Defending proprietary Web applications is an even more difficult challenge because unlike commercial products, such as PeopleSoft, Siebel and Oracle financials, Web apps are built on a complex mixture of open-source software and third-party services. Web pages are typically dynamic, so every user experience varies slightly, making application security testing more complicated.

The upshot is that you just can’t secure Web applications with generic assessment and auditing products. Security tools require a great deal of customization, and the applications require more thorough forms of testing and certifications than commercial apps.

Challenge 4: Extensive Threat Surface
The sheer number of features and options provided by Oracle creates a larger threat surface, with far more targets of opportunity for attackers. Oracle comes standard with many features that a lot of businesses rarely use. And just about every Oracle package has been compromised at one time or another.

Because Oracle serves so many different use cases, there is no such thing as a secure default configuration. The default Oracle configuration is insecure, and users must take the time to remove features they don’t need, and to verify that user, platform, and application security measures are in place before the database goes into production.

Challenge 5: Legacy Installations
Not every Oracle customer uses version 11 of the database. In fact, a majority of customers use older versions. Large percentages of Oracle customers still use versions 8 and 9. The database is functionally stable, so customers are not in a hurry to make the investment in upgrading.

But these versions were designed and built before most people had ever heard of buffer overflow attacks or remote exploits. Many of the known security threats have been addressed with patches -- provided they have been backported -- but these older versions lack some of the advancements in password management, encryption, separation of DBA roles, and auditing.

Similarly, legacy applications -- control systems, homegrown applications, mainframe connectors, SAP R3, and so on -- that use older versions of Oracle don’t have security built in. They have interlocking dependencies between the application and databases, and rely on external security services to detect and protect against threats.

All of these challenges notwithstanding, Oracle offers an increasingly strong set of security features and applications. Companies can go a long way to protecting their Oracle databases by making use of these tools.

To get a detailed discussion of the new tools and techniques available for handling these challenges, download the full report.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.