PCI Compliance - The Good, The Bad, and The Insecure

In this first part of a two part article about PCI compliance and web application security, the author looks into the history of compliance, rules and regulations and explores the common shortcomings of such rules. The author also explains why there are such shortcomings and explains that by being compliant, does not necessarily mean having secure web applications.

Does having a PCI compliant website and business means they are bulletproof, or better, hacker proof? This first part of this PCI compliance article looks into, and explains the shortcoming of compliancy, specifically focusing on the popular Payment Card Industry compliance (PCI).

A History Lesson When You Thought Your School Days Were Over

Around 600 BC, the first coins were minted in Greece and Persia, now known as Iran. Their usage was simple: the coins represented a currency value that was used in lieu of previous generations' barter systems. But, as with everything else in the world, innovation and progress led to further complexities. Eventually we evolved to a stage where currency and the use thereof went from a gold standard, to a paper and minted coin system, and now to nothing more than ones and zeros on computer servers.

As that slow progression of change occurred, laws and security surrounding digitized transactions needed to evolve as well. Originally, keeping your money safe was as simple as keeping your coin purse or wallet safe. However, with the advent of magnetic strip cards, digitization of money flow, and finally the Internet and shopping online, there began to grow a need for security methodology to protect that data. Your wallet and your bank were no longer the only two things that protected your money; the places you shopped at were now held responsible as well.

In the beginning, the major credit card companies had their own individual methods: Visa's Card Information Security Program, MasterCard's Site Data Protection, American Express's Data Security Operating Policy, Discover's Information and Compliance, Japan Credit Bureau's Data Security Program, and many others. Each company's program was designed to ensure an additional level of protection of consumer financial details at the merchants themselves, typically by policy restrictions on the storage, processing, and transmission of cardholder data.

This, however, made for many fragmented systems that sometimes varied wildly from card company to card company, which proved quite difficult, if not outright impossible, to adhere to completely because in some cases, one card company's policies violated another's. In fact, often merchants would not accept certain card types simply due to the restrictions imposed. In order to combat this variety and make for a simplistic and easier-compliance policy, the card companies assembled in late 2004 and formed a global alliance. Thus the Payment Card Industry Data Security Standard (PCI DSS) and its managing agency, the Payment Card Industry Security Standards Council (PCI SSC), were born.

PCI compliance, as it is called, became a regulatory standard for all merchants, big or small, that processed transactions involving cardholder data. Organized into six logically related groups with twelve overall requirements, compliance required several key features: A secure network, protection of cardholder data, vulnerability mitigation, access control measures, monitoring and penetration testing, and finally, adherence to a strict and well-defined security policy. This all seems well and good, and proper adherence to these guidelines should yield no breaches of security. Except those are the exact problems: guidelines and adherence.

A Rule is Only as Good as Its Enforcement

The first problem is that PCI compliance is, for the most part, a guideline, not a law. The difference is that while laws have a governing body, strict definitions, and a form of enforcement with punishment for illegal acts, the PCI compliance guidelines are loosely defined by a conglomeration of banking institutions with nearly no oversight (however, plenty of punishment in the form of massive private-industry fines are still levied by this regime). In fact, PCI compliance effectively has the feel of being almost on a volunteer-level of completion due to the rather limited amount of control and oversight. The PCI SSC has no registration entity to handle any sort of listing or inspection of compliant members, nor does it explicitly restrict merchants from participation for non-compliance (unless a merchant finds itself the victim of compromise and, thus, under the watchful eye, and punishment, of the PCI DSS). Because of this, merchants are almost exclusively responsible for not only their own ability to adhere to PCI standards, but their own inspection and certification of compliance as well.

There exist many entities that 'certify' a merchant's PCI compliance, such as ScanAlert, VeriSign, TRUSTe, and others. Some of these entities also proudly tout "Hacker Safe" badges to throw on a merchant's website to assure its customers that their data is secure and the merchant follows the guidelines of PCI compliance to a satisfactory degree. However, the duty falls solely on the merchant to obtain this certification, and there is no real requirement for such certification, either. This lack of certification requirement and self-policing obviously leads to the potential problem of little, if any, adherence to PCI standards. Couple this with the fact that such "Hacker Safe" emblems are, in fact, a welcome mat to black-hat hackers, and you have quite a dangerous concoction of voluntary uncertainty and insecurity. We will cover more on this later in the article.

PCI Compliance Applies Only To Big Boys, Like Amazon. Right?

Wrong. PCI compliance extends to all merchants, big and small, though, most especially big because they are in the limelight of the show. In order to realize the depth and importance of this, we first need to have a basic understanding of how banking institutions and digitized currency works. At its core, you have the Federal Reserve, the Automated Clearing House (ACH) system for Electronic Funds Transfer (EFT) payments directly via bank accounts, and even systems for wire transfers, both domestic (such as FedWire and the Clearing House Interbank Payments System (CHIPS)) and international (such as the Society for Worldwide Interbank Financial Telecommunication (SWIFT)). However, these strictly and federally regulated systems only handle the final processing of payments in between banking institutions, and almost never are used directly by merchants. Instead, merchants will file their transactions through larger entities known as payment processors, which do not fall under the same federal regulation standards as these federal institutions.

When you go to a brick-and-mortar store or shop online and use your credit or debit card, your transaction is processed through a payment processor. In a matter of a few seconds, your card information is provided from the merchant (the store you are shopping at) to a card payment processor. That payment processor checks the cardholder data via the banking institution responsible for that card (such as Visa or MasterCard, as well as a banking institution in the case of debit cards), performs a series of anti-fraud checks, then sends final authorization or denial to the merchant for your transaction. These payment processors typically handle hundreds of thousands, sometimes millions of transactions a day, for millions of cardholders. As such, payment processors are held to the utmost strictest compliance level, known as Compliance Level 1. But not even this highest and most restrictive level of compliance is a perfect guarantee of the safety and security of cardholder data.

How the Mighty Fall - When Compliance is Not Enough

As a payment processor, Heartland Payment Systems handles electronic and other transactions for over 250,000 businesses within the United States, completing over 11 million transactions a day for more than $120 billion USD a year. As one of the largest payment processors in the United States, Heartland is held to the strictest adherence of Compliance Level 1. In fact, as one technology analyst has stated, Heartland effectively leads the way for the entire industry.

It then came as a shock to the industry when Heartland announced that in 2008 it had fell victim to one of the largest mass compromises in history, where more than one hundred million card numbers were compromised to such a degree that entire cards could be duplicated perfectly. But Heartland was not alone in this. Other processors, such as Hannaford Brothers and TJX Companies, also fell victim to the same attack that hit Heartland, yielding an estimated grand total of over 250 million compromised card numbers -- nearly one card number for every person in the United States at that time. And that was not the first nor last time, either.

A few years later in 2012, Global Payments Inc. reported yet another mass compromise: Over ten million card numbers. Even extremely large first-level merchants themselves have fallen victim to massive data breaches, such as the attacks that hit Sony in 2011, compromising the cardholder and other personally identifiable information of over twenty million of Sony's PlayStation Network users. In fact, in 1999, approximately one out of every 1,200 transactions turned out to be fraudulent, resulting from compromised cardholder data. There are some estimates that claim over ten million card numbers are involved in mass compromises every year, resulting in billions of dollars lost due to fraud.

Even merchants certified PCI compliant and "Hacker Safe" are quite heavily vulnerable. As aforementioned in this article, not only is certification a voluntary effort, but it has even proven to be a star-bright, mile-wide target for attacks. Take for example the "Hacker Safe" website seal provided by ScanAlert Inc., a provider of one of the most prominent and widely-used security seals at the time. Touted by major corporations' websites, such as those of Johnson & Johnson, Sony, and Warner Bros, ScanAlert finally garnered the attention of its largest competitor, McAfee, which acquired ScanAlert in October of 2007. This acquisition comes as no surprise considering the business effectiveness of a "Hacker Safe" badge (most websites notice an average of 14% boost on conversion rates, yielding quite a high rate of return).

However, barely three months after its acquisition, ScanAlert found itself under fire for proving to be sometimes ineffective at its badge's promise. In January 2008, technology retailer Geeks.com put out a notice to its customers that it had become the victim of a mass compromise of customer data -- while being certified "Hacker Safe" by ScanAlert. This was later asserted to be due to the generic method of vulnerability scanning and automated certification ScanAlert incorporates. According to McAfee itself, 90% of ScanAlert's "Hacker Safe" daily scans are performed by automated systems with no manual intervention or oversight, designed to look for common SQL injection, cross-site scripting, and other general web application security flaws. After the Geeks.com hack, one security research organization claimed to be able to effectively penetrate nine out of ten "Hacker Safe"certified websites well enough to easily access customer financial data. Not only this, but hackers may also find a "Hacker Safe" badge to be a challenge. Where they may normally ignore a website and move on to the next once their basic vulnerability scanning tools fail, a "Hacker Safe" badge may prompt hackers to pursue further, more advanced methodologies to prove the badge wrong. Such seems true, especially in Geeks.com's case.

The most interesting and damaging part is that all of these entities -- Heartland, Hannaford Brothers, TJX Companies, Global Payments Inc., Sony, Geeks.com, and so many others -- shared one important thing in common: They were all either certified PCI-compliant (or worse, were the PCI compliance certifiers) at the time of their attacks.

Note: This is a 2 part article. Read the second part of the article PCI Compliance - The Good, The Bad, and The Insecure.

Subscribe to our blog via RSS or follow Netsparker on Twitter or Facebook to be automatically notified once the second part of the article PCI Compliance – The Good, The Bad, and The Insecure is released.