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.
1 Comment
