Jno Security Dbs

Compliance

hite Paper
Database Security for PCI Compliance
The Payment Card Industry Data Security Standard (PCI DSS) sets forth security
requirements for organizations that store, process, and/or transmit credit card
transactions. To meet these data security requirements, organizations need to
implement complex processes that often turn into a costly burden.
Designed for auditors,security professionals, and database administrators, this
paper analyzes PCI compliance challenges and outlines applicable solutions. This
paper focuses on the key PCI DSS requirements that impact database security:

» PCI Requirement 10: Track and monitor all access to network resources
and cardholder data
» PCI Requirement 8.5.5: Remove and/or disable inactive user accounts
at least every 90days
» PCI Requirement 7: Limit access to cardholder data by business
need-to-know
» PCI Requirement 6.1: Ensure all system components and software are
protected from known vulnerabilities by installing the latest vendor-supplied
security patches
» Data in Scope: Identify, and track, all locations of cardholder data

“

Organizations that process or store cardholder data are
to a databreach and maintain customer trust in their
ability to securely transact business.

S ecurity
Standards Council

”

obligated to secure it to minimize their financial exposure

DatabaseFileWeb

Database Security for PCI Compliance

PCI Requirement 10:
Track and Monitor all Access to Network Resources and Cardholder Data
PCI Requirement 10 mandates that organizations establish anaudit log of all access to network resources and
cardholder data. It includes 25 sub-requirements that delineate not only what needs to be logged, but also
how those logs are to be managed.
PCI Section 10.2 mandates implementation of automated audit trails, and Section 10.3 lists the details that must
be included in audit trail entries. Since most IT environments are heterogeneous and containvarious database
platforms, implementing audit controls across corporate databases is not a trivial task. Some organizations
consider using a “free” database utility, such as native auditing. However, this poses several challenges for
database administrators (DBAs) and consultants looking to use built-in native database logging.

Challenge: Performance and Capacity Impact
Using native auditingtools is not simply a matter of “turning on” logging. Organizations should consider the
costs associated with the enablement of native auditing, such as the utilization of CPU resources and related
storage requirements. The costs associated with these “free” mechanisms can rise quickly.
Enablement of native auditing can result in significant performance degradation; consuming 30%-50% of CPUresources. Additionally, native audit storage requirements can quickly consume valuable disk space. Native
auditing tools were not designed to operate around-the-clock, but rather for a short time-frame to assist in
debugging efforts.

Consider: Database Activity Monitoring (DAM) for Achieving Transparent Auditing
By monitoring database activity on the network, and/or using specializedlow-impact agents residing on
the host, SecureSphere Database Security solutions can provide comprehensive, high volume auditing with
minimal risk to performance. Keeping the audit log on SecureSphere appliances eliminates the need to add
storage capacity to the database server.

Challenge: Missing Audit Capabilities

Imperva White Paper

Each database platform offers different native auditcapabilities. Some platforms are more mature and provide
sufficient data, while other platforms offer only basic audit capabilities that do not fully address the required
details specified in PCI Section 10.3.

Consider: DAM for Achieving Comprehensive Database Audit Capabilities Across Enterprise Platforms
SecureSphere Database Security solutions provide comprehensive audit capabilities and a...