PCI PA-DSS Implementation Guide Onslip PAYAPP V2.1.x for Onslip S80, Onslip S90

PCI PA-DSS Implementation Guide Onslip PAYAPP V2.1.x for Onslip S80, Onslip S90

Revision history Revision Date Author Comments 0.1 2013-10-04 Robert Hansson Created 1.0 2014-01-14 Robert Hansson Review and update of document 1.1 2014-12-29 Robert Hansson Annual review. No modifications 1.2 2015-06-26 Robert Hansson Updates made during PA-DSS validation Page 2 of 16

References #no Reference title Version [1] Payment Card Industry Payment Application Data Security Standard 3.1 [2] Payment Card Industry Data Security Standard 3.1 [3] Security Requirements for an EFTPOS Terminal 3.0 [4] PCI PIN Security Requirements 2.0 Page 3 of 16

Table of Contents REVISION HISTORY 2 REFERENCES 3 INTRODUCTION 6 BACKGROUND 6 THE PURPOSE OF THIS GUIDE 6 VERSIONING METHODOLOGY 6 ABBREVIATIONS 7 PA-DSS REQUIREMENTS 8 1.1.4 DELETE SENSITIVE AUTHENTICATION DATA STORED BY PREVIOUS PAYMENT APPLICATION VERSIONS 8 8 8 1.1.5 DELETE ANY SENSITIVE AUTHENTICATION DATA (PRE-AUTHORIZATION) GATHERED AS A RESULT OF TROUBLESHOOTING THE PAYMENT APPLICATION 8 8 8 2.1 SECURELY DELETE CARDHOLDER DATA AFTER CUSTOMER-DEFINED RETENTION PERIOD. 8 9 9 2.2 MASK PAN WHEN DISPLAYED SO ONLY PERSONNEL WITH A BUSINESS NEED CAN SEE THE FULL PAN. 9 9 9 2.3 RENDER PAN UNREADABLE ANYWHERE IT IS STORED (INCLUDING DATA ON PORTABLE DIGITAL MEDIA, BACKUP MEDIA, AND IN LOGS). 9 9 9 2.4 PROTECT KEYS USED TO SECURE CARDHOLDER DATA AGAINST DISCLOSURE AND MISUSE. 9 9 10 2.5 IMPLEMENT KEY MANAGEMENT PROCESSES AND PROCEDURES FOR CRYPTOGRAPHIC KEYS USED FOR ENCRYPTION OF CARDHOLDER DATA. 10 10 10 2.5.1 2.5.7 IMPLEMENT SECURE KEY MANAGEMENT FUNCTIONS. 10 10 10 2.6 PROVIDE A MECHANISM TO RENDER IRRETRIEVABLE CRYPTOGRAPHIC KEY MATERIAL OR CRYPTOGRAMS STORED BY THE PAYMENT APPLICATION. 10 10 10 3.1 USE UNIQUE USER IDS AND SECURE AUTHENTICATION FOR ADMINISTRATIVE ACCESS AND ACCESS TO CARDHOLDER DATA. 11 11 11 3.2 USE UNIQUE USER IDS AND SECURE AUTHENTICATION FOR ACCESS TO PCS, SERVERS, AND DATABASES WITH PAYMENT APPLICATIONS. 11 11 11 4.1 IMPLEMENT AUTOMATED AUDIT TRAILS. 11 Page 4 of 16

11 11 4.4 FACILITATE CENTRALIZED LOGGING. 12 12 12 5.4.4 IMPLEMENT AND COMMUNICATE APPLICATION VERSIONING METHODOLOGY. 12 12 12 6.1 SECURELY IMPLEMENT WIRELESS TECHNOLOGY. 12 12 12 6.2 SECURE TRANSMISSIONS OF CARDHOLDER DATA OVER WIRELESS NETWORKS. 13 13 13 6.3 PROVIDE INSTRUCTIONS FOR SECURE USE OF WIRELESS TECHNOLOGY. 13 13 13 8.2 USE ONLY NECESSARY AND SECURE SERVICES, PROTOCOLS, COMPONENTS, AND DEPENDENT SOFTWARE AND HARDWARE, INCLUDING THOSE PROVIDED BY THIRD PARTIES. 14 14 14 9.1 STORE CARDHOLDER DATA ONLY ON SERVERS NOT CONNECTED TO THE INTERNET. 14 14 14 10.1 IMPLEMENT TWO-FACTOR AUTHENTICATION FOR REMOTE ACCESS TO PAYMENT APPLICATION THAT ORIGINATES FROM OUTSIDE THE CUSTOMER ENVIRONMENT. 14 14 15 10.2.1 SECURELY DELIVER REMOTE PAYMENT APPLICATION UPDATES. 15 15 15 10.2.3 SECURELY IMPLEMENT REMOTE ACCESS SOFTWARE. 15 15 15 11.1 SECURE TRANSMISSIONS OF CARDHOLDER DATA OVER PUBLIC NETWORKS. 15 15 16 11.2 ENCRYPT CARDHOLDER DATA SENT OVER END USER MESSAGING TECHNOLOGIES. 16 16 16 12.1 ENCRYPT NON-CONSOLE ADMINISTRATIVE ACCESS. 16 16 16 12.2 ENCRYPT NON-CONSOLE ADMINISTRATIVE ACCESS. 16 16 16 Page 5 of 16

Introduction Background The Payment Card Industry Data Security Standard (PCI-DSS) defines specific requirements to make sure that the payment equipment are configured, used and maintained in the merchant s payment environment in a way that card transactions are stored, processed and transferred in a secure way. The requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the PCI DSS Requirements and Security Assessment Procedures. The PA-DSS applies to terminal vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties. In order to help merchants to fulfill those requirements the terminal vendor obtains a PA-DSS approval to demonstrate that the payment application follows the PCI DSS. The purpose of this guide The purpose of this PA DSS implementation guide is to provide merchants and integrators with information on how to use, install, maintain and secure a PCI DSS compliant environment for Onslip PAYAPP and the Onslip payment equipment in a way that does not compromise the PCI DSS compliance. The merchant is responsible for creating and maintaining a PCI compliant environment with the help of this guide and the PCI regulations. The merchant will also find installation guides, quick guides for how to install and use a card terminal and this implementation guide at Onslip support web site, http://support.onslip.com. Versioning methodology The versioning methodology of the payment application consists of version elements each representing a single digit with value 0-9 where each element is separated by a dot for major (high impact), minor (low impact) and insignificant (no impact) following the syntax M.m.x. The table below describe the different elements and the impact of the changes for a new version of the payment application. The version element insignificant is a wilcard position for changes that are not having any impact on security. Prefix Change Impact Description M Major High A major change have big impact on the PA-DSS requirements and occur rarely in situations where modifications have been made affecting: half or more of the application code base crucial parts of key management and the security handling crucial parts of the payment transactions engine crucial parts of the mechanism handling card holder data crucial modifications to the operating system or hardware Page 6 of 16

m Minor Low A minor change have smaller impact to the PA-DSS requirements and occur more regular in situations where modifications have been made affecting: less than half of the application code base non crucial parts of key management and the security handling non crucial parts of the payment transactions engine non crucial parts of the mechanism handling card holder data x Insignificant None A change graphical where no user impact interface, have been receipts done layout to the and PA-DSS other requirements changes and occur in situation where modifications have been made affecting: other non crucial changes not listed for major and minor changes Abbreviations Abbreviation Full name PCI-DSS PA DSS ECR PNC E2EE PPL SSL IPSEC Payment Industry Data Security Standard Payment Application Data Security Standard Electronic Cash Register Pan Nordic Card Association End To End Encryption Program and parameter loading Secure Sockets Layer Internet Protocol Security Page 7 of 16

PA-DSS Requirements 1.1.4 Delete sensitive authentication data stored by previous payment application versions Historical data must be removed (track data, card verification codes, PINs, or PIN blocks stored by previous versions of the payment application) How to remove historical data Such removal is absolutely necessary for PCI DSS compliance The payment application does not store any historical cardholder data in the payment application from any processed and transmitted card transaction. Therefor there is no need to delete historical cardholder data and such functionality is not provided. If the merchants absolutely need to enter PAN, expiration date and CVV2 manually the merchant shall never ever write down or otherwise store such sensitive cardholder data. 1.1.5 Delete any sensitive authentication data (pre-authorization) gathered as a result of troubleshooting the payment application 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 The payment application does not store any sensitive data in the payment application from any processed and transmitted card transaction. The payment application will check if there exist any store-and-forward (S&F) transactions that have not been transferred to the host using previous application version of payment application. The new payment application will make sure that all transaction data in S&F will be sent and thereafter be completely erased from payment application. 2.1 Securely delete cardholder data after customer-defined retention period. Instruction that cardholder data exceeding the customer-defined retention period must be securely deleted A list of all locations where payment application stores cardholder data, so that customer knows the locations of data that needs to be deleted Instruction that customers need to securely delete cardholder data when no longer required for legal, regulatory, or business purposes How to securely delete cardholder data stored by the payment application, including data stored on underlying software or systems (such as OS, databases, etc.) How to configure the underlying software or systems (such as OS, databases, etc.) to prevent inadvertent capture or retention of cardholder data Page 8 of 16

Cardholder data is sent encrypted in the authorization message making the transaction end-to-end encrypted required by PNC, the E2EE requirement and the requirements described in the specification Security Requirements for an EFTPOS Terminal. If the host is unavailable sensitive cardholder data of the transaction will be stored fully encrypted in a store-and-forward (S&F) queue. All transaction data in S&F will be sent immediately when host is available and will thereafter be completely erased from S&F queue when host have accepted the transaction. 2.2 Mask PAN when displayed so only personnel with a business need can see the full PAN. Details of all instances where PAN is displayed, including but not limited to POS devices, screens, logs, and receipts Confirmation that the payment application masks PAN by default on all displays Instructions on how to configure the payment application such that only personnel with a legitimate business need can see the full PAN The payment application only display PAN masked to the personnel following the PCI requirements on how to mask PAN. The personnel cannot see or retrieve unmasked PAN from POS device, screens, logs or receipts. 2.3 Render PAN unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs). Details of any configurable options for each method used by the application to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment application (per PA-DSS Requirement 2.1) A list of all instances where cardholder data may be output for the merchant to store outside of the payment application, and instructions that the merchant is responsible for rendering PAN unreadable in all such instances The payment application always render PAN unreadable and cannot be retrieved in any other way. It is not possible to retrieve PAN readable from receipts, displays or logs. The payment application does not have any functionality to make backups of PAN or any other sensitive data on any digital media. 2.4 Protect keys used to secure cardholder data against disclosure and misuse. Restrict access to keys to the fewest number of custodians necessary. Store keys securely in the fewest possible locations and forms All keys used to secure encryption are stored in a secure memory of the terminal, which is never allowed to be accessed by the payment application. The key loading is handled in a secure environment where a limited amount of key custodians have access to the key loading facility following PCI PIN Security Requirements. Page 9 of 16

2.5 Implement key management processes and procedures for cryptographic keys used for encryption of cardholder data. Instructions on how to securely generate, distribute, protect, change, store, and retire/replace encryption keys, where customers or integrators/resellers are involved in these keymanagement activities A sample Key Custodian form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities. The key management process where the most secure keys are loaded in a secure environment follows procedures defined by the PCI PIN Security Requirements and the specifications defined by acquiring banks. 2.5.1 2.5.7 Implement secure key management functions. Generation of strong cryptographic keys Secure cryptographic key distribution Secure cryptographic key storage Cryptographic key changes for keys that have reached the end of their cryptoperiod Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised Split knowledge and dual control for any manual clear-text cryptographic key-management operations supported by the payment application Prevention of unauthorized substitution of cryptographic keys The key management process where the most secure keys are loaded in a secure environment follows procedures defined by the PCI PIN Security Requirements and the specifications defined by acquiring banks. 2.6 Provide a mechanism to render irretrievable cryptographic key material or cryptograms stored by the payment application. Procedures detailing how to use the tool or procedure provided with the application to render cryptographic material irretrievable Instruction that cryptographic key material be rendered irretrievable whenever keys are no longer used and in accordance with key-management requirements in PCI DSS Instructions on how to re-encrypt historic data with new keys, including procedures for maintaining security of clear-text data during the decryption/reencryption process The payment application does not store any cryptographic key material or cryptograms. Page 10 of 16

3.1 Use unique user IDs and secure authentication for administrative access and access to cardholder data. Directions on how the payment application enforces strong authentication for any authentication credentials (for example, users, passwords) that the application generates or manages, by: - Enforcing secure changes to authentication credentials by the completion of installation per PA-DSS requirements 3.1.1 through 3.1.11 - Enforcing secure changes to authentication credentials for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1.11 That, to maintain PCI DSS compliance, any changes made to authentication configurations would need to be verified as providing authentication methods that are at least as rigorous as PCI DSS requirements Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts. How to change and create authentication credentials when such credentials are not generated or managed by the payment application, per PA-DSS Requirements 3.1.1 through 3.1.11, by the completion of installation and for subsequent changes after installation, for all application level accounts with administrative access or access to cardholder data. The payment application has no administrative access to any sensitive cardholder data. Any existing administrative access is used for common configuration of the terminal. 3.2 Use unique user IDs and secure authentication for access to PCs, servers, and databases with payment applications. Instruct customers and integrators/resellers to use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, per PA-DSS requirements 3.1.1 through 3.1.11 The payment application has no administrative access to any sensitive cardholder data. Any existing administrative access is used for common configuration of the terminal. 4.1 Implement automated audit trails. How to install the application so that logs are configured and enabled by default upon completion of the installation process How to set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4, for any logging options that are configurable by the customer after installation Logs must be enabled, and disabling the logs will result in non-compliance with PCI DSS. How to configure PCI-compliant log settings for any third-party software components packaged with or required by the payment application, for any logging options that are configurable by the customer after installation The payment application has transaction logs which can be accessed to see details such as date, time and amount. The logs does not show any sensitive cardholder data. The transaction logs cannot be turned on/off. Page 11 of 16

4.4 Facilitate centralized logging. Provide a description of which centralized logging mechanisms are supported, as well as instructions and procedures for incorporating the payment application logs into a centralized logging server The payment application transactions sent to the transaction host are logged into a centralized logging server. 5.4.4 Implement and communicate application versioning methodology. Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.) Details of how security-impacting changes will be indicated by the versioning scheme. Details of how other types of changes will affect the version Details of any wildcard elements that are used, including that they will never be used to represent a securityimpacting change The requirements is described in the beginning of the Implementation Guide under section versioning methodology. 6.1 Securely implement wireless technology. Instruction that the payment application enforces changes of default encryption keys, passwords, and SNMP community strings at installation for all wireless components controlled by the application Procedures for changing wireless encryption keys and passwords, including SNMP strings, anytime anyone with knowledge of the keys/passwords leaves the company or changes positions Instructions for changing default encryption keys, passwords, and SNMP community strings on any wireless components provided with, but not controlled by, the payment application Instructions to install a firewall between any wireless networks and systems that store cardholder data Details of any wireless traffic (including specific port information) that the wireless function of the payment application would use Instructions to configure firewalls to deny or (if such traffic is necessary for business purposes) permit only authorized traffic between the wireless environment and the cardholder data environment Any wireless network shall be setup and maintained as a secure wireless network at all times. If the merchant uses a wireless network within the office network the merchant must make sure to: 1. Always change all wireless vendor default settings of wireless encryption keys, passwords or SNMP community strings and other related security settings for any wireless product used in the network. 2. Always use a minimum of WPA2 for encryption for wireless traffic and never use any wireless network without encryption or any less secure encryption such as WEP. 3. Always install a firewall between the merchant wireless network and the point-of-sale equipment running a payment application. The firewall must be configured to only permit authorized traffic between the wireless environment and the payment application handling the cardholder data environment. 4. Always update firmware for any wireless products used in the network to support strongest possible encryption using IEEE 802.11i (WPA2) for authentication and data transmission over the wireless network. Page 12 of 16

5. Always change encryption keys and passwords for router/firewall settings or any other security issues each time an merchant employee leaves the company, have no need of knowing such security details or changing position where access to such security details are not needed anymore. 6. Always configure to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. 6.2 Secure transmissions of cardholder data over wireless networks. How to configure the application to use industry best practices (for example, IEEE 802.11.i) for strong encryption for authentication and transmission, and/or How to configure all wireless applications bundled with the payment application to use industry best practices for strong encryption for authentication and transmission Any wireless network shall be setup and maintained as a secure wireless network at all times. If the merchant uses a wireless network within the office network the merchant must make sure to: 1. Always change all wireless vendor default settings of wireless encryption keys, passwords or SNMP community strings and other related security settings for any wireless product used in the network. 2. Always use a minimum of WPA2 for encryption for wireless traffic and never use any wireless network without encryption or any less secure encryption such as WEP. 3. Always install a firewall between the merchant wireless network and the point-of-sale equipment running a payment application. The firewall must be configured to only permit authorized traffic between the wireless environment and the payment application handling the cardholder data environment. 4. Always update firmware for any wireless products used in the network to support strongest possible encryption using IEEE 802.11i (WPA2) for authentication and data transmission over the wireless network. 5. Always change encryption keys and passwords for router/firewall settings or any other security issues each time an merchant employee leaves the company, have no need of knowing such security details or changing position where access to such security details are not needed anymore. 6. Always configure to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. 6.3 Provide instructions for secure use of wireless technology. Instructions to change all wireless default encryption keys, passwords, and SNMP community strings upon installation Instructions to change wireless encryption keys, passwords, and SNMP strings anytime anyone with knowledge of the keys/passwords leaves the company or changes positions Instructions to install a firewall between any wireless networks and systems that store cardholder data, and to configure firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment Instructions to use industry best practices (for example, IEEE 802.11.i) to provide strong encryption for authentication and transmission Any wireless network shall be setup and maintained as a secure wireless network at all times. If the merchant uses a wireless network within the office network the merchant must make sure to: 1. Always change all wireless vendor default settings of wireless encryption keys, passwords or SNMP community strings and other related security settings for any wireless product used in the network. 2. Always use a minimum of WPA2 for encryption for wireless traffic and never use any wireless network without encryption or any less secure encryption such as WEP. Page 13 of 16

3. Always install a firewall between the merchant wireless network and the point-of-sale equipment running a payment application. The firewall must be configured to only permit authorized traffic between the wireless environment and the payment application handling the cardholder data environment. 4. Always update firmware for any wireless products used in the network to support strongest possible encryption using IEEE 802.11i (WPA2) for authentication and data transmission over the wireless network. 5. Always change encryption keys and passwords for router/firewall settings or any other security issues each time an merchant employee leaves the company, have no need of knowing such security details or changing position where access to such security details are not needed anymore. 6. Always configure to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. 8.2 Use only necessary and secure services, protocols, components, and dependent software and hardware, including those provided by third parties. Document all required protocols, services, components, and dependent software and hardware that are necessary for any functionality of the payment application. Any data sent over public networks are either TLS- and/or IPSec-encrypted. 9.1 Store cardholder data only on servers not connected to the Internet. Instructions not to store cardholder data on public facing systems (for example, web server and database server must not be on same server) Instructions on how to configure the payment application to use a DMZ to separate the Internet from systems storing cardholder data A list of services/ports that the application needs to use in order to communicate across two network zones (so the merchant can configure their firewall to open only required ports) No sensitive cardholder data are stored on any servers. Do not store cardholder data on public-facing systems. The merchant need to configure to allow network traffic over ports 990, 16021 and 30000 to 40000 for the payment application to function. 10.1 Implement two-factor authentication for remote access to payment application that originates from outside the customer environment. Instruction that all remote access originating from outside the customer s network to the payment application must use two-factor authentication in order to meet PCI DSS requirements Description of the two-factor authentication mechanisms supported by the application Instructions on how to configure the application to support two-factor authentication (two of the three authentication methods described in PA DSS Req. 3.1.4) There is no remote access allowed to the payment application. Page 14 of 16

All remote access originating from outside the customer s network to the payment application must use twofactor authentication. No action needed in payment application. 10.2.1 Securely deliver remote payment application updates. Instructions for activation of remote-access technologies for payment application updates only when needed for downloads, and turning access off immediately after download completes, per PCI DSS Requirement 12.3.9 Instructions that, if computer is connected via VPN or other high-speed connection, receive remote payment application updates via a securely configured firewall or personal firewall per PCI DSS Requirement 1 The payment application will initiate an update when needed by fetching software and parameters over secure Internet connection using secure FTP connection to PPL terminal management system following the PPL specification. The merchant need to make sure that a merchant managed PPL terminal management system or other third party PPL terminal management system have been implemented in a PCI DSS certified environment. 10.2.3 Securely implement remote access software. 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.11) Enable encrypted data transmission according to PA-DSS Requirement 12.1 Enable account lockout after a certain number of 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 Enable the logging function Restrict access to customer environments to authorized integrator/reseller personnel There is no remote access allowed to the payment application. The merchant need to make sure that a merchant managed PPL terminal management system or other third party PPL terminal management system have been implemented in a PCI DSS certified environment. 11.1 Secure transmissions of cardholder data over public networks. Required use of strong cryptography and security protocols if cardholder data is ever transmitted over public networks Instructions for verifying that only trusted keys and/or certificates are accepted How to configure the payment application to use only secure versions and secure implementations of security protocols How to configure the payment application to use the proper encryption strength for the encryption methodology in use Cardholder data is sent encrypted in the authorization message making the transaction end-to-end encrypted required by PNC, the E2EE requirement and the requirements described in the specification Security Requirements for an EFTPOS Terminal. The encrypted transaction is transferred to the bank hosts using TLS and IPSEC protocols to make it secure and not transferred on open public networks. Page 15 of 16

11.2 Encrypt cardholder data sent over end user messaging technologies. Procedures for using the defined solution to render the PAN unreadable or secure the PAN with strong cryptography Instruction that PAN must always be rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies There are no such messaging technologies. 12.1 Encrypt non-console administrative access. If the payment application facilitates non-console administrative access, include instructions on how to configure the application to use strong cryptography (such as SSH, VPN, or SSL/TLS) for encryption of all non-console administrative access to payment application or servers in cardholder data environment There is no administrative access in the payment application. 12.2 Encrypt non-console administrative access. Include instructions for customers and integrators/resellers to implement strong cryptography, using technologies such as SSH, VPN, or SSL/TLS, for encryption of all non-console administrative access There is no administrative access in the payment application. Page 16 of 16