Caption: PCI data security standards are failing us
Source: Maksim Kabakou / Shutterstock
Recent breaches of payment systems at Target, Neiman-Marcus, and Michaels show that there’s something fundamentally wrong with the payment card data security standard we’re all reliant on, PCI DSS. The original idea of the PCI data security standards was simple but ambitious: The more PCI-compliant merchants out there, the less frequently security breaches occur. In reality, the list of card data breach victims still grows almost every day.
Proponents of PCI standards may say the breaches were made possible because there were violations of one of numerous PCI requirements. For example, the latest version of the standard includes 399 (!) “testing procedures.” Even if it’s true, does it really matter? If even the largest retailers, with their IT departments and security experts, failed to maintain PCI compliance, how can consumers rely on medium and small businesses?
The PCI-compliant merchant environment is similar to a poorly designed nuclear reactor. The cooling water continuously circulates in order to cool down the active zone, and if the pumps stop for a while, the whole thing melts down and blows up. Fortunately for us, modern nuclear stations have multiple backup systems and extra levels of protection. But PCI-compliant payment systems don’t. Security controls dictated by the standards are either ineffective or difficult (and sometimes impossible) to implement and maintain in a brick-and-mortar environment.
Once a hacker discovers a new exploit and sneaks into the merchant’s network, the fortress falls. There is nothing inside that protects the sensitive cardholder data from being stolen.
Most retail point of sale (POS) systems run on special hardware managed by Windows OS, which makes it similar to a standard PC from an application security viewpoint. Payment software, which takes care of credit and debit card processing, can be either a separate app or a part of the POS, but normally it resides on the same physical machine and shares the same computer resources with the POS and other Windows applications.
In order to process credit or debit card transactions, the payment application communicates with the outside world — the payment terminal, POS, and the payment processor — and therefore it must continuously store, transmit, and process the sensitive cardholder data loaded from the cards. The data is stored on magnetic cards in clear text and, if stolen, can be used “as is” in order to produce a counterfeit card.
Several areas of payment application vulnerabilities exist. Sensitive cardholder data, which is the main target for hackers, can be stolen by penetrating one of those surfaces. Designers of payment systems (or security standards for payment systems) must ensure that their product (either software or standard) protects all possible vulnerability areas.
Unfortunately, for some reason, PCI data security standards (and therefore most payment applications) explicitly take care of only one area, data at rest, which is the information stored on hard drives. Perhaps, it happened because, back in 2004, when the standards were created, collecting data at rest was the easiest and therefore most popular way to pump out the credit card data from the retail store. Back then, POS and payment applications were storing and abandoning enormous amounts of unencrypted card data records on every hard drive. So the creators of the PCI standards were focused on encryption of data at rest in order to fix the obvious flaw, while other surfaces were still vulnerable and waiting in the wings.
PCI rules enabled the processing of data in clear text in the RAM (random access memory) of point of sale machine (data in memory) as well as transmitting the unencrypted card data over the local networks. In addition, the payment application was allowed to store its binary and configuration files with no protection so they could be altered by malicious software. Even without going into the details, it is pretty obvious that there are plenty of ways to attack the PCI-compliant payment application.
RAM scraping, or Memory Parsing, probably is the most reliable way to steal the cardholder data from a PCI compliant POS by exploiting the unprotected data in memory area. A special piece of software installed on a POS machine continuously scans the entire computer memory, or sometimes even a specific POS application process, looking for magnetic track data containing the sensitive cardholder information. A RAM scraper filters out only useful information from an enormous stream of memory data using a special technique — regular expression, or regex. Most likely, this memory parsing technique was used to steal the card data in Target, Neiman-Marcus, Michaels, and many other breaches.
PCI requirements, which were designed with large data centers in mind, are hardly feasible in the reality of the retail store environment. PCI DSS puts an unnecessary burden on merchants who spend a lot of resources on compliance instead of investing in robust security technologies.
Let’s take just a couple of examples. Requirement 10 — “Track and Monitor All Access to Network Resources and Cardholder Data.” Can you imagine a large supermarket chain, operating hundreds of stores with thousands of POS machines, effectively monitoring the activity of each and every device in real time? Or Requirement 12 — “Maintain a Policy That Addresses Information Security for All Personnel.” Imagine a family restaurant owner creating a security policy for its waitresses. Most people in the retail industry don’t know much about information security, and they shouldn’t have to, because security features should be provided by the payment system out of the box.
So if PCI standards are failing to protect retailers, is there anything that can be done to stop the breaches? Chip & PIN (EMV) cards, already adopted in Europe and Canada, are much more secure than the regular magnetic stripe cards that are still used in the US. However, full transition to EMV, even if started today, would take several years.
Fortunately, there is an existing security technology that can be implemented to protect magnetic stripe cards: point-to-point encryption (P2PE), also known as end-to-end encryption. The concept of P2PE in general is simple: The data in clear text is encrypted on one end of the system and decrypted on the another end. When applied to the payment systems, it means that the data is encrypted at the point of card entry — magnetic stripe reader (MSR) — and decrypted only in the remote data center of the merchant’s payment processor. If P2PE is implemented correctly, the sensitive data in clear text never touches the memory, hard drives, or network inside the retail store.
You’d be surprised, but P2PE is pretty old as it’s been used by the same payment card industry to protect debit PIN numbers for many years. However, instead of investing in well-known technology and forgetting about the massive breaches once and for all, the industry decided to implement the bulky and ineffective PCI standards. It’s important to note, however, that PCI DSS is still helpful in many cases, for example, to protect ecommerce servers or payment processor data centers, where access to unencrypted card data is really necessary.
Unfortunately, it is helpless in the hazardous environment of brick-and-mortar stores.
(Disclaimer: The views and opinions expressed in this article are mine and do not necessarily reflect the official policy or position of HP.)
Slava Gomzin is a security and payments technologist at Hewlett-Packard and author of the book Hacking Point of Sale: Payment Application Secrets, Threats, and Solutions (John Wiley & Sons, Feb. 2014), for which the Kindle version was just released. He also has a blog on payment security and technology, PayAppSec. In his role at HP, Slava helps create products that are integrated into modern payment processing ecosystems using the latest security and payments technologies. Prior to joining Hewlett-Packard, he was a security architect, corporate product security officer, R&D and application security manager, and development team leader at Retalix, a Division of NCR Retail. As PCI ISA, he focused on security and PA-DSS, PCI DSS, and PCI P2PE compliance of POS systems, payment applications, and gateways. Before moving into security, Slava worked in R&D on design and implementation of new products including next-generation POS systems and various interfaces to payment gateways and processors. Slava currently holds CISSP, PCIP, ECSP, and Security+ certifications.
