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

PCI PA-DSS Implementation Guide Onslip PAYAPP V2.0 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 Page 2 of 12

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

Table of Contents REVISION HISTORY 2 REFERENCES 3 INTRODUCTION 6 BACKGROUND 6 PURPOSE 6 USAGE FEL! BOKMÄRKET ÄR INTE DEFINIERAT. ABBREVIATIONS 6 PA-DSS REQUIREMENTS 7 1.1.4 DELETE SENSITIVE AUTHENTICATION DATA STORED BY PREVIOUS PAYMENT APPLICATION VERSIONS 7 7 7 1.1.5 DELETE SENSITIVE AUTHENTICATION DATA STORED BY PREVIOUS PAYMENT APPLICATION VERSIONS 7 7 7 2.1 PURGE CARDHOLDER DATA AFTER CUSTOMER-DEFINED RETENTION PERIOD. 7 7 8 2.5 PROTECT KEYS USED TO SECURE CARDHOLDER DATA AGAINST DISCLOSURE AND MISUSE. 8 8 8 2.6 IMPLEMENT KEY MANAGEMENT PROCESSES AND PROCEDURES FOR CRYPTOGRAPHIC KEYS USED FOR ENCRYPTION OF CARDHOLDER DATA. 8 8 8 2.7 RENDER IRRETRIEVABLE CRYPTOGRAPHIC KEY MATERIAL OR CRYPTOGRAMS STORED BY PREVIOUS PAYMENT APPLICATION VERSIONS. 8 8 8 3.1 USE UNIQUE USER IDS AND SECURE AUTHENTICATION FOR ADMINISTRATIVE ACCESS AND ACCESS TO CARDHOLDER DATA. 8 9 9 3.2 USE UNIQUE USER IDS AND SECURE AUTHENTICATION FOR ACCESS TO PCS, SERVERS, AND DATABASES WITH PAYMENT APPLICATIONS. 9 9 9 4.1 IMPLEMENT AUTOMATED AUDIT TRAILS. 9 9 9 4.4 FACILITATE CENTRALIZED LOGGING. 9 9 9 5.4 USE ONLY NECESSARY AND SECURE SERVICES, PROTOCOLS, COMPONENTS, AND DEPENDENT SOFTWARE AND HARDWARE, INCLUDING THOSE PROVIDED BY THIRD PARTIES. 9 9 10 6.1 SECURELY IMPLEMENT WIRELESS TECHNOLOGY. 10 10 10 Page 4 of 12

6.2 SECURE TRANSMISSIONS OF CARDHOLDER DATA OVER WIRELESS NETWORKS. 10 10 10 9.1 STORE CARDHOLDER DATA ONLY ON SERVERS NOT CONNECTED TO THE INTERNET. 10 11 11 10.2 IMPLEMENT TWO-FACTOR AUTHENTICATION FOR REMOTE ACCESS TO PAYMENT APPLICATION. 11 11 11 10.3.1 SECURELY DELIVER REMOTE PAYMENT APPLICATION UPDATES. 11 11 11 10.3.2 SECURELY IMPLEMENT REMOTE ACCESS SOFTWARE. 11 11 11 11.1 SECURE TRANSMISSIONS OF CARDHOLDER DATA OVER PUBLIC NETWORKS. 11 11 12 11.2 ENCRYPT CARDHOLDER DATA SENT OVER ENDUSER MESSAGING TECHNOLOGIES. 12 12 12 12.1 ENCRYPT NON-CONSOLE ADMINISTRATIVE ACCESS. 12 12 12 Page 5 of 12

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. 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 6 of 12

PA-DSS Requirements 1.1.4 Delete sensitive authentication data stored by previous payment application versions Historical data must be removed (magnetic stripe 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. The merchant is responsible to make sure that any historical cardholder data (magnetic stripe data, card verification codes, Pins or Pin blocks) is removed from all surrounding storage devices used in the merchant s computers, ECRs, data storage or electronic cash registers. 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 sensitive authentication data stored by previous payment application versions 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 historical cardholder data in the payment application from any processed and transmitted card transaction. The payment application will check if there exist any store-andforward (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 Purge cardholder data after customer-defined retention period. Cardholder data must be purged after it exceeds the customer-defined retention period All locations where payment application stores cardholder data 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. Page 7 of 12

2.5 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. 2.6 Implement key management processes and procedures for cryptographic keys used for encryption of cardholder data. How to securely generate, distribute, protect, change, store, and retire/replace encryption keys, where customers or resellers/integrators are involved in these key management activities. A sample Key Custodian form for key custodians to acknowledge that they understand and accept their key-custodian responsibilities. How to perform key management functions defined in PA-DSS requirements 2.6.1 through 2.6.7. 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.7 Render irretrievable cryptographic key material or cryptograms stored by previous payment application versions. Cryptographic material must be rendered irretrievable How to render cryptographic material irretrievable Such irretrievability is absolutely necessary for PCI compliance How to re-encrypt historic data with new keys The payment application does not store any cryptographic key material or cryptograms. 3.1 Use unique user IDs and secure authentication for administrative access and access to cardholder data. That the payment application enforces secure authentication for any authentication credentials (e.g. users, passwords) that the application generates by: - Enforcing secure changes to authentication credentials by the completion of installation and for any subsequent changes (after installation) per PA-DSS requirements 3.1.1 through 3.1. Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts. Page 8 of 12

How to change and create authentication credentials when such credentials are not generated or managed by the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15, 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. Use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, PA-DSS requirements 3.1.1 through 3.1.10. 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. Set PCI DSS-compliant log settings, per PA-DSS Requirements 4.2, 4.3 and 4.4 Logs must be enabled, and disabling the logs will result in non-compliance with PCI DSS. The payment application has no administrative access to any sensitive cardholder data. 4.4 Facilitate centralized logging. Provide instructions and procedures for incorporating the payment application logs into a centralized logging server. The payment application has no administrative access to any sensitive cardholder data. 5.4 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 SSL/TLS- or IPSec-encrypted. Page 9 of 12

6.1 Securely implement wireless technology. If wireless is used within payment environment: Change wireless vendor defaults, including default wireless encryption keys, passwords, and SNMP community strings Install a firewall: - Between any wireless networks and systems that store cardholder data, and - Configured to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into 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 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. 4. Always change encryption keys, 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. 5. 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. If payment application is implemented into a wireless environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission of cardholder data. 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 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. 4. Always change encryption keys, 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. 5. 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. 9.1 Store cardholder data only on servers not connected to the Internet. Do not store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server). Page 10 of 12

No sensitive cardholder data are stored on any servers. 10.2 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. There is no remote access allowed to the payment application. 10.3.1 Securely deliver remote payment application updates. Activate remote-access technologies for payment application updates only when needed for downloads, and turn off immediately after download completes, per PCI DSS Requirement 12.3.9. 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.3.2 Securely implement remote access software. Implement and use remote access software security features if remote access software is used to remotely access the payment application or payment environment. There is no remote access allowed to the payment application. 11.1 Secure transmissions of cardholder data over public networks. Implement and use strong cryptography and security protocols for secure cardholder data transmission over public networks. 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 SSL and IPSEC protocols to make it secure and not transferred on open public networks. Page 11 of 12

11.2 Encrypt cardholder data sent over enduser messaging technologies. Implement and use a solution that renders the PAN unreadable or implements strong cryptography if PANs can be sent with end-user messaging technologies. There are no such messaging technologies. 12.1 Encrypt non-console administrative access. Implement and use 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. There is no remote access allowed to the payment application. Page 12 of 12