PCI Compliance Tips from PCI SSC

OTI Contactless Credit Card Reader

From PCI SSC –  The COVID-19 pandemic is quickly changing how many small merchants accept payments. Merchants that previously only had brick-and-mortar locations are moving to accept e-commerce and over-the-phone transactions. PCI Security Standards Council shares key
considerations to help small merchants keep their customers’ payment data secure in this rapidly changing environment.

One tip from Kiosk Industry Group is to understand and know what access, if any, your vendors and supply chain have access to.  The Target breach for example was due to a vendor using out-of-date free Malware protection on their PC and getting in via Microsoft infrastructure.

TIP #1: REDUCE WHERE PAYMENT CARD DATA CAN BE FOUND

The best way to protect against data breaches is not store card data at all. Many small merchants are offering curbside pickup now and are accepting telephone payments in lieu of former face-to-face transactions. Avoid writing payment card details down and instead enter them directly into your secure terminal. More Information: PCI SSC Special Interest Group Paper: Accepting Telephone Payments Securely

TIP #2: USE STRONG PASSWORDS

The use of weak and default passwords is one of the leading causes of payment data breaches for businesses. To be effective, passwords must be strong and updated regularly. Weak and vendor default passwords are a frequent source of small merchant breaches. More Information: Strong Passwords Infographic

TIP #3: KEEP SOFTWARE PATCHED AND UP TO DATE

Criminals look for outdated software to exploit flaws in unpatched systems. Timely installation of security patches is crucial to minimize the risk of being breached. One way to keep up with all the necessary changes is by ensuring vulnerability scans are performed regularly to identify security issues. PCI Approved Scanning Vendors (ASVs) can help you identify vulnerabilities and misconfigurations in your Internet-facing payment systems, e-commerce website, and other systems, providing a report of your vulnerabilities and how to address them—for example, what patches to
apply. Be sure to act upon the results of ASV vulnerability scans and keep your software up to date. More Information: Patching Infographic

TIP #4: USE STRONG ENCRYPTION

Encryption makes payment card data unreadable to people without a specific key, and can be used to protect stored data and data transmitted over a network. Ask your vendor whether your payment terminal encryption is done via a Point-to-Point Encryption solution and is on the PCI SSC’s List of PCI P2PE Validated Solutions. If you are setting up a new website, confirm the shopping cart provider is using proper encryption, such as TLS v1.2, to protect your customers’ data. More Information: Information Supplements on Use of SSL/Early TLS

TIP #5: USE SECURE REMOTE ACCESS

To minimize the risk of being breached, it’s important that you take part in managing how and when your vendors can access your systems. Criminals can gain access to your systems that store, process, or transmit payment data through weak remote access controls. You should limit use of remote access and disable it when not needed. If you must allow remote access, ask your vendors to use multi-factor authentication and strong remote access credentials that are unique to your business and not the same as those used for other customers. More Information: PCI SSC Secure Remote Access Infographic

TIP #6: ENSURE FIREWALLS ARE CONFIGURED PROPERLY

A firewall is a device or software that sits between your network and the Internet. It acts as a barrier to keep traffic out of your network and systems that you don’t want and didn’t authorize. Firewall rules can seem complex, but configuring them properly is vital to security. If you require additional assistance to properly configure your firewall, seek help from a network professional. More Information: Resource for Small Merchants: Firewall Basics

TIP #7: THINK BEFORE YOU CLICK

Hackers use phishing and other social engineering methods to target organizations with legitimate-looking emails and social media messages that trick users into providing confidential data, such as payment card number, merchant account number or password. Small merchants should be extra vigilant and be on the look out for common phishing and social engineering hacks. More Information: Beware of COVID-19 Online Scams and Threats

TIP #8: CHOOSE TRUSTED PARTNERS

It’s critical you know who your service providers are and what security questions to ask them. Is your service provider adhering to PCI DSS requirements? For e-commerce merchants (and those of you that recently started accepting e-commerce payments in lieu of face-to-face payments), it is important that your payment service providers are PCI DSS compliant, including the service provider that manages your payment process (your “payment service provider” or PSP). More Information:

Additional Links

• PCI Compliance Summary Page for Kiosk Industry
• What’s the Difference Between EMV Compliance and PCI Compliance?
• When PCI Compliance Isn’t Enough

Relevant PCI Compliance Member Links

• Contactless EMV Card Readers by OTI Global
• Gift Card Kiosks and Cash2Card by Self-Service Networks
• Contactless Card Readers by Unattended Card Payments
• Cloud Card Payment Processors and Gateways by DCAP
• World Leading Card Readers by Ingenico

PCI SSC Technical FAQs for use with Version 6

UCP Unattended Payments is a PCI Compliance expert

A new November update to the PCI SSC Technical FAQs has been issued. It is listed below. We have also listed some other interesting questions.

For a full copy of this document, it is provided by the PCI Security Standards Council

November 2020: POI devices must support one or more of four specified techniques for the loading of private or secret keys. Methods a and b are for plaintext key loading and methods c and d are for encrypted key loading. The requirement specifies that EPPs and OEM PEDs intended for use in an unattended environment shall only support methods a, c, and d. It further specifies that SCRPs shall only support the loading of encrypted keying material. Are there any other restrictions?

A Yes. For all new evaluations (i.e., evaluations that result in a new approval) of POI v5 devices, the POI devices must support at least one of the encrypted key loading methods for the loading of private or secret keys

Requirement A9 stipulates that the device must provide a means to deter the visual observation of PIN values as they are being entered by the cardholder. What methods are acceptable?

A The POI Security Requirements provide for several options that may be used separately or in combination to provide privacy during PIN entry. These options are: ▪ A physical (privacy)shielding barrier. Note that in case the privacy shield is detachable, a user’s guide must accompany the device that states that the privacy shield must be used to comply with ISO 9564. Optionally, the user’s guide can also reference PCI device requirements; ▪ Designed so that the cardholder can shield it with his/her body to protect against observation of the PIN during PIN entry, e.g., a handheld device; ▪ Limited viewing angle (for example, a polarizing filter or recessed PIN pad); ▪ Housing that is part of the ATM or kiosk, cardholder’s hand or body (applies to handheld devices only); and ▪ The installed device’s environment.

May (update) 2018: PIN entry devices may physically integrate in the same device other functionality, such as mobile phone, PDA capabilities or POS terminal. Handheld configurations of PIN entry devices may accommodate the attachment (e.g., via a sled, sleeve or audio jack) of a mobile phone, PDA or POS terminal, where the attached device communicates with the PED. Such a configuration appears as a single device, with separate interfaces for input by the clerk and cardholder. What considerations must be taken into account for either of these configurations?

A For any device where the cardholder is expected to use the same interface for PIN entry as the clerk would use for phone, PDA, payment application, etc. purposes, or where there are multiple interfaces in a single integrated device, the integrated device must be physically and logically hardened in accordance with the PTS POI security requirements. In a handheld configuration with an attached device, there is a risk that the cardholder enters the PIN on the wrong interface. Furthermore, the communication interface between the PED and the attached device may give the latter access to MSR functions without cryptographic controls, allowing skimming of card account data. In this integration model, then either: ▪ Both devices are assessed and validated as compliant to the PTS POI requirements, or PCI PTS POI Evaluation FAQs – Technical – For Use with Version 6 November 2020 Copyright © 2013-2020 PCI Security Standards Council, LLC. All Rights Reserved Page 8 ▪ The PED device, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module. The PED must enforce SRED functions for encryption of card data at all times. The PED is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted.

May (update) 2018: PIN Entry Devices that attach to a mobile phone, PDA or POS terminal via a sled, sleeve, audio jack, or wireless connection are required to support SRED. Does this apply to PEDs that are integrated with other devices (such as a tablet or mobile phone) that appear as a single device?

A Yes. An integrated device is one where two physically and electronically distinct devices (e.g., a PED and a commercial off the shelf (COTS) device such as a mobile phone) appear as a single device through the use of the plastics to mask the connectivity. In such a configuration, there is a risk that the cardholder enters the PIN on the wrong interface. Furthermore, the communication interface between the PED and the integrated device may give the latter access to card reader functions without cryptographic controls, allowing skimming of card account data. In this integration model, then either: ▪ Both the PED and non-PED are assessed and validated as compliant to the PTS POI requirements, or ▪ The PED, which must also control the card reader(s), must implement and be validated against the PTS POI SRED module and be both physically and electronically distinct from the non-PED system (for example, it is not acceptable to have the PED firmware execute within the same processor as the non-PED firmware). The PED must enforce SRED functions for encryption of card data at all times. The PED is only allowed one state, and that is to encrypt all account data. It cannot be configured to enter a state where account data is not encrypted. The Security Policy must also state that the non-PED has not been assessed under the PCI PTS program and security guidance is required to ensure the secure operation of the solution. An additional note will be added to the portal noting that the non-PED has not been assessed under the PTS program.

October 2018: Are there minimum requirements for the version of Android to be used within a PTS device?

A Yes, it is expected that the Android version is officially supported with security patches, at a minimum. Any reports, including deltas, where the Android version is not supported with regular security patches will be rejected. Where these patches are not provided by Google, evidence of security patches (implemented at least monthly) provided by the vendor must be documented in the report provided by PCI; evidence for this is expected to be validation of the update code by the laboratory for at least two previous patches, as well as validation by the laboratory that these patches have remediated existing known vulnerabilities in the version of Android used. Vendors should note that this means that consideration for the future patch status of any Android version used must be made during the initial design stages of the device, to prevent unexpected rejection of devices after an Android version becomes unsupported during the development of a solution.

What vulnerabilities must be taken into account for a touchscreen?

A If the sides are accessible, an overlay attack utilizing a second, clear touchscreen could be a problem. The connection/path from the touchscreen to the processor (and any devices used for decoding the signals in between) needs to be verified to be secure. Bezels around the touchscreen are especially dangerous because they can conceal access to areas of concern that are described above. The API for firmware and applications (if applicable) needs to be looked at carefully to determine the conditions under which plain-text data entry is allowed. Example: It should not be possible unless under acquirer display prompt-controlled devices, for a third party to display an image (JPEG) that states “press enter when ready for PIN entry” and then have a plain-text keypad pop up on the next screen. The extra caution is warranted for touchscreen devices because of the desire to make touchscreen devices user-friendly and to run many different, unauthenticated, uncontrolled applications. This is especially true for the devices that are intended to be held because of the tendency to regard them as a PDA that can perform debit transactions.

February (update) 2014: Does the use of protective keypad overlays impact the approval status of a device?

A Yes. In general, overlays are not supported by the device approval program due to the potential for keypad tapping or hiding tamper evidence. Overlays may be used where they do not cover any portion of the PIN entry area. For example, in a touchscreen device where the touchscreen is used for both signature capture and PIN entry, an overlay may be used to protect the signature area from excessive wear. In this example only the area used for signature capture may be protected. The material used must be transparent, and not merely translucent, so as not to obstruct the key-entry area when viewed from any angle

Some devices ship with firmware that may be convertible into a compliant version but is not compliant as shipped. When is this acceptable?

A This is only acceptable where the conversion is one way and cannot be reversed. A device can only be converted to a compliant version. It shall not be capable of converting a compliant version to a non-compliant version. The conversion must be performed at the initial key loading of the acquiring entity’s secret keys. The transformation must result in the zeroization of any previously existing acquiring entity secret keys. The compliant version of firmware must be clearly distinguishable from the non-compliant version. Merely appending a suffix (one or more characters) to an existing firmware version is not acceptable. Rather the conversion must result in a high order version number that is clearly distinguishable to purchasers of such devices. Only the compliant version shall be approved and listed.

January 2015: There are a number of FAQs on the use of wireless technologies, such as Bluetooth and Wi-Fi. What is the intent of these FAQs, and does PCI have any specific requirements for other types of communications technologies?

A The intent of the FAQs on all wireless communications for POI devices is to ensure that the interfaces of the POI are protected such that: ▪ Card data cannot be easily intercepted. ▪ Command interfaces to the terminal cannot be easily accessed, intercepted for attack (such as MITM), or used as an attack vector into the device. ▪ Compromise of the interface does not lead to, support, or facilitate further compromise of security assets of the POI. PCI does not mandate or require the use of any specific communication technology, but any implementation must meet the above requirements through some aspect of the physical or logical layers of communication. Physical or direct wired communication often achieves this through the nature of its physical interface. Wireless communications cannot rely on this and therefore must rely instead on security at the link or application layers through use of a Security Protocol to establish a trusted path for all communications over the wireless link. This Security Protocol must have been tested and approved under the open-protocols module of the PCI PTS evaluation of that device, and examples of acceptable Security Protocol implementations include WPA2 (implemented at the link layer), or VPN encrypted tunnels (implemented at the application layer)

December (update) 2016: Can a PTS device be used as a beacon (iBeacon or BLE beacon) transmitter?

A Beacons for any version of BLE (e.g., 4.0, 4.1) are allowed providing the following conditions exists and are validated by a PTS approved lab: ▪ The beacon is listed as a device interface in the PTS POI report. ▪ Over the Air (OTA) provisioning is not allowed at any time. Provisioning and updating of beacons must be consistent with existing PTS standards. (i.e., Section J, B4 or B4.1) ▪ Must be referenced in the security policy. ▪ Beacons are transmit-only. The lab must validate that BLE communication cannot be used to respond to any external requests, connect, pair, or otherwise provide two-way communication to any other device. ▪ The vendor provides documentation on the secure use and provisioning of the beacon and that the documentation clearly states the beacon is used for transmit only, and that OTA provisioning is not allowed. ▪ The vendor will document the purpose of use of the beacon functionality⎯i.e., its intended use. The documentation must include what data is transmitted and ensure that no sensitive data can be transmitted. ▪ The PTS device is never allowed to receive beacon transmissions.

Additional Links

• PCI Compliance Summary Page for Kiosk Industry
• What’s the Difference Between EMV Compliance and PCI Compliance?
• When PCI Compliance Isn’t Enough

Relevant PCI Compliance Member Links

• Contactless EMV Card Readers by OTI Global
• Gift Card Kiosks and Cash2Card by Self-Service Networks
• Contactless Card Readers by Unattended Card Payments
• Cloud Card Payment Processors and Gateways by DCAP
• World Leading Card Readers by Ingenico