Six Steps Toward Better Database Security Compliance

In a sea of compliance initiatives, database security is often overlooked. But experts say no matter what the regulations say, securing the database is a critical part of any compliance effort.

"What I've found in my experience is that the database is often the forgotten layer, even though it's the layer where the crown jewels -- the data -- usually resides," says Scott Laliberte, global leader of information security assessment services for Protiviti, which conducts third-party audit assessments for enterprises.

But improving the security of the database as part of a larger compliance initiative is doable, experts say. The trick is to follow six steps toward database compliance. Let's take a look.

1. Database Discovery And Risk Assessment Before organizations can start their database compliance efforts, they must first find the databases -- and where the regulated data resides in them.

"That's a big challenge for a lot of folks. They know where their mainframes are, and they know where a lot of their systems are but...they don't really know which database systems they have on their network," says Josh Shaul, vice president of product management for Application Security, a database security company. "And even the systems they know about, they're not entirely sure which ones contain the sensitive data."

2. Vulnerability And Configuration Management Once an inventory has been developed, organizations need to look at the databases themselves. Before moving forward, they must ensure each database is securely configured and hardened to attack.

"Basic configuration and vulnerability assessment of databases is a key starting point for enterprises," Shaul says.

3. Access Management and Segregation of Duties Figuring out who has access to regulated data, what kind of access they are given, and whether that access is appropriate for their jobs is at the heart of complying with regulatory mandates.

The act of managing database accounts and entitlements can range from the simple to the incredibly complex. Laliberte recommends enterprises start with the simpler tasks, which are still ignored in many organizations.

"Sometimes it's as simple as account management, password controls, and removing default accounts," Laliberte says. "Those types of things we typically see not as well controlled at the database level as they are at the operating system or application level."

More complicated is the issue of segregation of duties and entitling permissions based on roles. "It's segregation of duties violations that get organizations every single time [when they're audited]," Shaul says. "Segregation of duties in the end is a cornerstone of the regulations that folks are trying to deal with."

The task of segregating users based on roles means understanding each user's duties, experts say. And it can't be a one-time task. Organizations need to be vigilant to constantly review roles and entitlements to prevent toxic combinations of privileges.

Take, for example, a payments clerk who gets a promotion to run the accounts payable department. In the new position, that person "owns" the AP system and has the ability to modify and delete checks that have been written. If his ability to write new checks hasn't been revoked, that person now has the ability to commit fraud. 4. Monitoring Risky Behaviors And Users Unfortunately there is a built-in segregation of duties violation in every database -- and it's one you can't get rid of, Shaul says. It's called a database administrator.

"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.