Protecting databases is hardly an easy task, but it is often the attacks that go after the simplest vulnerabilities that are most successful. Enterprises that stick to the basics will generate the most bang for their database security bucks.

According to Alex Rothacker, manager of AppSec's Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research), his team has found that are 10 common database vulnerabilities that keep plaguing organizations over and over again.

The common thread in this list is that databases rarely ship security-ready, and their configuration is not a fire-and-forget operation for database administrators. Organizations must continually assess packages to determine if they are really necessary and disable those they don't need to reduce attack surfaces. They need to be vigilant about keeping on the lookout for default or weak log-in credentials. They have to put sound privilege and authentication practices into play. And most important, they need to patch regularly.

About half of the vulnerabilities named by Rothacker and his team are directly or indirectly related to lax patch management practices within the database environment. That's a scary thought considering only 38 percent of administrators patch their Oracle databases within the initial three-month patch cycle. And almost a third take a year or more to patch.

Take a look at the following top 10 list:

It might be a daunting task at an organization that has to keep track of hundreds or even thousands of databases. But removing default, blank and weak log-in credentials is an important first step for filling chinks in your database armor. The bad guys are keeping track of default accounts, and they'll use them when they can.

When your database platform fails to sanitize inputs, attackers are able to execute SQL injections similar to the way they do in Web-based attacks, eventually allowing them to elevate privileges and gain access to a wide spectrum of functionality. A lot of vendors have released fixes to prevent these problems, but it won't do much good if your DBMS remains unpatched.

Organizations need to ensure privileges are not given to users who will eventually collect them like janitors collect keys on their key chains. Instead, Rothacker recommends only making users part of groups or roles and administering the rights through those roles, which can be managed collectively more easily than if users were assigned direct rights.

Every database installation comes with add-on packages of all shapes and sizes that are mostly going to go unused by any one organization. Since the name of the game in database security is to reduce attack surfaces, enterprises need to look for packages that don't use and disable or uninstall them. This not only reduces risks of zero-day attacks through these vectors, but it also simplifies patch management. When it'those packages need the patching, your organization won't need to scramble.

Similarly, databases have a panoply of many different configuration choices and considerations available to DBAs to fine-tune performance and enhanced functionalities. Organizations need to be on the lookout for unsafe configurations that could be enabled by default or turned on for convenience of DBAs or application developers.