4D Payments Gateway Implementation Guide

Payment Application Data Security Standard (PA-DSS) Implementation Overview for 4D Payments Gateway 2016


PA-DSS stands for Payment Application Data Security Standard. PA-DSS is managed by the PCI Security Standards Council. Any payment application that is sold, distributed, or licensed to third parties are subject to the PA-DSS requirements. The key to this program is the PCI DSS, or “Payment Card Industry Data Security Standard.” This standard describes how a merchant is to secure electronic data, physical servers, hard drives, employee access to data, and more.
For an entity (merchant, service provider, etc.) to be PCI compliant, the application used to authorize credit cards and store customer data must conform to these Payment Application Data Security Standards.
This application is designed to be used to support another application. It can be used to create a PA-DSS compliant secure payment application. This documentation is intended for developers of payment applications. It provides instructions on how to implement this application in such a way that it will meet PA-DSS and PCI requirements.
IMPORTANT: You must write your own implementation guide to be supplied with your product to your customers. This guide should not be distributed to your customers (end users), only your implementation guide that you create should be supplied.

Installation

When installing this product the installer will create files on disk at the location specified during the setup. The default installation location is under a folder at “C:\Program Files\4D Payments”. The files written include demos, the uninstall program, and the application itself. Additionally during installation on windows machines a registry key is added under “HKEY_LOCAL_MACHINE/SOFTWARE/DPayments/RT” to hold the license.

Patches and updates

All official updates to this product must be obtained from our website at a URL provided by our support staff or via our download page at https://4dpayments.com/download/. To verify that the build is an official build, right click the setup file (setup.exe) and choose properties. From this window select the Digital Signature tab and press the Details button to view details about the digital signature. The text “This digital signature is OK.” should be present in this dialog window. The certificate must be issued by a recognized and trusted authority to either /n software, or 4D Payments Inc.
All registered users of the 4D Payments Gateway will be notified via email any time a new patch or update of the product is published. You must always download the product from our official website at https://4dpayments.com and follow the process described in the above paragraph to ensure that the downloaded package is legitimate and has not been tampered with.
All patches and updates to the 4D Payments Gateway will be delivered as part of a complete installation package. There will be no partial replacement of particular files. The updated installation package will remove the old version and replace it with the new version.

Configuration

After a successful installation you are prompted to open the Gateway UI. It is important to select a valid SSL Server certificate under the Settings tag before starting the server. You are able to select the default Plain Text Port and SSL Port under the same view.
Before running the gateway and start sending any request, you must generate API Keys which uniquely authenticate requests to 4D Payments Gateway. Requests with incorrect API Keys will result in an authentication error “401 Unauthorized” displayed in the gateway UI. More information on the API Keys will be provided below, in the Controlling User Ids and Authentication section.

After the above steps are completed you may start the gateway and use its facilities to authorize and settle credit card payment transaction directly through major Internet payment processors.

Application Versioning

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 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: https://4dpayments.com/version-mapping

Sensitive Authentication Data

This application does not store any authentication data, and has not done so in previous versions. As a result there are no sensitive authentication data to delete from previous versions. If your application stores sensitive authentication data you must be sure it is properly deleted. Sensitive authentication data is not required for troubleshooting this product. If sensitive authentication data is received by our support staff it is immediately and permanently deleted. If you or your customer obtain sensitive authentication data as a result of troubleshooting the following rules must be followed:

  • Sensitive authentication data (pre-authorization) must only be collected to solve a specific problem
  • The data must be stored in a known, specific location with limited access.
  • Limit the amount of data to only the amount necessary to solve the issue.
  • Sensitive authentication data MUST be encrypted while stored.
  • The data must be deleted immediately after it is no longer needed.

If your application stores any cardholder data it must be purged after the customer-defined retention period. It must be stored on servers that are NOT connected to the Internet. You must also document all locations where the data is stored. This application does not store any cardholder data, therefore there are no locations to disclose.
The system on which the application runs must be configured to prevent accidental exposure of sensitive cardholder information. In Windows this includes disabling system backup and restore to prevent inadvertent storage of cardholder data. Additionally the Windows paging file (pagefile.sys) should be cleared during shutdown to prevent unsecured data from being written to disk. In non-Windows systems the swap space should be cleared. To further protect cardholder data in both Windows and non-Windows systems the swap space, or the entire disk, may be encrypted. Any crash dumps from the application may contain cardholder data and must be encrypted if stored.

Cryptographic Keys

Cryptographic keys are used to encrypt cardholder data for storage. This application does not store any cardholder data, as such there are no keys to protect. No previous versions of this application have stored cardholder data, so there were no cryptographic keys in previous versions either.
If your application stores cardholder data you must protect the keys used to encrypt it against disclosure and misuse. Restrict access to the keys to the fewest number of custodians. Store the keys in the fewest possible locations and in the fewest possible forms. You must implement key management procedures to protect the keys (See Appendix B at the bottom of this document). A sample key custodian form can be found here: https://4dpayments.com/wp-content/docs/Sample_Key_Custodian_Form.pdf. If previous versions of your application stored cryptographic key material it must be rendered irretrievable.

Controlling User Ids and Authentication

This application 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. See Appendix A at the bottom of this document for more details.
The only authentication form used by the 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.

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 (Error, Warning, Info or Verbose) and other settings in the Logging Options menu under the Settings Tab as shown on the screen shot below:

The typical Server responses logged in the UI can be found in the homepage API which is easily accessible by clicking on the Home button located in the upper-right corner of the gateway UI. The self-documenting APIs offer a detailed information on the various demos/scripts located in the installation folder. For each demo a request and response example is written in three different languages: JavaScript, cURL and HTTPS for users’ reference.
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.

Secure Protocols and Transmission

All connections to the software are secured using TLS 1.2. Connections not supporting TLS 1.2 are rejected. Connections made from the software to the payment processor all use TLS 1.2. TLS 1.2 is implemented by the Microsoft Crypto API, which is used by the software. The software explicitly disallows the use of TLS versions prior to TLS 1.2 (Early TLS).
The software must be run on Windows 7 or later with PowerShell 3.0 or higher installed. The software does not require any specific hardware and does not rely on any 3rd party libraries. The software does not have any dependencies on any additional services.

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.

Remote Access

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 PA-DSS Requirements 3.1.1 through 3.1.11).
  • Enable encrypted data transmission according to PADSS Requirement 12.1. 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. (See PA-DSS Requirement 3.1.9 through 3.1.10.)
  • Establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed. 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 environments to authorized integrator/reseller personnel.
  • Establish strong and complex customer passwords. See “Appendix A – Unique UserIDs and Secure Authentication”.

Data transmissions

All 4D Payments Gateway transmissions of cardholder data, whether over a private network or a public network, are secured by the use of TLS 1.2+. This helps satisfy Requirement 4.1 of the PCI Data Security Standard.
Important:

  • Strong cryptography and security protocols must be used if cardholder data is ever transmitted over public networks.
  • Only trusted keys and/or certificates can be accepted.
  • You must use only secure versions and secure implementations of security protocols.
  • Prevent fallback to an insecure version or configuration (for example, if TLS is used, the application must not allow fallback to SSL).
  • You must use proper encryption strength for the encryption methodology.

Messaging

This application does not allow or facilitate the transmission of PANs via end-user messaging technologies. If your application allows or facilitates sending of PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat) then a solution must be in place that renders the PAN unreadable or implements strong cryptography, to satisfy Requirement 4.2 of the PCI Data Security Standard.
Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).
PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Non-console administrative access

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 Secure Shell (SSH), VPN, or Transport Layer Security (TLS) for web-based management and other non-console administrative access, as required by Requirement 2.3 of the PCI Data Security Standard. Telnet or rlogin must never be used for administrative access.
If your application does have an administrative interface and you choose to use non-console administrative access then:

  • multi-factor authentication must be used for all personnel with non-console administrative access to the CDE (Cardholder Data Environment), and also
  • provide the procedures for using the multi-factor authentication with the application.

Note: Multi-factor authentication requires at least two of the three authentication methods be used for authentication (see PA-DSS Requirement 3.1.4 for descriptions of authentication methods). Aligns with PCI DSS Requirement 8.3

Appendix A – Unique UserIDs and Secure Authentication:

The following guidelines must be adhered to.

  • 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.

Appendix B – Key management Procedures:

Companies that use payment applications must have key management procedures that cover the points listed below. The following requirements and procedures must be addressed:

  • 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.