PA-DSS Implementation Guide For

PA-DSS Implementation Guide For, CAGE (Card Authorization Gateway Engine), Version 4.0 PCI PADSS Certification 2.0 December 10, 2013.

Table of Contents 1. Purpose... 4 2. Delete sensitive authentication data stored by previous payment application versions. 5 3. Purge cardholder data after customer-defined retention period.... 5 4. Delete cryptographic key material or cryptograms stored by previous payment application versions.... 6 5. Disable System Restore Points... 6 6. Use unique user IDs and secure authentication for administrative access to CAGE and access to cardholder data.... 7 7. Implement automated audit trails and centralized logging... 8 8. Wireless... 12 9. Store cardholder data only on servers not connected to the Internet.... 13 10. Securely deliver remote payment application updates.... 13 11. Implement two-factor authentication for remote access to payment application.. 14 12. Securely implement remote access software... 14 13. Secure transmissions of cardholder data over public networks... 15 14. Encrypt cardholder data sent over end-user messaging technologies.... 15 15. Encrypt non-console administrative access... 15 16. Ensure Network Security... 16 17. Maintain Instructional Documentation and Training... 16 18. Merchant/Customer Responsibility... 16 19. CAGE never stores cardholder data and ICS will never request for cardholder data 17 20. Ports needed for CAGE communication... 17 21. Required components for CAGE application... 18 22. Configuring Windows accounts/users on ICS machines that run CAGE... 18

1. Purpose PA-DSS Requirement 14 requires that all merchants develops, implements, and enforce PCI standards in the implementation of POS products. This guide will be used to ensure that ICS CAGE will be installed according to PA-DSS Requirements. This guide shall help mitigate the risk that the PA-DSS compliant application will be installed incorrectly leaving it vulnerable to attack. This guide helps you maintain a secure environment. Changing out-of-the-box settings to a state that is less strict will result in PCI noncompliance.

2. Delete sensitive authentication data stored by previous payment application versions. CAGE does not facilitate the collection or storage of sensitive authentication data. Therefore, there are no additional steps necessary for PCI DSS compliance when updating and/or install CAGE. Following are the instructions for customers, if updating from a different payment application: Historical data must be removed (magnetic stripe data, card validation codes, PINs, or PIN blocks stored by previous versions of the payment application). Delete any historical data within the payment applications user defined data fields as well as any other means of data entry that contain sensitive authentication data. Such removal is absolutely necessary for PCI DSS compliance. Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem. Such data must be stored only in specific, known locations with limited access. Only collect a limited amount of such data as needed to solve a specific problem. Sensitive authentication data must be encrypted while stored. Such data must be securely deleted immediately after use. 3. Purge cardholder data after customer-defined retention period. Cardholder data must be purged after it exceeds the customer-defined retention period. This means all locations where payment application stores cardholder data. CAGE only stores cardholder data in volatile RAM (random access memory). This data is automatically purged from memory after processing occurs.

4. Delete cryptographic key material or cryptograms stored by previous payment application versions. Cryptographic material must be removed Prior versions of CAGE did not store cardholder data. Therefore, there is no further action needed to remove cryptographic material. CAGE does not store cardholder data. Therefore, there is no further action needed to re-encrypt historic data with new keys. 5. Disable System Restore Points If you use Microsoft Windows XP, Windows Vista, or Windows 7 turn off System Restore on the System Properties screen. System Restore creates and uses restore points to track changes in Windows. These restore points may retain sensitive cardholder data. When you turn off System Restore, the operating system automatically removes existing restore points and stops the creation of new restore points. Steps to turn off System Restore on XP, Vista and Windows 7 1. Click Start, right-click My Computer, and then click Properties. 2. In the System Properties dialog box, click the System Restore tab. 3. Click to select the Turn off System Restore check box. Or, click to select the Turn off System Restore on all drives check box. 4. Click OK. 5. When you receive the following message, click Yes to confirm that you want to turn off System Restore: You have chosen to turn off System Restore. If you continue, all existing restore points will be deleted, and you will not be able to track or undo changes to your computer. Do you want to turn off System Restore? After a few moments, the System Properties dialog box closes.

Steps to turn off System Restore on Windows 7: Open System by clicking the Start button, right-clicking Computer, and then clicking Properties. In the left pane, click System protection. If you're prompted for an administrator password or confirmation, type the password or provide confirmation. Under Protection Settings, click the disk, and then click Configure. Do one of the following: To be able to restore system settings and previous versions of files, unclick Restore system settings and previous versions of files. Unclick only restore previous versions of files. Click OK, and then click OK again. 6. Use unique user IDs and secure authentication for administrative access to CAGE and access to cardholder data. CAGE enforces secure authentication for all authentication credentials that the application generates by: Enforcing secure changes to authentication credentials by the completion of installation. Enforcing secure changes for any subsequent changes to authentication credentials. Default accounts in CAGE are automatically removed during the installation process. You must use unique user IDs and passwords for all the users. The user is forced to enter a unique user ID during the user account setup process. A code, provided by ICS is required to create an empty configuration file as well as user and password to access the configuration screens. The password must be alphanumeric, eight characters in length, must contain letters and at least one number. Passwords expire every 90 days. New passwords must be unique to the prior four.

Up to five unsuccessful login attempts causes the system to lock out the account. To unlock the account, another code provided by ICS is required which is only valid for one day. Idle sessions will timeout within 15 minutes. PA DSS 3.1.1 The payment application assigns unique IDs for user accounts. PA DSS 3.1.2 - The payment application employs at least one of the following methods to authenticate all users: Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric PA DSS 3.1.3 - The payment application does not require or use any group, shared, or generic accounts and passwords. PA DSS 3.1.4 - The payment application requires changes to user passwords at least every 90 days. PA DSS 3.1.5 - The payment application requires a minimum password length of at least seven characters. PA DSS 3.1.6 -The payment application requires that passwords contain both numeric and alphabetic characters. PA DSS 3.1.7 - The payment application keeps password history and requires that a new password is different than any of the last four passwords used. PA DSS 3.1.8 - The payment application limits repeated access attempts by locking out the user account after not more than six logon attempts. PA DSS 3.1.9 - The payment application sets the lockout duration to a minimum of 30 minutes or until administrator enables the user ID. PA DSS 3.1.10 - If a payment application session has been idle for more than 15 minutes, the application requires the user to re-authenticate to re-activate the session. 7. Implement automated audit trails and centralized logging

CAGE automatically creates updates and manages log files per PCI DSS requirements. Logs cannot be disabled from within CAGE. Logging is preconfigured to be compliant with PA-DSS 4.2 and 4.3, and cannot be changed. Please see below section for instructions on configuring centralized logging for PA-DSS 4.4 Compliance. PA-DSS 4.4a: Validate that payment application provides functionality that facilitates a merchant s ability to assimilate logs into their centralized log server. PA-DSS 4.4.b Examine the PA-DSS Implementation Guide prepared by the vendor to verify that customers and resellers/integrators are provided with instructions and procedures for incorporating the payment application logs into a centralized logging environment. Centralized logging is provided as a separate application by ICS. The application is named as CAGE-CLS.exe which runs as a server listening on default port 32700. All the individual CAGE applications running on AutoSentries, TouchNCleans and POS machines have to be pointed to the centralized CAGE-CLS application which runs centrally on a site server or on any other PC at the site. CAGE-CLS application stores logs in D:\ICS\Logs\Cage location. The logs are saved as separate files for each individual ICS devices (Autosentry, TouchNClean and POS). Following are the configurations needed for centralized logging. 1. Run CageCLS.exe which runs listening on default port 32700. This port can be changed as shown below

2. Configure each individual CAGE application running on devices to point to CAGE-CLS application as below.

Central server IP is nothing but CAGE-CLS location for individual CAGE applications to log. Other systems in your cardholder data environment, such as the operating systems, should be configured with PCI DSS compliant log settings as mentioned below. Set PCI DSS-compliant log settings, per PCI DSS Requirement 10. o PCI DSS 10.2.1 - All direct access to the database is logged within the databases logging facilities. o PCI DSS 10.2.2 - logs include actions taken by any individual with root or administrative privileges. o PCI DSS 10.2.3 - logs include access to all audit trails. o PCI DSS 10.2.4 - logs include invalid logical access attempts. o PCI DSS 10.2.5 - logs include use of identification and authentication mechanisms. o PCI DSS 10.2.6 - logs include initialization of audit logs. o PCI DSS 10.2.7 - logs include creation and deletion of system level objects. o PCI DSS 10.3.1 - logs include user identification. o PCI DSS 10.3.2 - logs include type of event. o PCI DSS 10.3.3 - logs include date and time stamp. o PCI DSS 10.3.4 - logs include success or failure indication. o PCI DSS 10.3.5 - logs include origination of event

8. Wireless In wireless environments, the wireless vendor s default setting must be changed to be PCI compliant. This includes, but is not limited to changing, Wi-Fi Protected Access (WPA) keys, default service set identifier (SSID), and passwords. Disable SSID broadcasts. Enable Wi-Fi protected access only. PA DSS 6.1 - For payment applications using wireless technology, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. The wireless technology must be implemented securely. PA DSS 6.1.a - Verify encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions PA DSS 6.1.b - Verify default SNMP community strings on wireless devices were changed PA DSS 6.1.c - Verify default passwords/passphrases on access points were changed PA DSS 6.1.d - Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks PA DSS 6.1.e - Verify other security-related wireless vendor defaults were changed, if applicable For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. The use of Wired Equivalent Privacy (WEP) as a security control is prohibited (PA-DSS 6.2 and PCI DSS 4.1.1). Industry best practice (example, IEEE 802,11.i) must be used to enforce strong encryption for authentication and transmission. If wireless is used or implemented in the payment environment or application, the wireless environment must be configured per PCI DSS version 1.2 requirements 1.2.3, 2.1.1, and 4.1.1. Wireless technology must be securely implemented and transmissions of cardholder data over wireless networks must be secure. A perimeter firewall is required between any wireless network and systems that store cardholder data per PCI DSS requirement 1.2.3. Because of the Visa USA PCI Data Security Standard, it is mandated that each site ensure that all PCs, databases, wireless access points, and any other medium containing sensitive data reside behind a firewall. The firewall configuration must restrict connections between publicly accessible hosts

and any system storing cardholder data, including any connections from wireless networks. CAGE application itself does not have any wireless functionality included, but can be integrated into an environment that uses wireless technology. Generally, CAGE is used only on wired networks for security, simplicity and reliability. We do not recommend wireless technology since it should not be needed in your environment. This is requirement applies to all accounts controlling the PC, database and servers in cardholder data environment. 9. Store cardholder data only on servers not connected to the Internet. Credit card data cannot be stored on systems directly connected to the Internet. For example, web servers and database servers should not be installed on the same server. A DMZ must be set up to segment the network so that only machines on the DMZ are Internet accessible. PA-DSS 9.1 The payment application must be developed such that the database server and web server are not required to be on the same server, nor is the database server required to be in the DMZ with the web server, per PCI DSS version 1.1 1.3 and 1.3.4 <OR> version 1.2 1.3.2. CAGE never stores cardholder data. 10. Securely deliver remote payment application updates. Receive remote payment application updates via secure modems, per PCI DSS Requirement 12.3. If a computer is connected via VPN or other high speed connection, receive remote payment application updates via a firewall or a personal firewall per PCI DSS Requirement 1 or 1.3.9. Cage will verify successful update by performing an MD5 check of the binaries delivered. If there are any discrepancies, then CAGE will fail to launch. Customers must speak to an ICS representative for remediation.

11. Implement two-factor authentication for remote access to payment application Use two-factor authentication (user ID and password and an additional authentication item such as a token) if the payment application may be accessed remotely. Implement strong cryptography, such as SSH, VPN, or SSL/TLS. 12. Securely implement remote access software PA-DSS 10.2: If the payment application may be accessed remotely, remote access to the payment application must be authenticated using a two-factor authentication mechanism. When any remote-access technologies are used, they should be activated only when needed and immediately deactivated after use. Use a securely configured firewall or a personal firewall product if computer is connected via VPN or other high-speed connection, to secure these always on connections. Implement and use remote access software security features if remote access software is used to remotely access the payment application or payment environment. Note: Examples of remote access security features include: Change default settings in the remote access software (for example, change default passwords 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.10) Enable encrypted data transmission according to PA-DSS Requirement 12.1 Enable account lockout after a certain number of failed login attempts (See PADSS Requirement3.1.8) 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 customer passwords according to PA-DSS Requirements 3.1.1through 3.1.10.

If customers want to access the payment application remotely then they will need to make sure they use one of the 2 factor authentication. For example, RADIUS with tokens, TACACS with tokens, or other technologies that facilitate two-factor authentication. Note: Two-factor authentication requires that two of the three authentication methods (see below) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication. The authentication methods, also known as factors, are: Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric 13. Secure transmissions of cardholder data over public networks Implement and use SSL for secure cardholder data transmission over public networks, in accordance with PCI DSS Requirement 4.1 CAGE resides on each of ICS KIOSK and POS machines and the cardholder data is always encrypted when it is transmitted out to processors. No configuration is needed as CAGE always makes SSL connections to processors while transmitting cardholder data. 14. Encrypt cardholder data sent over end-user messaging technologies. Implement and use an encryption solution if PAN numbers are to be sent with end-user messaging technologies. CAGE does not allow or facilitate the sending of PANs by end-user messaging technologies. 15. Encrypt non-console administrative access

Implement strong cryptography, such as SSH, VPN, or SSL/TLS for encryption of any non-console administrative access to payment application or servers in cardholder data environment. 16. Ensure Network Security Ensure that the payment application stores cardholder data in the internal network, and never in the DMZ. Never configure the database server and web server to be on the same server, or the database server to be in the DMZ with the web server. CAGE does not allow or facilitate the storing of cardholder data. 17. Maintain Instructional Documentation and Training PA-DSS 13.1: Develop, maintain, and disseminate a PADSS Implementation Guide(s) for customers, resellers, and integrators that accomplish the following: 13.1.1 Addresses all requirements in this document wherever the PA-DSS Implementation Guide is referenced. 13.1.2 Includes a review at least annually and updates to keep the documentation current with all major and minor software changes as well as with changes to the requirements in this document. The implementation guide will be distributed as an electronic.pdf copy to all ICS customers who buy ICS products that use CAGE. This implementation guide will be reviewed annually for any software changes or updates as well changes to PA-DSS requirements. 18. Merchant/Customer Responsibility ICS will do every effort to secure the CAGE application. Once it is installed on merchant s machine, it is the responsibility of the merchant to keep the application from attacks or any other vulnerability. ICS suggests its customers to do the following to keep CAGE application secure.

Keep software up to date which includes Windows operating system, email programs, and internet browsers. Keep anti-virus and malware detection software up to date and perform routine scans. Install a firewall and lockdown router to allow outgoing connections to trusted sites only. Allow only authorized access to computer which runs CAGE. Do not browse the internet on ICS provided KIOSK or POS systems. More information on security can be found by visiting websites listed below: o http://www.sans.org/newsletters/ o http://www.microsoft.com/security/default.asp o http://www.cvedetails.com/cvss-score-distribution.php 19. CAGE never stores cardholder data and ICS will never request for cardholder data ICS will never ask for cardholder data from merchants or customers. ICS support personnel will not ask for any cardholder data from the merchants or customers for troubleshooting purposes. Any troubleshooting has to be using the CAGE logs which saves only truncated cardholder data. In the event, customer or merchant sends any cardholder data to support or any ICS employee, such cardholder data will be destroyed immediately. 20. Ports needed for CAGE communication 5.4 The payment application must only use or require use of necessary and secure services, protocols, daemons, components, and dependent software and hardware, including those provided by third parties, for any functionality of the payment application (for example, if NetBIOS, file sharing, Telnet, FTP, etc., are required by the application, they are secured via SSH, S-FTP, SSL, IPsec, or other technology). Aligns with PCI DSS Requirement 2.2.2 CAGE application uses TCP port 3212 for incoming connections. In addition the following applications use the following TCP ports:

AutoSentry 32501 Replication 3222, 3211 CoreGateWayServer - 32599 TouchNClean 32504 NetdebugLog - 32600 21. Required components for CAGE application 5.4. c Verify that the PA-DSS Implementation Guide documents all required protocols, services, components, and dependent software and hardware that are necessary for any functionality of the payment application, including those provided by third parties. CAGE is an independent application and following are the software and hardware requirements: x86 or x64 platform personal computer. Windows based operating system. Windows XP, Windows 7 POS Ready, Windows 8..Net 3.0 platform USB interface card reader. Software DLLs used o Cage.Communication DLL Which has communication protocol to communicate with ICS applications o Hid.Net.DLL USB card reader drivers o ICS.USB.DLL Wrapper class for USB card reader drivers o ICS.SMSS.DLL Heartbeat check to make sure CAGE is running o Interop.PSCharge.DLL Needed for communicating to PCCharge processor o Interop.LYNKCHANELLib.DLL Needed for communicating to Lynk processor o Interop.SaxComm8.DLL Needed for Transactive processor. o Interop.SJCOMAPILib.DLL Needed for Transactive processor. o SIM.DLL Needed for PCCharge processor. o Microsoft.Web.Services For all the processors which use https web service calls. 22. Configuring Windows accounts/users on ICS machines that run CAGE

This section describes on setting up Windows OS accounts on PCs. ICS ships pre-loaded and pre-configured computers to customers. Computers have administrative rights and non-administrative rights. When systems leave ICS facility, they are configured with a password which only ICS support will know. It is the responsibility of the customers to make sure the Windows OS passwords are changed to their desired ones upon installation of ICS provided PCs at the site. It is also the responsibility of merchants to configure a PCI DSS compliant manner network environment. The following rules must be strictly followed to adhere to PCI DSS compliant network environment: You are strongly advised to control access, via unique user ID and PCI DSS compliant secure authentication, to any PCs, servers, and databases with payment applications and cardholder data. Router admin account password must be changed to site s responsible network administrator. Do not use default passwords provided by ICS. Review and change all the ICS provided default passwords. Change administrative password to all the machines, so that only key persons at the site level. Keep strong passwords for all the accounts. Make passwords that contain at least one special character, one capital letter and one numeric character. o Example: mysite or mycat is not a strong password. Provide non administrative accounts for cashiers on POS, employee time clock and reports viewing on WashConnect. Do not share passwords with any of the accounts or use shared passwords across all the computers.