Show TOC

Using SAP PI in PCI-Compliant ScenariosLocate this document in the navigation structure

Use

This sections provides information on using SAP PI to implement scenarios that comply with the Payment Card Industry Data Security Standard (PCI-DSS, shortly referred to as PCI ) as documented under http://www.pcisecuritystandards.orgInformation published on non-SAP site.

SAP PI allows you to encrypt the payload and attachments of messages (shortly referred to as message content ) on data base level, which means: to store message content encrypted.

More information: Encrypting Message Content on Database Level

SAP PI provides the technical capabilities to comply with the PCI standard. However in the current, first implementation of the standard, the requirements are not always met in the most convenient way. For example, missing capabilities to mask of Primary Account Number (see table below) needs to be compensated by preventing payload display.

The following table lists in how far several requirements of the PCI standard are met by the PI encryption capabilities and which limitations exist with regard to the standard:

PCI Requirement - Short Description

PCI Requirement

SAP PI Approach and Limitations

Mask Primary Account Number (PAN) when displayed.

3.3

“Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).”

“This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN. ”

“This requirement does not supersede stricter requirements in place for displays of cardholder data-for example, for point-of-sale (POS) receipts.”

PI customers are advised to prevent payload monitoring for payment scenarios, as it is common practice for scenario that involve exchange of sensitive data.

Payload monitoring can be restricted by applying special authorizations.

More information:

Store PAN always encrypted.

3.4

“Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:”

  • “One-way hashes based on strong cryptography (hash must be of the entire PAN)”

  • “Truncation (hashing cannot be used to replace the truncated segment of PAN)”

  • “Index tokens and pads (pads must be securely stored)”

  • “Strong cryptography with associated key-management processes and procedures”

When you activate message encryption on database level, the entire payload containing the PAN (and any attachments) is stored encrypted.

However, PI components access the message in clear text (for example, in monitoring).

Allow to retire or replace encryption key in case the integrity of the key has been weakened.

3.6.5

“Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key), or keys are suspected of being compromised.”

In case a key has been compromised, the administrator can find out if the key is still in use for message encryption.

  • For encryption in the AAE message store:

    Open the corresponding page of the Messaging System under http://<host>:<httpport>/MessagingSystem (choose Persistence-Layer Encryption Monitor ).

  • For encryption in the IE message store:

    Run report RSXMB_CHECK_ENCKEY_USAGE.

Based on the result of this evaluation, the administrator has to either cancel or deliver messages that are still stored encrypted with the compromised key.

Log all individual access to PAN.

10.2

“Implement automated audit trails for all system components to reconstruct the following events:”

“10.2.1 All individual accesses to cardholder data”

All access to message content is logged in the security audit log of the underlying Application Server.

More information:
Note

The numbers and quotations in column PCI Requirement refer to the specification of the PCI standard at http://www.pcisecuritystandards.orgInformation published on non-SAP site.