Configuring cardholder data storage locations

Meet the PCI DSS requirements for cardholder data storage locations and configure the locations correctly.

PCI DSS requirement 1 mandates that cardholder data must not be stored on a server that is connected to the internet.

To comply with this requirement, you must complete the following step:

Place the data storage directories on a separate server computer that is not connected to the internet and in a different network zone. If you want to use a storage area network (SAN) instead, more measures might be needed to achieve PCI DSS compliance. Contact your local Qualified Security Assessor (QSA) for details.

Note:

You must disable the locate commands for the separate server computer. For more information, see Disabling locate for folders.
Changes to the file storage locations are processed after an instance is restarted. Thus, you can move the files while the instance is offline.

Configuration steps

IBM Safer Payments can store cardholder data in a number of locations. To identify and adjust these locations, complete the following steps.

Go to the user interface.
Click the Cluster tab.
Select a cluster instance from the table.
Scroll down to the Storage section.

For each cluster instance, the following directory locations can contain encrypted cardholder data:

Table 1. Default cardholder storage locations
Path name (default)	PAN stored as	PAN contained in
Archive (arc)	encrypted	archived cases
Configuration	encrypted	conditions
Disk data cache (DDC)	encrypted	attributes and indices
Email (eml)	masked, PANs are potentially also encrypted	notifications and case actions
FLI buffer (fli)	encrypted	FLI messages
Investigation (inv)	encrypted	cases
Log (log)	masked	log messages
User (usr)	encrypted	user preferences
Relational database interface (rdi)	masked	DML statements

You can now change the directory locations according to your configuration.
Note: The locations are different for each instance. You must adjust the locations individually for each cluster instance.

Exporting data by using external Python programs

IBM Safer Payments can be configured to feed data to external Python programs, which in turn can store that data on the local or a remote machine. If sensitive data is involved, more measures must be taken to protect that stored data. See Python code execution for details.

Data export jobs

Use the data export jobs to export transaction data to a csv file. For example, you can use it as training data for an external AI model. Because of this use case, data export jobs offer the option to export encrypted data like PANs as clear text, masked, or hashed. See Figure 1 for an example of those settings.

This image is explained in the surrounding text. — Figure 1. Data export options for encrypted attributes

The SHA256 hashing algorithm is used. The job definition includes a salt that is added to the exported values before the hashing algorithm is applied. This salt is usually randomly generated by using the boost library but can also be generated by a user. The salt is stored encrypted on disk and can be viewed only in the user interface if the user has the global privilege to change job definitions. If a user doesn’t have the privilege, the salt is not delivered to the user interface, and the field shows a random value with no meaning.

Whenever sensitive data is exported as clear text, you must make sure that the resulting export file is securely stored according to PCI DSS requirements 3.4.1, 3.5, 3.6, and all applicable subrequirements.

Attention: Users without the global privilege to view unmasked data inside the application can still gain access to such data in clear text by accessing an exported file if that file is not properly protected.

When hashing is used together with masking, you must be aware that an attacker who gains access to the exported file and knowledge of the salt is able to reconstruct the plain text version of this data.

Simulation Query Data Export

Use the simulation query to export transaction data to a .csv file. As with data export jobs, this data might be used to train an external AI model. For data that is encrypted in IBM Safer Payments, it is possible to export the data as clear text, masked, or hashed.

The SHA256 hashing algorithm is used, and as with data export jobs, the salt is usually generated randomly by using the boost library but can also be specified by a user. The salt is stored encrypted on disk and can be accessed in IBM Safer Payments only by users who have the privilege to see unmasked data. You can set this in the user account settings. Users without this privilege can use only reduced simulation query data export options.

When sensitive data is exported as clear text, PCI DSS Requirements 3.4.1, 3.5, 3.6, and all applicable subrequirements mandate that the export file is securely stored.

When hashing is used with masking, be aware that an attacker who gains access to the exported file and knowledge of the salt can reconstruct the plain text version of the data.

Configuration change journal

The configuration change journal is an optional type of log file that can be enabled on Administration > System > Configuration > Misc > Miscellaneous. If enabled, all changes to elements are written in clear-text to a log file.

The purpose of the configuration change journal is to transfer configuration changes from one IBM Safer Payments environment to another. Since the environments do not share encryption contexts, the files are stored as unencrypted. The storage location of configuration change journals is configured for each individual cluster instance on Cluster > System monitoring > Settings. In PCI DSS-compliant deployments, it is a best practice not to enable the configuration change journal. If it is enabled, the storage locations on all instances must be protected according to PCI DSS requirements 3.4.1, 3.5, 3.6, and all applicable subrequirements. If enabled, the PCI DSS compliance report includes a message.