As enterprises continue to struggle with large-scale data breaches and quiet exfiltration of sensitive information from databases, database security experts warn of the big role misconfigured databases play in these compromises.

"Almost all the data that gets stolen every year comes out of the database one way or another -- particularly if you are going to steal a lot of data at once," says Josh Shaul, CTO of Application Security Inc. "The reason why people are able to steal a lot of data out of databases is because nobody really bothers to secure them; breaking into databases is so ridiculously easy. There are so few organizations that actually take the security of their databases seriously."

Database configurations are among the top elements either ignored or mishandled, he says. They range from insecure default settings left unaltered to changes made by administrators that leave the database open to attack.

In the first category, default accounts still remain a big problem in enterprise database settings.

"We see them all over the place," Shaul says. "The databases all ship with default accounts, and when you install applications on your database, they install default accounts, too. All those default accounts have default passwords, and all those default passwords are easy to find on the Internet. So if you leave them in place, it's kind of like you're leaving a window open into the database."

[Do you see the perimeter half empty or half full? See Is The Perimeter Really Dead?]

Similarly, most databases come out of the box with a smorgasbord of applications installed, many of which will be unnecessary to the organization. But each enterprise has its own needs, so the list of extraneous apps varies by use case.

"We all talk about surface area in security. You want to cut down the surface area and give the hacker less area to go after. Well, if you're in the database business, your goal is to put as much functionality into the database out of the box as possible -- you want to make it easy for people to start up their apps, get them going, give them features they want," Shaul says. "There's so much stuff that just gets installed by default, including lots of functionality to access the operating system through the database."

Even when not turned on by default, many potentially dangerous database features are ticking time bombs for misconfigurations should they be flipped on. For example, Shaul calls a certain TRUST_ALLCLNTS parameter in DB2 a security knife-switch just waiting to stick enterprises where it hurts.

"If you turn TRUST_ALLCLNTS to 'yes,' that turns off all authentication authorization of the database. I see people turn TRUST_ALLCLNTS on," he says. "When you put features in your software -- even if they're stupid -- people use the features in the software."

According to Roxana Bradescu, senior director of security product management for Oracle, many of the database misconfiguration pain felt by organizations today stem from the fact that they're still managing database configurations manually, typically tracking them with spreadsheets.

"That's how most organizations do it. They have to manually compare those spreadsheets, so someone is literally comparing one spreadsheet versus another," she says. "It's very time-consuming, error-prone, and very reactive."

Without automation, simply tracking configurations is hard enough. But then there is the issue of also keeping tabs on configuration dependencies. Understanding these dependencies are important for operational resiliency and forensics analysis.

"A lot of times having these configuration dependencies also allows you very valuable analysis in forensics after a potential breach or potential exfiltration to see exactly what other things may have been compromised," Bradescu says.

But before even automating the tracking of configurations and their dependencies, organizations have to have some kind of baseline to compare current configurations against. Without standards, it is impossible to tell whether a configuration is right or wrong, secure or insecure.

At the moment, the industry has two big standards most commonly used to develop database configuration baselines. One, the Defense Information Systems Agency Database Security Technical Implementation Guide (DISA STIG), is "pretty heavyweight," according to Shaul, and primarily used in the government defense space. The other is a standard from the Center of Internet Security, one that's "pretty good, but not rock-solid," he adds. According to Shaul, probably only 10 percent to 15 percent of organizations have adopted either standard, with perhaps another 10 percent of organizations with their own internal standards.

"But that leaves you with 70 to 80 percent of organizations out there that don't have a target," he says. "And it's so hard to hit a target when you don't have a target. How do you ask people to go and set up a secure database when there is no definition for what that looks like?"

Bradescu is of a similar mind, explaining that the only way to prevent database configurations from drifting into insecurity over time is by creating a gold image for databases to compare configurations against.

"You probably are going to have multiple images for different types of databases," she says. "They may be application-specific, clusters versus single instance, [and so on], but you want to be able to compare that configuration against the baseline, making sure throughout the life cycle that the configuration stays consistent."

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.