You may have heard about or read the following stories in the news recently: - A major retailer's systems are infiltrated by hackers in a parking lot taking advantage of security weaknesses in corporate Wi-Fi networks and credit card data is compromised
- Laptops containing records of credit card numbers, sensitive HR data or personal medical records have gone missing or have been stolen
- Disgruntled employees caught downloading databases of payment information (including credit card details) and selling the information through internet black market channels
While stories like these are likely to continue to periodically appear, there are steps which you can take in your SAP systems to protect your customer's sensitive data and mitigate your liability in the event a breach should occur.
Many of SAP's products contain business logic for processing payment cards. Each of these products stores a record of the credit card data used to process the authorization requests and also the details of the authorization response. This information, stored in the database of the SAP products, should be secured through some means of encryption or tokenization to prevent unauthorized users from gaining access to unencrypted credit card details.
A good first place to start is with the encryption logic offered by SAP in each product. In the R/3 system a good place to start learning about the credit card encryption functionality is OSS note 766703. This note is an FAQ describing the functionality provided natively by SAP for securing credit card numbers and is applicable for versions 4.6C, 4.7, ECC 5.0 and ECC 6.0. For SAP ERP 6.0 specifically, note number 1032588 describes additional functionality provided in this release related to masking of card numbers, security objects for viewing decrypted card numbers, logs of decryption events, migration and conversion programs for existing unencrypted credit card account numbers stored in various database tables, etc.
Application of these notes (and the additional notes referenced in 766703 and 1032588) and the setup of the appropriate SAPCRYPTOLIB security library as described in OSS note 662340 will allow you to activate the standard SAP functionality for securing credit card account numbers in R/3 or SAP ERP 6.0. The following functionality will then be active:
- Ability to generate .pse (Personal Security Environment) files containing encryption keys with the SAPCRYPTOLIB security library.
- Encryption, during Order Save, of credit card account numbers stored in table FPLTC and related to Authorization REQUEST and RESPONSE lines.
- Encryption, during Accounting Document Save, of credit card account numbers stored in table BSEGCC and related to Authorization RESPONSE lines used for billing, copied to Accounting and staged for Settlement processing.
- Encryption, during Customer Master Save, of credit card account numbers stored in tables VCKUN and VCNUM in relation to the Customer Master record.
- Storage of the encryption strings representing the credit card account numbers in SAP table CCARDEC. NOTE: There will be 2 records added to table CCARDEC for each corresponding record in FPLTC, BSEGC, VCKUN or VCNUM.
- Addition of Security Activities to various Security Objects used to control decryption of credit card account numbers while viewing payment information on Invoices, Accounting documents, Customer Master Records, etc. See OSS notes previous referenced for exact details.
Implementation of these OSS notes and encryption functionality available in standard SAP will provide a merchant protection for credit card account information stored within the SAP database. However, a merchant should also be aware of the following: - The .pse ((Personal Security Environment) files need to be copied across all Application Servers and are accessible to anyone with access to the file system of the Application Servers.
- The additional encryption string data stored in the CCARDEC table adds a significant amount of data to the SAP database and must be accounted for when sizing storage requirements.
- Encrypted credit card account numbers must be decrypted prior to and Authorization Request, Settlement submission or replication of Order or Customer Master Data to a CRM system.
- For key rotation activities, SAP's current conversion programs require full decryption of all encrypted records prior to generation of new .pse files and subsequent re-encryption of all records. This will require a maintenance window of perhaps several hours during which no Order Processing, Billing or Settlement submission activities should take place to avoid any decryption errors.
- If Process Integration (PI) is used as a middleware for Payment Card Processing then the PI logs may be capturing unencrypted credit card account numbers in violation of the PCI-DSS rules.
Can these additional issues be overcome as well? Yes!
The next blog entry will discuss the concept of Tokenization of credit card account numbers and the advantages of Tokenization over the encryption logic currently available in standard SAP business logic.
Now you can read that blog entry Tokenization as a means of securing credit card numbers.
UPDATE: 18 November 2008
I've received several emails asking about encryption of payment card numbers in SAP CRM. Rather than address that in a new blog posting, I'll just add here that OSS Note 1034482 is an FAQ for implementing encryption in SAP CRM. OSS Note 662340 is also relevant for SAP CRM.
