PCI Compliance for Oracle EBS
Recently, Michael Miller of Integrigy and I lead a webinar outlining the difficulties of maintaining PCI compliance within Oracle E-Business Suite. Here’s a brief recap:
We covered three main topics.
- PCI DSS Compliance requirements
- PCI DSS Compliance in Oracle EBS
- CardConnect’s solution
Mike began by reviewing the twelve sections of PCI requirements. He then delved into sections six, eight, ten, and eleven and the amount of time required to maintain compliance.
PCI DSS Compliance requirements
Requirement 6: Develop and maintain secure applications
- Apply application and database CPU security patches within 30 days of release
Requirement 8: Assign unique ID to each person with access
Review needs to be done every three months, and you must be able to prove these reviews have taken place in the event of an audit.
- No generic accounts
- Review user accounts every 90 days. Disable inactive users and change user passwords.
- Strict password complexity
Requirement 10: Track and monitor access
Auditing/logging within Oracle EBS is minimal. Additional auditing needs to be step up and a process must be in place so you can provide attestation to auditors that your logs are reviews on a daily basis. This is necessary for EBS, the database, the network, and the operating system.
- Auditing within Oracle EBS is minimal
- Log all activity to cardholder data
- Implement automated audit trails
- Daily log review
Requirement 11: Regularly test security systems and processes
- Annual application and penetration test
- Quarterly internal and external vulnerability scans
- Deploy file integrity monitoring
PCI Compliance in Oracle EBS
The main challenges:
- Oracle EBS is not PCI compliant out of the box
- Oracle Release 12 (R12) provides new PCI DSS functionality, but needs to be manually enabled
- Maintaining PCI compliance within Oracle EBS is an on-going process, not a one-time setup.
The standard functionality of Oracle EBS
R12
The new release consolidates all of the payment activity into a single module called Oracle Payments. This consolidation includes the storing and processing of credit cards, including both internal and external accounts. Oracle defines external accounts as any accounts owned by your customers or vendors, while internal accounts are the accounts you use to run your business. This includes corporate cards. While PCI DSS does not require corporate cards to protected, it is still recommended that businesses do so and Oracle Payments includes them in their encryption process.
Secure Payment Repository
This part of the new Payments module offers PCI-approved encryption and masking to allow you to meet the requirements of PCI section 3–“Protect stored cardholder data”.
Enabling E-Business Credit Card Protection
1. Create Payment Wallet
- Standard Oracle Wallet
- Integrigy recommends a separate wallet just for encryption, plus a second wallet if you use SSL or advanced security options
2. Set protection configuration options
- Oracle offers full and partial encryption. Full encrypts primary account numbers as well as cardholder name and expiration dates. Partial only encrypts the card number number
- Oracle’s encryption is a chained encryption approach that exceeded PCI’s requirements by using a 150 bit key
- Possible cloning issues
3. Encrypt existing cardholder data
- This can be difficult with concurrent programs, and you must ensure they are run in the correct order.
- Since these programs can also unencrypt, you must carefully monitor execution on them
Testing/dev environments
In creating a test or development instance from production, you will need to ensure there is no live credit card data in the environment. When creating a non-production environment you must do the following post-clone:
- Remove, purge, or scramble credit card data
- Protect the encryption keys
- Rotate the Payment wallet
- Securely wipe the wallet files from the operating system
Purging cardholder data
Along with requiring that merchants only store cardholder data for the absolute minimum possible time, PCI also requires a quarterly purge. At this time, most Oracle modules do not offer a purging solution.
Other places credit card data may exist in Oracle EBS
- Custom tables
Customizations by developers, backup before data fixes, through dev process/updates - Maintenance tables
DBA copies of tables to make backup prior to the direct SQL update - Interface tables
Credit card numbers are often accepted in external applications and sent to Oracle EBS - Interface files
Flat files used for interfaces or batch processing - Log files
Log files generated by the application (e.g., Oracle Payments, Apache)
Michael’s summary
Michael wrapped up his section of the webinar with three main points:
- PCI DSS compliance is costly and on-going
- Encryption is just one of many requirements of PCI DSS
- There is a tokenization alternative
I then took the stage to explain CardConnect’s solution for PCI DSS compliance within Oracle EBS
The CardConnect Solution
While encryption is a strong option for protection of credit card data, it’s not the only option. An easy way to maintain compliance and reduce risk, exposure, and cost is tokenization.
Why tokenize?
Tokenization completely removes payment data from Oracle EBS, reducing the scope of PCI compliance and ultimately reducing your cost. It allows you to not only protect new card data, but using batch tokenization allows you to remove historical card data from Oracle EBS entirely.
How does it work?
When a credit card is run through a tokenizer, the card number is encrypted and the encrypted number is replaced with a randomly generated token. CardConnect tokens all begin with a 9, followed by two numbers to represent the card brand, and end in the last four numbers of the card to make them recognizable. The remaining numbers in the token are generated without any sort of pattern, making them mathematically irreversible.
The encrypted card number is stored off-site in our vault, and the only number that ever touches your Oracle EBS is the token. By doing this, CardConnect takes on the burden of storing all of your sensitive data, greatly reducing your PCI compliance burden.
Selecting a provider
When choosing a tokenization provider, you must review every channel through which you receive payment data and ensure your provider can cover you. This includes Oracle Forms, iStore, POS, mobile, e-commerce, etc. You’ll need to make sure that all of the channels will be tokenizing data at the point of entry with only the token stored within Oracle EBS. Only Oracle Payments will be interacting with the payment gateway, so it’s vital to choose a provider that has integration options designed just for Oracle. This will reduce not only the amount of time your integration will take, but also your costs.
CardConnect offers dozens of APIs–from AJAX to our desktop tokenizer, from card-present options to mobile–that insulate Oracle EBS from credit card information. A demo system only takes about 15-30 minutes to installs
Single-use vs. Multi-use tokens
CardConnect’s tokens are irreversible one-way tokens that are totally reusable. This is particularly useful for recurring billing or subscription services. Business that do monthly invoicing will greatly benefit from choosing a provider that offers multi-use tokens for this reason.
Hosting
Vault on premise or in cloud?
Pros and cons
On premise you’ll be in more PCI scope
Off-premise scope risk and cost are greatly reduce
Additional benefits
• Zero modifications to Oracle E-Business
• Enhanced automatic reconciliation
• Automatic account updater
• Process Level II and Level III payment data
Risks of Non-Compliance
If a merchant is found to be non-compliant, Visa and Mastercard may fine you up to $25,000/month until you become compliant. Additionally, if you experience a data breach while not compliant, you are liable. Fines for a data breach without compliance can rocket into the millions depending upon certain factors. Not only that, but it’s estimated that the cost of a breach are between $100-$200 per compromised record. If you remember Target’s breach of 40 million accounts, you can imagine how quickly that can add up.
PCI Scope Reduction
Before
SAQ-D 3.0
60+ pages
300+ questions
QSA costs $100k+
After
SAQ-A/B
about 6 pages
20 questions
$3,000
In conclusion, Oracle EBS is not PCI Compliant out of the box, but there are plenty of things you can do to get there. CardConnect’s solution can greatly reduce the scope of PCI compliance, both saving you money and offering your customers the protection they expect.
View the webinar below and let us know in the comments what webinar topics would interest you.
