PCI-DSS Detailed Analysis

PCI-DSS is the Payment Card Industry’s Data Security Standard. It is required for working with Visa, MasterCard, American Express, Discover or JCB. PCI-DSS version 2.0 contains very detailed instructions about how security should be implemented, what should be done, and is prohibited.
PCI-DSS Requirement 10 is dedicated to activity monitoring. Below is a detailed analysis of requirement 10 and how it should be implemented on Oracle databases.
Go to page12All

10.2.5 - Audit Sessions

PCI-DSS 10.2.5 requires logging of authentication mechanisms. In the Oracle database, that means logging of all successful and failed logons.
There are several reasons to capture all logon activity in the Oracle database, including:
  • Review of database logons can point to suspicious behavior and might indicate an attack or a breach
  • Most brute force attacks would generate a substantial number of failed logons while the attacker is attempting to guess Oracle account passwords
  • An audit trail of who accessed the Oracle database and when is a basic component of building a timeline during a forensic investigation
PCI compliance requires capturing of all logon activity from all sources, including:
  • Network access to the Oracle database through SQL*Net
  • Local access to the Oracle database through SQL*Net
  • Local access to the Oracle database through BEQ connections
  • Encrypted access to the Oracle database using Oracle Advanced Security (OAS)
  • Encrypted access to the Oracle database using TCP layer encryption
  • Access to the Oracle database using older Oracle protocols that are still supported by new releases (e.g. OCI7)
  • Access to the Oracle database through the SQL Loader, export, and import (both new and old versions)
  • Authentication via any of the many methods, including regular passwords, OPS$, RADIUS, Kerberos, and more.
The many supported features and authentication options of the Oracle database pose a significant challenge here as an auditing solution must be able to capture them all.

10.2.6 - Audit Trails Initialization

PCI-DSS 10.2.6 requires logging of audit trail initialization.
This is another audit trail security requirement like 10.2.3, and refers to audit trails that reside inside the Oracle database (such as sys.aud$), or in files on the Oracle database server.
Our practical suggestion is, again, to send the audit information to secured locations as soon as possible to minimize exposure. For this reason Core Audit continuously sends the audit data to the audit server and are never stores it locally.

10.2.7 - Audit Creation and Deletion of Objects

PCI-DSS 10.2.5 requires logging of creation and deletion of system level objects. The intention of this PCI requirement is to detect manipulation of the Oracle database by modifying it.
In Oracle, such modifications are performed by DDLs and can be classified into four groups:
  • Authentication and Authorization changes – for example, create users, change passwords, grant privileges, etc.
  • Schemas changes – for example, create synonyms or views, drop tables, copy tables, etc.
  • Programming changes – for example, changes to triggers, procedures, Java code, etc.
  • Database changes – for example, changes to tablespaces, control files, redo logs, etc.
The auditing solution must not only capture these DDLs, but also be immune to them. For example, capturing DDLs via triggers is problematic since triggers are modified by DDLs.

10.3 - Audit Record Information

PCI-DSS 10.3 specifies the minimum information that much be associated with every audited activity.
The information required can be classified into three groups:
  • When – the time of the event
  • Who – the individual that performed the activity and the source of the activity (e.g. program/machine that sent the SQL).
  • What – the type of event, the data affected, and whether is was successful.
“Who did what, when, and how”, are the basic questions that any auditing solution must answer.

10.4 - Time Synchronization

PCI-DSS 10.4 requires synchronizing the time between all critical systems.
There are two reasons for this:
  • When correlating events in different systems (for example, SQLs in the database to application log entries, to web server log entires), it is important to have the clocks that generated the time stamps synchronized.
  • When creating the forensic timeline in an incident investigation, it is important to know when things happened in real time.
In other words, all audit records must be synchronized between the different systems, and must correspond to the wall clock.

10.5 - Secure Audit Trails

PCI-DSS 10.5 requires securing of audit trails.
There are four specific security requirements that must be upheld:
  • Read – only personnel who require it for their job duties should be able to view the information
  • Write – no one should be able to modify the audit information
  • Isolation – audit information should be kept on a secured server that protects it
  • Integrity – audit storage should resist manipulation and generate alerts if such manipulation occurs.
In other words, this PCI compliance requirement is saying is that good activity capture must be follow by proper protection of the captured data. Guaranteeing the accuracy of the audit records is a vital component of any Oracle database auditing solution. For example, Core Audit contains a proprietary encrypted storage that cannot be modified.

10.6 - Audit Trail Review

PCI-DSS 10.6 requires daily review of Oracle audit trails.
One of the most powerful detection components is the human common sense. No technology to date can replace conclusions drawn by a human being from glancing at a report. While automation and detection have their place, human involvement in the security process is paramount.
Reports are, therefore, an important component of an Oracle compliance solution. There are many important features in reports, but the most prominent ones are:
  • Automatically generation of the daily reports required for PCI compliance
  • Easy to read and digest
  • Due to system changes and evolution of needs, occasional changes are inevitable. To ensure the reports remain effective, it is important to have easy tuning of filters to remove noise, as well as adjustments of columns and grouping to show pertinent information.
  • A good automation like Intelligent Auditing can reduce the burden of the daily reports and detect anomalies that might escape the human eye

10.7 - Audit Trail Retention

PCI-DSS 10.7 requires audit trails to be available for at least one year.
The requirement for a year’s worth of data is made for a several reasons:
  • Oracle audit data is often reviewed by the auditors during the yearly audit
  • Should a data breach occur, the audit data is the corner stone of any incident investigation.
The challenge lies in the immense volume of activity captured and recorded by an Oracle database auditing solution. To compound the problem, a single Oracle auditing solution tends to audit many Oracle databases.
When using relational databases for audit storage, the hundreds of millions of audit rows can consume extremely large disk space and the indexes degrade in performance as the volume increases. Core Audit’s proprietary storage was designed to hold unlimited amounts of data with a minimal storage footprint.