Analytics
2/5/2010
10:19 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Database Account-Provisioning Errors A Major Cause Of Breaches

Database accounts are often managed manually -- if at all

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. Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Threat Intel Today
Threat Intel Today
The 397 respondents to our new survey buy into using intel to stay ahead of attackers: 85% say threat intelligence plays some role in their IT security strategies, and many of them subscribe to two or more third-party feeds; 10% leverage five or more.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0485
Published: 2014-09-02
S3QL 1.18.1 and earlier uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object in (1) common.py or (2) local.py in backends/.

CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5136
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in Innovative Interfaces Sierra Library Services Platform 1.2_3 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.