Meanwhile, ever-expanding security demands continue to wash up on your doorstep. If both Oracle EBS R11 and R12 are non-PCI compliant, how are you to navigate the elements of steady payment security in the fluid world of Oracle EBS?  This blog post will focus on key elements facing Oracle EBS managers: Encryption. Reducing scope. Middleware portability between R11 and R12.

Encryption.  EBS 11i originally stored payment card information (the PAN) unencrypted, although this was later remedied with a credit card encryption patch. However, if payment card data is encrypted indigenously and stored within the EBS, the scope of a PCI audit continues to encompass a wide swath of EBS. Encryption alone won’t pass muster these days.

Issues of Scope. Meeting the twelve basic requirements of the PCI-DSS is fundamentally important to protecting your business from harm. However, there are various routes available to meet the requirements, from the onerous (comprehensive reviews of every application throughout your EBS where cardholder data might be accessible), to the easiest: removing your EBS from scope. Removing your EBS from PCI audit scope is a goal that can be accomplished with your choice of middleware. Ideally you want the capability to achieve tokenization for storage of PAN up-front (so that your EBS never takes on card data), plus appropriately segregated system hardware data storage options, either on-site or hosted. The very latest tokenization techniques permits P2PE with a PCI-certified entry device (such as the award-winning PANPAD ® from PPS), which removes even customer service from PCI audit scope.

Transferability among EBS Releases. In the swirling world of Oracle EBS, you have your hands full keeping your business on an even keel, and attending to patch releases. If you are currently facing PCI compliance issues in R11i, you want a fast, sensible middleware implementation AND you want your middleware to deliver flexibility on your path towards R12 or Fusion. Maybe you’ll eventually opt for a technical upgrade to select R12 components; maybe you will commit to a full R12 re-implementation. In either case, by limiting your pool of middleware contenders now to those with demonstrated compatibility with both R11 and R12, you’ll spare yourself redundant effort later.

Well-designed middleware options currently available will not only protect your business from payment card security breaches, and simplify your PCI-DSS compliance effort, but can also minimize unnecessary complications as you contemplate your evolving Oracle EBS choices.

Let’s start by considering a settlement file, totaling $1000, sent to collect your cash. Some SAP middleware simply accepts a settlement acknowledgement file coming back from your processor, and… that’s it. SAP cannot accept a deposit file without enhanced middleware. To reconcile, the finance department has no transaction/settlement detail and is simply trying to compare transactions with bank deposits, which will likely not be $1000 – interchange fees, delayed transactions, and other penalty fees will have been netted out. This hand-crafted reconciliation is only feasible on a very small transaction volume. However, other middleware providers offer extended capabilities in automated reconciliation, as add-on functions and management reports. In that case, your SAP system can receive a deposit file sent directly from the processor back to the finance department. Differences are identified and highlighted by the enhanced middleware, but the power of the SAP enhanced functionality and reporting will vary considerably by provider.

For instance, when an automated deposit file is returned on the $1000 settlement file, your standard interchange fees will have been deducted and identified (let’s assume 2.4%, or $24). But what if the file is only $944 (not $976): how are you going to identify (reconcile) the sources of the discrepancy? An enhanced automated solution like CardConnect with CardDeposit from PPS would have transferred the deposit amounts and fee data into SAP via an update function module, storing it in custom tables with optional automated posting capability. Research, reconciliation, and adjustment postings are now an automated process.

This $32 difference could be for a number of reasons, here are a couple:

• There is simply a missing record in the deposit file; for some reason one (or more) transactions have been left “pending”.
• There are unmatched transactions, which means there is an extra record. It turns out that it could be positive or negative. Ouch – that means the $32 difference is a NET difference – not a specific amount to research. Now your finance staff is looking for plus or minus transactions.

CardDeposit expedites your reconciliation by automatically matching the settlement file that was sent out with an automated deposit file with detail. Reports can follow the transaction details from settlement through deposit. Any deposit record(s) which vary from the originating settlement file are automatically identified.

By way of a function call, the specific records needing attention are brought up in a CardDeposit report, and prominently highlighted with a red flag. As your finance staff investigates the details, and the source of the red flag is identified, the staff can mark the record for automatic posting as discrepancies are resolved. Staff resources are used efficiently. The environment is paperless. Penalty fees are minimized as the transaction is still able to settle timely, with timely attention.

A reconciliation that is automated, paperless and powerful. The quiet child can shine. At PPS, we get it. As your expert provider of powerful middleware, PPS specializes in connecting you to the payment system in both directions plus enhancing the management power of your SAP ERP with proven add-on functions and reports.

It means that businesses have attained a certain level of security proficiency in communicating PAN data to payment card processors, in PAN segregation, and PAN storage. These are the rewards of strenuous efforts to develop and comply with PCI DSS. Now for the bad news: much more recently, like a pack of jackals, hackers have focused on the next weakest member of the herd, the one on the fringe: credit card data transiting into a cardholder data environment at the PED (payment entry device). So, what does Point-to-Point-Encryption entail? How is security on the fringe assured?

After serious attacks on Pin Entry Devices (PED) began a few years ago, the PCI SSC published a guidance document, “The Roadmap,” in October 2010 [i], which was followed in September 2011 by the initial release of solution requirements (hardware only) [ii]. Both documents provide assurance that P2PE will not change established security practices: businesses still need to be sure that the fundamental twelve requirements of the PCI DSS [iii] are met. But, scope is malleable: including the point of interaction (POI) in scope could be a nightmare. Or on the other hand, encrypting at the POI could strengthen your security on the fringe, reducing the risk of attack or breach. It could also shrink PCI scope, and limit the relevant PCI DSS requirements to 1, 9, and 12. Wow!

The Roadmap lights a pathway on how P2PE might improve a business’s security posture, and suggests that P2PE does indeed provide for reducing the size of the overall compliance effort! As could be expected, the P2PE document mirrors the DSS requirements by including “the people, processes, and technology in place to encrypt and decrypt a transmitted PAN (or sensitive authentication data)”. However, P2PE “must include comprehensive cryptographic and key management systems which limit or prevent the business’s access to “plaintext” of the PAN in transit, processing and storage”. This is a gift: Early encryption creates a broad avenue of opportunity to reduce scope by reconsidering your cardholder data environment and compliance strategy

What the Roadmap doesn’t do is help you find the most cost-effective, efficient route towards shrinking the cardholder data environment and reworking your compliance approach. Securing the PAN in an open retail environment via “sheer muscle” can be a very complicated, expensive process. Some larger businesses have spent millions of dollars to rebuild and lock-down the retail channel. Others invested similar amounts building a parallel infrastructure to segregate PAN data as required by their auditor. Perhaps various vendor elements purchased separately didn’t work well together; successful system integration will be a key success factor in P2PE. None of these approaches is very inviting: expensive to build, and expensive to run, prone to complications. But, if well planned and executed, P2PE doesn’t have to be like that.

So, can we imagine a smarter, PCI DSS compliant, cost-effective, efficient P2PE process, which also shrinks the cardholder data environment (CDE)? Yes!

Consider this scenario: Your business is already PCI DSS compliant: communications with your card processor are encrypted; and you already tokenize the PAN for processing and storage purposes, minimizing scope to the current standards. Perhaps your secure servers are running on site, perhaps they are hosted – that part doesn’t matter.

Your final link in assuring P2PE is encrypting the PAN at the Point of Interaction, in a manner designed to be specifically compatible with your chosen security software solution.

Thus, imagine for moment a PIN pad at the POI, capable of triple DES encryption prior to sending the PAN for tokenization, at a cost of a few hundred dollars per device. Yes, such an option does exist.

This approach aggressively minimizes the opportunities to view the PAN in plaintext and reduces scope. You will have reduced risk, and capped the expense of installing and running your compliance effort.