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:
- Impartial -- Conducted by staff or a trusted third-party separate from the DBAs and others who manage the databases under audit
- Independent -- Based on third-party tools which are distinct from native database auditing functions, thus bolstering audit integrity
- Tamper-Proof -- Structured such that the results can’t be changed by DBAs or rogue insiders
- 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.
This article is an excerpt from "Apply Best Practices to Protect Data" by Aaron Newman, Application Security Inc. co-founder & CTO, originally published in the 2006 Issue 4 of Compliance Solutions Advisor. For more information on corporate compliance strategies and solutions, go to the Compliance Solutions Advisor home page.