Every new data breach that hits the headlines snowballs the embarrassment for the IT security community, especially because this constant follies show revolves around recurring themes.

Data breaches tend to happen because organizations are making the same mistakes over and over again. These poor practices usually start at the database. Here are some of the ways organizations make it easy for hackers and insiders to gain a one-way pass right into the database's crown jewels.

1. Leaving Database Unpatched
DBAs fear the functions that vendors will break with their latest security updates, but allowing that fear to put the patch cycle into indefinite delay gives even the most unskilled hackers a huge opportunity to steal truckloads of data.

"Some huge holes are getting fixed with each patch, and the exploit code is almost always posted on the Internet for any script kiddie to cut and paste into an attack," says Josh Shaul, chief technology officer for Application Security Inc.

2. Not Seeking Out Rogue Databases
You can't secure the databases you don't know about, says Patrick Bedwell, vice president product marketing for Fortinet. And yet he frequently runs across customers that don't maintain inventories of their databases or scan for rogue databases. It's a problem because those databases are out there.

"It is a common practice to install small footprint databases and populate them with production data for development and testing," Bedwell says.

Hackers love it when organizations don't keep track of rogue databases because these are the ones that are most likely to be unpatched, left wide open to attack since the security team hasn't had a pass at them.

3. Granting Excessive Privileges
When time is crunched and resources spread thin, it is very tempting to just blanket the user base with a ton of access privileges and move on, says Noa Bar Yosef, senior security strategist at Imperva. But all it takes is one user to abuse those privileges to cause a huge problem, she warns.

"Consider the case at Diablo Valley Community College. For three years they had the DBAs there modifying student grades," she says. "When the breach came to light, they found that out of the 100 users who were granted DBA privileges, only 11 really required them."

The problem with granting excessive privileges is that users can not only do things they aren't supposed to, but they are probably not going to be policed because the suspicious activity isn't expected there, says Alex Rothacker, manager of Application Security's research arm, Team SHATTER.

"As a side effect of having excessive privileges, users can perform functions on the database or OS that they aren't authorized or qualified to do so," he says. "For example, a user with excessive privileges in the accounts payable department can create a false company, send payments to the false company, and then delete any record of the company in order to cover their tracks."

NEXT PAGE: 'Database Security Not My Problem' 4. Allowing Default Username/Passwords
Leaving username and password combos at their default settings is like rolling out the welcome mat to data thieves. But many organizations do that just for expediency's sake because many applications that tap into database information are designed to sync in with default accounts, and changing passwords might break something.

"The worst offender we see is the DBSNMP account in Oracle," Shaul says. "It's such a problem, we joke that to the DBA community, DBSNMP stands for DataBase Security Not My Problem."

5. Failing To Self-Examine
Sticking your head in the sand with regard to what users are doing, how the databases are being used, and what kinds of attacks the database is vulnerable to only emboldens thieves to do their dirty business without fear of getting caught.

And yet most security experts agree that the majority of organizations fail to monitor users or audit database activity because they're afraid of taking a performance hit.

"It's a constant struggle -- security professionals wanting to turn on an audit, and DBAs, on the other hand, crying for better performance. When it comes to serving customers, performance usually wins or the teams decide to compromise," Imperva's Bar Yosef says. "But at the end of the day, or rather -- breach -- what is crucial for discovery, recovery, and accountability is missing."

According to Rajesh Goel, chief technology officer of security consultancy Brainlink International, many organizations will also deny security assessors or penetration testers the authority to include the database in their attacks, even though that's the first place a malicious attacker will target.

"We know of a number of firms that told us to not attack their databases, or only perform limited attacks, because if the database went down, some folks might get fired," Goel says.

6. Allowing Arbitrary Internet Connections And Input
When databases are connected to the Internet, free to be accessed by any arbitrary client without any restrictions, bad things happen.

"This means that SQL injection attacks have a devastating impact, exposing arbitrary data," says Jose Nazario, senior manager of security research for Arbor Networks. "Splitting rights and roles goes a long way. Read-only roles should be used to serve Web content."

Similarly, user input needs to be scrubbed to prevent injection and denial-of-service attacks, and untrusted users should never be able to query tables directly or database object names like tables, functions, or views, Nazario says.

7. Failing To Encrypt
According to Alan Wlasuk, CEO of 403 Web Security, the single dumbest database security mistake organizations make is leaving their databases unencrypted.

"It is a given that hackers will eventually get into your database. An encrypted database gets the hackers very little, [while] a clear text database could be a deadly embarrassment to your company," he says. "Encryption is free, fast, and easy to use."

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