4Go PA-DSS Implementation Guide - Amazon Web Services · UTG PA-DSS Implementation Guide. Once the...

Join us for treats Thursday, Month Day, at 3:00 p.m. in the kitchen.

PA-DSS Implementation Guide

Copyright © 2019 Shift4 Payments, LLC. All rights reserved.

4Go ®

4Go PA-DSS Implementation Guide

© 2019 Shift4 Payments, LLC. All rights reserved. Version 1.8 External Use NDA of 33

Copyright Notice

Shift4 Payments 1491 Center Crossing Road Las Vegas, NV 89144 702.597.2480

www.shift4.com [email protected] Document Title: 4Go® PA-DSS Implementation Guide Publication Date: 01/14/2019

Copyright © 2019 Shift4 Payments, LLC. All rights reserved worldwide.

Universal Transaction Gateway® (UTG®), 4Go®, and i4Go® are covered by one or more of the following U.S. Pat. Nos.: 7770789, 7841523, 7891563.

Shift4 Payments may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property except as expressly provided in any written license agreement from Shift4 Payments. All graphics are property of Shift4 Payments.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission from Shift4 Payments. The contents of this publication are proprietary information of Shift4 Payments. Shift4 Payments reserves the right to revise this document and to periodically make changes to the content thereof without any obligation or notification to any organization of such revisions or changes unless required to do so by prior written agreement.

Notice of Confidentiality

This document contains information that is proprietary to and/or confidential of Shift4 Payments. It carries the Shift4 Payments classification “External Use NDA.” It is provided for the sole purpose of specifying the point-of-sale interface to Shift4 Payments. The recipient agrees to maintain this information in confidence and not reproduce or otherwise disclose this information. Please refer to the signed Bilateral Non-Disclosure and Confidentiality Agreement for additional agreements and expectations.

Notice to Government End Users

If any Shift4 Payments product is acquired under the terms of a DoD contract: use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of 252.227-7013. Civilian agency contract: use, reproduction, or disclosure is subject to 52.227-19 (a) through (d) and restrictions set forth in the accompanying end user agreement. Unpublished rights reserved under the copyright laws of the United States.



Securing 4Go Shift4 Payments’ 4Go® is a payment application that operates in conjunction with Shift4 Payments’ Universal Transaction Gateway® (UTG®). To secure 4Go, the UTG must first be secured. For guidance in securing the UTG, please see the UTG PA-DSS Implementation Guide.

Once the UTG is securely installed and configured, 4Go can be enabled in the UTG, securely configured in Lighthouse Transaction Manager, and securely installed on the merchant’s terminals.

WARNING! Shift4 Payments must be held harmless for loss or compromise of cardholder data if the user disables or otherwise makes configuration state changes to the Shift4 Payments technology or integrated third party payment application that are not specified in the certification letter. In addition, any ability to store cardholder data subsequent to the initial authorization, encrypted or not, must be disabled in all locations.

Security Best Practices While Shift4 Payments products provide ironclad security of cardholder data when properly configured, there are other security best practices that must be enforced by the merchant to ensure cardholder data security. Review the following merchant responsibilities and refer to the PCI Security Standards Council website at www.pcisecuritystandards.org for more information.

WARNING! This section must not be construed as a roadmap or guide to PCI DSS compliance. See the PCI Security Council website at www.pcisecuritystandards.org for complete guidelines.

Environmental Requirements for Installing or Upgrading Payment Applications Before installing payment applications in your environment, you must ensure you are installing applications on clean hard disk drives with no latent files occupying unallocated free space.

If you are installing a payment application on a repurposed system or hard disk drive, you should first take steps to ensure the system is clean. There are several tools available for this purpose.

WARNING! Some of those system cleaning tools will erase everything, including the operating system.

http://www.pcisecuritystandards.org/

http://www.pcisecuritystandards.org/



Host System Guidelines From a security best practices perspective, Shift4 Payments recommends the following guidelines be followed in a Windows environment:

• The paging [swap] file must be set to a static size and the minimum and maximum sizes must be manually configured to be the same size.

Note: After configuring the paging [swap] file, Shift4 Payments recommends securely cleaning up your free space. This ensures any sensitive data stored by other applications used prior to, or in conjunction with Shift4 Payments' products is removed. There are several products available for this purpose.

o Although paging is a normal process performed by the Windows operating system, it can be considered a security risk if not properly controlled.

o Windows security prevents users from logging in and browsing the page file, but there is nothing to stop a user from booting an alternate operating system to circumvent Windows security and browse the page file.

• Memory dump files must be disabled.

o An attacker could invoke an abnormal termination of the payment application or the host system, perhaps with a buffer-overflow attack or with a simple request for the system to output a full memory dump, and can scan the crash dump files for sensitive data that would normally be encrypted. Tools such as Windows memory image toolkits, which may include aeskeyfind or rsakeyfind utilities, will also output any encryption keys if found in memory.

o As memory dumps are part of an operating system’s design, it’s unlikely that a security update would fix or prevent this type of attack.

o While it is unlikely the dump file will be needed to diagnose an error and restore the system, the dump file may also contain unencrypted PAN and sensitive authentication data.

• Hibernation must be disabled.

o Hibernation is a power-saving state designed for workstations and laptops. Hibernation captures everything in memory (RAM) and writes it to your hard disk as the hiberfil.sys file when the system goes to sleep. If you have 1GB of memory, the hiberfil.sys will be about 1GB. Like swap files, hibernation files may contain a significant amount of sensitive information.

o Sleep is also a power-saving state that allows a computer to quickly resume full-power operation (typically within several seconds) when you want to start working again. Putting your computer into the sleep state is like pausing a DVD player – the computer immediately stops what it is doing and is ready to start again when you want to resume working.

o The difference between sleep and hibernation is sleep puts your work and settings in memory and draws a small amount of power, and hibernation puts your open documents and programs on your hard disk and then turns off your computer.

o Hybrid sleep is a combination of sleep and hibernate – it puts any open documents and programs in memory and on your hard disk and then puts your computer into a low-power state so that you can quickly resume your work. That way, if a power failure occurs, Windows can restore your



work from your hard disk. When hybrid sleep is turned on, putting your computer into sleep automatically puts your computer into hybrid sleep. Hybrid sleep is typically turned on by default on desktop computers.

o Once again, any time data is written to disk there is a risk that latent data is permanently left behind.

• Restore points must be disabled on all relevant platforms.

o System Restore is a Windows feature that helps you undo changes made to a computer’s operating system files. The restore process attempts to return the computer to a saved configuration from an earlier point in time.

o When a computing system is restored to an earlier state, important updates such as new antimalware definitions and security patches may be removed. You may also rollback an otherwise compliant payment application to a vulnerable state.

Networking Guidelines 4Go must be installed in a trusted network segment, not the DMZ, to avoid exposing data to corruption or theft. Shift4 Payments recommends that all servers and stations be located on a dedicated subnet and protected from the internet by a firewall.

Wireless Implementations Shift4 Payments recommends avoiding the use of wireless networks because they are generally less secure than wired networks. However, in the event that wireless networks must be used, the following guidelines are recommended to ensure compliance with PCI DSS Requirement 4.1.1:

1. Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment use strong encryption. This can be achieved by using WPA2/CCMP instead of WPA/TKIP or WPA2/TKIP. Never use WEP.

2. Change the default service set identifier (SSID) on the wireless router.

3. Configure your wireless router to never broadcast the SSID.

4. Use static, RFC 1918 and RFC 4193 compliant IP addresses on all wireless nodes.

5. Enable MAC address filtering on the wireless router to guard against IP spoofing.

6. Set up the wireless router’s access control list (ACL) to whitelist only the wireless nodes (IP and MAC address pairs) that are allowed to connect. Deny connection requests by all others.

7. All other wireless access points not part of the payment system must be logically segregated from the cardholder trusted network segment by a firewall.

Remote Access Never install hardware or software that is not required, such as remote access mechanisms. If it must be installed, remote access to the cardholder data environment (CDE), which includes the payment application, must be restricted to only those individuals that require access to do their job. Remote access to the CDE must also be authenticated with two-factor authentication in accordance with PCI DSS Requirement 8.3. Ensure all remote users have unique usernames and passwords. Remote access activity by vendors and contractors must be monitored. Deactivate their user accounts when not in use.



System Privileges Administrative access is required to install all Shift4 Payments products in the Shift4 Payments branch of the installation directory, with “directory create” permissions, “file change” permissions, and complete “read/write” permissions for the HKEY_LOCAL_MACHINE\SOFTWARE\Shift4 Corporation folder in the Registry.

Default Passwords Passwords for user accounts must be strong strings of at least seven alphanumeric characters, which is the PCI DSS minimum. Eight or more characters with numbers, a mix of uppercase and lowercase letters, and special characters would be considered a strong password. Never use dictionary words or the username for passwords. Refer to PCI DSS Requirement 8.5 for all password minimum security standards. Do not use vendor-provided, default passwords. Doing so will render your system vulnerable and violate PCI DSS Requirement 2.

Log Data PCI DSS Requirement 10 requires that all log data be retained for a minimum of 12 months. Configure all log settings to ensure compliance. It may be necessary to incorporate an offline storage procedure (tape, DVD, etc.) to reduce the amount of disk space used to store log data and still comply with the PCI DSS logging requirement.

Prior Data Sanitization All files retaining sensitive cardholder data must be deleted after 4Go has been successfully installed and configured. Most of the sensitive information is found in old log files and journals. The logging and journal features in the system must also be modified to prevent the creation of new, non-secure records.

File Integrity Monitoring The File Integrity Monitoring section of this document is designed to provide the necessary 4Go file information to set up file integrity monitoring in compliance with PCI DSS standards. The PCI DSS Version 2.0, Requirement 11.5 states: Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

The following matrix lists the currently installed files by the 4Go installer. This matrix assumes a default install directory of C:\Shift4 which can be changed by the customer during installation.

Files and Objects Included in the Installer

Changes on Version Upgrade

Changes on Configuration Change to

Terminal Settings in DOTN

C:\Shift4\4Go\4Go.exe Yes Yes No

C:\Shift4\4Go\4Go-4.ico Yes Yes No

C:\Shift4\4Go\4Go-Go.ico Yes Yes No







C:\Shift4\4Go\4GoLaunch.exe Yes Yes No

C:\Shift4\4Go\4GoLaunch.ini Yes Yes Yes

C:\Shift4\4Go\4GoMSG.dll Yes Yes No

C:\Shift4\4Go\4GoRestart.exe Yes Yes No

C:\Shift4\4Go\4GoRUN.dll Yes Yes No

C:\Shift4\4Go\4GoRun64.dll Yes Yes No

C:\Shift4\4Go\4GoTray.exe Yes Yes No

C:\Shift4\4Go\Manifest Yes Yes No

C:\Shift4\4Go\S4.ico Yes Yes No

C:\Shift4\4Go\Documentation\4Go PA-DSS Implementation Guide.pdf Yes Yes No

C:\Shift4\4Go\Documentation\4Go Reference Guide.pdf Yes Yes No

C:\Shift4\4Go\Documentation\4Go Technical Installation Guide.pdf Yes Yes No

C:\Shift4\4Go\Driver\s4wf.sys Yes Yes No

C:\Shift4\4Go\Driver\s4wf-usb.inf Yes Yes No

C:\Shift4\4Go\Utils \ShredAndDelete.exe Yes Yes No







HKEY_LOCAL_MACHINE\SOFTWARE\Shift4 Corporation Yes Yes Yes



System-Level Object Logging (PA-DSS Requirement 4.2.7)

PA-DSS Requirement 4.2.7 A payment application must provide an audit trail to reconstruct the following events: Creation and deletion of system-level objects within or by the application.

A system-level object is defined as anything on a system component that is required for its operation, including but not limited to application executable and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files, and added third-party components.

An Audit Trail or Audit Log is defined as a chronological record of system activities. It provides an independently verifiable trail sufficient to permit reconstruction, review, and examination of sequence of environments and activities surrounding or leading to operation, procedure, or event in a transaction from inception to final results.

In order to meet this requirement it is necessary to set up auditing for the “Everyone” Group on the objects detailed in the File Integrity Monitoring Section.

Microsoft Windows Server 2008, Server 2008 R2, Vista, and Windows 7

To Enable Object Access Auditing

1. Click Start, click Control Panel and Administrative Tools, and then double-click Local Security Policy.

2. In the Navigation pane, select Local Policies.

3. In the Navigation pane, select Audit Policy.

4. In the File list, double-click Audit object access.

5. Select the Success option.

6. Click OK.



To Apply or Modify Auditing Policy Settings for a Local File or Folder

1. Open Windows Explorer.

2. Right-click the file or folder that you want to audit, click Properties, and then click the Security tab.

3. Click Advanced. (If you are not logged on as a member of the Administrators group on this computer, you must provide administrative credentials to proceed.)

4. In the Advanced Security Settings for <object> dialog window, click the Auditing tab.

5. Click Add. In the Enter the object name to select field, enter “Everyone” and then click OK.

6. In the Apply onto field, select the location where you want auditing to take place.

7. In the Access section, indicate what actions you want to audit by selecting the appropriate options:



To Audit Activity on a Registry Key

1. Open Registry Editor.

2. Click the key you want to audit.

3. On the Edit menu, click Permissions.

4. Click Advanced, and then click the Auditing tab.

5. Click Add.

6. Enter “Everyone”.

7. In the Access section, select or clear the Successful and Failed options for the activities that you want to audit or to stop auditing.

8. When you have finished making your changes, click OK.



Additional Considerations

• You must be logged on as a member of the Administrators group or you must have been granted the Manage auditing and security log right in Group Policy to perform this procedure.

• To open Windows Explorer, click Start, point to All Programs, click Accessories, and then click Windows Explorer.

• After object access auditing is enabled, view the security log in Event Viewer to review the results of your changes.

• You can set up file and folder auditing only on NTFS drives.

• If you see either of the following, auditing has been inherited from the parent folder:

o In the Auditing Entry for <File or Folder> window, in the Access section, the options (checkboxes) are unavailable.

o In the Advanced Security Settings for <File or Folder> window, the Remove button is unavailable.



Object Deleted by User Event



Object Created by Application Event



Microsoft Windows Server 2012 and Windows 8


1. Click Administrative Tools, and then click Local Security Policy.

2. Select Local Policies.

3. In the console tree, click Audit Policy.

o Security Settings/Local Policies/Audit Policy

4. In the results pane, double-click Audit object access.


To Apply or Modify Auditing Policy Settings for a Local File or Folder



3. Click Advanced. (If you are not logged on as a member of the Administrators group on this computer, you must provide administrative credentials to proceed.)

4. In the Advanced Security Settings for <object> window, click the Auditing tab.

5. Select Continue.

6. Click Add.

7. Click Select a principal.

8. In the Enter the object name to select field, enter “Everyone” and then click OK.

9. Select Show advanced permissions.










5. Click Add.

6. Click Select a principal.

7. In the Enter the object name to select field, enter “Everyone” and then click OK.

8. Select Show advanced permissions.

9. Select the Successful options for the activities that you want to audit.



Object Deleted by User Event



Object Created by Application Event



Server 2003 and Server 2003 R2


1. Click Start, point to Administrative Tools, and then click Local Security Policy.

2. Select Local Policies. 3. In the console tree, click Audit Policy.

o Security Settings/Local Policies/Audit Policy

4. In the results pane, double-click Audit object access.


To Apply Auditing Policy Settings for a Local File or Folder




4. Click Add. In the Enter the object name to select field, enter “Everyone” and then click OK.










5. Enter Everyone.




Object Deleted by User Event Chain



Object Created by Application Event Chain



Windows XP

Auditing User Access of Files, Folders, and Printers

The audit log appears in the Security log in Event Viewer. To enable this feature:

1. Click Start, click Control Panel, click Performance and Maintenance, and then click Administrative Tools.

2. Double-click Local Security Policy.

3. In the left pane, double-click Local Policies to expand it.

4. In the left pane, click Audit Policy to display the individual policy settings in the right pane.

5. Double-click Audit object access.

6. Select the Success option to audit successful access of specified files, folders, and printers.

7. Click OK.

Specifying Files, Folders, and Printers to Audit

After you enable auditing, you can specify the files, folders, and printers that you want audited. To do so:

1. In Windows Explorer, locate the file or folder you want to audit.

2. Right-click the file, folder, or printer that you want to audit, and then click Properties.

3. Click the Security* tab, and then click Advanced.

4. Click the Auditing tab, and then click Add.

5. In the Enter the object name to select field, enter “Everyone”. You can browse the computer for names by clicking Advanced, and then clicking Find Now in the Select User or Group window.

6. Click OK.

7. Select the Successful or Failed options for the actions you want to audit, and then click OK.

8. Click OK, and then click OK.

*If the Security tab is not present, open Control Panel\Folder Options\View and clear the “Use simple file sharing (Recommended)” option.


1. Open Registry Editor




5. Enter “Everyone”.




Object Deleted by User Event Chain



Object Created by Application Event Chain

\



PA-DSS Requirements and Responsibility Matrix The following matrix represents your guide to PA-DSS implementation.

WARNING! This matrix must not be construed as a road map to PCI DSS or PA-DSS compliance or a guarantee that Shift4 Payments will render a merchant PCI DSS or PA-DSS compliant.

PA-DSS Requirement Responsible Party Details

1. Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data after authorization.

Aligns with PCI DSS Requirement 3.2

Shift4 Payments

4Go terminals do not store this information on disk unless 4Go is set to diagnostic mode which requires involvement by Shift4 Payments.

The customer will be reminded that they have a 4Go terminal set to diagnostic mode every time they log in to Lighthouse Transaction Manager and every time 4Go is displayed on the terminal.

Merchant

The merchant is responsible for disabling diagnostic mode in Lighthouse Transaction Manager after they have gathered the appropriate trace files and sent them to Shift4 Payments via a secure mechanism.

The merchant must use the Shift4 Payments Shred and Delete Utility to securely delete any data from disk after a terminal is no longer set to diagnostic mode.

The Shift4 Payments Shred and Delete Utility will be installed with 4Go in the utils directory or it can be downloaded at:

www.shift4.com/downloads/shredanddelete.exe.




1.1.5. Securely delete any sensitive authentication data (pre-authorization data) used for debugging or troubleshooting purposes from log files…


Shift4 Payments

When debugging and/or troubleshooting an issue for a merchant, Shift4 Payments Customer Service team will direct the merchant to email the application trace file to [email protected].

The trace file does not contain sensitive authentication data and/or cardholder data because that information is not written to the trace file by Shift4 Payments applications.

Local operating procedures require the deletion of all trace files when closing a support case because the data is no longer needed.

2.1 Software vendor must provide guidance to customers regarding purging of cardholder data after expiration of customer-defined retention period.


Shift4 Payments

4Go does not store post-authorization cardholder data.

All cardholder data is maintained in Shift4 Payments’ PCI DSS compliant data center and is automatically purged based on customer-defined data retention policies.

2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).


Merchant

When configuring 4Go in Lighthouse Transaction Manager, the merchant must enable Mask Card Input, thus ensuring 4Go masks the PAN when swiped or manually entered on the 4Go terminal.

2.3 Render PAN unreadable anywhere it is stored, (including data on portable digital media, backup media, and in logs)


N/A 4Go does not store the PAN.

2.4 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms…

Aligns with PCI DSS Requirement 3.4.1

N/A 4Go does not use disk encryption utilities. 4Go does not store post-authorization cardholder data.

mailto:[email protected]




2.5 Payment application must protect any keys used to secure cardholder data against disclosure and misuse.


Shift4 Payments

The cryptographic key used to encrypt the data between the UTG and 4Go is generated by the UTG. When 4Go starts, it sends a request to the UTG for its encryption key. The encryption key is never written to disk.

Merchant The UTG generates a new 4Go encryption key every time it starts. It is recommended that the merchant restart the UTG at least monthly.

2.6 Payment application must implement key management processes and procedures for cryptographic keys used for encryption of cardholder data.


N/A 4Go and the UTG automatically negotiate keys through a handshake process.

2.7 Render irretrievable any cryptographic key material or cryptogram stored by previous versions of the payment application…


N/A 4Go does not store cryptographic key material or cryptograms.

3.1 The payment application must support and enforce the use of unique user IDs and secure authentication for all administrative access and for all access to cardholder data…

Aligns with PCI DSS Requirements 8.1, 8.2, and 8.5.8–8.5.15

N/A

4Go administration is done in Lighthouse Transaction Manager with unique user IDs.

4Go does not provide access to cardholder data and does not store post-authorization cardholder data.

3.2 Software vendor must provide guidance to customers that all access to PCs, servers, and databases with payment applications must require a unique user ID and secure authentication.

Aligns with PCI DSS Requirements 8.1 and 8.2

Merchant The merchant must control access to 4Go terminals by using unique user IDs and passwords in accordance with PCI DSS Requirement 8.




3.3 Render payment application passwords unreadable during transmission and storage, using strong cryptography based on approved standards.


N/A

4.1 At the completion of the installation process, the “out of the box” default installation of the payment application must log all user access…


Merchant

4Go does not have a user database.

The merchant must ensure that they provide individual operating system account profiles to their employees and must have a way to monitor their activity.

4.2 Payment application must implement an automated audit trail to track and monitor access.

Aligns with PCI DSS Requirements 10.2 and 10.3

Merchant

Since 4Go does not store cardholder data, this generally does not apply. However, PA-DSS Requirement 4.2.7 requires the merchant to implement Windows Object Level Auditing and File Integrity Monitoring; refer to Microsoft for implementation instructions specific to your Windows version.

The "File Integrity Monitoring" section in this document lists files, directories, and objects that must be monitored.

The "System-Level Object Logging" section in this document provides detailed instructions on how to setup system object auditing for your Windows version. Also refer to Microsoft technical reference guides.

4.3 Payment application must record at least the following audit trail entries for each event…


Merchant

The merchant is responsible to record all audit trail entries for all system components for each event listed in PA-DSS Requirements 4.3.1 through 4.3.6.

Automated transaction audit trail information is maintained in Lighthouse Transaction Manager.




4.4. Payment application must facilitate centralized logging.


Shift4 Payments

4Go locally writes events to the trace file. This file does not contain sensitive authentication data and/or cardholder data.

Merchant The merchant is responsible for monitoring the trace file and for all other centralized logging requirements.

5.1 The software vendor develops payment applications in accordance with PCI DSS and PA-DSS…


Shift4 Payments

4Go has been developed in accordance with the Shift4 Payments Software Development Life Cycle and secure coding best practices.

5.2 Develop all web payment applications (internal and external, and including web administrative access to product) based on secure coding guidelines…


N/A 4Go is not a web application.

5.3 Software vendor must follow change control procedures for all product software configuration changes.


Shift4 Payments

Change controls for 4Go are in accordance with the Shift4 Payments Change Control policy.

5.4 The payment application must only use or require use of necessary and secure services, protocols, daemons, components, and dependent software and hardware…


Shift4 Payments

4Go does not require the use of unnecessary and insecure services and protocols.

6.1 For payment applications using wireless technology, change wireless vendor defaults…

Aligns with PCI DSS Requirements 1.2.3 and 2.1.1

Merchant

Shift4 Payments strongly recommends that merchants do not use any wireless connections for credit card transaction processing. If the merchant requires the use of wireless devices, the use of strong encryption technology for authentication and transmission is also required in accordance with PCI DSS Requirement 2.1.1.




6.2 For payment applications using wireless technology, payment application must facilitate use of industry best practices…


Merchant Refer to PA-DSS Requirement 6.1 details.

7. Test payment applications to address vulnerabilities.

Shift4 Payments

4Go has been developed in accordance with the Shift4 Payments Software Development Life Cycle and secure coding best practices that aligns with PCI DSS Requirement 6.

8. The payment application must be able to be implemented into a secure network environment. Application must not interfere with use of devices, applications, or configurations required for PCI DSS compliance…

Aligns with PCI DSS Requirements 1, 3, 4, 5, and 6

Shift4 Payments

4Go will not interfere with anti-virus software, firewall configurations, or any other device, application, or configuration required for the merchant’s cardholder data environment.

Merchant The merchant is responsible for installing 4Go on terminals within the cardholder data environment of the trusted network.

9. Cardholder data must never be stored on a server connected to the internet.

Shift4 Payments

4Go does not store post-authorization cardholder data.

Merchant The merchant must not store cardholder data on the 4Go terminal. 4Go must be installed inside the trusted network, never the DMZ.

10.1 The payment application must not interfere with use of two-factor authentication technologies for secure remote access…


Shift4 Payments

4Go will not interfere with two-factor authentication technologies.




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.


Merchant The merchant is responsible for incorporating two-factor authentication for remote access to the network as specified in PA-DSS Requirement 10.1.

10.3.1 If payment application updates are delivered via remote access into customers’ systems, software vendors must tell customers to turn on remote-access technologies only when needed for downloads…

Aligns with PCI DSS Requirements 1 and 12.3.9

Shift4 Payments

When remote support by Shift4 Payments is necessary, the customer will receive a one-time use session key from Shift4 Payments’ remote support tool which is hosted by Shift4 Payments.

The customer will then use that session key to download and install remote connection software on their system.

Through an outbound connection from the customer’s system to Shift4 Payments, the customer will enable remote support.

After the support session is terminated by Shift4 Payments or the customer, the remote connection software on the customer’s system automatically uninstalls itself.

A remote connection to the customer’s system is no longer possible unless a new, one-time session key is issued and the remote connection software is reinstalled.

10.3.2 If vendors, resellers/integrators, or customers can access customers’ payment applications remotely, the remote access must be implemented securely.


Merchant The merchant must ensure any remote access is implemented securely.

11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security…


Shift4 Payments

4Go must not be configured to send cardholder data over public networks; however, 4Go always uses strong cryptography when transmitting cardholder data across any network.




11.2 If the payment application facilitates sending of PANs by end-user messaging technologies…


Shift4 Payments

4Go does not facilitate sending PANs via end-user messaging technologies.

12. Encrypt all non-console administrative access.


Shift4 Payments

4Go administration is done in Lighthouse Transaction Manager using an SSL connection.

The settings are encrypted before being downloaded to 4Go.

Merchant

The merchant is responsible for encrypting all other non-console administrative access to the 4Go terminals in accordance with PA-DSS Requirement 12.

13. Maintain instructional documentation and training programs for customers, resellers, and integrators.

Shift4 Payments

Shift4 Payments provides this guide that facilitates the implementation of PA-DSS requirements.

Shift4 Payments performs a review of this document at least annually and updates the guide to keep it current with software changes.

4Go PA-DSS Implementation Guide - Amazon Web Services · UTG PA-DSS Implementation Guide. Once the...

Documents

Transcript of 4Go PA-DSS Implementation Guide - Amazon Web Services · UTG PA-DSS Implementation Guide. Once the...