As data thieves become more sophisticated and networks grow more complex, organizations managing sensitive payment card information are feeling increased pressure to better secure the data they store. High-profile thefts of card data from a range of retailers and processors have raised awareness and created a sense of urgency for more stringent data security.

Payment Card Industry (PCI) standards, which apply to store merchants, banks, service providers, and card processors, aim to reduce the risk of a security threat by mandating the proper use of firewalls, message encryption, computer access controls, and antivirus software. They also require frequent security audits and network monitoring, and forbid the use of default passwords.

Companies processing more than 20,000 transactions annually are required to scan their networks quarterly and conduct annual audits of their Payment Card Industry Data Security Standard (PCI DSS) compliance. The mandate applies to hundreds of thousands of organizations around the world, and complying with the standard is no simple task. The card issuers have made it clear that failure to comply with PCI’s detailed technical requirements can result (and have resulted) in substantial penalties, including fines.

The PCI DSS requirements consist of 12 specific points related to building secure networks and protecting cardholder information. Addressing these requirements not only protects businesses and merchants from cardholder fraud but also satisfies a broader mandate for information protection and security. Stakeholders in the process commonly include the CFO, CIO, the treasury and sales departments, and the Basis and IT teams. Cooperation among these entities is essential to achieving successful compliance.

In this article, I focus on SAP-specific issues surrounding two of the 12 requirements, which are listed in the sidebar, “12 Requirements of PCI DSS”: Requirement 3, which addresses the protection of stored data; and Requirement 7, which sets forth restrictions on accessing data on a need-to-know basis.

Encryption Makes Data Unreadable and Unusable

Requirement 3 of the PCI DSS document, “Protect Stored Cardholder Data,” notes how critical encryption is to cardholder data protection because it makes the data unreadable and unusable to potential intruders.

For mySAP ERP users, this requirement makes it imperative that any card data residing on a database in SAP’s products be encrypted. SAP’s ERP encryption logic offers a starting point for the process. SAP Note 766703 answers frequently asked questions about credit card number encryption logic.

First, access the SAP Cryptographic Software downloads from the SAP Service Portal at https://webmp209.sap-ag.de/swdc. From the list download the SAP Cryptographic Library file relevant to your organization’s operating system.

To access the encryption maintenance view within your SAP system, use transaction SM30 (Figure 1).

Figure 1

Table maintenance view to enable credit card encryption per card type

SAP hasn’t added access via the IMG yet, so for now this is the only way. Click on the Maintain button in Figure 1 and the screen shown in Figure 2 appears. In Figure 2, you can enable the encryption for each card type by checking the check box under the Encrypted column next to whichever card you wish to enable. In this instance, I enabled all card types except Visa for SAP encryption.

Figure 2

Credit card types enabled for SAP encryption functionality

Figure 3 shows the SSFA (secure, store, and forward application) transaction maintenance view, in which you can see the configuration parameters required to enable the encryption of payment cards in the R/3 application.

Figure 3

Transaction SSFA — setup of Personal Security Environment (PSE) files and enablement of Secure, Store, and Forward (SSF) functionality for encryption of card numbers

Of particular interest in this view are the .pse entries next to Priv. add. book (private address book) and SSF profile. These are the files that contain the encryption keys, and this is where SAP’s encryption functionality reaches a dead end for payment card management. Originally designed to secure communications between two systems, SAP’s SSFA function provides no access to the encryption keys. SAP generates the keys but provides no key management utilities. This inability to access encryption keys makes it impossible for merchants with high transactional volume to fulfill the PCI DSS requirement that they periodically change their encryption keys. I’ll discuss workaround options later in this article.

Encrypted Data Access Defined by “Need to Know”

Requirement 7 of PCI DSS, “Restrict access to cardholder data by business need-to-know,” is designed to ensure that only authorized personnel can access critical data. Fulfilling this requirement within SAP requires close review and scrutiny of how each user security profile is set up in the enterprise.

In an SAP application, access to system functionality is controlled through a complex array of authorization objects. A Basis or security resource usually sets up security in the system to define a user’s level of access to reports and ability to execute certain updates. Successful execution of PCI DSS requirements calls for a multi-layered approach that restricts access and limits views of the card number on a need-to-know basis.

It’s important to note that giving any user an SAP_ALL profile represents significant control risks and undermines the validity of the security initiative. Best practices dictate that there be only one user ID established with this profile, and it should be highly controlled and used only for emergency purposes.

In addition to super-user security profiles such as SAP_ALL, companies need to tightly manage other composite security profiles that contain multiple authority objects. These authorization objects are often assigned to user profiles in the production environment and often lack close control.

Note
SAP security documentation states that the SAP_ALL composite profile contains all SAP authorizations, thereby allowing a user with the SAP_ALL profile to perform all tasks in the SAP system. SAP further recommends that this authorization profile not be assigned to any users. Rather, you should maintain a single emergency user ID with the SAP_ALL profile, and use it judiciously in extreme circumstances.

You can find more information regarding SAP’s recommendations concerning use of the SAP_ALL composite profile at https://help.sap.com/saphelp_nw04s/helpdata/en/78/7a553efd234644e10000000a114084/content.htm.

SAP Encryption in Practice

Let’s look at how authorization affects a user’s ability to view decrypted card numbers in various SAP screens. Figure 4 provides a view of the customer master payment card screen, which displays decrypted card numbers. The system automatically grants individuals with access to view or maintain information (via security objects F_KNA1_APP, F_KNA1_GEN, and F_KNA1_GRP) on the customer master payment card screen the authority to view decrypted card numbers on this screen.

Figure 4

Card numbers not encrypted on the customer master change view because the user has the authority to decrypt

In contrast, when viewing the pop-up screen from the card number field pull-down on the order create screen (Figure 5), the system always masks the card numbers, with no option to decrypt them. SAP provides no security object to determine if the user does or does not have the authority to view decrypted card numbers. The only relevant object is V_VBAK_AAT, which determines if a user has the authority to display or view the payment card details on the order. Also note that the Visa card number is not configured in Figure 4 for encryption; therefore, the card number is not shown encrypted in Figure 5.

Figure 5

View of cards on customer master record from order create mode

On the sales order payment card header screen (Figure 6), you can see the most recent authorization request and response, still only viewing the masked card numbers.

Figure 6

Encrypted card numbers in the payment card header screen of sales order in change mode

You can find that same information on the invoice payment header screen (Figure 7), with no object access authority to view a decrypted card number.

Figure 7

Encrypted credit card information on the invoice payment card header screen

In the accounting document detail (Figure 8), you can see that the user has security object authority to view the decrypted card number.

Figure 8

Unencrypted credit card data on accounting document detail screen due to user having authority

This is the only document screen where SAP has added security authority object checking capabilities, via authority object F_BKPF_BUK (Figure 9), for viewing decrypted card numbers.

Figure 9

SAP security object for decryption of credit card numbers (activity C4)

Figure 9 provides a view of the SAP security object, which allows for decryption of card numbers on accounting documents. The long list of activities available for security object F_BKPF_BUK helps illustrate the importance of specifying only certain activities for individual users. You should assign individual activities rather than simply assigning a value of *, thereby granting permission for decryption of card numbers, intentionally or unintentionally. Figure 10 shows the database table SAP uses to store encrypted credit card data. The CCARD_GUID field shown in table CCARDEC is the key field link to tables BSEGC, FPLTC, VCKUN, and VCNUM, where SAP stores card number data in relation to accounting documents, orders, invoices, and customer master records.

Figure 10

View of entries in table CCARDEC — SAP encrypted card numbers. Masked card numbers are shown.

SAP Encryption Limitations

Organizations attempting to achieve PCI DSS compliance within their SAP enterprise inevitably discover that they need to use custom programs or third-party tools for some procedures. A custom program would be any report or utility that you would write to view or manipulate credit card data, either in standard SAP tables or custom tables. For example, I could create a custom table to store credit card information on a customer’s master record together with a flag to indicate what types of orders it should be allowed to be used on. The custom program would read credit card numbers from the database and display them.

Because SAP originally designed SSFA to secure communications between only two systems, the SSFA function provides no key management capabilities. This makes the task of fulfilling the PCI DSS requirement to periodically change encryption keys exceptionally difficult, since administrators must bring the system to a standstill as they decrypt or encrypt data.

With only three algorithms available in the SAP solution, the selection is limited, and the algorithms may not meet the PCI DSS definition of strong cryptography due to the inability to verify the actual algorithm being utilized. SAP’s offering supports only a software-based encryption solution, offering no possibility to use hardware-based encryption components.

Another consideration is that SAP’s encryption secures payment card number data in only four tables: Two tables related to storage of card numbers on customer master records, VCKUN and VCNUM; a third table related to storage of card numbers on sales orders and invoices, FPLTC; and a fourth table related to storage of card numbers on accounting documents, BSEGC. This targeted coverage in only four tables leaves card number data in other standard SAP tables and in custom tables unencrypted and exposed.

Implementing Encryption Functionality

Robust encryption functionality is essential for organizations with high transactional volume to achieve PCI DSS compliance. Organizations with an SAP ERP system must opt for either a custom or third-party solution to satisfy PCI requirements.

Ideally, the solution would run external to SAP, allowing for key management and facilitating zero or near-zero downtime for key changes. The solution shouldn’t be tied to fields and specific tables. Instead, it should apply to the credit card domain at a fundamental level, affecting card number data in any standard or custom table.