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.