X-Payments:PA-DSS implementation guide for X-Cart Payments 3
Contents
Introduction
The purpose of this PA-DSS Implementation Guide is to inform employees of organizations using the X-Payments payment application by Qualiteam Software Limited about the methods and means of protection of account data in the X-Payments software.
The methods include the need for compliance with the information security standards in the payment card industry developed by the international payment systems Visa and MasterCard – Payment Card Industry Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA-DSS). For additional information about PCI DSS, please visit the Official PCI Security Standards Council Site.
The document provides instructions on how to implement the application in a PCI DSS compliant manner.
Full product name – X-Payments.
Product version – 3.0.х.
Any servers used to run the X-Payments payment application must be configured according to this PA-DSS Implementation Guide.
This PA-DSS Implementation Guide should be updated:
- at least annually;
- after changes in the payment application (if required);
- after changes in the PCI DSS and PA-DSS standards.
The updated Version of the PA-DSS Implementation Guide has to be sent to all the merchants using X-Payments.
The history of changes to the X-Payments PA-DSS Implementation Guide is provided in the table below.
Table.1. X-Payments PA-DSS Implementation Guide history of changes
| Author | Date | Number | Change description |
|---|---|---|---|
| 05/17/2016 | 01 | The original version of the document, designed to meet the requirements of PCI DSS version 3.1 and PA DSS version 3.1 |
Data protection
The PCI DSS and PA-DSS standards prohibit storage of sensitive authentication data (after authorization) or cardholder data in cleartext.
Cardholder data includes:
- Primary Account Number (PAN)
- Cardholder Name
- Expiration Date
- Service Code
Sensitive authentication data (SAD) includes:
- Full track data (magnetic-stripe data or equivalent on a chip)
- CAV2/CVC2/CVV2/CID
- PINs/PIN blocks
X-Payments has the ability to store parts of cardholder data temporarily to perform 3D Secure verification and certain types of transactions for some of the integrated payment processors. During storage, cardholder data is encrypted using RSA 2056 algorithm and AES 256 for key encryption. When its storage period is over, the data is removed automatically via "cron" software that needs to be installed and configured to run X-Payments periodic tasks.
X-Payments may not be configured to store permanently in the database the following types of data:
- Full PAN
- Full track data (magnetic-stripe data or equivalent on a chip)
- CAV2/CVC2/CVV2/CID
- PINs/PIN blocks
Merchants and/or developers implementing X-Payments should not attempt to customize this as a feature.
The payment application masks PAN on display (except for the moment when the user enters the card number).
X-Payments can display masked PAN on the "Payment details" pages and in the "View details" pop-up windows for some of the integrated payment processors in the following format: 123456******1234 MM/YY or **********1234 MM/YY. X-Payments does not have the ability to display full PAN anywhere, and there are no settings that can change this behavior of the user interface.
Data Collected while Testing
Delete any sensitive authentication data (pre-authorization) gathered as a result of testing or troubleshooting your X-Cart Payments:
- Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem. You should never use real credit card information when testing your store. Instead, contact your payment gateway and ask them for special credit card numbers that you can use while testing.
- If you ever choose to collect credit card information to troubleshoot a problem that a customer of yours is having, then please note the following:
- Such data must be stored only in specific, known locations with limited access.
- Only collect a limited amount of data (no more than is needed to solve the problem).
- Sensitive authentication data must be encrypted during storage. Make sure to encrypt it before storing it. There are many encryption software packages that you can install on your computer to do so.
- Sensitive authentication data must be securely deleted immediately after use.
To prevent uncontrolled storage of cardholder data (for example, in case of operating system failure), it is recommended to disable the swap file or move it to a specially prepared encrypted partition.
Authentication and access
The X-Payments payment application has an only user type. This type cannot get access to payment card numbers and does not have any administrative privileges that may affect PA-DSS compliance. There are no built-in/default user accounts in X-Payments. You must carefully control access to X-Payments. Follow these rules:
- Restrict the number of employees who have access to X-Payments to only those who have a business need.
- Always provide unique usernames for each person who needs access.
- Do not use system-default usernames and/or passwords.
- Ensure that web server is run under a non-privileged user account and the application has access to the database from a limited privilege user account.
- Ensure that user accounts inactive for more than 3 days are blocked, and password lifetime is set to 30 days.
To set password lifetime:
- Log in to X-Cart Payments.
- Go to Settings -> General Settings.
- In the "User account password lifetime" field, enter the number of days for which the user account password needs to be valid. The maximum allowed password lifetime is 90 days.
The following related rules apply:
- The minimum password length is 8 characters.
- A password must contain both numbers and lower- and uppercase characters.
- The last 4 passwords must be unique.
- A user account must be blocked for a specified period (30 minutes by default) after 6 unsuccessful attempts to enter a password.
- A user is logged off after an inactivity period of 10 minutes.
PCI compliance requires that you use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data. This means that you should use different user names/passwords:
- For your Web hosting account administration area (Web hosting account where your online store is hosted);
- For FTP access to the Web server;
- For Remote Desktop Connection to the Web server (if available);
- To connect to the MySQL server that contains your store data.
Linux authentication mechanism is used for login in the servers with running X-Payments.
Accounts for access to the operating system are managed by the Linux administrator.
For Linux operating system accounts, you must configure the following attributes of the password policy:
- use personal accounts, do not use any group, shared, or generic accounts and passwords;
- changes to user passwords at least once every 90 days;
- require a minimum length of at least seven characters;
- contain both numeric and alphabetic characters;
- do not use last four passwords used previously;
- block account after six invalid logon attempts (minimum 30 minutes or until an administrator enables the user ID).
Two-factor authentication must be used for remote access to the operating system. The authentication methods, also known as factors, are:
- something you know, such as a password or a passphrase;
- something you have, such as a token device or a smart card;
- something you are, such as a biometric.
Logging
Audit trails are automatically enabled with the default installation of X-Payments. Users do not have the ability to disable or change the logging parameters of X-Payments. X-Payments log journal does not contain cardholder data. It is implemented at the source code level. The setting of an event log journal does not require any additional action from users. The log files are created in the var/log/ directory. Make sure you restrict access to the log files by business need-to-know. The following types of activity are logged:
- All actions taken by any individual with root or administrative privileges.
- Successes and failures of all individual accesses to application sections and functions.
- Initialization of the audit logs.
- User sign in and sign out.
Individual access to cardholder data is not logged, because cardholder data is not stored before and after authentication. Access to audit trails must be provided on the operating system level. Audit trails are written to the file system, to the files access.log and error.log.
Each log event includes:
- Type of event;
- Date and time of event;
- Username and IP address;
- Success or failure indication;
- Action which led to the event;
- Component which led to the event.
There is also a meta-log which contains information about other log files being created.
Make sure you have a system-level auditing software properly configured to monitor users' activity on the server. This software should:
- warn on a checksum change of any of X-Cart Payments source code files except for the log file and the database files;
- record any file writing operations related to X-Cart Payments files.
Communication
LAN channel or other available connection method can be used as a communication channel. X-Payments payment application supports the following data formats:
| Protocol | HTTP protocol (RFC 2616: HTTP/1.1) is used for data transfer between client and server |
| Data transmission method | Only encrypted cardholder data (RSA 2048 and AES 256) are transferred. RAW POST method is used for data transmission – (data stream is transmitted in the body of the request that is sent from client to server) |
| Data format | Data are transmitted in XML format (Extensible Markup Language (XML) 1.0) |
| Port | Payment application X-Payments uses 80, 123, 443 ports |
See also
|
