Are Your Databases Audit-Ready?

As the repositories of some of the most sensitive and regulated data in the enterprise, databases stand as perennial targets in hacker crosshairs. But they also draw a lot of unwanted attention from another outside force: regulatory auditors. These assets are some of the most likely to draw a flag from auditors due to misconfigured settings, insecure schemas and undisciplined practices, experts say. As organizations seek to pass compliance checks, consultants and auditors suggest that concentrated work at the database level can reap a lot of ROI for compliance spend.

"Organizations need to implement security controls as close to this data as possible," says Phil Lerner, vice president of technology for Stonesoft. "This includes asset valuation, classification and single loss expectancy (SLE) and annual loss expectancy (ALE) exercises as part of a larger governance effort. This also means protecting the data at the database layer."

Policies, Standards And Procedures
Organizations seeking to increase database audit-worthiness should probably direct their first efforts on the areas where the auditors would start their digging. That's typically going to be focused on standards, policies and procedures, says Rick Link, managing director of the Southwest region for Coalfire, an IT security and audit firm.

[Wish You Could Tell Your CEO 'I told you so'? You're not alone. See Airing Out Security's Dirty Laundry.]

"I start at the polices, procedures and standards bases because those documents are going to be a reference tool for the experienced database administrators that have been supporting the technology and organization for a while, but it's also a training tool for new database administrators," he says.

Policies are the overarching mandates coming from CIOs and CISOs and feed into what standards and procedures look like, Link says. Standards offer guidelines on things like configuration settings, parameter settings and backup processes around database technologies. Standards then feed into the procedures, which are the very granular measures taken by people supporting the technology governing how they do day-to-day jobs like recycling a database, making a backup or whatever else it takes for DBAs to administer securely. Policies don't change often, but standards and procedures will need to be amended frequently, he says.

"If I don't have policies, procedures and standards right off the bat, i'm concerned that they're not following industry best practices to protect their data that's found inside the databases," Link says.

Configuration Management
The complexity of today's database environment leaves ample opportunity for configuration and vulnerability trouble that'll torpedo an audit before it's hardly begun.

"When administrators focus on availability, they often overlook configuration issues that can introduce security vulnerabilities and expose confidential data," Lerner says. "When it comes to security audits, many of the vulnerabilities identified by auditors exist because of hold-over default configurations from earlier versions of the database that did not get changed during the upgrade process."

Organizations should be seeking to configurations within the database by avoiding default settings, uninstalling components they don't use and segmenting data according to risk. Similarly, they should be putting effort into patching known vulnerabilities as quickly as possible and testing regularly for vulnerabilities.

"Effective internal and external vulnerability testing and penetration testing should also be performed on the critical DB environments at least quarterly by strong and well referenced security firms," Lerner says.

It isn't just the configuration of the databases themselves that enterprises should be concerned with, he says, emphasizing that auditors will look into how applications interact with database resources.

"Just as the database needs to consider security, the application must also take security into account," Lerner says.

Encryption
When organizations fail to encrypt data at the database level or institute insecure encryption practices, it just makes it all the easier for bad guys to exfiltrate data. Auditors will also look askance at the absence or improper use of encryption.

" A company should identify what data is contained within their databases and use an encryption algorithm and key length that is sufficient for the data they are protecting," says Joe DeSantis, manager of incident response for SecureState.

Auditors will also look closely at the kind of encryption employed and whether or not it is easily defeated.

"Many fail to encrypt sensitive tables in a database and instead simply rely on whole disk encryption," says Ken Pickering, development manager of security intelligence for Core Security. "While whole disk encryption can help prevent leaks in certain IT cases, a SQL injection can easily expose data if the tables are unencrypted."

Access Control
Whether it is in the database or on the network, access control tends to prevail as a pet issue on most auditors' checklists. Regulators want organizations to route users into the database in a way that maximizes control and visibility around when and how individual users access or manipulate data. Unfortunately, many organizations don't have that level of control due to overly permissive privileges.

Particularly a problem is the practice of granting excessive privileges to application accounts for the sake of expediency, Pickering says.

"It's easiest to give an application a wide range of rights over a database server, but this may give the application access to data it isn't supposed to see," he says. "If you think of an application like a user--because, to the database, it is--then the security of the data that application can access is only as strong as the security of the application itself."

Whether on shared back-end accounts like application accounts or administrative accounts, limiting super-user privileges on database accounts should be the name of the game, Pickering says.

"Granting all privileges to a user should be limited, the use of public privileges should be limited, separation of duties/roles and OWASP plus OSSTMM/OISSG security testing should be employed when possible," Lerner recommends.

Part and parcel with access control is the effective administration of authentication technology. Even organizations with strong identity management practices elsewhere in IT tend to fall down at the database layer where ID and passwords are often administered separately from IAM accounts.

"Often times, there is a lack of password complexity and password expiration that would allow a user to use a very weak password for an endless amount of time," says DeSantis. "Coupled with weak access controls within the database, it would be very easy for someone to guess a valid user's password and have unrestricted access to all objects accessible within the database."

Monitoring
Auditors love documentation, but without internal audits afforded by solid database monitoring, there's nothing to show them when they come knocking. DeSantis says that many organizations may only track dates and times of when access was granted to the database but that's not a deep enough dive.

" If more thorough auditing is not in place, such as what data within the database was modified, accessed or created, it is much more difficult to determine what the user is doing once inside the database, or be able to identify possible abuse," he says.

Whether or it is through a database activity monitoring solution or some other means, auditors will also be looking at how well monitoring data dovetails into other compliance and reporting functions across the IT infrastructure, Lerner says.

"Monitoring for compliance and reporting purposes should also be integrated into a strong enterprise SIEM solution so effective telemetry can be collected and analyzed by the enterprise security team," he says.

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.