PCI Standards

 “Not All That Glitters Is Gold”

By John W. Kelly and the CISOHandbook.com Team

Kudos to the Payment Card Industry Security!  The PCI Data Security Standard version 1.1 is the first best attempt to create an overarching framework of IT security controls that is intent on protecting consumer data.  Not only is it the first, but it is actually fairly effective at achieving its objective. However, security is a “deficiency-focused” discipline.  We look for the short-comings in everything around us in an attempt to identify and mitigate risk.  Well, the PCI standard is no exception.  Though the standard is good, we are going to explore some of its deficiencies. In that spirit, this article will not serve as an exhaustive overview of PCI; rather it is intended to present additional considerations with regard to protecting consumer data.  In order to provide a common frame of reference for this article, we will begin with a quick primer on PCI.

The PCI DSS version 1.1 consists of a collection of comprehensive requirements for enhancing payment account data security. It is a collaborative effort set forth by the founding payment brands of the PCI Security Standards Council, which include American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. The primary focus of this venture is to help aid in the adoption of consistent data security measures across the globe.

This framework contains requirements for security management, policies, procedures, network architecture, software design and other critical protective measures intent on helping organizations to proactively protect customer account data.

The PCI DSS v1.1 framework consists of the following levels of certification:

MERCHANT LEVEL	MERCHANT DEFINITION	COMPLIANCE
Level 1	More than six million V/MC transactions annually across all channels, including e-commerce	Annual Onsite PCI Data Security Assessment and Quarterly Network Scans
Level 2	1,000,000 - 5,999,999 V/MC transactions annually	Annual Self-Assessment and Quarterly Network Scans
Level 3	20,000 - 1,000,000 V/MC e-commerce transactions annually	Annual Self-Assessment and Quarterly Network Scans
Level 4	Less than 20,000 V/MC e-commerce transactions annually, and all merchants across channel up to 1,000,000 VISA transactions annually	Annual Self-Assessment and Annual Network Scans

PCI Council requires that their merchants retain consumer credit card data for 12-16 months in an effort to satisfy card company retrieval requests. For those not in the know, a card company retrieval request is a procedure whereby a cardholder or card-issuing institution questions or disputes a credit transaction.

In 2004, BJ's Wholesale Club sued IBM for allegedly failing to disable a feature in its payment software that stored so-called Track II data (cardholder's account, encrypted PIN, plus other discretionary data) from a credit card's magnetic stripe after a transaction was approved. As a result, BJ's claimed in its lawsuit, Track II data on customer cards (with transactions between July 2003 and February 2004) may have been stolen or misused.

This requirement seems redundant since consumer credit card data is already being stored centrally within the confines of the card issuer’s secured data centers, where the likelihood of a data breach is significantly reduced.

In other words, this issue could be avoided if we were to do away with this requirement entirely and make the card issuers solely responsible for the custodianship of this information. Merchants could then shift their focus to the proper destruction of any paper generated as part of the card transaction; a process for which the PCI standard already provides guidelines.

The current standard does not enforce encryption of “in flight” cardholder data on the Internal private network.

In March 2008 a PCI Certified Massachusetts grocery chain (Hannaford Brothers) suffered a breach in which unencrypted cardholder data was captured “in flight” by a piece of malware that had infiltrated their computing environment.

This type of incident could be avoided by mandating that “in flight” consumer data be encrypted using PCI certified and industry accepted encryption mechanisms (e.g. 128 bit SSL or SFTP) when data is transported on an internal network and/or between network zones.

While this may seem like overkill, it has validity provided there are other deficiencies in regard to the overall internal network security posture. This suggestion becomes a catch-all for organizations that do not have a strong concept of the trusted network (Controls existing within the environment e.g. NAC, internal IPS/IDS with proper levels of event correlation, monitoring and alerting).  

The current standard only requires merchants prove they have antivirus protection.

Again, the Hannaford Brothers incident comes into focus, as requiring only antivirus protection as part of the certification criteria is an outdated and insufficient measure for protecting card holder data. Today’s blended threats are much more sophisticated and their delivery mechanisms (e.g. phishing, browser drive-by’s) are far more pervasive. Antivirus does not provide sufficient protection against the threat malware presents as a whole.

The PCI DSS framework should be revised to require the more all-encompassing threat of malware, which includes computer viruses, worms, Trojan Horses, root kits, spyware and dishonest adware.

 The current standard consist of 12 requirements sections with which merchants must comply, but does not provide a means by which to score noncompliant areas requiring remediation.

This particular issue creates a situation which every organization faces at some point: An endless number of tasks and a fixed number of resources.  This is particularly true in the area of security.  Management rarely enjoys paying for the proactive security measures. And when faced with a laundry list of issues and initiatives, requires guidance in prioritizing those limited resources.

A weighted scoring system could provide that type of guidance.  A simple mechanism that prioritizes issues based on the level of risk would go a long way in identifying and prioritizing an organization’s remediation efforts. 

It would also aid organizations in reducing that critical element that all security incidents require: time.  Any gap in compliance potentially leaves an organization (and consumer data) exposed, while the merchant scrambles to figure out where to start.  The longer the time period, the more likely the vulnerability will be exploited.

This proposed assessment framework should provide a scoring mechanism that can be utilized by the Qualified Security Assessor (QSA) to more effectively direct the remediation efforts of the entity attempting to attain certification.

As we have seen, there are a number of complexities associated with the PCI Standard that directly impact hundreds of thousands of merchants.  Many of which do not possess the where-with-all to properly interpret and implement these controls.  Maybe it’s time to “flip the script.”

As with many aspects of life, we adopt a single paradigm for addressing a specific issue and become locked into that method.  This becomes the constraint or “box” that limits our ability to approaching the same problem from a different perspective.  So, in the name of thinking outside the box, let’s get crazy for a second and look past all of the security controls and focus on the reason that PCI was created: the protection of consumer data.  Using this as the foundation, perhaps the implied model by which PCI operates could be altered. 

Let’s consider the gold supply of the United States.  It is housed in the bullion repository located in southern Kentucky; right in the middle of an army base named Fort Knox.  It is conceivably one of the most fortified “banks” in the world since it is the home to the US Army’s 46^th Infantry Regiment, the 16^th Cavalry Regiment, the 194^th Armored Brigade, and the 15^th Cavalry Regiment.  Now that is “Anti-Virus.”   In the history of Fort Knox it has never been robbed, nor has there ever been an attempt.  The deterrent measures are simply too great.

Now, let’s take a look at how we address consumer data: it is a distributed model where the burden is placed on merchants and vendors who accept the payment.  Perhaps the model could be simplified by the creation of a “Fort Knox” model for Consumer Data.  Since the credit card companies already receive the data for processing, it would be logical that they could also make it available to the merchants and vendors who sent it to them. Then the PCI standard would only be for the proper destruction of data on the part of the merchants and vendors.  This is a much easier task that does not require a high level of security sophistication. 

We do not feel that it can be stated too many times…bravo to the credit industry for creating the PCI standard!  The PCI Data Security Standard is beneficial and is the most comprehensive security framework to date in addressing confidential information.  However, as we have illustrated, it is certainly not a security panacea. And any organization that is relying solely upon PCI for guidance is asking for trouble.

Moving forward, we feel that the PCI Council should CONSIDER centralizing the storage and retention of consumer credit card data. After all, who is better suited to adequately protect this sensitive data, the hundreds of thousands of merchants with varying IT infrastructures and security capabilities scattered all over the United States or large and well funded organizations like Visa, MasterCard and American Express? We feel the latter is the best choice.

As always, your comments and feedback are welcome and encouraged.

John Kelly is currently engaged at one of the world’s largest credit bureaus where he deals with security issues involving confidential consumer information on a daily basis.  He has also been as member of the CISOHandbook.com team for the past 2 years as a research analyst and subject matter expert. We are certainly glad he has come out of his shell and put his opinions in writing. We look forward to more of his work in the future.

Ron Collette and Mike Gentile

PCI table verbiage from the Cybertrust website