Payment Application Data Security Standard (PA-DSS) Implementation Overview for Direct Payment Integrator V6

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 to give you 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.

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 http://www.nsoftware.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.

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\nsoftware". The files written include help files, demos, the uninstall program, and the application itself. Additionally during installation on windows machines a registry key is added under "HKEY_LOCAL_MACHINE/SOFTWARE/nsoftware" to hold the license.

Sensitive Authentication Data

This application does not store any authentication data, and has not done so in previous versions. As a result there is no sensitive authentication 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: http://www.nsoftware.com/docs/epayment/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.

Logging

This application does not perform any administrative function that are required to be logged. 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 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

Remote Access

This application does not allow remote access in any form. 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.

Messaging

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

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.