Database Configuration Standards
The trouble with database assessment and compliance
"Where do I find database security benchmarks?" That was the question posed to me this week when discussing database security assessment. It's an odd question for database administrators (DBAs) because a "benchmark" is a term we associate with performance. In compliance or security parlance, it means configuration standards, and this customer wanted to know, "Where do I find industry standards for database configuration?" The short answer is, "You don't."
A database security benchmark, or viewed more practically, a database configuration template for compliance has not successfully been done by a reputable third party. A good template, from an independent organization just does not exist. But not for lack of trying: The database vendors, standards organizations, and various government entities have tried and failed.
More Security Insights
- Forrester Study: The Total Economic Impact of VMware View
- Securing Executives and Highly Sensitive Documents of Corporations Globally
- Top Big Data Security Tips and Ultimate Protection for Enterprise Data
- Client Windows Migration: Expert Tips for Application Readiness
Standards organizations have provided "best practices" before. They fail because in an effort to provide general concepts that apply to all databases, they provide meaningless security abstractions that give no help to DBAs charged with implementation. Some of my favorite examples are "encrypt sensitive data," "segregate administrative roles," and "ensure users cannot overwrite the stack."
Good ideas, granted, but how you encrypt data will depend on your threat objective. On some databases, it's impossible to provide separation of duties, and -- outside of patching -- it is not the DBAs responsibility to fix database code flaws. In short, there are too many ways to be simultaneously compliant yet totally insecure.
Many organizations produce little more than a list of database security patches and related CERT Advisories, but patching is just one dimension of configuration management. The database vendors typically provide best practices, but they lack specific links to compliance and security objectives, workarounds, and other needed information. DBAs view these lists with disdain because the recommended settings break database deployments, and also because they lack any specific information about what security threats individual settings help address.
Another problem has been the compliance regulations: Ones like PCI-DSS and Sarbanes-Oxley, which are intended to protect data and ensure data accuracy, respectively, don't mention database benchmarks at all. Most firms I speak with use database assessment tools to meet part of their PCI-DSS compliance reporting, and every large enterprise I've spoken with that has database monitoring bought it to provide SOX control reports. In fact, those tools have become critical to the compliance process. But SOX says nothing about database monitoring being an acceptable control, and PCI only describes the need to ensure all database access is authenticated. There is no official mapping of database settings to these compliance standards, nor any of the other half-dozen compliance requirements people use database assessment to address.
For some of you with the time, you may want to sit down and see how the DBAs would address compliance requirements. That's helpful to understand what options are at your disposal to address audit requirements. The problem is the external auditor may not approve of your choices or is afraid to without a recognized independent third party sanctioning the settings. And that's the root of the issue as to why customers want external validation of database settings.
The best sources for database security settings I've come across are user groups and commercial assessment vendors. Database user groups are usually comprised of some very talented database administrators, from different industry verticals, and most of them have some compliance concerns to address. Because user groups usually focus regionally, it's hard to mine this source for information, and most tend not to publish a compendia of database configurations.
If you attend enough meetings, you'll meet users who have to address the same compliance challenges you do, and they are usually willing to share what they do for compliance and security. But it's the database assessment vendors that have taken the time to map compliance requirements to specific database features and settings, and have worked with customers to know what works and what doesn't. Thus far, they are the best source for database compliance and security benchmarks, and usually package policies according to different compliance regulations, broken down by database type. You pay for it, but it's that research and mapping of settings to compliance controls that provides value.
Adrian Lane is an analyst/CTO with Securosis LLC, an independent security analyst firm. Special to Dark Reading.