|
Blogs
A new trend is emerging in the world of credit card security which is often referred to as "Beyond PCI". This new trend is also moving into the SAP market as more and more SAP customer look for solutions to eliminate the entry of RAW credit card numbers completely from their SAP applications in order to remove those applications from scope of a PCI audit. What exactly does "Beyond PCI" mean? Simply put it means doing more than simply meeting the 12 requirements of the PCI DSS standards that all merchants accepting credit cards as a form of payment are required to comply with. And which of those 12 requirements tends to receive the most visibility in an SAP environment? Requirement 3 (Protect stored cardholder data) and Requirement 4 (Encrypt transmission of cardholder data across open, public networks). Recently a trend is emerging among the companies I speak with regarding how to address the PCI DSS requirements in their SAP landscape. Some companies are running only an SAP ERP system, others may also be running SAP CRM or have a Web Store in which customers can place orders. In all cases the company is concerned with how to best address Requirements 3 & 4 regarding secure storage and transmission of cardholder data. And increasingly companies are expressing a desire to prevent entry of RAW credit card numbers and cardholder data into their applications, over their networks and via their hardware. But what exactly constitutes "cardholder data"? To define "cardholder data" let's look at page 4 of the PCI DSS v1.2 requirements dated October 2008. The following table identifies what data constitutes "cardholder data": The footnotes are of particular importance for this discussion - especially footnote #1: Per the table, cardholder data includes:
However, footnote #1 states the following, "PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted." So if you are not storing, processing or transmitting a PAN in your system then PCI DSS is not applicable - but how is that possible? Let's look at a few possible options. The most obvious option would be to stop accepting credit cards as a form of payment. However customer demands for credit cards as a form of payment plus make this impractical. The benefits to the merchant that accepts credit cards, such as lower Days Sales Outsanding, shifting the credit burden/liability to the credit card issuer and a payment guarantee prior to shipment (authorizing the card) make acceptance of credit cards attractive to merchants. Perhaps you could consider outsourcing your sales and/or collections functions to a third-party and let them take on the PCI DSS burden. If your company is not directly receiving credit card numbers from customers and then processing those payments in your systems there would be no need for storage, processing or transmission of that sensitive cardholder data. But of course not every company can, or desires, to outsource that function to someone else. Another option, which will still allow you to take advantage of the payment card processing business logic in your SAP and other applications, is to prevent entry of RAW card numbers into the system through tokenization. In a previous blog I discussed the benefits of tokenization, particularly when outsourcing the tokenization functionalty to an external third-party. If a RAW card number (PAN per the PCI DSS requirements) is never entered into your applications then PCI DSS does not apply even if you are storing a token in place of the PAN and the remaining data elements that constitute cardholder data. One way to tokenize credit card numbers prior to the RAW PAN entering a Merchant environment can be seen in this diagram depicting a tokenization process in an Web Store scenario.
The steps are as follows:
A similar approach can be taken when orders are entered directly in the SAP GUI as is outlined in the following diagram. In this case the steps are as follows (this process flow includes the Settlement as well as Authorization logic):
In both scenarios above the entry of RAW card numbers has been prevented in SAP through the use of Tokenization and Data Intercept technologies. Because a RAW card has not been entered or displayed in SAP the SAP system can be considered out of scope because, per the quote on page 4 of the the PCI DSS v1.2 requirements, "PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted." Eric Bushman is Vice President, Solutions Engineering for Paymetric. |