Assessment of Shift4’s True P2PE™ Solution Payment Card ... · Shift4 offers a robust suite of payment card gateway solutions for merchants, including tokenization, and is EMV

Assessment of Shift4’s True P2PE™ Solution

Payment Card Industry Technical Assessment Merchant Environment Impact

Report Date: March 4, 2016

Table of Contents

Executive Summary ............................................................................................. 4

About PCI DSS 3.1 ........................................................................................................... 5

About P2PE ...................................................................................................................... 6

Shift4 True P2PE™ Overview ............................................................................. 7

Deployment Scenarios ...................................................................................................... 8

POS with 4GO® ............................................................................................................ 8

POS with UTG® ............................................................................................................ 9

Mobile with VT4™ ....................................................................................................... 10

Assessment Scope ......................................................................................................... 10

Assessment Methodology ............................................................................................... 11

Detailed Technical Analysis ............................................................................. 13

Merchant Environment PCI DSS Scope Impact .............................................. 15

Merchant PCI DSS 3.1 Scope Reduction Summary ....................................................... 15

PCI DSS 3.1 Impact Detail by Applicable Requirement .................................................. 17

PCI DSS 3.1 Requirement 1: Install and maintain a firewall configuration to protect cardholder data ........................................................................................................... 17

PCI DSS 3.1 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters .................................................................. 18

PCI DSS 3.1 Requirement 3: Protect Stored Cardholder Data ................................... 21

PCI DSS 3.1 Requirement 4: Encrypt transmission of cardholder data across open, public networks ............................................................................................................ 21

PCI DSS 3.1 Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs ....................................................................... 22

PCI DSS 3.1 Requirement 6: Develop and maintain secure systems and applications .................................................................................................................................... 23

PCI DSS 3.1 Requirement 7: Restrict access to cardholder data by business need to know ............................................................................................................................ 26

PCI DSS 3.1 Requirement 8: Identify and authenticate access to system components .................................................................................................................................... 28

PCI DSS 3.1 Requirement 9: Restrict physical access to cardholder data ................. 33

PCI DSS 3.1 Requirement 10: Track and monitor all access to network resources and cardholder data ........................................................................................................... 38

PCI DSS 3.1 Requirement 11: Regularly test security systems and processes ......... 41

PCI DSS 3.1 Requirement 12: Maintain a policy that addresses information security for all personnel ........................................................................................................... 45

PCI P2PE 2.0 Domain 1 Analysis ...................................................................... 49

PCI P2PE 2.0 Domain 1 Encryption Device & Application Management Summary ....... 49

PCI P2PE 2.0 Domain 1 Encryption Device & Application Management Detail ............. 51

Conclusion ......................................................................................................... 78

Executive Summary Shift4 is a privately held, self-funded, Nevada company that provides high-speed, reliable, secure, and PCI-compliant connectivity to a merchant’s payment processor of choice. Shift4 is a leading provider of security technology that enables electronic payment transactions and value-added services at the point of sale and during settlement. Shift4 offers a robust suite of payment card gateway solutions for merchants, including tokenization, and is EMV ready. The inventor of tokenization as it applies to the Payment Card Industry, Shift4 has tokenized over 6 billion transactions since 2005. Shift4 is a Level 1 service provider in the Payment Card Industry and offers a P2PE solution that can reduce risk and PCI DSS scope for merchants.

Shift4 Corporation engaged Dara Security, an information security services firm and Payment Card Industry (PCI) Qualified Security Assessor (QSA), Payment Application QSA (PA-QSA), and Point-to-Point Encryption QSA (P2PE-QSA) company, to conduct an independent technical security assessment of Shift4’s True P2PE™ solution to assess the security of the solution for provider and payers and to evaluate the solution in comparison to PCI P2PE 2.0 Domain 1 for Encryption Device and Application Management.

Dara Security’s responsibility is to express an opinion on the security efficacy of the True P2PE solution based on the technical presentations and documentation provided by Shift4. For the PCI P2PE 2.0 evaluation, we conducted our examination in accordance with testing standards provided in the PCI P2PE Solution Requirements and Testing Procedures Version 2.0 (Revision 1.1) published July 2015, on the suitability of the design and operating effectiveness of the True P2PE™ solution’s ability to meet Encryption Device and Application Management.

The following findings are relevant highlights from this assessment.

• True P2PE™ integrates securely with any computer that has access to the Shift4 service without exposing cardholder data to other systems.

• In order to reduce the amount of applicable controls during a PCI DSS audit, the True P2PE™ supported, PTS-approved devices must be the only point where cardholder data is captured, either through swiped or keyed entry.

• True P2PE™ with secure point of interaction (POI) devices could alleviate any applicable controls involved with the PCI DSS compliance requirements for network firewall, network configuration, physical controls or administrative procedures for a merchant.

• When True P2PE™ is properly deployed, it can almost completely eliminate the risk of a data breach within the merchant environment.

• To best mitigate security and compliance risk, a merchant’s deployment

architecture must: 1) have all cardholder data captured by a supported PTS-approved device via True P2PE™; and 2) communicate directly with Shift4 which manages all decryption services.

• A merchant can reduce the amount of applicable controls of PCI DSS compliance requirements required for the majority of its CDE if all cardholder data is captured by the supported POI devices and no decryption appliances or decryption keys exist in the merchant’s CDE.

This white paper has three target audiences:

• Merchants interested in using a P2PE solution to reduce PCI DSS compliance scope.

• The QSA and Internal Audit community that is evaluating True P2PE™ or its impact on scope of PCI DSS compliance in general on behalf of merchant or service provider clients.

• Acquiring banks and merchant service providers concerned with merchants’ credit card processing risk profile.

About PCI DSS 3.1

The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitates the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

PCI DSS comprises a minimum set of requirements for protecting account data, and may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations. The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with applicable PCI DSS requirements. PCI DSS requirements apply to organizations where account data (cardholder data and/or sensitive authentication data) is stored, processed or transmitted. The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE)

is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or

management of their CDE. Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the third party per the applicable PCI DSS requirements protects the account data. About P2PE

P2PE 2.0 is standard developed by the card brands and the PCI SSC. P2PE is standard designed to work hand-in-hand with PCI DSS. P2PE is a methodology for securing credit card data by encrypting it from the time a card is swiped until it reaches the payment processor where it is decrypted. When implemented properly, these types of solutions make payment card transactions more secure by preventing the theft of credit card data while unencrypted on a POS device, or in transit.

Point-to-point encryption is designed to encrypt cardholder data at the time of swipe point-of-interaction (POI) utilizing an encryption key that is built in to the POI. Once encrypted, sensitive cardholder data is not decrypted until it arrives at a secured end point, typically an acquirer, processor or gateway. By using P2PE, account data (cardholder data and sensitive authentication data) is unreadable until it reaches the secure decryption environment, which makes it less valuable if the data is stolen in a breach. By encrypting cardholder data at the POI, merchants can significantly reduce the risk of a data breach and the scope of PCI DSS compliance requirements.

Shift4TrueP2PE™OverviewShift4 has three methods available to initiate a True P2PE™ transaction: POS with 4Go®, POS with UTG®, and mobile. In each case, all cardholder data is captured by one of the supported PTS validated POI devices when the merchant swipes, manual enters, or utilizes contactless or Chip & PIN entry. Components needed for the True P2PE™ are:

1. One of the supported PTS validated POI Devices: a. ID Tech

i. SecuRED

ii. SREDKey

b. Ingenico

i. iSC 250

ii. iSC 350

iii. iSC 480

iv. iPP 320

v. iPP 350

vi. iWL 252

vii. iWL 257

viii. iCMP

ix. iSMP

x. iUP 250

xi. iUR 250

xii. iUR 150

c. Verifone

i. MX 915

ii. MX 925

2. Shift4 provided software consisting of: a. POS with 4Go®

b. POS with UTG®

c. Mobile with VT4™

DeploymentScenarios

The Shift4 True P2PE™ solution has three deployment scenarios described below.

POS with 4GO®

1. Shift4’s True P2PE solution uses a specialized card reader that has built-in encryption capabilities (e.g., 3DES, AES, etc.). When the device reads the credit/debit card data (and before it sends that data to the merchant’s POS/PMS), its onboard chipset converts that cardholder data (CHD) using PCI-approved, industry-standard encryption (that cannot be locally decrypted). That encrypted data and the reset and last few digits of the card number are immediately intercepted by 4Go, Shift4’s CHD- intercepting, driver-based firewall, before entering the merchant’s POS/PMS terminal.

2. 4Go routes the encrypted CHD to the Universal Transaction Gateway® (UTG®), where it is wrapped in a second layer of encryption using Shift4’s proprietary Derived Unique Key Per Transaction with Moving Target Encryption (DUKPT w/MTE) algorithm. The UTG then generates a random, alphanumeric ID called a TrueToken, or it generates false cardholder data (FCHD) to securely reference the actual CHD.

3. The UTG temporarily holds the encrypted CHD in memory and forwards the newly generated TrueToken (or FCHD) back to 4Go.

4. 4Go sends the TrueToken or FCHD to the POS/PMS, which uses the data to process the transaction normally – as if it were actual CHD.

5. The POS/PMS terminal collects the TrueToken or FCHD and forwards the data to the UTG, where it is immediately recognized and matched with the actual encrypted CHD.

6. The UTG securely sends the encrypted CHD and the TrueToken or FCHD over the Internet to Shift4’s PCI DSS-compliant gateway, DOLLARS ON THE NET®.

7. Once the information is received by DOLLARS ON THE NET, the actual CHD is decrypted and sent with the authorization request for approval over a secure

private line to the processor of choice. Unlike other P2PE solutions, all major processors are supported. Direct processing to AMEX and third-party gift card solutions are also supported.

8. The processor forwards the request to the appropriate card association to be authorized. NOTE: This step is not necessary in the case of AMEX or third-party gift cards.

9. The card association returns the authorization code to the processor. NOTE: This step is not necessary in the case of AMEX or third-party gift cards.

10. The processor returns the CHD and the authorization code to DOLLARS ON THE NET over a secure private line. DOLLARS ON THE NET securely stores the CHD and generates a TrueToken to reference the transaction.

11. DOLLARS ON THE NET returns the TrueToken with the authorization code back through the Internet to the UTG.

12. The UTG discards the original TrueToken or FCHD and forwards the new TrueToken with the authorization code to the POS/PMS to complete the sale. The TrueToken is then stored in the POS/PMS in place of the actual CHD.

POS with UTG®

For those who choose not to use 4Go (or whose environment will not support it), True P2PETM functionality can still be provided directly through the UTG.

1. In this method, the merchant’s POS or PMS sends the invoice, terminal ID, and sales total to the UTG, requesting payment information.

2. The UTG then requests the swipe data directly from the payment terminal device. 3. The specialized card reader then sends the encrypted data and the first and last

few digits of the card number to the UTG. 4. The UTG adds a second layer of encryption to the device-encrypted data using

Shift4’s proprietary DUKPT w/MTE algorithm. Then, it securely sends the encrypted cardholder data (CHD) over the Internet to Shift4’s PCI DSS-compliant payment gateway DOLLARS ON THE NET.

5. The transaction is then completed following steps 7-12 of the diagram depicted

for POS with 4GO.

Mobile with VT4™

With the addition of a device that encrypts at the swipe, the benefits of True P2PETM can also be applied to processing payments using mobile devices delivered through our VT4® mobile payment solution.

1. In this method, a payment card is swiped at the point of sale using a specialized card reader attached to the merchant’s mobile Internet-connected device (e.g., laptop, tablet, or smartphone). This specialized reader has built-in encryption capabilities (e.g., 3DES, AES, etc.).

2. When the device reads the card data – before it sends that data back to the UTG – its onboard chipset converts that cardholder data (CHD) using PCI-approved, industry-standard encryption (which cannot be locally decrypted). That encrypted data, the first and last few digits of the card number, invoice, sale amount, and other transaction details, are immediately sent to the UTG via Shift4’s application programming interface (API).

3. The UTG adds a second layer of encryption to the device-encrypted data using Shift4’s proprietary DUKPT w/MTE algorithm. The UTG securely sends the encrypted CHD over the Internet to Shift4’s PCI DSS-compliant payment gateway DOLLARS ON THE NET. The transaction is completed following steps 7-12 of the diagram on the previous page.

Assessment Scope

The objective of the engagement was two-fold. First, it addressed the critical elements to validate the security and effectiveness of True P2PE™ within a merchant environment. The goal was to demonstrate strong encryption of cardholder data from point of entry on the POI device through the merchant environment to the Shift4 gateway and to validate that the merchant has no access to any key materials related to the encryption or decryption process. The second goal of the assessment was to demonstrate adherence to PCI P2PE 2.0 Domain 1 requirements for Encryption Device

& Application Management as applicable to the service provided. Note: The scope of the assessment did not include providers used by Shift4 to perform key injection, device inventory control, or loading of applications on devices, but it should be noted that all key injection providers used by Shift4 are certified ESO organizations to perform PIN services and adhere to Visa PCI PIN standards for key injection activities. Shift4 does not require the loading of applications on devices for True P2PE™ operation.

Assessment Methodology

Using industry best practices in its assessment and testing methodologies, including standard audit methods, Dara Security conducted technical lab testing on for the True P2PE™ service which included its integration with the supported PTS validated POI Devices:

1. ID Tech

a. SecuRED

b. SREDKey

2. Ingenico

a. iSC 250

b. iSC 350

c. iSC 480

d. iPP 320

e. iPP 350

f. iWL 220

g. iWL 250

h. iCMP

i. iSMP

j. iUP 250

k. iUR 250

l. iUR 150

3. Verifone

a. MX 915

b. MX 925

Our examination involved performing procedures to obtain evidence about the security efficacy of the technical presentation and documentation on the True P2PE solution. This was based on the description criteria, the suitability of the design, and operating effectiveness of those controls to lower the impact of PCI DSS controls within a merchant environment and to address PCI P2PE 2.0 Domain 1 applicable requirements.

Dara Security performed the assessment using the following approach:

• Performance of architecture design review of the implementation of the POI devices within a merchant environment;

• Implementation of POI device within a test environment to support the performance of test payment card transaction;

• Forensic testing on the lab network environment, deployed applications, and host systems;

• Forensic review POI devices performing cryptographic operations; and • Interview of Shift4 security, technical, and managerial staff on the technical

aspects of Shift4’s True P2PE solution

Dara Security met with the Shift4 P2PE technical team to understand the typical merchant environment. This allowed for a better understanding of the environment in which a merchant utilizes the solution.

First, the make and model of each POI device was compared with the PCI SSC list of PTS validated devices to confirm Secure Reading and Exchange of Data (SRED) support. This was followed by an examination of device configuration to ensure that SRED capabilities were enabled. Using a controlled laboratory environment, test transactions entered in the supported POI devices using their various input methods to validate the encryption process of the internal hardware encryption module within the POI devices. Transaction data was forensically analyzed as the data traversed supported connection from the POI device to the connected host system, the network laboratory, until it reached Shift4’s data decryption facility.

This environment included the POI devices, host-computing devices, and applications, which were contained within an isolated network in order to eliminate any outside variables or network interference, and the data transport connection between the controlled environment and Shift4’s decryption facility. The host system leveraged a fully patched Microsoft Windows 7 workstation, Shift4’s required software, antivirus software, and was configured with several forensic tools that supported wire-level inspection of Serial/USB & Ethernet traffic between the POI devices and the host system and the host system to Shift4’s decryption facility and wireless-level of WiFi and Bluetooth between the POIs and the host system.

True P2PE™ is designed to interoperate within a merchant environment that has deployed third-party point-of-sale (POS) application. This POS software has no access to decrypted cardholder data captured by the True P2PE™ solution. Data captured will not be decrypted until Shift4 receives it within their decryption environment. This environment is isolated from the merchant encryption environment. The merchant environment does not have access to decryption keys nor does the Shift4 software contain code supported data decryption.

For all Shift4 provided POI device, the devices are injected with encryption keys prior to delivery to the merchant, and the encryption keys may not be changed outside of the key injection facility. Interviews with the KIF technical support personnel and reviews of device security policies confirm that the firmware on the POI devices is designed to be “locked” following key injection. Re-keying of the POI device requires a reload of the firmware by specialized tools and processes at the key injection facility.

DetailedTechnicalAnalysisThe testing environment consisted of the following PTS approved POI devices:

Manufacturer Model Name/Number Input Supported

Host Communication

Interface(s) Cardholder

Data PTS

Approval #

ID Tech SecuRED MSR USB Track 4-10144 4-10184

ID Tech SREDKey MSR USB Track 4-10156

Ingenico iSC250

MSR Manual

Chip & PIN Contactless

Ethernet Serial USB

Track Chip

4-30062

Ingenico iSC350 MSR

Manual Chip & PIN

Ethernet Serial USB

Track Chip

4-20133

Ingenico iSC480

MSR Manual


Ethernet Serial USB

Track Chip

4-30098

Ingenico iPP320/350

MSR Manual


Ethernet Serial USB

Track Chip

4-20142

Ingenico IWL220/250

MSR Manual


Ethernet Serial USB

Bluetooth WiFi

Track Chip

4-20181

Ingenico iCMP

MSR Manual


Bluetooth USB

Track Chip

4-20235

Ingenico iSMP

MSR Manual


Bluetooth USB

Track Chip

4-20183

Ingenico iUP250 MSR

Manual Chip & PIN

Serial USB

Ethernet Bluetooth

Track Chip

4-30075

Ingenico iUR250 MSR

Chip & PIN Serial

Track Chip

4-30083

Ingenico iUR150 Contactless Serial USB

Track 4-30172

Verifone MX915/925

MSR Manual


Ethernet Serial USB Wifi

Bluetooth

Track Chip

4-10110

All POI devices were included in the security assessment, and following a detailed, forensic analysis of the POIs devices, no unencrypted cardholder data was found outside the POI devices. Attempts were made to access configuration data and encryption keys injected into the POI devices. These attempts were made using POI vendor application used for debugging and maintenance. This software did not provide access to encryption keys or allow for placing the POI device in non-SRED mode that would allow for cardholder data access.

In order to monitor communications from the POI devices to the host-system through the POI devices various communication methods, wired and wireless sniffing was performed. This sniffing allowed for the capture of data transmission from the POI devices to the host-system be it Ethernet, WiFi, Bluetooth, serial, and/or USB. Furthermore, raw captures of the host-system I/O interfaces and memory was performed to gather data prior to it being provided to the Shift4 software and after it had been provided to the aforementioned software. Examination of the captured I/O data and raw memory space revealed no clear-text Primary Account Numbers (PAN) or Sensitive Authentication Data (SAD).

The technical assessment included a forensic examination of the hard drive of the lab system with the POI devices installed. This process involved creating a forensic image of the system hard drive and memory space. Live and Dead system analysis was performed. Forensic analysis based on SANS GCFA and EnCase EnCE/EnCEP processes in which captured images were searched for PAN and SAD data confirmed that no unencrypted data could be found and that once data had been sent to the Shift4 decryption facility that no encrypted or residual data was retained.

No vulnerabilities were discovered during this process.

• No PAN/SAD was discovered during the monitoring of the I/O data streams. • No PAN/SAD was discovered during the direct capture of data from the POI. • No PAN/SAD was found during the forensic examination of the system pre- and

post- communication with the Shift4 decryption facility. • No PAN/SAD was discovered in the controlled network. • No ability to read or access sensitive configuration or encryption key data was

discovered.

Merchant Environment PCI DSS Scope Impact There will always be certain controls for PCI DSS compliance that must be independently assessed in any merchant’s environment. PCI DSS compliance will always apply to a merchant that transmits, processes or stores cardholder data anywhere in its physical environment. By properly implementing the Shift4 True P2PE™ solution, a merchant can potentially reduce the amount of applicable controls during a PCI DSS compliance audit.

The following sections and corresponding charts provide Dara Security’s opinion of Shift4’s True P2PE™ scope impact to PCI DSS control requirements in the merchant’s cardholder environment. However, it must be understood certain assumptions have been made to include:

• Proper implementation of the True P2PE™ solution within the environment. • All cardholder data is entered into the True P2PE™ solution. Support of other

acceptance methods will expand the overall PCI DSS scope for the merchant.

Merchant PCI DSS 3.1 Scope Reduction Summary

PCI DSS Requirement

Impact

Major Minor None

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

X

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters X

Requirement 3: Protect stored cardholder data X

Requirement 4: Encrypt transmission of cardholder data across open, public networks X

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

X

PCI DSS Requirement

Impact

Major Minor None

Requirement 6: Develop and maintain secure systems and applications X

Requirement 7: Restrict access to cardholder data by business need to know

X

Requirement 8: Identify and authenticate access to system components X

Requirement 9: Restrict physical access to cardholder data

X

Requirement 10: Track and monitor all access to network resources and cardholder data X

Requirement 11: Regularly test security systems and processes

X

Requirement 12: Maintain a policy that addresses information security for all personnel X

Table Legend:

• Major – A majority (50% or more) of the number of controls are removed from scope and/or with a significant reduction in the number of IT assets requiring the controls.

• Minor – A limited number (Less than 50%) of controls are removed from scope and/or with a limited reduction in the number of IT assets requiring the controls.

• None – No controls are removed from scope.

PCI DSS 3.1 Impact Detail by Applicable Requirement

If a specific requirement is not listed, then that requirement is either not or only slightly impacted by proper implementation of the Shift4 True P2PE™ solution, and will probably still be applicable during a PCI DSS audit.

PCI DSS 3.1 Requirement 1: Install and maintain a firewall configuration to protect cardholder data

PCI DSS Requirement Description of Requirement Impact

1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

As there is no storage of cardholder data within the environment through the use of the True P2PE™ solution, this requirement is not applicable.

1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall configurations include:

• Specific configuration settings are defined for personal firewall software.

• Personal firewall software is actively running. • Personal firewall software is not alterable by

users of mobile and/or employee-owned devices.

Employee-owned and mobile devices not configured to use the Shift4 solution would not be in-scope for this requirement. This requirement would only apply to those employee-owned and mobile devices authorized to run the Shift4 solution with a permitted POI device.

.

PCI DSS 3.1 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters


2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.

This requirement would apply only to those systems authorized to use the Shift4 software and POI devices. In addition, this requirement would apply to the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Sources of industry-accepted system hardening standards may include, but are not limited to:

• Center for Internet Security (CIS) • International Organization for Standardization

(ISO) • SysAdmin Audit Network Security (SANS)

Institute • National Institute of Standards Technology

(NIST)


2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.




2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc. Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after 30th June, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after 30th June, 2016.


2.2.4 Configure system security parameters to prevent misuse.


2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.


2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console



PCI DSS Requirement Description of Requirement Impact administrative access.

Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after 30th June, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Effective immediately, new implementations must not use SSL or early TLS.

POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after 30th June, 2016.

2.4 Maintain an inventory of system components that are in scope for PCI DSS.


PCI DSS 3.1 Requirement 3: Protect Stored Cardholder Data


All of Requirement 3 and its sub-requirements

For cardholder data captured through the Shift4 True P2PE™ solution, this requirement is not applicable. Captured cardholder data is encrypted at the hardware level and is not stored once delivered to the Shift4 decryption environment. In addition, the Key Injection Facility providers perform all key management for the deployed PTS POI devices. Merchants have no ability to access keys or change keys as part of this delivered solution. A merchant should monitor Shift4’s ongoing PCI DSS compliance to ensure security requirements continue to be met.

PCI DSS 3.1 Requirement 4: Encrypt transmission of cardholder data across open, public networks


All of Requirement 4 and its sub-requirements

For cardholder data captured through the Shift4 True P2PE™ solution, this requirement is not applicable. Captured cardholder data is encrypted at the hardware level through the use of industry standard encryption (AES). Furthermore, the Shift4 application further encrypts the data payload during transmission to the Shift4 decryption facility. The Shift4 software will only communicate to the Shift4 decryption facility. A merchant should monitor Shift4’s ongoing PCI DSS compliance to ensure security requirements continue to be met.

PCI DSS 3.1 Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs


5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

This requirement would apply only to those systems authorized to use the Shift4 software and POI devices.

5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.


5.2 Ensure that all anti-virus mechanisms are maintained as follows:

• Are kept current. • Perform periodic scans. • Generate audit logs which are retained per

PCI DSS Requirement 10.7.


5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.


PCI DSS 3.1 Requirement 6: Develop and maintain secure systems and applications


6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected. Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data.


6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within



PCI DSS Requirement Description of Requirement Impact one month of release.

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

Requirement 6.3 and sub-requirements.

This requirement is not applicable for environment solely using the Shift4 True P2PE™ solution for cardholder data acceptance. The solution is delivered to the merchant by Shift4 and is not developed by the merchant. The merchant should continue to monitor Shift4’s PCI DSS compliance status to ensure applicable requirements continue to be met by Shift4.

6.4 Follow change control processes and procedures for all changes to system components. The processes must include the following: • 6.4.1 Development/test environments are

separate from production environments with access control in place to enforce separation.

• 6.4.2 A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

• 6.4.3 Production data (live PANs) are not used for testing or development.

• 6.4.4 Test data and accounts are removed before a production system becomes active.

• 6.4.5 Change control procedures related to implementing security patches and software modifications are documented.

This requirement would apply only to those systems authorized to use the Shift4 software and POI devices and applicable testing/pre-production rollout environments. In addition, this requirement would apply to the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.

Requirement 6.5 and sub-requirements. This requirement is not applicable for environment solely using the Shift4 True P2PE™ solution for cardholder data acceptance. The solution is delivered to the merchant by Shift4 and is not developed by the merchant. The merchant should continue to monitor Shift4’s PCI DSS compliance status to ensure applicable requirements continue to be met by Shift4.



Requirement 6.6 and sub-requirements. This requirement is not applicable for environment solely using the Shift4 True P2PE™ solution for cardholder data acceptance. The solution is delivered to the merchant by Shift4 is not a publicly-facing web application.

PCI DSS 3.1 Requirement 7: Restrict access to cardholder data by business need to know


7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

This requirement would apply only to those systems authorized to use the Shift4 software and POI devices. Even though cardholder data is encrypted upon entry to the True P2PE™ solution, only authorized employees should be allowed handle transactions and access said systems.

In addition, this requirement would apply to the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.

7.1.1 Define access needs for each role, including: • System components and data resources that

each role needs to access for their job function.

• Level of privilege required (for example, user, administrator, etc.) for accessing resources.



7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.



7.1.3 Assign access based on individual personnel’s job classification and function.



7.1.4 Require documented approval by authorized parties specifying required privileges.


In addition, this requirement would apply to the infrastructure equipment (Firewall, routers, switches, etc.)

PCI DSS 3.1 Requirement 7: Restrict access to cardholder data by business need to know

PCI DSS Requirement Description of Requirement Impact that enables communications for authorized devices.

7.2 Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

This access control system must include the following: • 7.2.1 Coverage of all system components • 7.2.2 Assignment of privileges to individuals

based on job classification and function • 7.2.3 Default “deny-all” setting.



PCI DSS 3.1 Requirement 8: Identify and authenticate access to system components


8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:

• 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

• 8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

• 8.1.3 Immediately revoke access for any terminated users.

• 8.1.4 Remove/disable inactive user accounts within 90 days.

• 8.1.5 Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:

o Enabled only during the time period needed and disabled when not in use.

o Monitored when in use. • 8.1.6 Limit repeated access attempts by

locking out the user ID after not more than six attempts.

• 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

This requirement would only apply to the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant. As such, these requirements would not apply to those systems using the Shift4 solution.


PCI DSS Requirement Description of Requirement Impact • 8.1.8 If a session has been idle for more

than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing 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.


The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant. As such, this requirement would not apply to those systems using the Shift4 solution.

8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.



8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.



8.2.3 Passwords/phrases must meet the This requirement would only apply to the infrastructure equipment (Firewall, routers, switches, etc.) that


PCI DSS Requirement Description of Requirement Impact following: • Require a minimum length of at least seven

characters. • Contain both numeric and alphabetic

characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

enables communications for authorized devices.


8.2.4 Change user passwords/passphrases at least once every 90 days.



8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.



8.2.6 Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.





8.3 Incorporate two-factor authentication for remote network access originating from outside the network, by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).

Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication. Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.

This requirement would only apply to remote access to the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.


8.4 Document and communicate authentication policies and procedures to all users including:

• Guidance on selecting strong authentication credentials.

• Guidance for how users should protect their authentication credentials.

• Instructions not to reuse previously used passwords.

• Instructions to change passwords if there is any suspicion the password could be compromised.



8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as

This requirement would only apply to the infrastructure equipment (Firewall, routers, switches, etc.) that


PCI DSS Requirement Description of Requirement Impact follows:

• Generic user IDs are disabled or removed. • Shared user IDs do not exist for system

administration and other critical functions. • Shared and generic user IDs are not used to

administer any system components.

enables communications for authorized devices.


8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) use of these mechanisms must be assigned as follows:

• Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.

• Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.



8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

• All user access to, user queries of, and user actions on databases are through programmatic methods.

• Only database administrators have the ability to directly access or query databases.

• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

This requirement is not applicable to the merchant environment. The Shift4 solution does not store any cardholder data within the merchant environment. All data is encrypted upon entry into the POI device and delivered to the Shift4 decryption facility.

PCI DSS 3.1 Requirement 9: Restrict physical access to cardholder data

PCI DSS Requirement Description of Requirement Impact 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

• 9.1.1 Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

• 9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks.

In regards to the use of the Shift4 True P2PE™ solution only by a merchant, the deployment of the solution within a merchant environment is typically in areas where POI devices are present such as a cashier area within a retail store or kiosk area. These areas are not considered sensitive areas as prescribed by PCI DSS 3.1 and as such these requirements do not apply.

9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.

Even though for cardholder data captured by the Shift4 solution cannot be accessed within the merchant environment, the merchant should still restrict access to POI devices and infrastructure equipment.

9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:

• Identifying onsite personnel and visitors (for example, assigning badges).

• Changes to access requirements. • Revoking or terminating onsite personnel and

expired visitor identification (such as ID badges).

Even though for cardholder data captured by the Shift4 solution cannot be accessed within the merchant environment, the merchant should still restrict access to non-deployed POI devices and areas storing infrastructure equipment.

9.3 Control physical access for onsite personnel to sensitive areas as follows:

• Access must be authorized and based on individual job function.



PCI DSS Requirement Description of Requirement Impact • Access is revoked immediately upon

termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

9.4 Implement procedures to identify and authorize visitors. Procedures should include the following:

• 9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.

• 9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel.

• 9.4.3 Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration.

• 9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted.


9.5 Physically secure all media. The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant. As such, this requirement would not apply to those systems using the Shift4 solution as its sole method of data capture.

However, physical controls must be implemented for any physical media (Receipt, Mail Orders Forms, etc.) containing PAN data.



9.6 Maintain strict control over the internal or external distribution of any kind of media, including the following: • 9.6.1 Classify media so the sensitivity of the

data can be determined. • 9.6.2 Send the media by secured courier or

other delivery method that can be accurately tracked.

• 9.6.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals).

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant. As such, this requirement would not apply to those systems using the Shift4 solution as its sole method of data capture.


9.7 Maintain strict control over the storage and accessibility of media. • 9.7.1 Properly maintain inventory logs of all

media and conduct media inventories at least annually.



9.8 Destroy media when it is no longer needed for business or legal reasons as follows: • 9.8.1 Shred, incinerate, or pulp hard-copy

materials so that cardholder data cannot be reconstructed. Secure storage containers used for materials that are to be destroyed.

• 9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.


However, physical destruction must be implemented for any physical media (Receipt, Mail Orders Forms, etc.) containing PAN data.

9.9 Protect devices that capture payment card Even though for cardholder data captured by the Shift4 solution cannot be accessed within the merchant


PCI DSS Requirement Description of Requirement Impact data via direct physical interaction with the card from tampering and substitution.

Note: These requirements apply to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads. Note: Requirement 9.9 is a best practice until June 30, 2015, after which it becomes a requirement.

• 9.9.1 Maintain an up-to-date list of devices. The list should include the following: 1. Make, model of device. 2. Location of device (for example, the

address of the site or facility where the device is located).

3. Device serial number or other method of unique identification.

• 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

• 9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following: 1. Verify the identity of any third-party

persons claiming to be repair or maintenance personnel, prior to

environment, the merchant is still required to protect devices that capture card data.


PCI DSS Requirement Description of Requirement Impact granting them access to modify or troubleshoot devices.

2. Do not install, replace, or return devices without verification.

3. Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).

4. Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

PCI DSS 3.1 Requirement 10: Track and monitor all access to network resources and cardholder data


10.1 Implement audit trails to link all access to system components to each individual user.


10.2 Implement automated audit trails for all system components to reconstruct the following events: • 10.2.1 All individual user accesses to

cardholder data. • 10.2.2 All actions taken by any individual

with root or administrative privileges. • 10.2.3 Access to all audit trails. • 10.2.4 Invalid logical access attempts. • 10.2.5 Use of and changes to identification

and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges.

• 10.2.6 Initialization, stopping, or pausing of the audit logs.

• 10.2.7 Creation and deletion of system-level objects.

These requirements would apply only to those systems authorized to use the Shift4 software and POI devices. In addition, this requirement would apply to the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.

10.3 Record at least the following audit trail entries for all system components for each event: • 10.3.1 User identification • 10.3.2 Type of event • 10.3.3 Date and time • 10.3.4 Success or failure indication



PCI DSS Requirement Description of Requirement Impact • 10.3.5 Origination of event • 10.3.6 Identity or name of affected data,

system component, or resource

10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

• 10.4.1 Critical systems have the correct and consistent time.

• 10.4.2 Time data is protected.

• 10.4.3 Time settings are received from industry-accepted time sources.


10.5 Secure audit trails so they cannot be altered.

• 10.5.1 Limit viewing of audit trails to those with a job-related need.

• 10.5.2 Protect audit trail files from unauthorized modifications.

• 10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

• 10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.

• 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

These requirements would apply only to the logs of those systems authorized to use the Shift4 software and POI devices. In addition, this requirement would apply to the logs of the infrastructure equipment (Firewall, routers, switches, etc.) that enables communications for authorized devices.



10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

• 10.6.1 Review the following at least daily: 1. All security events 2. Logs of all system components that

store, process, or transmit CHD and/or SAD

3. Logs of all critical system components 4. Logs of all servers and system

components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

• 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.

• 10.6.3 Follow up exceptions and anomalies identified during the review process.


10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).


PCI DSS 3.1 Requirement 11: Regularly test security systems and processes


11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.

Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

• 11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification.

• 11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected.

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant nor are the means to decrypt the data accessible to the merchant. As such, these requirements would not apply to those merchants using the Shift4 solution as their sole method of data capture as the purpose of these requirements are secure the transmission of data across the network and to prevent the unauthorized access to cardholder data from a wireless network.

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

• 11.2.1 Perform quarterly internal

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant nor are the means to decrypt the data accessible to the merchant. As such, the requirement for internal vulnerability scan would not apply to those merchants using the Shift4 solution as their sole method of data capture as the purpose of this requirement are secure is to prevent the unauthorized access to cardholder data from systems or network by internal personnel.


PCI DSS Requirement Description of Requirement Impact vulnerability scans, and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.

• 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

• 11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.

External Vulnerability scans in the form of quarterly ASV scans by an authorized ASV provider would still be required.

11.3 Implement a methodology for penetration testing that includes at least the following:

1. Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115).

2. Includes coverage for the entire CDE perimeter and critical systems.

3. Includes testing from both inside and outside of the network.

4. Includes testing to validate any segmentation and scope reduction controls.

5. Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5.

6. Defines network-layer penetration tests to

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant nor are the means to decrypt the data accessible to the merchant. As such, the requirement for internal penetration testing would not apply to those merchants using the Shift4 solution as their sole method of data capture as the purpose of this requirement are secure is to prevent the unauthorized access to cardholder data from systems or network by internal personnel. In addition, segmentation testing would not be required, as the environment does not have the ability to decrypt captured data.

External penetration testing to demonstrate the security of the environment from outside threats would still be required.


PCI DSS Requirement Description of Requirement Impact include components that support network functions as well as operating systems.

7. Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.

8. Specifies retention of penetration testing results and remediation activities results.

• 11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification

• 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification

• 11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.

• 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.

11.4 Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel

This requirement would apply at the entry points for external networks (Internet) in order to detect attack against the environment from outside sources. However, IDS would need to be deployed internally.


PCI DSS Requirement Description of Requirement Impact to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.

11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the POI device encrypts the cardholder data. This unencrypted cardholder data is not accessible by the merchant, the system connected to the POI device, or to any software deployed on the system communicating to the POI device. Furthermore, there are no means to decrypt the data accessible to the merchant. As such, this requirement would not apply as there as the risk to cardholder data to be addressed by FIM technology does not exist.

PCI DSS 3.1 Requirement 12: Maintain a policy that addresses information security for all personnel


12.1 Establish, publish, maintain, and disseminate a security policy.

• 12.1.1 Review the security policy at least annually and update the policy when business objectives or the risk environment change.

The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant nor are the means to decrypt the data accessible to the merchant.

Regardless of the protections and reduction of risk provided by the solution, proper security policies will still be required for the governing of the environment. These policies may be reduced in size and scope, but they are required.

12.2 Implement a risk assessment process, that:

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),

• Identifies critical assets, threats, and vulnerabilities, and

• Results in a formal, documented analysis of risk.

• Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.


Regardless of the protections and reduction of risk provided by the solution, a risk assessment should still be performed to address the physical risk to the POI devices themselves.

12.3 Develop usage policies for critical technologies and define proper use of these technologies. Ensure these usage policies require the following:

• 12.3.1 Explicit approval by authorized parties.

• 12.3.3 A list of all such devices and personnel with access.


Regardless of the protections and reduction of risk provided by the solution, a proper usage policy for the use of the POI devices and the systems they connect to should be developed. This policy can be limited in scope to requiring approval for users to use the POI device, maintaining a list of POI devices (already required in requirement 9.9), and defining locations that POI devices may be deployed and stored


PCI DSS Requirement Description of Requirement Impact • 12.3.6 Acceptable network locations for the

technologies. (already required in by requirement 9.9).

12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.

Regardless of the protections and reduction of risk provided by the solution, security issues still arise and a policy and procedure must be in place describing security responsibilities for personnel.

12.5 Assign to an individual or team the following information security management responsibilities:

• 12.5.1 Establish, document, and distribute security policies and procedures.

• 12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.

Regardless of the protections and reduction of risk provided by the solution, responsibility for key security responsibilities must be assigned. Due to the protections afforded by the Shift4 True P2PE™ solution, the responsibilities can be limited to assigning responsibility for policy development, distribution, and enforcement and assigning responsibility for handling an incident like a virus outbreak or loss of a POI device.

12.6 Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

Security training is required regardless of the protection provided by the Shift4 solution. This training can be limited to items such as instructing employees on how to inspect POI devices for tampering, how to confirm personnel asking to work on POI devices are authorized, et al. Most training can be limited to securing the physical environment. However, if card data is accepted by phone or mail and entered into the Shift4 solution, training should include proper handling of the data acceptance methods.

12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)

This requirement is not applicable to employees such as cashiers or individuals with no access to cardholder data. The Shift4 True P2PE™ solution only allows access to the physical card when provided to the merchant by the consumer. Once a card is swiped or entered into the POI device, the cardholder data is encrypted by the POI device and not accessible by the merchant nor are the means to decrypt the data accessible to the merchant.

12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:

Implementing a policy to maintain a list of services provider with whom cardholder data is shared is a requirement. However, if the Shift4 solution is the only solution utilized in regards to cardholder data, this requirement can be limited to documenting that Shift4 is the sole provider and confirming their PCI DSS status. Shift4 addresses item 12.8.2 within their standard SLA. In addition, Shift4 does not managed


PCI DSS Requirement Description of Requirement Impact • 12.8.1 Maintain a list of service providers.

• 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s CDE.

• 12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

• 12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

• 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

systems deployed within the environment, as such, requirement 12.8.5 does not apply as it relates to the Shift4 relationship.

Requirement 12.9 Requirement does not apply to the merchant environment

12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach.

• 12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:


Regardless of the protections and reduction of risk provided by the solution, an incident response plan is still required. This plan can be limited to the systems and POI devices. It must cover key areas such as how to report a suspect incident (i.e. loss of POI device), who to report to, and how to report the incident


PCI DSS Requirement Description of Requirement Impact 1. Roles, responsibilities, and communication

and contact strategies in the event of a compromise including notification of the payment brands, at a minimum.

2. Specific incident response procedures. 3. Business recovery and continuity

procedures. 4. Data back-up processes. 5. Analysis of legal requirements for reporting

compromises. 6. Coverage and responses of all critical

system components. 7. Reference or inclusion of incident response

procedures from the payment brands.

to Shift4.

PCIP2PE2.0Domain1AnalysisThe review of the Shift4 True P2PE™ solution in relation to the PCI P2PE 2.0 Domain 1 requirements focused on:

• Use of PCI Approved POI Device with SRED • Security of POI Devices Prior to Merchant Deployment • Use of Applications that Protect PAN and SAD Data • Secure Application Management of Applications and POI Devices

The following sections contain specific details providing Dara Security’s opinion of the solution’s ability to meet specified PCI P2PE Domain 1 requirements

PCI P2PE 2.0 Domain 1 Encryption Device & Application Management Summary

Domain 1: P2PE Validation Requirements

Summary of Findings (check one)

In Place N/A Not in

Place

1A Account data must be encrypted in equipment that is resistant to physical and logical compromise.

1A-1 PCI-approved POI devices with SRED are used for transaction acceptance.

1A-2 Applications on POI devices with access to clear-text account data are assessed per Domain 2 before being deployed into a P2PE solution.

1B Logically secure POI devices.

1B-1 Solution provider ensures that logical access to POI devices deployed at merchant encryption environment(s) is restricted to authorized personnel.

1B-2 Solution provider secures any remote access to POI devices deployed at merchant encryption environments.

1B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.

1B-4 Solution provider implements procedures to secure account data when troubleshooting

Domain 1: P2PE Validation Requirements

Summary of Findings (check one)

In Place N/A Not in

Place

1B-5 The P2PE solution provides auditable logs of any changes to critical functions of the POI device(s).

1C Use P2PE applications that protect PAN and SAD.

1C-1 Applications are implemented securely, including when using shared resources and when updating applications and application functionality.

1C-2 All applications/software without a business need do not have access to account data.

1D Implement secure application-management processes.

1D-1 Integrity of applications is maintained during installation and updates.

1D-2 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.

1E Component providers ONLY: report status to solution providers

1E-1 For component providers of encryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.

PCIP2PE2.0Domain1EncryptionDevice&ApplicationManagementDetail

Domain 1: Encryption Device and Application Management – Reporting

Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1A-1.1 Encryption operations must be performed using a POI device approved per the PCI PTS program (e.g., a PCI-approved PED or SCR), with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics: • Model name and number • Hardware version number • Firmware version number • SRED listed as a function provided

1A-1.1 For each POI device type used in the solution, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing: • Model name/number • Hardware version number • Firmware version number • SRED listed as a function provided

For each POI device type used in the solution, describe how the POI device configurations and PCI SSC list of Approved PTS Devices verified that all of the POI device characteristics at 1A-1.1 match the PTS listing:

Examination of each in-scope POI device configuration and vendor provided documentation confirmed each device matched PCI SSC PTS listing. Examination of each in-scope POI devices model, hardware version, firmware version, and SRED support in comparison to the PTS listing confirmed POI device characteristics match.

1A-1.1.1 The POI device’s SRED capabilities must be enabled and active.

1A-1.1.1.a Examine the solution provider’s documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.

Documented procedures reviewed:

KIF service providers provide POI device configuration and deployment. Providers are instructed to only enable SRED capabilities.

Personnel interviewed: Shift4 Security Officer

1A-1.1.1.b For all POI device types used in the solution, review POI device configurations to verify that all POI device types used in the solution have SRED capabilities enabled and active (that is, the POI devices are operating in

For each POI device type used in the solution, describe how the POI device configurations observed verified that SRED capabilities are enabled and active prior to being deployed to merchant encryption environments:


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings “encrypting mode”) prior to devices being deployed to merchant encryption environments.

Examination of PTS POI device configurations confirmed that SRED is enabled on each device to be deployed.

1A-1.2 POI devices must be configured to use only SRED-validated account-data capture mechanisms.

1A-1.2.a For all POI device types intended for use in the P2PE solution, identify and document all account-data capture interfaces.

Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.

1A-1.2.b For each POI device type used in the solution, examine the device configuration to verify that it is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions.

For each POI device type used in the solution, describe how the device configuration verified that each device type is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions: Examination of in-scope PTS device configurations confirmed that only SRED data capture mechanisms are enabled on each device.

1A-1.2.1 All capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant. 1A-1.2.1.a Examine POI configuration and deployment procedures to verify they include either: • Disabling all capture mechanisms that are not SRED validated, or • Implementing configurations that prevent all non-SRED validated capture

mechanisms from being used for P2PE transactions.

Documented POI configuration and deployment procedures reviewed:

KIF service providers provide POI device configuration and deployment. Providers are instructed to only enable SRED validated data capture mechanisms.

1A-1.2.1.b Verify that the documented procedures include ensuring that all non-SRED-validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.


KIF service providers provide POI device configuration and deployment. Providers are instructed to only enable SRED validated data capture mechanisms.

1A-1.2.1.c For all POI device types, verify: • All non-validated capture mechanisms are either disabled or configured to

prevent their use for P2PE transactions, prior to devices being deployed to merchant encryption environments.

• Disabled capture mechanisms cannot be enabled by the merchant, and/or the configurations that prevent capture mechanisms from being used for

Describe the testing methods used to verify that for all POI device types, all non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions, prior to devices being deployed to merchant encryption environments: Examination of tested PTS POI devices and testing of capture mechanisms confirmed that non-validated capture mechanisms are disabled.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings P2PE transactions cannot be enabled by the merchant. Describe the testing methods used to verify that for all POI device types,

disabled capture mechanisms cannot be enabled by the merchant, and/or the configurations that prevent capture mechanisms from being used for P2PE transactions cannot be enabled by the merchant. Failed attempts to capture cardholder data in using non-validated capture mechanisms confirmed that these mechanisms are disabled.

1A-1.3 If the POI device implements open protocols as part of the solution, the device must also be validated to the PCI PTS Open Protocols (OP) module. Open protocols include the following: • Link Layer Protocols • IP Protocols • Security Protocols • IP Services

1A-1.3 For all POI device types that implement open protocols, examine device configurations and review the list of approved PTS devices at www.pcisecuritystandards.org, to verify that all POI devices that implement open protocols used in this solution are listed. Confirm each such device has a valid SSC listing number on the PCI SSC website under “Approved PCI PTS Devices” with “OP” listed as a “function provided”.

Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.

1A-1.4 Clear-text account data must not be disclosed to any component or device outside of the PCI-approved POI device.

1A-1.4.a Examine documented transaction processes and data flows to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.

Documented transaction processes and data flows reviewed:

PTS POI Device dataflow diagrams.

1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of transactions to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.

Identify the sample of transactions

Multiple transaction attempts through each supported POI Device

Describe the forensic tools and/or other data tracing methods used to inspect the sample of transactions: Forensic analysis or I/O, disk space, and memory space confirmed that clear-text account data is not disclosed to any component or device outside the POI device.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain 2. The assessment must match the application in the following characteristics: • Application name • Version number

1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the P2PE application listing in the following characteristics: • Application name • Version number

Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for this documentation. No further reporting required here.

1A-2.1.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV(s) and verify that the applications used in the solution match the application P-ROV in the following characteristics: • Application name • Version number

Identify application P-ROV(s) reviewed:

Not Applicable. Applications are not loaded on the PTS Devices.

1A-2.1.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV(s) and verify that the applications used in the solution match the application P-ROV in the following characteristics: • Application name • Version number

1A-2.2.a.For applications on the PCI SSC list of Validated P2PE Applications, review the list and verify all POI device types the application is used on are: • Confirmed per 1A-1.1 as a PTS-approved device(s) • Explicitly included in that application’s listing

Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” and Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.

1A-2.2.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV and verify the POI device types the application is used on are: • Confirmed per 1A-1.1 as a PTS-approved device(s) • Explicitly included in that P-ROV as assessed for that application.

Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for confirmation per 1A-1.1 of PTS-approval (if this testing procedure is applicable). Identify application P-ROV(s) reviewed:

Not Applicable. Applications are not loaded on the PTS Devices.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-1.1 Solution provider must ensure merchant logical access to POI devices, if needed, is restricted as follows: • Be read-only • Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD • Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text

PAN and/or SAD • Cannot enable disabled device interfaces or disabled data-capture mechanisms

1B-1.1.a Examine documented POI device configuration procedures and account privilege assignments to verify that merchant logical access to POI devices is restricted as follows: • Be read-only • Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD. • Cannot view or access device configuration settings that could impact the

security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD

• Cannot enable disabled device interfaces or disabled data-capture mechanisms


KIF service providers provide POI device configuration and deployment. Providers are instructed to restrict merchant access.

Describe how account privilege assignments verified that merchant logical access to POI devices is restricted as follows: • Be read-only • Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD. • Cannot view or access device configuration settings that could impact the



Review of in-scope POI device configurations confirmed that restricted access is implemented properly.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-1.1.b For a sample of all POI devices used in the solution, logon to the device using an authorized test merchant account. Verify that merchant-account logical access meets the following: • Be read-only • Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD. • Cannot view or access device configuration settings that could impact the



Identify the sample of POI devices used: 1. ID Tech

a. SecuRED

b. SREDKey

2. Ingenico

a. iSC 250/350/480

b. iPP 320/350

c. iWL 220/250

d. iCMP/iSMP

e. iUP250/iUR250/iUR150

3. Verifone

a. MX 915/925

Describe how logon to the device using an authorized test merchant account verified that merchant-account logical access meets the following: • Be read-only • Only view transaction-related data • Cannot view or access cryptographic keys • Cannot view or access clear-text PAN • Cannot view or access SAD. • Cannot view or access device configuration settings that could impact the



Examination for each devices configuration and access confirmed that merchant logical access meets aforementioned requirements.

1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements

Responsible personnel interviewed:

Shift4 Security Officer


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings are configured for all devices used in the solution. Identify the sample of POI

devices used: 1. ID Tech

a. SecuRED

b. SREDKey

2. Ingenico

a. iSC 250/350/480

b. iPP 320/350

c. iWL 220/250

d. iCMP/iSMP

e. iUP250/iUR250/iUR150

3. Verifone

a. MX 915/925

Describe how the POI device configurations observed verified that the defined merchant-access requirements are configured for all devices used in the solution: Examination for each devices configuration and access confirmed that merchant access requirements are configured for all a devices.

1B-1.1.1 Where there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose but ONLY if the following are met: • The solution provider must document which payment application(s) facilitates printing of PANs for merchants. • The P2PE application that facilitates this is confirmed per 1A-2.1 as assessed to Domain 2 and on PCI SSC’s list of Validated P2PE Applications.

Note that Domain 2 (at 2A-3.1.2) and Domain 3 (at 3A-1.3) also include requirements that must be met for any P2PE application and P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so. 1B-1.1.1.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation specifies which payment application(s) facilitates printing of PANs for merchants.

Solution provider’s documented procedures reviewed:

KIF service providers provide POI device configuration and deployment. Providers are instructed to meet local legal or regulatory obligations.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-1.1.1.b Review applications confirmed at 1A-2.1 to verify the application(s) that facilitates printing of full PANs on merchant receipts is on PCI SSC’s list of Validated P2PE Applications.

Identify any P2PE Applications at 1A-2.1 that facilitate printing of full PANs on merchant receipts:

Not applicable. No applications are installed on the devices with access to clear-text cardholder data.

Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for documentation of the PCI SSC listing of the P2PE Application (if this testing procedure is applicable):

1B-1.2 All solution-provider personnel with logical access to POI devices deployed in merchant encryption environments must be documented in a formal list and authorized by solution provider management. The list of authorized personnel is reviewed at least annually. 1B-1.2.a Examine documented authorizations to verify: • All personnel with access to devices are documented in a formal list. • All personnel with access to devices are authorized by management. • The list of authorized personnel is reviewed at least annually.

Documented authorizations reviewed:

Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-1.2.b For a sample of all POI device types, examine account-access configurations to verify that only personnel documented and authorized in the formal list have access to POI devices.

Identify the sample of POI devices used:


Describe how account-access configurations for a sample of all POI device types verified that only personnel documented and authorized in the formal list have access to POI devices: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-1.2.1 Solution provider personnel with logical access to POI devices deployed in merchant encryption environments must be granted based on least privilege and need to know. 1B-1.2.1a Examine documented access-control policies and procedures to verify that solution provider personnel with logical access to POI devices deployed at merchant encryption environments is assigned according to least privilege and need to know.

Documented access-control policies and procedures reviewed:


1B-1.2.1.b For a sample of all POI devices and personnel, observe configured accounts and permissions, and interview responsible personnel to verify that the level of logical access granted is according to least privilege and need to know.

Identify the sample of POI devices used:



Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings Identify the sample of personnel used:




Describe how configured accounts and permissions for the sample of all POI devices and personnel verified that the level of logical access granted is according to least privilege and need to know: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.1 Solution provider’s authorized personnel must use two-factor or cryptographic authentication for all remote access to merchant POI devices. Note: This includes remote access to POI devices via a terminal management system (TMS) or other similar systems 1B-2.1.a Examine documented procedures to verify that either two-factor or cryptographic authentication must be used for all remote access to POI devices.



1B-2.1.b Observe remote-access mechanisms and controls to verify that either two-factor or cryptographic authentication is configured for all remote access to POI devices.

Describe how remote-access mechanisms and controls verified that either two-factor or cryptographic authentication is configured for all remote access to POI devices: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.1.c Interview personnel and observe actual remote connection attempts to verify that either two-factor or cryptographic authentication is used for all remote access to POI devices.

Personnel interviewed: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

Describe how actual remote connection attempts verified that either two-factor or cryptographic authentication is configured for all remote access to POI devices:


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.2 POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems.

1B-2.2.a Examine documented device-configuration procedures and interview personnel to verify that devices must be configured to permit remote access only from the solution provider’s authorized systems.

Documented device-configuration procedures reviewed:


Personnel interviewed: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.2.b For all devices used in the solution, observe a sample of device configurations to verify that remote access is permitted only from the solution provider’s authorized systems.

Describe how sampled device configurations for all devices used in the solution verified that remote access is permitted only from the solution provider’s authorized systems: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.3 POI devices must be configured such that merchants do not have remote access to the merchant POI devices.

1B-2.3.a Examine documented POI-configuration procedures and interview personnel to verify that devices must be configured to ensure merchants do not have remote access to the POI devices.

Documented POI-configuration procedures reviewed:

KIF service providers provide POI device configuration and deployment. Providers are instructed to disallow all remote merchant access to POI devices.

Personnel interviewed: Shift4 Security Officer

1B-2.3.b For all devices used in the solution, observe a sample of device configurations to verify that merchants do not have remote access to the POI devices.

Describe how sampled device configurations for all devices used in the solution verified that merchants do not have remote access to the POI devices: Testing of in-scope POI devices confirmed that remote access is not enabled for devices.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-2.4 Solution provider must implement secure identification and authentication procedures for remote access to POI devices deployed at merchant encryption environments, including: 1B-2.4.a Examine documented identification and authentication procedures to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.

Documented identification and authentication procedures reviewed:


1B-2.4.b Verify documented procedures include requirements specified at 1B-2.4.1 through 1B-2.4.3.

Identify the P2PE Assessor who confirms that documented procedures include requirements specified at 1B-2.4.1 through 1B-2.4.3:


1B-2.4.1 Individual authentication credentials for all authorized solution-provider personnel that are unique for each merchant. Note: If a centralized terminal-management system (TMS) is utilized to manage multiple merchant accounts, it is acceptable for the TMS system to only require unique access for each authorized solution-provider employee accessing the TMS instead of requiring unique access per merchant. 1B-2.4.1 Examine device configurations and authentication mechanisms to verify that all authorized solution-provider personnel have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS).

Describe how device configurations and authentication mechanisms verified that all authorized solution-provider personnel have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS): Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.4.2 Tracing all logical access to POI devices by solution-provider personnel to an individual user.

1B-2.4.2.a Examine POI device configurations and authentication mechanisms to verify that all logical access to POI devices can be traced to an individual user.

Describe how POI device configurations and authentication mechanisms verified that all logical access to POI devices can be traced to an individual user: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.4.2.b Observe authorized logical accesses and examine access records/logs to verify that all logical access is traced to an individual user.

Describe how the authorized logical accesses and access records/logs observed verified that all logical access is traced to an individual user: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-2.4.3 Maintaining audit logs of all logical access to POI devices, and retaining access logs for at least one year.

1B-2.4.3.a Observe authorized logical accesses and examine access records/logs to verify that an audit log of all logical access to devices is maintained.

Describe how the authorized logical accesses observed and access records/logs examined verified that an audit log of all logical access to devices is maintained: Not Applicable. Shift4 personnel do not access POI devices deployed within merchant environments.

1B-2.4.3.b Examine access records/logs to verify that access logs are retained for at least one year.

Identify access records/logs reviewed:


1B-3.1 Secure update processes must be implemented for all firmware and software updates, including: • Integrity check of update • Authentication of origin of the update

1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include: • Integrity checks of update • Authentication of origin of the update


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined for proper firmware and software updates for POI devices.

1B-3.1.b Observe a sample of firmware and software updates, and interview personnel to verify: • The integrity of the update is checked • The origin of the update is authenticated

Identify sample of firmware and software updates observed:

Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined for proper firmware and software updates for POI devices.

Personnel interviewed: Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined for proper firmware and software updates for POI devices.

1B-3.2 An up-to-date inventory of POI device system builds must be maintained and confirmed at least annually and upon any changes to the build.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-3.2.a Examine documented procedures to verify they include: • Procedures for maintaining an up-to-date inventory of POI device system

builds • Procedures for confirming all builds at least annually and upon any

changes to the build


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined maintaining and up-to-date inventory of builds and confirmation of builds.

1B-3.2.b Review documented inventory of devices, and examine the inventory of system builds to verify: • The inventory includes all POI device system builds. • The inventory of POI device system builds is up-to-date.

Describe how the documented inventory of devices and inventory of system builds verified that: • The inventory includes all POI device system builds. • The inventory of POI device system builds is up-to-date.

Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation process are defined maintaining and up-to-date inventory of builds and confirmation of builds.

1B-3.2.c Observe results of vulnerability assessments and interview responsible personnel to verify vulnerability assessments are performed against all POI device system builds: • At least annually and • Upon any changes to the build


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined requiring the performance of vulnerability assessment against POI device system builds.

Describe how results of vulnerability assessments verified that vulnerability assessments are performed against all POI device system builds: • At least annually and • Upon any changes to the build

Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined requiring the performance of vulnerability assessment against POI device system builds.

1B-3.3 Critical software security updates must be deployed to POI devices in the field within 30 days of receipt from device vendors or application vendors. Note: A “critical software security update” is one that addresses an imminent risk to account data, either directly or indirectly. Note: These security patches can be deployed via “push” from the solution provider or vendor, or via “pull” from the POI device or merchant. In all cases, the solution provider is ultimately responsible to ensure security patches are installed in a timely manner. Aligns with 2C-1.2


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-3.3.a Examine documented procedures to verify they include defined procedures for deploying critical software security updates to POI devices in the field within 30 days of receipt from device or application vendors.


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined supporting the deployment of critical software updates to POI devices in the field with 30 days or receipt from manufacturer.

1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel and to verify that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.

Responsible solution provider personnel interviewed:

Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined supporting the deployment of critical software updates to POI devices in the field with 30 days or receipt from manufacturer.

Describe how the security update deployment records and device logs verified that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors. Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined supporting the deployment of critical software updates to POI devices in the field with 30 days or receipt from manufacturer.

1B-3.4 Updates must be delivered in a secure manner with a known chain-of-trust, as defined by the vendor—e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide. 1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor for delivering updates in a secure manner with a known chain-of-trust.


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined supporting the delivering of updates in a secure manner with a known chain-of-trust.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1B-3.4.b Observe processes for delivering updates and interview responsible personnel to verify that updates are delivered in a secure manner with a known chain-of-trust, and following guidance from the device or application vendor.


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined supporting the delivering of updates in a secure manner with a known chain-of-trust.

Describe how the processes for delivering updates verified that updates are delivered in a secure manner with a known chain-of-trust and following guidance from the device or application vendor: Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined supporting the delivering of updates in a secure manner with a known chain-of-trust.

1B-3.5 The integrity of patch and update code must be maintained during delivery and deployment, as defined by the vendor—e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide. 1B-3.5.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor to maintain the integrity of all patch and update code during delivery and deployment.

Documented procedures for device updates reviewed:

Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined to maintain the integrity of all patch and update code during delivery and deployment.

1B-3.5.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor.


Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined to maintain the integrity of all patch and update code during delivery and deployment.

Describe how the processes for delivering updates verified that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor:


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined to maintain the integrity of all patches and update code during delivery and deployment.

1B-3.5.c Observe authorized personnel attempt to run the update process with arbitrary code to verify that the system will not allow the update to occur.

Describe how the attempt by authorized personnel to attempt to run the update process with arbitrary code verified that they system will not allow the update to occur: Shift4 utilizes a Visa approved KIF service provider for the maintenance of deployed POI Devices. Based on KIF documentation, processes are defined to maintain the integrity of all patches and update code during delivery and deployment. Processes are in place to prevent the updating with arbitrary code.

1B-4.1 Any PAN and/or SAD used for debugging or troubleshooting purposes must be securely deleted. These data sources must be collected in limited amounts and collected only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use. 1B-4.1.a Examine the solution provider’s procedures for troubleshooting customer problems and verify the procedures include: • PAN and/or SAD is never output to merchant environments • Collection of PAN and/or SAD only when needed to solve a specific

problem • Storage of such data in a specific, known location with limited access • Collection of only a limited amount of data needed to solve a specific

problem • Encryption of PAN and/or SAD while stored • Secure deletion of such data immediately after use

Documented solution provider’s procedures for troubleshooting customer problems reviewed:

Shift4 Support procedures

1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B-4.1.a were followed.

Identify the sample of recent troubleshooting requests:

Shift4 does not provide troubleshooting support of POI devices within the merchant environment. All data encryption is performed by the POI device. Should the device fail, the POI device is replaced.


Shift4 Security Officer

Describe how the data collection and storage locations for the sample of recent troubleshooting requests verified that procedures identified at 1B-4.1.a were followed:


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings Shift4 does not provide troubleshooting support of POI devices within the merchant environment. All data encryption is performed by the POI device. Should the device fail, the POI device is replaced.

1B-5.1 Any changes to critical functions of POI devices must be logged—either on the device or within the remote-management systems of the P2PE solution provider. Note: Critical functions include application and firmware updates as well as changes to security-sensitive configuration options, such as whitelists or debug modes. 1B-5.1.a Examine device and/or system configurations to verify that any changes to the critical functions of the POI devices are logged, including: • Changes to the applications within the device • Changes to the firmware within the device • Changes to any security-sensitive configuration options within the device

(including whitelists and debug modes)

Describe how the device and/or system configurations observed verified that any changes to the critical functions of the POI devices are logged, including: • Changes to the applications within the device • Changes to the firmware within the device • Changes to any security-sensitive configuration options within the device

(including whitelists and debug modes) Examination of in-scope PTS POI devices confirmed they are configured to log and changes to critical functions.

1B-5.1.b Observe authorized personnel perform authorized changes on POI devices, as follows, and examine log files to verify that all such activities result in a correlating log file: • Changes to the applications within the device • Changes to the firmware within the device • Changes to any security-sensitive configuration options within the device

(including whitelists and debug modes)

Describe how observation of authorized personnel performing authorized changes on POI devices, as follows, and examination of log files verified that all such activities result in a correlating log file: • Changes to the applications within the device • Changes to the firmware within the device • Changes to any security-sensitive configuration options within the device

(including whitelists and debug modes) Shift4 utilizes a Visa approved KIF provider for updates to POI devices. KIF providers are instructed to log all activities.

1C-1.1 Applications with access to account data must be installed and configured to only use external communication methods specified in the application’s Implementation Guide. Aligns with 2A-3.3 1C-1.1.a Observe application and device configurations and interview personnel to verify that applications with access to account data are installed and configured to only use approved external communication methods, by following guidance in the application’s Implementation Guide.

Personnel interviewed: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings Describe how application and device configurations observed verified that applications with access to account data are installed and configured to only use approved external communication methods: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1C-1.1.b For all devices on which the application will be used in the solution, observe application and device operations as implemented in the solution—that is, the application and device should be tested together with all other applications intended to be installed on the device)—and use an appropriate “test platform” (as necessary) provided by the application vendor to perform test transactions for all functions of the application that handle account data. Examine results of tests and verify that the application only uses approved external communication methods.

Describe how results of tests verified that the application only uses approved communication methods for all devices on which the application will be used in the solution: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1C-1.2 Processes for any whitelisting functionality must include: • Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide. • Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control. • Cryptographic authentication by the POI device’s firmware • Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data. • Approval of functionality by authorized personnel prior to implementation • Documentation for all new installations or updates to whitelist functionality that includes the following:

- Description and justification for the functionality - The identity of the authorized person who approved the new installation or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data

Aligns with 2A-3.4 1C-1.2 Review documented policies and procedures and interview personnel to verify that processes for implementing any whitelisting functionality include: • Following the device vendor's security guidance or the application’s

Documented policies and procedures reviewed:

Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings Implementation Guide

• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.

• Cryptographic authentication of whitelisting functionality by the POI device’s firmware

• Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.

• Approval of functionality by authorized personnel prior to implementation • Documentation for all new installations and updates to whitelist functionality

that includes the following: - Description and justification for the functionality - The identity of the authorized person who approved the new installation

or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-PCI

payment brand account/card data


1C-1.2.1 Any whitelisting functionality must only allow the output of clear-text account data for non-PCI payment brand account/card data.

1C-1.2.1.a Observe application and device configurations and interview personnel to verify that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards, by following guidance in either the device vendor's security guidance or the application’s Implementation Guide.


Describe how application and device configurations observed verified that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1C-1.2.1.b For all device types with whitelisting functionality, perform test transactions to verify output of clear-text account data is only enabled for non-PCI payment brand account/card data.

Describe how test transactions verified that output of clear-text account data is only enabled for non-PCI payment brand account/card data: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1C-1.2.2 Any new installations of, or updates, to whitelisting functionality must be: • Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control. • Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s Implementation

Guide. 1C-1.2.2 Observe the process for new installations of, or updates to, whitelisting functionality and interview personnel to verify they are performed as follows: • Cryptographically signed (or similar) prior to installation on the POI device

only by authorized personnel using dual control. • Cryptographically authenticated by the POI device firmware, in accordance

with the device vendor's security guidance or the application’s Implementation Guide.


Describe how the process for new installations of, or updates to, whitelisting functionality verified they are cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment. Describe how the process for new installations of, or updates to, whitelisting functionality verified they are cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1C-1.2.3 Any new installations of, or updates to, whitelisting functionality must follow change-control procedures that include: • Coverage for both new installations and updates to such functionality. • Description and justification for the functionality. • The identity of the person who approved the new installation or update prior to release. • Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.

1C-1.2.3 Review records of both new installations and updated whitelisting functionality, and confirm they include the following: • Coverage for both new installations and updates to such functionality.

Identify sampled records of new installations of whitelisting functionality:



Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings • Description and justification for the functionality. • The identity of the person who approved the new installation or update

prior to release. • Confirmation that it was reviewed prior to release to only output non-PCI

payment account/card data.

Identify sampled records of updated whitelisting functionality:


1C-2.1 Processes must be documented and implemented to ensure that, prior to new installations or updates, applications/software without a business need do not have access to account data, including that the software: • Does not have any logical interfaces (e.g., application programming interfaces (APIs)) that allow for the storing, processing, or transmitting of account data. • Is cryptographically authenticated by the POI device’s firmware. • Requires dual control for the application-signing process.

1C-2.1 Review the solution provider’s documented processes and interview responsible personnel to confirm the processes include: • Review of the application vendor’s documentation to determine all logical

interfaces used by the application/software. • Documenting how the solution provider confirmed that the application has

no logical interfaces that allow for storing, processing, or transmitting account data

• Authentication of the application by the POI device’s firmware • Requiring dual control to authenticate the application • Following this process both for new installations and for updates.

Documented solution provider’s processes reviewed:




1C-2.1.1 The application/software does not have any logical interfaces—e.g., application programming interfaces (APIs)—that allow for storing, processing, or transmitting account data. 1C-2.1.1 For each POI device type and each application that does not have a business need to access account data, review the solution provider’s documentation to verify it confirms that the application has no logical interfaces that allows for storing, processing, or transmitting account data.

Identify any application(s) without business need to access account data:


Solution provider’s documentation reviewed:


1C-2.1.2 The application/software is authenticated within the POI device using an approved security mechanism of the POI device.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1C-2.1.2 Interview solution-provider personnel and observe the process for new application installations or application updates to verify that applications with no need to access clear-text account data are authenticated to the device using an approved security mechanism.

Solution provider personnel interviewed:


Describe how the process for new application installations or application updates verified that applications with no need to access clear-text account data are authenticated to the device using an approved security mechanism: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1C-2.1.3 Require dual control for the application-signing process.

1C-2.1.3 Interview solution-provider personnel and observe processes for new application installations or application updates to confirm that application signing is performed under dual control.



Describe how the process for new application installations or application updates verified that application signing is performed under dual control: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1D-1.1 Processes must be documented and implemented to manage all changes to applications, including: • Following vendor guidance in the application’s Implementation Guide. • Documented approval for all changes by appropriate personnel. • Documented reason and impact for all changes. • Functionality testing of all changes on the intended device(s). • Documented back-out procedures for application installations/updates.

Note that adding a changed application or a changed POI device to a PCI-listed P2PE Solution requires the Solution Provider to undergo an assessment per PCI’s “Designated Change” process. See the P2PE Program Guide for more information. Aligns with 2C-2.1 1D-1.1.a Review the solution provider’s documented processes for implementing changes to applications, and interview solution-provider personnel, and confirm the following processes are in place:

Documented solution provider processes for implementing changes to applications reviewed:



Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings • Guidance in the Implementation Guide is followed. • All changes to applications include documented approval by appropriate

authorized solution-provider personnel. • All changes to applications are documented as to reason and impact of the

change. • Functionality testing of all changes on the intended devices is performed. • Documentation includes back-out procedures for application

installations/updates.



1D-1.1.b Review records of changes to applications and, and confirm the following: • All Implementation Guide requirements were followed. • Approval of the change by appropriate parties is documented. • The documentation includes reason and impact of the change. • The documentation describes functionality testing that was performed. • Documentation includes back-out procedures for application

installations/updates.

Identify the sample of records of changes to applications:


1D-1.2 All new installations and updates to applications must be authenticated as follows: Aligns with 2C-2.1 1D-1.2 Review the solution provider’s documentation and confirm their documented processes include using the guidance in the application’s Implementation Guide for any application installations and updates.



1D-1.2.1 All new installations and updates of applications must be cryptographically authenticated by the POI device’s firmware.

1D-1.2.1 Interview responsible personnel and observe installation and update processes to confirm that new application installations and updates are cryptographically authenticated by the POI device’s firmware.



Describe how the installation and update processes observed verified that new application installations and updates are cryptographically authenticated by the POI device’s firmware: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1D-1.2.2 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.

1D-1.2.2 Confirm the following through interviews with responsible solution provider personnel and by observing an installation/update: • Cryptographic signing processes for applications are followed as specified

in the Implementation Guide. • Cryptographic signing (or similar) is performed prior to installation only by

authorized personnel using dual control. • All new installations and updates to applications are signed prior to

installation on the device. • Cryptographic signing for new installations and updates to applications is

done under dual control.

Responsible solution provider personnel interviewed:


Describe how the installation/update verified that: • Cryptographic signing processes for applications are followed as specified

in the Implementation Guide. • Cryptographic signing (or similar) is performed prior to installation only by

authorized personnel using dual control. • All new installations and updates to applications are signed prior to

installation on the device. • Cryptographic signing for new installations and updates to applications is

done under dual control. Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1D-1.3 The application must be configured to securely integrate with any device resources that may be shared with other applications. Aligns with 2B-2.2 1D-1.3 Interview solution-provider personnel and observe configuration processes to determine that applications are integrated with any shared resources in accordance with the Implementation Guide.



Describe how configuration processes observed verified that applications are integrated with any shared resources in accordance with the Implementation Guide: Not Applicable. Shift4 does not install application on the POI device nor does the Shift4 solution have access to cardholder data in the merchant environment.

1D-1.4 Processes must be in place to implement application developer guidance on key and certificate usage from the application’s Implementation Guide. Aligns with 2B-3.1.1


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1D-1.4.a Review the solution provider’s documentation and confirm their documented processes include application developer key-management security guidance.



1D-1.4.b Interview solution-provider personnel to confirm that they follow key-management security guidance in accordance with the Implementation Guide.



1D-2.1 Upon receipt from the application vendor, a current copy of the application vendor’s Implementation Guide must be retained and distributed to any outsourced integrators/resellers used for the P2PE solution. Aligns with 2C-3.1.3 1D-2.1 Interview solution-provider personnel and examine documentation (including a current copy of the Implementation Guide from the application vendor) to confirm the following: • The solution provider retains a current copy of the Implementation Guide. • The solution provider distributes the Implementation Guide to any

outsourced integrators/resellers the solution provider uses for the P2PE solution upon obtaining updates from the application vendor.



Documentation reviewed, in addition to the current copy of the Implementation Guide from the application vendor:


Current Application Vendor Implementation Guide(s) reviewed:


Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s device-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include device-management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties). 1E-1.1 Track status of the encryption-management services and provide reports to solution provider annually and upon significant changes, including at least the following: • Types/models of POI devices. • Number of devices deployed and any change in numbers since last report. • Date of last inventory of POI device system builds. • Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated.


Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented: • Types/models of POI devices. • Number of devices deployed and change since last report. • Date of last inventory of POI device system builds. • Date list of personnel with logical remote access to deployed merchant POI

devices was last reviewed/updated.

Documented component provider’s procedures reviewed:

Not Applicable. Shift4 is not a component provider.

Responsible component provider personnel interviewed:


1E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following: • Types/models of POI devices. • Number of devices deployed and changed since last report. • Date of last inventory of POI device system builds. • Date list of personnel with logical remote access to deployed merchant POI

devices was last reviewed/updated.

Reports reviewed for this testing procedure:


1E-1.2 Manage and monitor changes to encryption-management services and notify the solution provider upon occurrence of any of the following: • Critical software security updates deployed to POI devices. • Addition and/or removal of POI device types. • Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change. • Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change. • Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.

Note that adding, changing, or removing POI device types, P2PE applications, and/or P2PE non-payment software may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution. 1E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include

Documented component provider’s procedures reviewed:



Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings notifying the solution provider upon occurrence of the following: • Critical software security updates deployed to POI devices. • Addition and/or removal of POI device types. • Adding, changing, and/or removing P2PE applications on POI devices (with

access to clear-text account data), including description of change. • Adding, changing, and/or removing P2PE non-payment software on POI

devices (without access to clear-text account data), including description of change.

• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software.

Responsible component provider personnel interviewed:


1E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence: • Critical software security updates deployed to POI devices. • Addition and/or removal of POI device types. • Adding, changing, and/or removing P2PE applications on POI devices (with

access to clear-text account data), including description of change. • Adding, changing, and/or removing P2PE non-payment software (without

access to clear-text account data), including description of change. • Updated list of POI devices, P2PE applications, and/or P2PE non-payment

software.

Reports reviewed for this testing procedure:


Conclusion Shift4’s True P2PE™ solution is not a PCI P2PE 2.0 validated solution. It employs a software based key management system in the decryption environment and does not utilize third-party HSMs for any other P2PE process within its decryption environment. This key management system was reviewed in comparison to PCI DSS 3.1 Requirements 3.5 and 3.6 and PCI P2PE 2.0 Domain 5. Except for some physical security requirements only available in HSMs, Shift4’s True P2PE solution meets and in most cases exceeds all other security requirements of PCI P2PE 2.0 Domains 5 and 6, key management and decryption processes. For technical details concerning the key management process utilized by the Shift4 True P2PE solution and comments on how the Shift4 solution directly addresses PCI DSS 3.1 key management and specific PCI P2PE Domain 5 and Domain 6 requirements, please inquire directly with Shift4, Inc. for a Detailed Technical Document.

Shift4’s True P2PE™ solution provides merchants a reduction of risk and scope by reducing the cardholder footprint within a merchant’s environment as it pertains to the encryption environment much like that of a PCI P2PE 2.0 solution as detailed within the PCI P2PE Domain 1 requirements table detailed in this report. The analysis of Shift4’s solution confirmed the encryption of cardholder data prior to leaving the supported POI. It is our professional opinion that the Shift4 True P2PE™ solution provides for high levels of security and data integrity from time of data capture to delivery to the Shift4 decryption environment. Further, Dara Security attests that a properly implemented Shift4 True P2PE™ solution provides for a reduction in merchant requirements as detailed within this report. Our testing confirmed the absence of cardholder data within the merchant environment when solely leveraging the Shift4 True P2PE™ solution.

When correctly implemented, using POI devices that encrypt cardholder data as the card is entered using the POI devices acceptance method, Shift4’s True P2PE™ solution will dramatically improve overall data security posture in merchant environments and render cardholder data inaccessible from point of interaction at merchant end-points (POI devices) to Shift4’s decryption facilities. The Shift4 solution does not provide the ability to decrypt cardholder data in the merchant environment nor does it allow access to the decryption keys.

Documents

Assessment of Shift4’s True P2PE™ Solution Payment Card ... · Shift4 offers a robust suite of payment card gateway solutions for merchants, including tokenization, and is EMV