Apply These 'Best Practices' to Protect Enterprise Data

 

From employees, to partners, to consultants, to customers, everyone needs increasingly more direct access to databases. A database's centrality to a company's operation is reason enough to consider auditing it. However, regulatory compliance and security are two other forces that drive companies to consider database auditing.

What is Database Auditing, Anyway?

Even when it's clear your company requires some sort of database audit, what actions to take may not be so obvious. You must consider database activity, usage, and security for auditing to be credible.

Activity and security auditing are the two primary functions of a database audit. Both types of auditing involve controls and measures that map to compliance requirements, such as:Sarbanes-Oxley (SOX); Graham Leach Bliley (GLBA); Health Insurance Portability and Accountability Act (HIPAA); security breach notification laws (such as California Senate Bill 1386); as well as security best practices defined by ISO 27001 (formerly 17799); the Federal Information Systems Management Act (FISMA); or the consolidated Payment Card Industry Data Security Standard (PCI-DSS). As a result, by defining activity and security auditing functions and mapping them to the appropriate compliance frameworks, companies can extend auditing to databases in a way that supports multiple requirements.

Auditing is an important component of a defense-in-depth approach to database security. More than merely tracking and monitoring user activity, database auditing encompasses all aspects of database information controls and counter measures, including monitoring authorized and un-authorized access to sensitive data; access control policies; configuration standards; and vulnerability management practices on a regular basis.

Database Audit Defensibility and Security

Current industry realities are causing a head-on collision between security best-practice and regulatory compliance requirements. On the one hand, compliance requirements are simply impossible to ignore. On the other hand, pursuing compliance at the expense of security best practice (and effectively documenting yourself out of a good security posture) ultimately undermines both objectives.

Compliance + Security

The vulnerability management methodology most companies use to manage network security can be applied to a company’s data to satisfy the requirements of both security and compliance efforts. Key steps in this approach include:

• Inventory and assess present systems
• Prioritize efforts based on business value and security exposure
• Harden systems against known threats
• Track suspicious activity with real-time monitoring

The security benefits of this approach are straightforward:

1. It decreases the likelihood of a breach because there are fewer ways to compromise databases.

2. It reduces the impact of a breach by providing prompt, intelligent notice of malicious or suspicious activity.

Create Defensible Audits

For a database audit to be useful, it must be demonstrable, defensible, and repeatable. In brief, the audit should be:

1. Impartial -- Conducted by staff or a trusted third-party separate from the DBAs and others who manage the databases under audit
2. Independent -- Based on third-party tools which are distinct from native database auditing functions, thus bolstering audit integrity
3. Tamper-Proof -- Structured such that the results can’t be changed by DBAs or rogue insiders
4. Recurring -- Conducted on a recurring and regular basis, not just as a one-time or ad hoc process

Determining Audit Credibility

As a practical matter, establishing credibility for compliance-driven database audits depends on the regulatory initiative. Some regulatory requirements, like PCI-DSS for retailers and the U.S. Department of Defense (DoD) Information Technology Security Certification and Accreditation Process (DITSCAP) for government agencies, specifically enumerate database applications in their language. For these requirements, whoever signs off on the compliance effort will determine audit credibility. Other regulations aren't nearly as explicit about what systems are covered and leave audit requirements open to interpretation. In these cases, a database audit may, or may not, be strictly required and the nature of the audit will be subject to interpretation.

In either case, however, a well-documented practice of database audits makes a remarkable impression by establishing a practice of due diligence which grounds compliance efforts in the systems where sensitive data spends the bulk of existence.