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:

• Primary Account Number (PAN) - the credit card number itself 
• Cardholder Name
• Service Code - (CVV or CID)
• Expiration Date

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 Tokenization as a means of securing credit card numbers 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:

1. The end customer places an order on the Web Store
2. Customer prepares to checkout and make payment
3. The Merchant Web Store calls Data Intercept to begin card number capture process.
4. Data Intercept renders a field on the Merchant Web Store checkout page in which the end customer will enter the credit card number
5. The end customer enters the RAW card number in the Data Intercept hosted field - outside of the Merchant Web Application thus keeping the Web Application out of PCI scope 
6. Data Intercept sends the RAW card number to the be Tokenized (the encrypted string is stored in the Paymetric data vault)
7. Data Intercept receives back a Token
8. The Merchant Web Application receives the Token
9. The Merchant Web Application submits an Authorization Request using the Token in place of the RAW card number
10. The Paymetric service forwards the Authorization request to the Processor
11. The Processor sends the Authorization Request to the bank which issued the card
12. The Issuing Bank returns the Authorization Response to the Processor
13. The Processor returns the Authorization Response to Paymetric service
14. The Paymetric service sends the Authorization Response (with Token) to the Merchant Web Application
15. The end customer is shown an Authorization Response and the checkout is complete

1. The end customer calls the Merchant call center to place an order
2. The Customer Service agent opens up a Data Intercept Web Page hosted by Paymetric and enters the RAW card number thus preventing SAP from being exposed to a RAW card number
3. Data Intercept sends the RAW card number to the be Tokenized (the encrypted string is stored in the Paymetric data vault)
4. Data Intercept receives back a Token and the Customer Service agent copies the Token and Pastes it in the SAP Order in the Payment Card Number field
5. During Order Save SAP requests an Authorization and sends the Token to the Paymetric CA-PCI RFC adapter in place of a RAW card number
6. The Paymetric CA-PCI RFC adapter converts the Authorization Request to a Web Service call and forwards it to the Paymetric service
7. The Paymetric service forwards the Authorization request to the Processor
8. The Processor sends the Authorization Request to the bank which issued the card
9. The Issuing Bank returns the Authorization Response to the Processor
10. The Processor returns the Authorization Response to Paymetric service
11. The Paymetric service sends the Authorization Response (with Token) to the Paymetric CA-PCI RFC adapter
12. The Paymetric CA-PCI RFC adapter sends the Authorization Response (with Token) to the SAP Order and the Order is saved
13. The Order is delivered
14. The Delivery is Billed and the Authorization Response details (with Token) are copied from the Sales Order to the Invoice
15. The Invoice is posted to Accounting and the Authorization Response details (with Token) are copied from the Invoice to the Accounting Document
16. The Settlement process is executed (typically as a nightly, scheduled job)
17. A Settlement Clearing Document is posted to Accounting as a result of the Settlement process
18. The Authorization Response details (with Token) of each item in the Settlement Batch are read from the corresponding Accounting Document and sent to the Paymetric CA-PCI RFC adapter
19. The Paymetric CA-PCI RFC adapter converts the call to a Web Service call and sends the Settlement Batch details (with Token) to the Paymetric service
20. The Paymetric service responds to the Paymetric CA-PCI RFC adapter (with Token) that the Settlement Batch has been received
21. The Paymetric CA-PCI RFC adapter responds to SAP (with Token) that the Settlement Batch has been received by the Paymetric service
22. The Paymetric service sends the Settlement Batch details to the Processor
23. The Processor sends each transaction from the Settlement Batch to the corresponding Issuing Bank
24. The Issuing Banks respond to the Processor with notification of processing of funds
25. The Processor initiates the Settlement Batch deposit at the Merchant Depository Bank
26. The Merchant Depository Bank notifies the Merchant that a deposit has been made and a Manual Settlement Reconciliation is performed in SAP

My previous blog post titled Securing credit card account numbers in SAP focused on implementing functionality provided by SAP for encrypting credit card numbers stored in the SAP ERP database.  In an update I also included a brief reference to encryption functionality in the SAP CRM database.  FAQ OSS notes mentioned in the post provide the necessary information to implement the SAP standard encryption functionality and thus secure the payment card and credit card numbers stored in your SAP applications.

At the end of the post I mentioned several items that you should be aware of when implementing the standard SAP functionality which may prevent compliance with PCI DSS requirements.  I then alluded to Tokenization as a means of addressing the additional items.  In this post I want to explore the differences between SAP's standard encryption offerings in each application and tokenization as an application independent encryption approach.

Many applications provide encryption functionality which is specific to that particular product.  SAP's encryption offering for credit card numbers in the SAP ERP and CRM applications is one such example.  The encryption functionality is designed to work only with that application - specifically by encrypting the credit card number data stored in the database.  Should data need to be passed between applications, such as order data being replicated from the SAP ERP to SAP CRM system, the data must be decrypted in the source application passed in an unencrypted form (and therefore potentially logged in an unencrypted format) and finally encrypted in the target application.  Using this application specific encryption approach has the following weaknesses:

• Encryption solutions on each application must be setup, maintained and managed
• Encryption keys in each solution must be managed independent of other solutions
• Encryption keys must be rotated independently of other solutions
• Increased number of encryption solutions require additional IT staff time for management and maintenance
• Disparate encryption solutions increase security risks if maintenance is not always kept current
• Encrypted data must first be decrypted before being passed to other applications and then re-encrypted before being stored by the target application

A typical enterprise with an SAP system, a web store and a payment application each storing encrypted credit card data locally using application specific encryption applications would have an architecture which look like this:

Implementing a solution which Centralizes and Tokenizes the credit card number data in a secure data vault would change the architecture to look like the following:

This solution would extract the unencrypted card numbers from the various applications, consolidate the application specific encryption functionality into a single, central solution and would simplify key management and key rotation functions.  Centralization and Tokenization would specifically help address the following PCI DSS requirements:

Additional advantages to this approach would include the following:

• One centralized storage location of all encrypted credit card number data
• All applications would store tokens at the database level rather than unencrypted or encrypted card numbers - Security At Rest
• All application interfaces could pass tokens rather than encrypted or unencrypted card numbers - Security In Transport
• Rotation of encryption keys would be performed centrally and would be transparent to other applications as the tokens would remain unaffected
• Centralized logs can be kept of all decryption attempts from all source systems thereby providing a valuable audit trail
• If an external, third-party solution is used the risk of data loss in a breach of internal systems is greatly diminished - only tokens would compromised, not the encrypted data or encrypted keys

Finally, let's take a look at how the workflow of processing of a credit card authorization would look in an enterprise using SAP along with a Centralization and Tokenization solution:

As enumerated above, there are clearly many advantages and benefits to using a token-based solution for securing credit card details not only in SAP by across the enterprise.  The token-based approach is currently not supported by standard SAP functionality, but is supported by solutions from third-parties like Paymetric. 

As scrutiny increases surrounding how companies are securing sensitive customer data, such as credit card numbers, serious consideration should be made of token-based solutions.  Merchants who choose to outsource the storage of this sensitive data have less risk of embarrassing data loss in the event of a system breach as only tokens would be stored locally.  All encrypted data and keys would be stored by the external solution this greatly diminishing a Merchant's exposure and potential public relations nightmare.