10 Most Common Security Vulnerabilities In Enterprise Databases

[The following is excerpted from "10 Most Common Security Vulnerabilities in Enterprise Databases," a new report published this week on Dark Reading's Database Security Tech Center.]

Databases contain the largest -- and most sensitive -- store of enterprise data, making them a prime target for attackers. But it's often the enterprise's internal staff -- database developers, administrators, and even users -- who create the vulnerabilities that attackers exploit to compromise that data.

In this report, we look at how and why database vulnerabilities are created -- whether it's during the creation of a new database, during customization of an off-the-shelf application, or in the process of patching or updating the data. We examine the most common causes of database security vulnerabilities and recommend ways to prevent them.

Here are some of most common areas of database security weaknesses, based on the issues we've seen in customer environments we've evaluated during the last decade.

1. Deployment Fail
The most common cause of database vulnerabilities is the lack of care with which they are deployed. Sure, databases are often functionally tested to make sure they provide core functions for calling applications. In fact, the majority of predeployment tests are designed to verify that a database is doing what it should do; very few are checking to ensure that it isn't doing something it should not do.

Every database should pass a long checklist of tests prior to deployment. That list covers just about every facet of the database, but most map directly to common exploit vectors leveraged by attackers. Every relational database platform (including Oracle, DB2, SQL Server, Sybase, Postgres, and MySQL) is insecure after a fresh installation,and it will remain that way until you fix it.

2. Broken Databases
The Slammer worm put the issue of vulnerabilities at the forefront of DBAs' consciousness in 2003, when it took down thousands of databases in a matter of minutes. This worm exploited a buffer-overflow vulnerability and allowed for an attacker to crash, or gain control over, any database it discovered.

Slammer was the first of many such vulnerabilities, and it was the catalyst that pushed vendors to start offering regular security patches. Vulnerabilities like command injection and buffer overflows don't make headlines like they used to; fewer issues are found, and vendors are fairly responsive with patches when they are.

But this doesn't mean that new exploits have gone away. Quite the contrary. New exploits are found regularly, and we see critical security patches released several times a year. However, unbelievably, many companies don't install security patches, leaving their database systems vulnerable to attack and often subject to complete compromise. The reasons firms don't patch vary, but what we usually hear is that they lack time and resources to test patches prior to deployment, and thereby verify function and stability.

It's true that it takes time to test patches, but most patches are released on a regular schedule -- often every three months. A partial regression test to verify functions simply doesn't take that long. What's more, test tools are designed to automate testing processes like this for you, thus ensuring that you don't destabilize your applications.

Our recommendation here is simple and non-negotiable if you want to keep your database systems secure: Patch your databases.

3. Leaked Data
Some DBAs forget about network security. The common mindset is that the databases are in the "back office," a network secured from the Internet, so data communications to and from databases don't have to be encrypted. What these IT pros are forgetting -- or ignoring -- is the networking interface of their database. But make no mistake: It's trivial for an attacker to capture network traffic and parse interesting data from multiple user connections to the database -- in essence, seeing all data moving in and out.

In all cases, you should enable Transport Layer Security. Secure Sockets Layer has minimal impact on network performance and makes it very difficult for someone to collect data from the wire. Most relational platforms provide SSL- or TLS-encrypted communications as part of the basic database package, enabled through a simple configuration setting change.

For platforms that don't include encrypted network communications features, you will have to add a third-party option. Many good TLS options are available from the open source community.

To read about the other seven most common vulnerabilities in enterprise databases -- and what you can do about them -- download the free report.

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