"Databases in general don't give you the ability to take away DBAs' data access away from them," Shaul says. "And that's what auditors are coming in and flagging folks for, saying, 'First and foremost, you've got this easy-to-find segregation of duties violation. Your DBA can touch your data, modify your data, and take it out of the building.'"
This exposure is one reason why database activity monitoring is so critical to enterprises seeking to satisfy regulatory requirements. Unfortunately, all too many organizations fail to log, track, or monitor database activity because they worry that such monitoring may affect database performance.
"Typically, database logging is not turned on because it can generate a lot of log activity," Laliberte says. "And not having those elements turned on can make it difficult to monitor for inappropriate access."
DBAs and other database stakeholders should know that today's third-party monitoring tools aren't nearly as burdensome to database performance as in years past, experts say. Organizations can also balance their monitoring activity by prioritizing it based on risk.
"Typically, what I advise my clients is to look at it from a risk-based approach," Laliberte says. "You really want to structure the audit and logging settings appropriate to the risk factors that would be affecting the resources that you're trying to protect."
Among other metrics, enterprises should track failed login attempts, changes in privileged user access, and changes to highly sensitive data, experts say.
5. Reporting On Compensating Controls In those instances where organizations have appropriate compensating controls in place, auditors want proof that these controls actually exist, Laliberte says.
"In some instances they may have mitigating controls or compensating controls in place, but they may not have them very well-documented," he says.
For example, you may tell an auditor that you're conducting a biweekly review to ensure access controls are appropriate. But if you can't produce evidence that the review is taking place according to schedule, the auditor will likely flag you, Laliberte says.
"And by the way, usually when you can't produce evidence that a control exists, that tends to break down over time and somebody forgets to do it each week," Laliberte says. "Unless it's formally tracked and reported upon, the control will typically fail at some point."
While automation of these tasks certainly can increase the potential success of controls over time, it isn't always necessary. For example, Laliberte notes that if the company was conducting biweekly reviews, all they may need to do is implement a ticketing system that reminds the responsible party to do the manual review every two weeks. That person then can enter results of the review and close out the ticket once the job is complete. This creates a paper trail that's available when the auditors come knocking.
6. Following Defense-In-Depth Strategies Finally, it is important to remember to keep a little perspective on the matter of database security and compliance.
"This is really just a piece of what has to be a pretty large security program that's going to allow you to meet these regulations," says Mike Rothman, senior vice president of strategy for eIQnetworks, a security information and event management company. "There's no silver bullet."
Most security experts warn organizations they need to maintain layered "defense in depth" strategies to avoid runs around current database defenses, leaving an organization both noncompliant and insecure.
Take out-of-band access to databases, for instance. Phil Lieberman, president of Lieberman Software, a password management company, believes this is one of the biggest database risks of all. "They're accessing the database using secondary methods," he says.
For example, Lieberman notes, many organizations leave themselves at risk when they fail to encrypt database backup tapes. The data may be secure on the server, but if someone with ill intent gets hold of the unencrypted tape, then it will be compromised all the same. Similarly, out-of-band access via application connection accounts must also be addressed, he says.
"People getting into the database using development tools rather than getting into it via the application itself is a big risk," Lieberman says. "It depends on how strong the connection paths are. A lot of companies will implement the application and the database in a DMZ, in which case there is no direct access to the database; you can only get to the application."
Above and beyond these access concerns, Rothman believes companies need to be able to integrate database security information with the other security data to satisfy regulations and pinpoint attacks in real time.
"There is a lot of stuff that you have to do programmatically -- and then you have to have the technology in place and the infrastructure and processes working to be able to analyze all of this stuff that you're looking at in order to really be compliant," he says. "Your goal should be to be doing all of that stuff to secure your environment -- from there, the compliance [issue] works itself out."
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.