Understanding Payment Device Compliance

Article PCI DSS
Payment Device Compliance

 

As you work to implement new payment card devices on campus, or are approached by different departments/merchants wanting to use new solutions or take payments at mobile events, new locations, etc., it is easy to get confused on what payment devices are acceptable, what devices you can implement and remain in compliance with PCI, and frankly, what the different acronyms you hear vendors reference even mean.

This guidance will hopefully take out some of the technical jargon and explain your options in clear text (wait…I thought we didn’t want information in clear text!)

PCI DSS: The Payment Card Industry Data Security Standard (PCI DSS) applies to all organizations that store, process, and/or transmit cardholder data. It covers technical and operational requirements for systems included in or connected to the cardholder data environment. If you are a merchant who accepts or processes payment cards, you must comply with the PCI DSS.

POS: A Point-of-Sale (POS) transaction is what takes place between a merchant and a customer when a product or service is purchased, commonly using a point of sale system to complete the transaction. A POS system is a combination of POS hardware and POS software for processing payments. Each time you eat at a restaurant or make a purchase at a grocery or convenience store, your card is most likely being processed through a POS system.

PTS: PIN Transaction Security (PTS) devices are the actual devices used by merchants at the point-of-sale interaction for capturing payment card data and authorizing the transaction. The PCI Security Standards Council validates the conformance of PTS devices to the PCI PTS standard and provides a list of approved devices. The Council urges merchants to use approved PTS devices in their payment environments. Some payment brands (i.e. VISA) require the use of approved PTS devices by merchants.

Why is it so important for merchants to use approved devices? Compliance with the PTS requirements ensure a device helps, not hinders, merchants’ overall PCI DSS compliance efforts and protects cardholder data. Attackers will often target outdated POS hardware and software, as these devices may not offer encryption technology, will not be configured to clear information in memory on a regular basis, and therefore may be storing information that can be easily compromised should attackers manage to access the devices. The PCI PTS standard focuses on securing payment devices, both physically and logically, and includes requirements for clearing memory and upgrading systems on a regular basis. PTS device manufacturers must submit each device for testing against the standards and applications must be reviewed ongoing.

It is up to individual merchants to ensure that they are using devices that meet the PTS requirements (a list of PCI-compliant PTS devices can be found on the PCI SSC website). This list can help merchants select a device that meets their needs and ensure it meets applicable compliance requirements. Merchants should also ensure that they take advantage of available security settings and modules, which starts by using the latest devices with the latest firmware and software. The Council’s PTS requirements include detailed guidance on other components to ensure they do not affect the security of the end product. This includes things like the secure use of open protocols, information regarding if the PIN devices are Internet-, Wi-Fi- or GPRS-enabled, etc., and the use of devices such as smart card readers, and components such as EPPs.

EPP: Encrypting PIN Pads (EPPs) are a component of unattended Personal Identification Number (PIN) Entry Devices (PEDs). Typically, EPPs are used to enter a cardholder’s PIN in a secure manner, and are seen on ATMs, gas stations, kiosks, and vending machines. Overall requirements for those devices can be found in other PCI PED security documents. Vendors may choose to have EPPs evaluated independently as the first step for PED approval, or as part of the overall PED approval for that device type.

SRED: SRED stands for secure reading and exchange of data. The SRED module verifies cardholder account data is protected at the point of acceptance, which is the first step in the broader point-to-point encryption process. The SRED module is important for the protection of non-PIN cardholder data.

P2PE: Point-to-Point Encryption (P2PE) is another standard from the Council. A P2PE solution is a combination of secure devices, applications, and processes that encrypt payment card data immediately upon swipe or dip in the payment device. The data remains encrypted until it reaches the solution provider’s secure decryption environment. Use of a P2PE solution protects payment card data as the information will not be readable to anyone who might steal it during the transmission process.

A key benefit of many P2PE solutions is that the solution providers are working to integrate their solutions with various payment applications, streamlining the overall payment process and automating the back-end reconciliation for merchants as well.

In order for a P2PE solution to receive validation from PCI, the solution, the solution provider, and associated players in the overall P2PE solution must undergo a comprehensive assessment and audit by a P2PE Qualified Security Assessor (QSA), before being brought before the Council for approval. Find a full listing of approved P2PE solutions.

Validated P2PE solutions will also list the approved devices that can be used as part of the overall solution. If you look at the P2PE solution listing and click on the Solution Details, you can view the supported PTS devices and corresponding model numbers, as well as expiration dates.

Stand-alone Payment Devices: Stand-alone payment devices that are not integrated with a payment application can typically be purchased from your acquiring bank. These devices allow you to manually enter a transaction amount and then swipe or key in payment card details directly into the device. How they gain access to the network and send payment information determines the self-assessment questionnaire the merchant will need to complete. A stand-alone payment device that is connected via an analog/phone line falls in the SAQ B category. A payment device connected to your network, or IP- connected, will move to the SAQ B-IP.

EMV: EMV is not a requirement of the PCI DSS, but the technology does improve security for card- present transactions. The EMV technology uses secret cryptographic keys to verify the authenticity of the physical card. Only after the card is validated as genuine by the issuing bank, does the authorization occur. Unlike the static security code on magnetic-stripe cards, every time an EMV card is used, the card chip creates a new, unique security code. If a hacker steals the cardholder data from one specific point of sale, normal card duplication would not work, because they wouldn’t know the dynamically generated security code, and any attempted card-present transactions would be declined.

By now most consumers have EMV/chip cards. If a customer has an EMV card, but the organization or department accepting the transaction does not have equipment that supports chip technology, and the magnetic stripe must be used to handle the transaction, the organization will assume the liability for any fraudulent transactions EMV could have prevented.

NFC/CTLS: Payment devices can also be enabled to accept contactless (CTLS) payments with Near Field Technology (NFC). This means users can use applications like Google Pay, Apple Pay, Pay Pal, etc. and make payments using their smartphone and their mobile wallets. Once the cashier has rung up the total cost and asked for payment, the customer can hold their phone up to the contactless terminal and exchange data to make the payment. For most applications, the actual 16 digit card number or any sensitive cardholder data is not stored on your phone, but is instead a ‘token’ which is given to the merchant, making the transaction itself very secure.

Device Lifecycle: The expiration date for devices is the date upon which the device’s PCI approval expires. Expired devices are not receiving updates and may not be able to withstand current vulnerabilities and attacks. Visa requires that PCI PTS devices must not be purchased after their expiration date, so it is important to check these dates carefully. When researching what devices may be right for your merchant environments, you will also want to check dates of the various P2PE solutions and devices to make sure they are not nearing the end of their compliance cycle.

If you are purchasing new devices and replacing old devices, it is also important to dispose of the previous models securely by either returning them to the acquiring bank from where they were purchased, or by utilizing a compliant destruction facility.

Criminals continue to target point of sale devices. Just last month, several restaurant chains, including Planet Hollywood, discovered that malware on their POS devices was able to capture customer payment card data over a timespan of 10 months. Ensuring your merchants are using up to date and compliant devices goes a long way towards preventing this type of incident from occurring.

Some additional guidance from the CampusGuard Security Advisor team:

[Hobby]: The devices that accept and process payment card transactions can be one of the greatest vulnerabilities to cardholder data. The PCI DSS is designed to protect cardholder data that is processed, stored, or transmitted by merchants. The PA-DSS protects that same data when processing by applications. The PCI PTS and PCI PIN security requirements, however, are more concerned with the physical and logical security of the point-of-sale devices or terminals, whether attended, i.e. manned by merchants, or unattended, i.e. automated parking payment machines.

One place payment device security crosses directly into the PCI DSS is requirement 9.9 which is focused on the protection of payment devices. Requirement 9.9 applies to organizations that process card-present transactions, and the most common way to process these transactions is with a payment card device or terminal. There are three major aspects of requirement 9.9:

  • Maintaining a list of devices
  • Periodically inspecting the devices to look for tampering of substitution
  • Training personnel to be aware of and report suspicious behavior or tampering.

While 9.9 is generally one of the best understood requirements of the PCI DSS, many organizations struggle with its compliance. Perhaps because it is so well understood,
organizations may not emphasize inspection training for their personnel; they may forget to inspect their card readers regularly; or they may not log those inspections.

We’ve all heard the old adage that “practice makes perfect.” I’d like to amend that by saying “perfect practice makes perfect.” If we practice “ticking boxes” during the PCI compliance review, we’re not providing continuous, day-to-day protection for payment devices. To provide that protection, organizations should regularly review their procedures and practice those procedures every day.

Share

About the Author
Katie Johnson

Katie Johnson

PCIP

Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.