While hackers pose a major threat to the inner sanctum of database information stores through wily cracks and attacks, some of the biggest threats to databases come not through SQL injections, but instead through poor account management. That's right: Some of the highest-impact data breaches today occur as a result of account-provisioning errors.

Take the case of Scott Burgess, 45, and Walter Puckett, 39, a pair of database raiders who were indicted this winter for stealing information from their former employer, Stens Corp. Burgess and Puckett carried out their thievery for up to two years after they left Stens simply by using their old account credentials, which were left unchanged following their departures. Even after accounts were changed, the duo were subsequently able to use different login credentials to continue pilfering information.

This scenario is hardly an anomaly, either. Most security experts will tell you that companies are burned every day by poor database account management practices.

"Things aren't always as tight as one would assume" with database account management practices, says Jerry Skurla, executive vice president of marketing for NitroSecurity, who says it isn't even always the former employee who abuses orphaned accounts. Insiders and hackers do it, too: "There's lots of cases where people get in because accounts of people who have long left the company had gotten discovered and been used for years."

The problem in a lot of cases is that database provisioning and validation of proper provisioning is such a cross-functional duty that many organizations see the whole process fall through the cracks. And whereas many organizations have some form of identity and access management (IAM) tool, or leverage LDAP or Active Directory to manage provisioning for the bulk of their IT systems, database accounts very often get left out of the IAM infrastructure due to the complexity of integration and the potential for performance hits to mission-critical data stores.

If accounts are tracked at all, then organizations typically do so manually.

"They're not even aware of who has access into these databases and how many accounts are there," says Prat Moghe, general manager of data compliance for Netezza. "Management in the database space is highly manual. Many people actually keep Excel spreadsheets manually of how many accounts are in the database and who has ownership, so there is no automation around it."

Understandably, such a process leads to oversights, and in many instances a former employee who may have had his physical access and network access revoked will still retain access to the database for weeks, months, and even years after he has left.

Adding further complication to the matter are the other additional accounts that are even more poorly managed than the average user account: namely, pooled application accounts.

"All databases ultimately feed an application of some sort," says Eric Knapp, director of product marketing for NitroSecurity. "When you're monitoring database activity, you'll see that there's massive amounts of access to and from the database from some Web application, but sometimes the user identity is lost completely at that point."

To get a handle on database account provisioning, the first step is for organizations to admit they have a problem and start asking themselves hard questions.

"They have to ask themselves the question, 'Where do we have accounts? Tell me all of the places where we have accounts, and tell me all the things they use these accounts for?'" says Phil Lieberman of Lieberman Software, which specializes in privileged user management. "And the second question is, 'So we're using these accounts -- when were those passwords changed? And if we're using those accounts, what is the ACL [access control list] system we're using, and when was the last time we checked the ACL system?' And finally, 'We have audit logs being generated by these databases -- are we analyzing these audit logs looking for patterns that indicate abuse?'"

Lieberman's last point is perhaps the most relevant to those organizations that might have manual processes in place, but are drowning in spreadsheet data and outdated account information. Organizations can leverage native database logging, database account monitoring, as well as log management and security information and event management (SIEM) tools to keep the process honest and validate that accounts are properly provisioned and aren't being abused.

Organizations can start with native logging tools, though they may find the performance hit too detrimental.

"I think a lot of times it starts with just native database logging and manual log reviews in a lot of cases, though all but the smallest companies quickly outgrow that," Knapp says, "But there has to be some sort of logging mechanism, whether it's native or external that really shows what accounts are being used and what they're accessing."

But simply tracking database access might not be enough to ensure proper provisioning. When an organization may be using accounts to provide database access to multiple users via another outside application, they need to find a way to provide visibility into who is actually behind each attempt to access information.

"You need to take another step and go beyond just native logging or outside database activity logging, and you need something like a SIEM and application monitoring that can also look at application activity and then correlate those two together," says Knapp, who believes this is the most cost-effective situation for businesses that can ill-afford to recode custom applications in order to avoid pooled database accounts.

In addition to providing correlation between application activity and database access instances, integrating monitoring solutions can also help fill in the gaps and reconcile with, say, Active Directory, even if the database accounts are not actually included in the IAM schema.

"From the monitoring side, this is one of the reasons why SIEM, log management, and database monitoring solutions work well together," he says. "We can say, 'We're seeing user John Doe accessing a database here, but when we look at the user privileges assigned to that person through Active Directory we see he's the guy that comes in and waters the plants in the evening, and he shouldn't be accessing the database."

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.