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.1 - Linking Activity to Individuals

PCI-DSS 10.1 requires linking activity to individuals, with a special stress on privileged activity.
This PCI compliance requirement emanates from a fundamental compliance principle – accountability. Every individual working with the Oracle database must be personally accountable for his or her activities, and to that end, must be associated with them.
In other words, associating activity only with the Oracle database account is insufficient. This is especially true in the case of highly privileged Oracle database accounts such as SYS and SYSTEM that are not individual accounts.
The Oracle database auditing solution must, therefore, associate each activity with sufficient information to allow identification of the individual. Such information can be a combination of the machine, OS user, terminal, IP address, Client Info, etc.
Here are some practical suggestions for implementation:
  • Every Oracle database account must be used by a single individual. Usage of shared Oracle accounts is strongly discouraged. There must be clear identification of the individuals that own each Oracle account.
  • Some shared accounts cannot be avoided (e.g. SYS and SYSTEM). For these accounts, a process much be established to trace the activity to the originating individual. For remote connection, this can be done through the OS User connecting to the account. For local connections, this can be done by matching the Terminal information to the Unix logs.
  • Application accounts are also share accounts. There much be a mechanism that involves the application for linking activity to actual end users. This can be done using Oracle mechanisms like Client Info, or using application audit trails.

10.2.1 - Audit Access to cardholder data

PCI-DSS 10.2.1 requires logging of every access to cardholder data. This is the most fundamental requirements as it will allow identification of suspicious access to the sensitive data, as well as provide forensic evidence during incident investigations.
This PCI requirement covers any activity in the Oracle database that accesses cardholder data. This includes:
  • Queries (select) statements
  • DML (insert, update, delete) statements
  • Certain DDLs (truncate, create table as select), as well as creation of indirect paths (synonyms, views, materialized views, etc)
  • Remote activity (over network)
  • Local activity (BEQ connections from within the Oracle server)
  • Internal activity (PL/SQL from stored procedures, triggers, anonymous blocks, Java, etc)
The intention of this PCI compliance requirement is clear – to identify manipulation or theft of cardholder information. It is, therefore, critical to capture any such attempt regardless of the skill level of the attacker or the privileges they hold.
Multiple examples from recent years demonstrated the significance of this requirement. Not having a working auditing solution proved extremely costly in these cases. Compliance would have prevented the long exposures and provided accurate information on what was stolen.
The many features and options supported by the Oracle database make this compliance requirement challenging as an auditing solution must be able to capture them all.

10.2.2 - Audit DBA and Privileged activity

PCI-DSS 10.2.2 requires auditing of every action performed by Oracle database administrators and privileged users. The reason behind this requirement is to mitigate the risk of privilege abuse as well as the risk of stolen or otherwise compromised privileged accounts.
Handling the difficult issue of administrators monitor themselves is discussed further in other requirements (such as 10.2.3 and 10.5). However, the ideal solution is for Oracle DBAs to have no control over the auditing of their own activities.
Our practical suggestion:
  • Audit all DBA and privileged user activity
  • Ensure the solution cannot be manipulated by the Oracle DBAs. For example, that DBAs cannot turn off auditing for their session
  • Ensure the solution cannot be circumvented by Oracle DBAs. In other words, that DBAs cannot perform activity that is not captured by the solution. Here are some Examples.
An additional challenge is the fact that Oracle DBAs know their way around the Oracle database, and are probably part of the team that evaluated and deployed the Oracle database auditing solution. They are, therefore, aware of any deficiencies in the solution and are capable of exploiting those. An auditing solution must truly be full-proof to achieve effective compliance with this requirement.

10.2.3 - Audit Access to Audit Trails

PCI-DSS 10.2.3 requires logging of all accesses to the audit trails.
This requirement refers to audit trails that reside inside the Oracle database (such as sys.aud$), or audit trails that reside in files on the Oracle database server. It is one of several requirements dealing with the security of audit trails.
Our practical suggestion (based on requirement 10.5.3): audit trails should be sent to secured locations as soon as possible. The less time the information is present on the database server, the less chance of manipulation.
In Core Audit, for example, the audit trails are continuously shipped to the audit server and are never present on the database server.

10.2.4 - Audit Errors

PCI-DSS 10.2.4 requires auditing of invalid access attempts. The purpose of this requirement is to identify potential attacks through the errors that might accompany them.
For example, SQLs that failed to parse or failed to execute and that contain the names of cardholder data tables, can be a good indicator of someone who is attempting to gain access to this data.

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.