White Paper

Compliance

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 90 days 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

Security Standards Council

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

obligated to secure it to minimize their financial exposure

Database Security for PCI Compliance

DatabaseFileWeb

PCI Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data
PCI Requirement 10 mandates that organizations establish an audit 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 contain various 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 auditing tools 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 CPU resources. 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 specialized low-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

Each database platform offers different native audit capabilities. 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 unified audit trail that enables consistent reporting and analysis. SecureSphere Database Security solutions extend advanced audit capabilities to leading database platforms, such as Oracle, Microsoft SQL, DB2, and Sybase as well as other mission critical systems, such as DB2 for z/OS, DB2/400, Terradata, and Netezaa.

Complete audit trail to monitor and report on access to credit card data.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Challenge: High Operational Costs Due to Lack of Centralization

Since there is no centralized management, native auditing is enabled on each database instance by itself. Audit policies need to be defined manually on each server. This process is resource intensive, requires expertise, and is also prone to error.

Consider: DAM for Lowering Operational Costs by Leveraging Centralized Database Audit and Security Management
SecureSphere Database Security solutions enable centralized management of audit trails and alerts from a centralized interface. SecureSphere also enables administrators to apply the same audit policies on different databases, regardless of the specific platform.

Challenge: Monitoring Privileged Users

DBAs require unrestricted access to perform their jobs. Without effective privileged user monitoring, these users can cause immense, undetectable damage. PCI requires privileged users to be closely monitored. However, native audit tools were designed as DBA tools to enable monitoring for debugging purposes. Therefore, DBAs set up these tools to monitor all activities, including their own. DBAs also have the ability to change audit policies, stop audit functionality, and access the audit data. As a result, the integrity of an audit trail, which was created by native audit tools, is considered questionable and the audit records can't be trusted.

Consider: DAM for Achieving Effective Separation of Duties

SecureSphere provides an independent, (physical or virtual) appliance that does not require the DBAs involvement to set up or maintain audit capabilities. SecureSphere agents audit database activity, including privileged user activity, without relying on relational database management system (RDBMS) mechanisms, such as native auditing or transaction logs. As a result, the agents enable separation of monitoring from other DBA duties. SecureSphere also meets PCI Requirement 10.5 provisions to secure the database audit trail so that it cannot be altered. Unlike native audit logs that allow access to audit data, SecureSphere audit data is stored in a tamperproof repository on the hardened appliance.

Challenge: Inability to Identify Each Unique User

PCI Requirement 10.1 requires organizations to establish a process for linking all access to system components to each individual user, especially access executed with administrative privileges, such as root access. However, todays modern applications use connection pooling to connect to the database. Connection pooling masks the real identity of the user from the database. As a result, databases and native audit tools are often unaware of the real end-user.

Consider: SecureSphere User Tracking Technology

Linking individual application users to specific database transactions (and the data accessed within those databases) is not a simple task. Essentially, organizations have two options: application rewrites or solutions such as Impervas Universal User Tracking (UUT). SecureSpheres Universal User Tracking technology can identify the source end-user by combining multiple user identification methods: Direct User Tracking: If the application opens a database connection for each user request, then the source user information will be available as part of the session information. SQL Connection User Tracking: Some applications use connection pooling, but pass information regarding the source user in some form. These applications include: SAP, Oracle E-Business Suite, PeopleSoft, and Siebel. Imperva can be configured to record this information as part of the audit record. Add on packages called ADC Insights are available for SAP, Oracle E-Business Suite, and PeopleSoft. In addition to user tracking, information regarding sensitive objects, vulnerability assessments, and policies to audit and secure these applications is also available.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

For other applications where the user information is available, like Siebel, user tracking can be easily configured (Imperva consultants can assist with the required configuration). Web to Database User Tracking: The integrated SecureSphere Data Security Suite can link specific credit card data access events to source application users, even if the application does not provide this information. Combining the capabilities of the SecureSphere Database Firewall (DBF) and SecureSphere Web Application Firewall (WAF), this integrated suite can transparently correlate Web application login and session information with database transactions and objects accessed. Privileged Account User Tracking: When privileged users log into the database using shared privileged accounts, SecureSphere agents can identify the original user and provide this user information with the audit record.

Typical audit appliances and native database audit capabilities record application names, not actual user names.

PCI Requirement 8.5.5: Remove/Disable Inactive User Accounts at Least Every 90 Days
Proper user management requires removal of dormant database user accounts. Doing so keeps the database secure and eliminates the need to manage stale accounts. User accounts must be disabled when an employee quits an organization or retires. In reality, DBAs are not always notified when somebody leaves. Dormant accounts increase the risk of a data breach. If these accounts are compromised and used for carrying malicious attacks, the impact can be devastating.

Challenge: Databases Do Not Track the User's Last Login Date and Time
If organizations could query the database for the user last login date, then dormant users could easily be identified. Unfortunately, databases do not record this information. Some DBAs try to use various scripts, or manually search audit logs. However, this is a tedious, resource-intensive process that often yields inaccurate results.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Consider DAM Integrated with User Rights Management for Automated Identification of Dormant Users and Dormant Rights
SecureSphere Database Activity Monitoring audits all successful, and failed, login attempts. Combining this information with aggregated user information from across all enterprise databases, enables SecureSphere to present an accurate picture of active users versus dormant users. Through User Rights Management analysis capabilities, organizations can easily identify inactive users, see the last date and time these users were active, and gain additional context about these users, such as manager, department, etc., for safe removal of dormant accounts.

PCI Requirement 7: Limit Access to Cardholder Data by Business Need-to-Know

Restricting access to authorized personnel based on business need-to-know greatly reduces the risk of a data breach. According to PCI Requirement 7, organizations should limit user access to the least necessary to perform job functions. Keeping access at a business need-to-know level is easier said than done. As users change roles or leave organizations and new applications are introduced, DBAs are not always aware of these changes. As a result, users may have excessive rights to cardholder data. Manual processes to identify users with excessive rights are labor intensive, time consuming, and often not even implemented.

Challenge: User Rights Review is Resource Intensive and Error Prone

Access rights management, and identification of users with excessive rights, represents a unique challenge for most organizations for the following reasons: Reporting on User Rights: Manual preparation of user rights reports is resource intensive and prone to error. Due to the dynamic nature of most environments, when the report is finally completed, it is often no longer accurate. The resources responsible for generating these reports struggle to maintain an up-todate picture of user rights. Complex Collaboration Between IT, DBAs, and the Business: Business stakeholders need to review user rights as well as notify the technical administrator if user rights should be removed. However, appropriate processes for this task are often not in place. In some cases, the business stakeholder receives a technical list of rights to objects that is difficult to understand. In other cases, such reports simply do not exist. As a result, business stockholders do not review and approve access rights, IT does not eliminate excessive rights, and users continue to have unrestricted access to data. Analysis of User Rights and Identification of Excessive Rights: Using the user rights reports to understand the different rights a user has as well as to determine the appropriateness of the rights is not a simple task. This process involves a lot of information that must be analyzed. Typically, user rights reports do not explain why, or how, the user received a certain right.

Consider: User Rights Management for Databases

In order to enable an effective rights management process, organizations need to aggregate rights across all systems, identify data owners, submit all rights for approval, and implement access rights decisions. Executing this process on an on-going basis reduces the risk of a breach from a compromised account or the use of excessive rights to access cardholder data. Solutions such as Imperva User Rights Management for Databases help organizations automate and manage the rights review process. Aggregate and Report on User Access Rights: SecureSphere automatically aggregates user rights from multiple database platforms to facilitate timely, manageable audits and reviews.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Identify Data Owners: In most organizations, it is not easy to identify who owns certain data. By tracking actual usage of the data, it is possible to identify the most active users who are, or can help identify, the actual data owner. Identify Excessive Access Rights: SecureSphere helps identify excessive rights by correlating user access rights reports with actual data access activity. Users who do not access data, despite their permissions, may no longer be part of the organization or may not need those permissions to perform their job. Establish a Repeatable Access Rights Review Process: Establishing a rights review workflow helps organizations build a repeatable process for reviewing access rights. In addition to following a regular workflow, organizations should maintain an audit trail of the review process by recording whether reviewers accept or reject existing access rights and the required changes.

User Rights Management identifies which users can access what data.

PCI Requirement 6.1: Ensure that all System Components and Software are Protected from Known Vulnerabilities by Having the Latest Vendorsupplied Security Patches Installed
PCI requires organizations to ensure their databases are protected by applying the latest security patches. Database breaches often exploit known vulnerabilities in applications and supporting data systems. Unpatched systems expose organizations to a variety of threats.

Challenge: Establishing a Repeatable Assessment Process Across all Corporate Databases

In order to meet PCI requirements, organizations must perform a comprehensive scan to detect vulnerabilities and mis-configurations. In an environment that includes a large number of database and heterogeneous database platforms, manually assessing corporate databases is impractical.

Consider: An Automated Vulnerability Scanner

An automated scanner, such as SecureSphere Discovery and Assessment Server (and also included with SecureSphere DAM and DBF products ), enables a repeatable assessment of all database platforms. Pre-defined assessments simplify policy creation, and allow organizations to measure compliance with regulations and industry best practices. Customization enables organizations to address unique application and internal policies.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Challenge: Keeping Up with New Vulnerabilities

New vulnerabilities are discovered almost every day. Oracle releases a CPU every quarter and Microsoft releases patches, during Patch Tuesday, usually the second Tuesday of each month. How do organizations make sure their scanning solutions are up-to-date?

Consider: A Scanning Solution with Automated Content Feeds

SecureSphere Discovery and Assessment Server receives content updates developed by Impervas research group, the Application Defense Center (ADC). This allows organizations to scan databases for the latest vulnerabilities and patches. ADC Updates save organizations the time and resources typically needed to research new vulnerabilities and define updated assessments.

Challenge: Protecting Unpatched Databases

According to the 2010 IOUG Data Security Survey, many organizations do not apply critical patches in a timely fashion. This is due to the thorough testing and change management procedures required before a patch can be deployed on a production system. In certain cases, a patch cannot be deployed because it affects the stability and/or availability of the system.

Consider: Virtual Patching Solution to Prevent Exploits of Vulnerabilities

Virtual patching, available with SecureSphere Database Firewall, is the application of a database firewall that blocks attempts to exploit vulnerabilities. It allows organizations to protect their databases without actually deploying a patch. Virtual patching enables organizations to thoroughly test patches and undergo change management processes without leaving the database vulnerable. Because this solution is simply a firewall, it can be easily turned on or off.

PCI Scope: Tracking Cardholder Data Locations

PCI DSS requires organizations to identify and track the locations of all cardholder data. PCI explicitly states that customers must be able to identify and control all instances of such data.

Challenge: Cardholder Data Proliferation in the Enterprise Creates Unmitigated Risk of a Data Breach
While organizations place controls on cardholder data, certain business processes reduce the effectiveness of these efforts. For example, production data is cloned into development and QA instances required to test new application development. Data warehouse applications use this data for business analytics. The need to identify all data in-scope is at the heart of the PCI compliance effort because it is both essential to achieve this objective and secure cardholder data, as well as to limit the scope of the audit to relevant systems only.

Consider: Cardholder Data Discovery and Classification

Organizations can use data discovery and classification capabilities to look for cardholder data as well as other personally identifiable information in enterprise databases. The results of such scans can lead to a decision to eliminate discovered instances reducing scope, or to include these instances within the scope of the PCI compliance initiative. Imperva SecureSphere offers both scanning-based detection of cardholder data as well as the ability to monitor database responses and alert on the presence of cardholder data. This approach enables organizations to demonstrate a repeatable process for tracking all instances of cardholder data.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Conclusion
PCI DSS establishes an actionable security and compliance framework for protecting cardholder data. Organizations that process or store such data are obligated to secure this data and minimize their financial exposure to a data breach. Organizations must also maintain customer trust in their ability to securely transact business data. Imperva is the market leader and innovator in data security for PCI compliance. Impervas comprehensive and powerful platform, SecureSphere, accurately protects and audits all in-scope assets, including Web applications, databases, and files. Unlike point solutions for PCI compliance, Imperva offers a single, fully integrated and centrally managed solution that reduces total cost of ownership and enables phased, seamless deployment. SecureSphere allows customers to incrementally address PCI requirements according to their business and technical priorities. Imperva accelerates deployment by providing built-in data discovery and classification capabilities and pre-packaged PCI policies and reports. With SecureSphere, customers can quickly and painlessly satisfy audit requirements while securing their data. Since many organizations are subject to more than one set of regulations, Imperva SecureSphere can also address additional compliance requirements such as SOX and HIPAA. Imperva has significant experience in enabling organizations to successfully meet, and exceed, PCI requirements. Imperva offers flexible consulting, support, and training offerings to help organizations rapidly realize the value of their SecureSphere investment. This article is an excerpt from the Imperva white paper Data Security for PCI Compliance. To view the original document, click here.

About Imperva
More organizations trust Imperva to protect their business applications and databases than any other vendor. Only Imperva delivers innovative technology to give full audit accountability and separation of duties to meet regulatory compliance. The award-winning Imperva SecureSphere is the only solution that delivers full activity monitoring from the database to the accountable application user. To learn more about Impervas solution visit www.imperva.com.

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Appendix A How Imperva SecureSphere Specifically Addresses PCI Requirements

Table 1: SecureSphere Applicability to PCI 6
Req #
6.1

Text
Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release. Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.

SecureSphere Applicability Direct Partial

X

NA

SecureSphere Applicability Detail

SecureSphere Database Security Solutions includes assessment capabilities that evaluate configuration of both underlying operating systems and database management system software. Assessments include patch and version information. This is an effective audit mechanism for database update/patch control objectives.

6.2

Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues. Separation of duties between development/ test, and production environments

Subscription-based SecureSphere ADC Insight Services provide regular updates to the assessments of known vulnerabilities in business application (SAP, Oracle EBS, etc.) and database software. This information is integrated in the assessment capability mentioned in section 6.1 SecureSpheres Dynamic Profiling can enforce and audit separation of duties between different users and/or roles based upon their normal behavior profiles. For example, by monitoring production environments user access SecureSphere can detect and log unauthorized changes made by developers. Sensitive data discovery and user account assessments can audit removal of these accounts from production Web application and database systems Sensitive data discovery and user account assessments can audit removal of these accounts from production Web application and database systems SecureSphere Change Control Module can audit on configuration changes to database servers SecureSphere protects against each of the vulnerabilities identified by requirements 6.5.1 through section 6.5.10 all of the vulnerabilities enumerated by the Open Web Application Security Project (OWASP) guideline as well as many advanced vulnerabilities not covered by PCI or the OWASP Top Ten. Since SecureSphere capabilities go above and beyond the latest standards, it may be considered as a compensating control in certain scenarios. Its also worth noting that as threats change over time, SecureSphere is automatically updated by Imperva to provide protection against the latest vulnerabilities and standards. It is much more difficult to identify and deploy secure coding practices to developers as threats change. For more information about how SecureSphere protects against the OWASP Top Ten list of security vulnerabilities, please see the SecureSphere and OWASP Top Ten Technical Brief.

6.3.3

6.3.5

Removal of test data and accounts before production systems become active Removal of custom application accounts, usernames, and passwords before applications become active or are released to customers Follow change control procedures for all changes to system components. The procedures must include the following: Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following: Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.

6.3.6

6.4

6.5

Imperva White Paper

<

>

Database Security for PCI Compliance

DatabaseFileWeb

Req #
6.5.1 6.5.2

Text
Cross-site scripting (XSS) Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws. Malicious file execution Insecure direct object references Cross-site request forgery (CSRF) Information leakage and improper error handling Broken authentication and session management Insecure cryptographic storage Insecure communications

SecureSphere Applicability Direct Partial

X X

NA

SecureSphere Applicability Detail

SecureSphere protects against cross-site scripting. SecureSphere protects against injection flaws, including SQL, LDAP, and Xpath injection flaws. SecureSphere protects against malicious file execution. SecureSphere protects against insecure direct object reference. SecureSphere protects against cross-site request forgery. SecureSphere protects against information leakage and improper error handling. SecureSphere protects against broken authentication and session management. SecureSphere protects environments that use cryptographic storage. SecureSphere protects environments that use secure communications. In proxy mode, SecureSphere can secure communications by terminating HTTPS (SSL) connections. SecureSphere can restrict URL access to sensitive resources. SecureSphere is the market leading Web Application Firewall. It automatically detects and blocks attacks before damage may occur. SecureSphere deployment meets this control requirement more cost effectively and with less security risk than repeated application review and fix cycles (see Application Reviews versus Web Application Firewalls section above).

6.5.3 6.5.4 6.5.5 6.5.6 6.5.7 6.5.8 6.5.9

X X X X X X X

6.5.10 6.6

Failure to restrict URL access For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes Installing a web-application firewall in front of public-facing web applications X

Imperva White Paper

< 10 >

Database Security for PCI Compliance

DatabaseFileWeb

Appendix A How Imperva SecureSphere Specifically Addresses PCI Requirements

Table 2: SecureSphere Applicability to PCI 10
Req #
10.1

Text
Establish a process for linking all access to system components (especially those with administrative privileges such as root) to each individual user.

SecureSphere Applicability Direct Partial

X

NA

SecureSphere Applicability Detail

SecureSphere audits all user access to database information and management functions by administrators. SecureSphere also captures Web application user names and audits all subsequent Web session activity associated with that specific user name. SecureSphere can uniquely combine Web and database security capabilities to link specific SQL queries to specific Web user names even when user information is not passed to the back-end database by the application (e.g. connection pooling).

10.2

Implement automated audit trails for all system components to reconstruct the following events:

SecureSphere audits on all database events specified for compliance with requirement 10.2. SecureSphere audits some of the Web application events required for compliance with requirement 10.2. In addition to auditing, SecureSphere can issue real-time alerts in the event of significant policy violations. For example, it may be important to know in real-time when a database administrator uses a decryption stored procedure to access a credit card table. SecureSphere audits all database access to cardholder data and link that access to specific users (see item 10.1). SecureSphere audits all database management actions by administrators. SecureSphere audits access to its own Web and database audit trail. SecureSphere can additionally audit access to data that resides within native database logs. SecureSphere audits invalid Web and database logical access attempts. X SecureSphere audits Web and database authentication events. SecureSphere audits initialization of its own Web and database audit logs. SecureSphere audits creations and deletions of system-level database objects (schemas, installation dangerous stored procedures, etc.). SecureSphere Web and database event logs include all of the data specified in requirement 10.3. SecureSphere Web and database event logs include specific user names (see 10.1). SecureSphere Web and database event logs include event types. SecureSphere Web and database event logs include the date and time. The SecureSphere Web Application Firewall records Web server response codes, indicating server errors. The SecureSphere Database Firewall and Database Activity Monitoring track database errors and login failures.

10.2.1

All individual accesses to cardholder data

10.2.2 10.2.3

All actions taken by any individual with root or administrative privileges Access to all audit trails

X X

10.2.4 10.2.5 10.2.6 10.2.7

Invalid logical access attempts Use of identification and authentication mechanisms Initialization of the audit logs Creation and deletion of system-level objects Record at least the following audit trail entries for all system components for each event: User identification Type of event Date and time Success or failure indication

X X

10.3

10.3.1 10.3.2 10.3.3 10.3.4

X X X X

Imperva White Paper

< 11 >

Database Security for PCI Compliance

DatabaseFileWeb

Req #
10.3.5 10.3.6 10.4 10.5

Text
Origination of event Identity or name of affected data, system component or resource Synchronize all critical system clocks and times. Secure audit trails so they cannot be altered.

SecureSphere Applicability Direct Partial

X X X X

NA

SecureSphere Applicability Detail

SecureSphere Web and database event logs include detailed event origination information. SecureSphere Web and database event logs include detailed affected system information. SecureSphere can synchronize itself with your network nntp or other time mechanism. SecureSphere audit logging is completely separate from the native database and Web application logging. Only authorized users can access audit logs. Logs can be signed and encrypted Only users with appropriate roles and permissions can access SecureSphere Web and database audit trails. Roles and permissions are customizable. All access to audit trails is itself logged by SecureSphere. Only users with appropriate roles and permissions can access SecureSphere Web and database audit trails. Roles and permissions are customizable. All access to audit trails is itself logged by SecureSphere. Imperva SecureSphere audit trail files can be backed up via scheduled processes. Logs can be digitally signed and encrypted.

10.5.1

Limit viewing of audit trails to those with a job-related need.

10.5.2

Protect audit trail files from unauthorized modifications.

10.5.3

Promptly back up audit trail files to a centralized log server or media that is difficult to alter. Write logs for external-facing technologies onto a log server on the internal LAN. Use file integrity monitoring or change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6

10.5.4

The SecureSphere Web Application Firewall, typically deployed as an external-facing technology, can write logs to a log server on the internal LAN. SecureSphere Web and database audit logs can be signed and encrypted.

10.5.5

10.6

SecureSphere Web and database audit reports and alerts enable this requirement. Workflow can be defined to track review activity and require sign-off.

10.7

Retain audit trail history for at least one year, with a minimum of three month immediately available for analysis (for example, online, archived, or restorable from back-up).

Imperva SecureSphere Web and database audit trail logs can be backed up and stored for a configurable period. Support for SAN, NAS and integration with log management from SenSage, ArcSight, Prism Microsystems, RSA, and others provides multiple options for long-term, high-volume data retention.

Imperva White Paper

< 12 >

White Paper
Appendix B Imperva SecureSphere Deployment
Imperva Agent

Databases
Network Monitoring Native Audit

Users

Web Servers Web Application Firewall (6.6) Database Activity Monitoring (10, 7, 8.5, 6.1)

Agent Auditing File Servers/ NAS

File Activity Monitoring (10, 7, 8.5, 11.5)

INTERNET
Uni ed Management Server (MX)

The SecureSphere Data Security Suite comprises market-leading SecureSphere Web Application, Database, and File Security Solutions. The SecureSphere Data Security Suite can be deployed as separate standalone appliances, as shown above, or as a single, integrated security appliance. Together, the SecureSphere deployment monitors and protects sensitive resources and addresses PCI requirements 6.6, 7, 8.5, 10, and 11.5. An MX Management Server centrally manages all SecureSphere appliances. Security updates from the Imperva Application Defense Center (ADC) and from ThreatRadar cloud servers keep SecureSphere defenses up-to-date.

Imperva Headquarters 3400 Bridge Parkway, Suite 200 Redwood Shores, CA 94065 Tel: +1-650-345-9000 Fax: +1-650-345-9004 Toll Free (U.S. only): +1-866-926-4678 www.imperva.com Copyright 2011, Imperva All rights reserved. Imperva, SecureSphere, and "Protecting the Data That Drives Business" are registered trademarks of Imperva. All other brand or product names are trademarks or registered trademarks of their respective holders. #WP-DATABASE-SECURITY-PCI-COMPLIANCE-0611rev1