PCI PA-DSS Training for 4D Payments’ Customers, Integrators, and Resellers
IMPORTANT: 4D Payments Gateway/SDK is a middleware that facilitates the building of payment applications. It is your responsibility to build your application in compliance with PA-DSS requirements and security standards as well as ensure that the integrators and resellers of your application are properly trained to implement your application in a PCI DSS compliant environment and on a PCI DSS compliant way. As such, you are required to provide your own training materials and implementation guide to your integrators and resellers. This training document as well as the implementation guide for the 4D Payments Gateway/SDK are provided as a courtesy to you but you cannot distribute them to your customers, integrators, or resellers.
What is a Payment Application?
A payment application is any software application that facilitates the processing of a payment transaction including credit card transactions, debit card transactions, gift card transactions etc.
What is PCI PA-DSS?
PCI Security Standards Council is a global open body formed to develop, enhance, disseminate and assist with the understanding of security standards for payment account security.
PA-DSS stands for Payment Application Data Security Standard and refers to the requirements and security assessment procedures that PCI has defined for software vendors and payment applications.
Is your Payment Application in-scope of PCI-DSS?
PCI Security Standards Council provides a specific document called “Guidance for PCI DSS Scoping and Network Segmentation” which you can find at this location: https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf and that can help determine whether your application is within scope or not. However, there are two simple rules that can help you decide without having to go through all the details:
- If at any point your payment application collects, stores, or transmits cardholder data and/or sensitive authentication data then your application is in-scope.
- If in doubt always assume that your application is in-scope.
Does 4D Payments’ PA-DSS certification cover your application?
The fact that 4D Payments Gateway has obtained the PA-DSS certificate simply guarantees that the 4D Payments Gateway complies with the requirements and security standards established by PCI Security Standards Council but in no way does it imply that your application complies with those same requirements and security standards. You will have to obtain your own PA-DSS certification for your application, listing our application as a dependency.
If I have to get my own PA-DSS certification why do I care if 4D Payments is certified or not?
The simple answer is that it reduces the scope of your application since a good portion of it is already certified so it should make your certification process easier.
Does PA-DSS compliance imply PCI DSS compliance?
No. in order for your entity to be PCI DSS compliant your PA-DSS compliant application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide provided by the payment application vendor.
How do I implement the application in a PCI DSS compliant way?
4D Payments Gateway/SDK do not store any cardholder data and therefore there are no specific instructions on how to delete such data. However, if your application that is build utilizing 4D Payments Gateway/SDK does store cardholder data you must ensure that the cardholder data that exceeds the customer-defined retention period is securely deleted. You must also provide guidance to your own customers as to the requirement to delete such data as well as how to delete the data.
4D Payments Gateway/SDK do not store account numbers (PAN) and therefore there are no specific instructions on rendering the PAN unreadable or masking it. However, if your application that is build utilizing 4D Payments Gateway/SDK does store PAN data you must provide instructions to your customers for masking PAN so that personnel that has no need to see the full PAN cannot see it. Furthermore, you must provide instructions to your customers for rendering PAN unreadable anywhere it is stored or output by your application.
Storing Cardholder Data
4D Payments Gateway/SDK do not store any cardholder data and therefore there are no specific instructions regarding storing such data. However, if your application that is build utilizing 4D Payments Gateway/SDK does store cardholder data you must not require that cardholder data be stored in the DMZ or in Internet-accessible systems.
Keys that protect cardholder data
4D Payments Gateway/SDK do not store any cardholder data and therefore there are no specific instructions regarding those keys. However, if your application that is build utilizing 4D Payments Gateway/SDK does store cardholder data you must provide guidance to your customers that keys used to secure cardholder data should be stored securely in the fewest possible locations and access to keys must be restricted to the fewest possible custodians.
4D Payments Gateway/SDK do not store any cardholder data and therefore there are no specific instructions regarding those keys. However, if your application that is build utilizing 4D Payments Gateway/SDK does store cardholder data you must provide specific instructions to your customers regarding the implementation of a key-management processes and procedures as well as instructions on implementing secure key-management functions including:
- The encryption algorithm used must be an industry recognized algorithm (proprietary in-house algorithms are not allowed).
- Generation of strong keys (minimum 128-bit key length)
- Secure key distribution
- Secure key storage
- Periodic changing of keys (as deemed necessary, but at least annually)
- Destruction of old keys
- Replacement of known or suspected compromised keys
- Revocation of old or invalid keys
- Split knowledge and establishment of dual control of keys so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key
- Prevention of unauthorized substitution of keys
- Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.
4D Payments Gateway/SDK do not store any cardholder data and therefore there are no specific instructions regarding those keys. However, if your application that is build utilizing 4D Payments Gateway/SDK does store cardholder data you must provide tools and/or procedures to securely remove cryptographic key material or cryptograms stored by the application and provide tools and procedures for re-encrypting historic data with new keys.
4D Payments Gateway does not provide any account management or authentication options. This application does not use any accounts. If your application allows authentication and provides accounts, you must use unique user IDs and secure authentication for administrative access and access to cardholder data. Secure authentication should be assigned to any default account, even if they are not used. Default accounts should be disabled and should not be used. Access to PCs, servers, and databases with payment applications must also be secured. Access to PCs, servers, and databases with payment applications must be secured by the completion of installation and for any changes after installation.
The only authentication form used by the 4D Payments Gateway is in the form of API Keys for specific authorized users. API Keys are used to authenticate requests to 4D Payments Gateway. They must be securely stored and not shared. A new API Key can be added by clicking in the Add button under the Authentication tab. This will open a window that allows the user to generate an API key and provide a name for the key. The API keys can be deleted by clicking in the Delete button under the same Authentication tab. The API Key is used identify all the requests sent to the 4D Payments Gateway by the authenticated and authorized users.
The following guidelines must be adhered to regarding the User IDs and secure authentication:
All users must be assigned a unique ID before being allowed to access the system components or cardholder data.
- At least one of the following methods must be used to authenticate all users.
- Something you know, such as a passphrase.
- Something you have, such as a token device or smart card.
- Something you are, such as a biometric.
- The application must not require or use any group, shared, or generic accounts and passwords.
- The application must require changes to user passwords at least every 90 days.
- The application must require a minimum password length of at least seven characters.
- The application must require that passwords contain both numeric and alphabetic characters.
- The application must keep password history and requires that any new password is different than any of the last four passwords used.
- The application limits repeated access attempts by locking out the user account after not more than six logon attempts.
- The application must set the lockout duration to a minimum of 30 minutes or until the administrator enabled the user ID.
- If an existing session has been idle for more than 15 minutes, the application must require the user to re-authenticate to re-activate the session.
Following is a description of our application versioning methodology however, it is critical to note that since our application will be part of your application you must document and implement your own application versioning methodology following the procedures in the PA-DSS Program Guide as well as have procedures in place to verify which version of the payment application are your customers using and ensure that validated versions are in use.
4D Payments Gateway/SDK version numbering is done based on the following methodology:
- The version numbers assigned have the format N.x.y where the first part “N” is a number that represents the major version, the “x” wildcard separated from the first number with a period is a number that represents a minor version, and the wildcard “y” is a number that represents the build number. So a full build number will look like 7.0.5123
- The major version number is incremented periodically when there is a justifiable need based on new major features that will involve API changes such as adding support for a new processor etc. Any change to the application that has an impact on security and / or PA-DSS requirements will result in incrementing of the major version number.
- The minor version (the wildcard x) is incremented periodically at the discretion of the product managers when there is a change that does not affect the core functionality or the API but may add functionality that is not justifiable as a new major version. Changes that have an impact on the functionality of the application but do not impact security or any of the PA-DSS requirements may result in incrementing the minor version number.
- The build number (the wildcard y) is incremented each day, so each build number corresponds to a particular day. Changes that have no impact on the functionality of the application or its dependencies will always result in incrementing of the build build number.
- The published external version number may use the year (yyyy) as the major version number. So major internal version 7 may correspond to major published version 2016. The mapping between internal version numbers and published external version numbers will be maintained at this location: http://4dpayments.com/version-mapping
Audit Trails and Logging
The 4D Payments Gateway logs information about the received request in the Status window of the gateway UI. Additionally, the gateway enables users to select the option of writing the logs in a file of their choice. You are able to select the log mode and other settings in the Logging Options menu under the Settings Tab.
It is your responsibility to implement logging in your application to meet the requirements for PA-DSS validation. You must implement and maintain automated audit trails. Automated audit trails must be implemented for all system components to reconstruct the following events:
- All individual accesses to cardholder data
- All actions taken by any individual with root or administrative privileges
- Access to all audit trails
- Invalid logical access attempts
- Use of identification and authentication mechanisms
- Initialization of the application audit logs
- Creation and deletion of system-level objects
Record at least the following audit trail entries for all system components for each event:
- User identification
- Type of event
- Date and time
- Success or failure indication
- Origination of event
- Identity or name of affected data, system component, or resource
Logging must be enabled. Disabling logs will result in non-compliance with PCI DSS.
You must also establish and maintain centralized logging. Examples of this functionality may include, but are not limited to:
- Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.
- Provided functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for centralized logging
Audit trail files must be promptly backed up to a centralized log server or media that is difficult to alter.
All communication performed by this product will be performed over SSL. The SSLCipherStrength configuration setting may be specified to force a minimum cipher strength. It is strongly recommended that this be set to a value of 128 to ensure at least 128 bit SSL is used. The SSLStatus event will fire with information about the negotiated SSL parameters which may be inspected to verify the connection was established securely.
In Windows this application relies on the Microsoft CryptoAPI to perform cryptographic functions. In other environments (Mac and Linux) this application relies on OpenSSL to perform cryptographic functions. This application does not have any other dependencies on any services, software, components, or hardware.
Wireless and Public Networks
If the application is used on a wireless or public network the transmission must be properly secured. You must:
- Change wireless vendor defaults, including default wireless encryption keys, passwords for access points, and SNMP community strings
- Change encryption keys anytime anyone with knowledge of the keys leaves the company or changes positions in the company
- Update firmware on wireless devices to support strong encryption for authentication and transmission
- Install a firewall between any wireless networks and systems that store cardholder data
- Configure the firewall to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment
- NOT use WEP as a security control
- Use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission of cardholder data
While remote access to the Gateway is possible, we strongly recommend that the Gateway services be restricted to local accounts only and are not exposed to the public. If your application may be accessed remotely, then remote access must be authenticated using a two-factor authentication mechanism. Two-factor authentication consists of a user ID and password and an additional authentication item such as a smart card, token, or PIN). Two forms of one-factor authentication are not sufficient. Examples of two-factor authentication include RADIUS with tokens, or TACAS with tokens.
This application does not deliver remote updates. If your application delivers remote updates via remote access into the customers’ systems, instruct the customers to turn on remote-access technologies only when needed for downloads. The technologies must be turned off immediately after download completes. Alternatively, if updates are delivered via VPN or other high-speed connections, instruct customers to properly configure a firewall or a personal firewall product to secure “always-on” connections. The following actions must be taken:
- Establish firewall and router configuration standards that include:
- A formal process for approving and testing all network connections and changes to the firewall and router configurations.
- Current network diagram with all connections to cardholder data, including any wireless networks.
- Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone.
- Description of groups, roles, and responsibilities for logical management of network components.
- Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP.
- Requirement to review firewall and router rule sets at least every six months.
- Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity’s ability to control or manage.
- Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.
- Secure and synchronize router configuration files.
- Install perimeter firewall between any wireless networks and the cardholder data environment, and configure these firewall to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
- Prohibit direct public access between the Internet and any system component in the cardholder data environment.
- Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
- Limit inbound Internet traffic to IP addresses within the DMZ.
- Do not allow any direct connections between the Internet and the cardholder data environment.
- Do not allow internal addresses to pass from the Internet into the DMZ.
- Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
- Implement stateful inspection, also known as dynamic packet filtering. That is, only “established” connections are allowed into the network.
- Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
- Do not disclose private IP addresses and routing information to unauthorized parties. Methods to obscure IP addressing may include, but are not limited to:
- Network Address Translation (NAT)
- Placing servers containing cardholder data behind proxy servers/firewalls or content caches
- Removal of filtering of route advertisements for private networks that employ registered addressing
- Internal use of RFC1918 address space instead of registered addresses.
- Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.
If your application can be accessed remotely, the remote access must be implemented securely. Examples of remote access security features include:
- Change default settings in the remote access software (for example, change default password and use unique passwords for each customer).
- Allow connections only from specific (known) IP/MAC addresses.
- Use strong authentication and complex passwords for logins. See “Appendix A – Unique UserIDs and Secure Authentication”.
- Enable encrypted data transmission. Instruct customers to encrypt all non-console administrative access with strong cryptography, using technologies such as SSH, VPN, or SSL/TSLS for web-based management and other non-console administrative access. Telnet or rlogin must never be used for administrative access.
- Enable account lockout after not more than six failed login attempts.
- Configure the system so a remote user must establish a Virtual Private Network (VPN) connection via a firewall before access is allowed.
- Enable the logging function.
- Restrict access to customer passwords to authorized reseller/integrator personnel.
- Establish strong and complex customer passwords. See “Appendix A – Unique UserIDs and Secure Authentication”.
Your payment application must support customers’ use of remote access security features.
This application does not have an administrative interface, therefore encrypting non-console administrative access is not a concern. If your application does have an administrative interface non-console administrative access must be encrypted with strong cryptography, using technologies such as SSH, VPN, or SSL/TSLS for web-based management and other non-console administrative access. Telnet or rlogin must never be used for administrative access.
This application does not support messaging. If your application supports messaging encrypt all PANs sent with end-user messaging technologies (for example, e-mail, instant messaging, chat). A solution must be in place that renders the PAN unreadable or implements strong cryptography to encrypt the PANs. Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).