The real challenge for meeting PCI compliance is the secure management of all the components and parts of the Oracle E-Business Suite environment every day of year. While Release 12 of the Oracle E-Business Suite by default does not protect cardholder data, it can be enabled. The steps are rather straight forward and can easily be completed in a non-production instance for testing. Future blog posts will review the daily, weekly, monthly and annual PCI requirements once these basic PCI setups have been completed.
Three Basic Steps
There are the three basic steps to enable PCI protection for a new Release 12 implementation are:
- Create Payment encryption wallet
- Set protection configuration options
- Encrypt existing cardholder data
Step 1: Create the Payment Encryption Wallet
With Release 12, the most critical step in meeting PCI DSS is the creation and on-going protection and maintenance of the Payment encryption wallet. There are several decisions to be made before creating a Payment Wallet. Wallets can either be self-signed, where the certificate is the same as the subject, or use a third party certificate from a well-known Certificate Authority. Which type of wallet is created is dependent on your trust requirements and expected usage. Payment Wallets must also be backed up separately from the E-Business database.
Step 2: Set Protection Configuration Options
Setting the protection configuration options is done using the Funds Capture Setup Administrator or Payments Setup Administrator responsibility. The decisions regarding which options to use should be carefully reviewed with internal audit, security and counsel.
- Wallet - Location of the wallet file, the name of the wallet and the wallet password. Another decision is the whether the system key will be system generated or user defined. Integrigy Corporation recommends using a system generated key unless specific requirements are identified.
- Account Number - Yes or No to encrypt the credit card number - select ‘Yes’
- Supplemental data - Yes or No whether card holder name and expiration date will also be encrypted. This is also referred to as partial encryption if set to ‘No’.
- Type – Whether or not encryption will occur immediately prior to being written to the database or later at a scheduled time. The options are ‘Immediate’ or ‘Scheduled’. If you select scheduled, data will be unencrypted until the request set ‘Encrypt Sensitive Data Request Set’ is run. Oracle does not automatically schedule this and it will need to be manually scheduled. Integrigy Corporation strongly recommends using ‘Immediate’ and not ‘Scheduled’.
- Card Owner Verification – Requiring the ‘Security Code’ and/or ‘Require Statement Billing Address’ by setting to ‘Yes’ requires the entry of the credit card security code or card statement billing address. This information is passed to the payment system, which in turn, checks with the credit card issuer to confirm the credit card owner's security code and/or statement billing address.
- Credit Card Masking - Allows for masking of all but the first or last x digits of a PAN, for which x is identified by the field ‘Number of Digits to Display.
Step 3: Encrypt Existing Cardholder data
Cardholder data created prior to setting the encryption configurations will not be automatically encrypted. To encrypt cardholder data that already exists run the request set ‘Encrypt Sensitive Data Request Set’.
Next Blog Posting
In the next blog posting we will review the PCI requirements for creating non-production instances from copies of production.
For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.
If you have questions, please contact us at email@example.com
-Michael Miller, CISSP-ISSMP
- Oracle E-Business Suite: Credit Cards and PCI Compliance
- PCI DSS 3.0 Compliance and the Oracle E-Business Suite
- "How To Enable Oracle Payments Data Encryption Functionality”, Oracle Metalink Note ID 1301337.1, Oracle Corporation, 1 November 2013