Is PCI-SSC Securing the Enterprise or Lining Pockets?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

When we were all introduced to the PCI standard, organizations right down to mom and pop operations were hopeful that the regulation would address many of the security issues involved with payment cards. Before long, security pros in the trenches realized that the initiative added a slew of technical difficulties while executives realized the crippling financial implications of the standard. Mom and pop stores were simply left in a cloud of confusion over the regulation.

And so, many still remain in that state.

Even so, we pressed on, doing our best to meet the requirements and acquire PCI certification. Many of us realized that even with massive overhauls, and the blessing of a Qualified Security Assessor (QSA), gaping issues still exist along with tons of confusion over the interpretation of the regulation.

A large Pennsylvania health care provider was faced with costs too great to maintain operations and still meet PCI regulations. Their executives decided to do what many others have already done after making failed attempts at compliance – roll the dice and hope not to get fined.

The strategy failed not once but twice.

Today, that same health care provider has what is described by staff as “crippling” lockdowns that prevent the business from actually operating. Many organizations have been financially hurt more by the regulation than from data leakage or theft.

A security auditor with a QSA outfit who asked to remain anonymous states, “We’ve run into many cases where interpretation of the standard by the organization drastically contradicts the interpretation by the QSA they hired. In addition, QSAs offer significantly different opinions to the same organization, which adds greater pressure, frustration, and confusion to the issue. Many times, organizations over compensate and go well beyond the requirements hoping to avoid fines and data disclosures.”

Of course, the PCI Security Standards Council heard the cries from the field. How did they respond? They added more requirements such as PCI PIN Entry Device (PED) Security Requirements and the Payment Application Data Security Standard (PA-DSS) along with an anticipated revision of the main PCI-DSS regulation.

PA-DSS requirements apply to commercial payment applications that are sold, distributed or licensed to third parties. PA-DSS requirements do not apply to in-house payment applications, but these applications must still be secured in accordance with PCI-DSS.

In addition, the Council will be qualifying companies to become Payment Application Qualified Security Assessors (PA-QSAs) in the coming months. Companies that are PA-QSA approved will be recognized in a Council-maintained and published list and can begin conducting PA-DSS assessments in accordance with PA-DSS Security Audit Procedures.

All companies that were previously recognized as PA-QSAs under Visa Payment Application Best Practices (PABP) will need to enroll and re-validate as a Council PA-QSA. Payment applications validated as compliant under Visa’s PABP program will transition to the PCI-SSC approved list.

But are these requirements going to simply put the squeeze on focus areas and move the threat vector somewhere else in the business process? How will this impact risk ownership?

Who’s Minding the Back Door?

Let’s look at Hannaford food stores for just a moment. The company said that the data breach it disclosed on March 17 involved malicious software that was found on computer servers at about 300 of the company’s stores.

The software reportedly intercepted credit card data during checkout and sent captured information overseas.

It’s obvious that while this organization was PCI certified, criminals still managed to load malware on 300 hosts across their enterprise and exploited data transit, for three months.

That said, the new regulations coming down from the PCI-SSC are supposed to deal with the above issues and more. Forgive me if I’m pessimistic here but from what others and I have seen, reactive regulations seem to be falling short of the mark on all fronts. In addition, they multiply the work needed to comply.

First of all, it adds a 3-card monty shell game in regards to risk. Auditors and the organization are pushing it around the table hoping to avoid being the outfit that ultimately ends up holding the bag. Now add more regulations and the situation only gets muddier.

So let’s recap. PCI was introduced to deal with security issues with payment cards. The regulation caused more problems than it solved, and as a nice side effect, it generated a healthy cash flow in the way of fines. Criminals ran amuck in a PCI certified environment by exploiting 300 hosts and attacking data in transit. And now, organizations have to deal with the new regulations AND re-certify even though they already hold Visa PABP.

Today it appears that organizations are going to have to deal with a web of red tape under the new trio of PCI regulations. On top of that, a wonderful new niche market has been created for “qualified” application assessors/auditors and scanners. This of course means that you’re going to see more expenses added to the PCI pile. It should be clear to many that additional regulations are not going to improve the situation we’re in, or in layman’s terms, you can’t improve an overcooked steak by cooking it longer.

While the stated mission of the PCI Security Standards Council is to enhance payment account security by driving education and awareness of the PCI Data Security Standard and other standards that increase payment data security, criminals, executives and security practitioners understand the impact that the regulation has caused.
And while security pros run around plugging leaks in the dam, and while organizations struggle to finance these plugs, criminals are simply shifting the attack vector to areas that PCI doesn’t cover or hasn’t identified as an issue yet.

This article was first published on EnterpriseITPlanet.com.