In an effort to protect its cardholders from identity theft, unauthorized disclosure of private information and other bad practices, VISA introduced its Cardholder Information Security Program (CISP) in June 2001. The program, focused on safeguarding personally identifiable cardholder information, applies to merchants, service providers and payment channels that maintain, collect or transmit data for VISA account holders. Other credit card companies, like MasterCard, also introduced similar standards.

Since then, Visa and MasterCard have collaborated to create an industry-wide security standard, largely based on and mapped to the CISP requirements. This is known as the Payment Card Industry (PCI) Data Security Standard, version 1.0 of which was published in December 2004, and it has been widely adopted by most U.S.-based card companies.

Like CISP, PCI lays out 12 key security requirements that are general in scope, each having more detailed sub-requirements. They outline best practices for controlling internal and external access to sensitive data, at levels such as network, communications, server, application and policy.

The Importance of Audit Trails in PCI/CISP Compliance

Audit trails are a valuable tool in daily operations identifying weaknesses and successes in systems, processes or procedures. They are also an absolute necessity during reviews for compliance whether complying with industry regulations or with company policy.

PCI/CISP, particularly Requirements 7 and 10, clearly emphasize the critical role that logging mechanisms play in the safeguarding of cardholder data. Access to cardholder data must be restricted to those whose jobs require it, prompting the need for a secure audit trail to ensure that unauthorized accesses are not occurring. System and user activity logs for all network resources, such as firewalls and database servers, must be maintained in secured environments. An organizations readiness to routinely comply with PCI/CISP is determined by their ability to identify, gather, store and analyze the required logs and audit data on a timely basis.

An additional challenge to merchant organizations is the expansion of commerce activity to distributed channels. As a result, an organizations transaction or cardholder data can originate from various sources such as a brick-and-mortar operation, an e-commerce website or a third-party vendor relationship -- each source possibly using different POS applications and database systems. Whoever the merchant or their contracted service provider stores the data, must institute specific perimeter and user security measures to protect it. In addition, access to this data must be audited. Without modifying each POS application to generate audit records, how would an organization be assured of having a reliable, independent, secure audit trail of its critical transaction and cardholder data?

One cost-efficient, pragmatic solution is to generate the audit trails at the repository or database level, actively auditing whenever a change occurs to specified tables or fields. Implementing audit trail mechanisms have historically required modifications, sometimes major in scope, to applications. Often, audit functionality is limited in scope to specific application modules and even further limited in the data elements that can be audited. In many cases, an applications audit data is not portable or separated from the application data, potentially limiting the ability to properly secure it.

Implementing Data Auditing with OmniAudit

OmniAudit distinguishes itself with the following features:

• Requires no changes to applications: Generates audit data based on triggers installed on the table-level. This eliminates the need to change applications to enable auditing
• Audit what you want: Easy point-and-click setup interface allows selection of the tables to audit (which installs the triggers) and even specific columns within those tables to audit. Decide which table to audit and which fields in those tables will be audited when changed (which configures the triggers). The scope of the audit data captured is dependent only on the organizations needs and audit plan. In addition, fields can be marked for capture". When a field is marked for "capture", the captured field's current value is added to the audit trail whenever any of the audited fields in that table change. Capture values are added in addition to the normal audited changes
• Auditing occurs automatically: Audit trails are generated automatically and transparently as the change event occurs
• Independent of the source: OmniAudits trigger-based architecture enables it to record all changes to the data, no matter whether the source was MS Query, a custom application, a web page or MS Access
• Separate SQL Server Audit Tables: Audit trail data is maintained in SQL Server tables, which is easily accessed, reported on and archived. The security of these tables is administered via SQL Server security therefore the data is inherently restricted from user access until permissions are explicitly granted to any privileged users. The tables can reside in the database that is being audited or in a separate database. The option to store the audit data in a separate database allows the audit trail to be portable, secured and independently backed up. The portability of this data is particularly useful when optimizing performance or resources.
• Low impact on performance: In most cases, OmniAudits impact on application performance and server resources is minimal. Performance is directly related to factors such as transaction volume and the organizations specific audit parameters. It is virtually transparent to the user.
• Easy to install and maintain: The point-and-click screens make it easy for non-technical users to select and change which tables and fields are setup for auditing. OmniAudit requires little effort by SQL Server DBA staff
• View Audit Trails: Use the OmniAudit Log Viewer to browse audit data and drill down to the table, field, user, workstation, or application levels.

PCI/CISP Requirements Facilitated by OmniAudit

OmniAudit supports an organization's ability to comply with Requirements 7 and 10 of PCI/CISP as they relate to changes made to cardholder data.

Requirement 7 of PCI/CISP states "Restrict access to data by business need-to-know". While OmniAudit does not actively secure the data, its audit trail provides the information needed to determine if:

• An unauthorized user has changed cardholder data
• An authorized user has made an inappropriate change to cardholder data
• An unauthorized source has changed the data

The current version of OmniAudit does not monitor access attempts to the cardholder data, however, with a combination of perimeter security and database connection logging, it is possible to provide sufficient documentation of a compensating control. Compensating controls can be considered as an alternative if a requirement cannot be met exactly as stated, as long as they meet the intention of the original requirement and are "above and beyond" the requirement.

Requirement 10 states "Track and monitor all access to network resources and cardholder data". With reference to the tracking and monitoring of changes to cardholder data, OmniAudits audit trail contains the key audit entries required by PCI/CISP:

• Who the username of the person who made the change
• When the date and time of the change
• What the name of the SQL Server Table and the name of the column that was changed
• Type of change (insert, update or delete)
• What it was the data value before the change
• What it is the data value after the change
• The source of the data change (query tool, application etc.)
• The machine name of the user or source that made the change

Requirement 10 also demands that audit trails be secured, unmodifiable, and retained for a period in accordance with its effective use and legal regulations. OmniAudit audit trail data is stored within standard SQL Server tables, leveraging SQL Server's built-in features to manage audit trail integrity, retention, and archiving.

Supporting other PCI/CISP requirements

OmniAudit does not directly connect to network devices like firewalls, storage systems or web servers and generate audit logs for their activity or configuration changes, but it can help facilitate compliance with other PCI/CISP requirements. It is possible for authorized administrators to extract essential policy, configuration and log data from their various sources and import them into SQL Server tables that have been setup for auditing with OmniAudit.

As a result, by providing a mechanism by which log and configuration data can be collected, analyzed, secured and archived, OmniAudit can play an important role in an organizations readiness to comply with PCI/CISP and other industry standards.

Summary

As with PCI/CISP for the Payment Card Industry, other industries have recently created and adopted similar standards that address the need to safeguard data from unauthorized access and identity theft. PCI/CISP, as well as other industry standards such as HIPAA and Sarbanes-Oxley, identify audit trails as a key mechanism to supporting compliance with the increasing requirements of data privacy.

Compliance is achieved via a combination of procedures, processes and technical controls. No vendor can validly offer a fully PCI/CISP compliant system or a turnkey solution to ensure compliance of PCI/CISP. Vendors can, at best, offer solutions that follow the best practices outlined, contain necessary technical controls or are tools that enable an organization to determine its readiness for compliance.

OmniAudit's ability to be deployed in a SQL Server database environment without requiring changes to existing applications, major effort from the DBA staff or sacrificing performance, provides a powerful solution to organizations of any size or industry.