PCI DSS - Why it fails

Filed Under: Featured

Read the contrasting opinion...

PCI DSS - Why it fails

PCI logoThe Payment Card Industry Data Security Standard (PCI DSS) is a globally agreed standard of compliance for any company that accesses, stores or transmits cardholder data (CHD) and personally identifiable information (PII).

I've written a contrasting article about the successes of the PCI DSS, but in this article I want to highlight five reasons I think it fails in its goal.

1. All bark, no bite

The PCI DSS is a lengthy document that provides a baseline for data security. By that I mean it's a starting point, not an end state.

Since when has doing the bare minimum been a good security strategy?

What's more, much of the document is open to interpretation in terms of compensating controls.

Why not be more explicit about which technologies are best suited to protect against a given threat?

If something is to be encrypted, clearly identify what kind of encryption standard is to be used, e.g. AES256. And when a given technology becomes obsolete, change the guidance!

I know this will cause more work by the maintainers of the standard but it's work that will pay off in both the short- and long-term.

As for the non-compliance penalties, in some cases they're hardly deterrents.

I have read about and gotten first-hand information from certain companies blatantly disregarding the standard because it will cost them more money than simply paying the fines.

The logic goes something like this:

  • I have data I need to protect;
  • The PCI DSS says I need to protect everything and it will cost $X to do it 'correctly';
  • I can do it for $N, which is much cheaper than $X, even when factoring in the non-compliance fines;
  • I'll do it my way.

So now we're left with an overly long, underwhelming security manual that we're free to ignore should our pockets be deep enough.

What could possibly go wrong?

2. Would you diagnose your own MRI?

For any merchant qualifying as Level 2 or below, you are free to conduct your own assessments.

To me that makes as much sense as performing your own dental surgery.

Not only are you not qualified to undertake such a task but you probably don't have the correct tools or know how to use them.

Next time you are talking with a small business owner, ask them to explain the difference between a stateful packet firewall and a web application firewall.

As a small business owner, they are probably experts in selling widgets and running their business but computer security is probably not their bailiwick.

The PCI DSS contains over 200 sub-requirements. Each must be fully understood and correctly implemented in order to stay compliant.

Even the larger merchants - Level 2 merchants processing up to 6 million transactions per year - may not have the in-house expertise to correctly implement the standard.

Yet the payment brands are happy to let them go about it on their own.

As a consumer, should we be entitled to know if a merchant has performed their own audit? Some might feel safer knowing it was done by a security expert instead of a pastry chef.

Luckily there's a solution. Hire a Qualified Security Assessor (QSA)!

3. QSAs to the rescue!

So the solution to wading through the PCI DSS is to hire a Qualified Security Assessor (QSA) - those trained professionals who are experts in the PCI DSS and are there to help merchants understand the requirements and provide guidance on what controls are appropriate.

Yes, they're 'Qualified' - they pay their annual dues, but how do you know they really understand security and the PCI DSS, your industry and your unique environment?

Luckily the PCI Council is on top of things:

Please note, the PCI Security Standards Council maintains an in-depth program for security companies seeking to be certified as Qualified Security Assessors (QSAs), as well as to be re-certified as QSAs each year.

Sort of:

Although the PCI Security Standards Council strives to ensure that the list of Qualified Security Assessors linked to this page is current, the list is updated frequently and the PCI Security Standards Council cannot guarantee that the list is current at all times.

Caveat emptor.

I speak as someone who has, at various points in my career, held many different certifications. They're not worthless, but they're not always a guarantee of expertise.

QSAs are supposed to understand the PCI standard and process. Unfortunately, many lack the necessary expertise to validate if a technical control is correctly implemented on a system which they don't understand.

Next time you meet a QSA, ask them who their favourite cryptographer is. If their answer is not on this list, tell them Bruce Schneier would like a word with them.

Just because you can pass a test doesn't mean you're qualified to do anything beyond that.

Compound that with companies who are downright insistent and seek out QSAs that will certify them unequivocally.

What could possibly go wrong?

4. AV vendors write the malware too, right?*

Having a roster full of QSAs is great. Now we can send them all out to make the payment world a safer place.

You know what would be even better though?

What if we also had a services business that could sell and implement all the controls that our QSAs recommend? This is common practice in the QSA world but is it wrong?

Well, it is and it isn't.

There is an endemic bias when a company is involved in both approving a control and selling it to the merchant.

If done right, the QSA firm will self-impose a model of segregation where the two sides of the operation are unable to influence each other.

This type of 'ethical wall' is commonly seen in finance, journalism and law.

The temptation to grow the bottom line can often overshadow ethics especially when there is no legal obligation to do so.

QSAs could also argue that being able to access the service delivery techs helps the customer, but the same can be accomplished if you use highly qualified and competent assessors.

(*If your scarcasm detector is broken, probably best to move on.)

5. One and done

Perhaps one of the greatest failures of the PCI DSS is its compliance-as-a-snapshot nature.

Threats are continually evolving and so must our ability to defend against them. As such, our computing environments are continually in flux.

If you are lucky enough to be in a business that is seeing growth, you will undoubtedly be adding complexity to your existing cardholder data environment (CDE).

The US is currently in the beginning stages of rolling out EMV. All of the existing payment terminals will have to be replaced.

And what about the end of XP? While most point-of-sale terminals run embedded XP - which is supported until 2016 - many still do not.

Then there's the ongoing maintenance of hardware and software applications. Each can potentially introduce new vulnerabilities into the CDE.

Operational costs are always a concern, so many companies might opt to switch service providers from time to time.

It is not outside the realm of possibility that all these activities could occur between yearly assessments. Especially if different groups are responsible for each part.

Yes, the PCI DSS has some mitigation built-in, such as the business-as-usual recommendation. But that's all it is - a recommendation.

The payment brands also require quarterly scans, but seeing as we patch our systems at least monthly (you do that, right?) is that often enough?

What's worse, for the smallest merchants, an annual assessment is only recommended, not required.

Taking all the above into consideration, it seems to me like there's plenty of room for error. Whether deliberate or not.

Read the contrasting opinion...

Image of no tag courtesy of Shutterstock.

You might like

One Response to PCI DSS - Why it fails

  1. LonerVamp · 131 days ago

    I like these two articles, but it's always a little annoying when we decry PCI. It begs the question, "So, what's the better answer?" while also trying to point out that, "You never win at security." No certification or third-party review is going to be faultless.

    RE: 1. I would much prefer that PCI not try to prescribe particular technologies or options as part of their requirements. I would want to figure out what works for my business/app/tool/system that also fits into the requirements. Doing too much of anything else falls into, "You must follow steps A-to-BC in order to be secure," which really steals away from the creative solutions that IT brings to an infinite number of business scenarios. Or, for instance, the dancing around of mentioning (and thus prescribing) DLP technologies; which is a whole new topic of futility.

    RE: 3. We certainly do expect a lot from our QSAs; a position that has some high burnout and churn rates due to the travel requirements and the fact that many QSAs who know their "stuff" can move on to better payer jobs (and probably should move on to better paying jobs). And it doesn't help that QSAs get about 1-2 weeks to review a brand new environment and solution set, while also under their own business pressure to cram more clients into a shorter time period (Jerry Maguire needs to be updated from sports agent to QSA?). Most business can't even understand their own internal processes and development and security, let alone have a QSA completely get it in such a short time frame. It takes some serious time and experience in enterprise technologies (and not ones that are 7+ years old) to know where to look and how to see holes in configs/process/code.

    But we gotta have something.

    I like PCI because it at least gets things started. These are conversations that, 8 years ago, were had but then immediately stifled by business as being too costly. You want an IDS/IPS? Network segregation? Pen tests? File encryption? Maybe next year. Few things get built correctly the first time, but once it's up, it's hard to tell someone they need to fix something that is still actually working.

    Especially now with 3.0 spelling things out more explicitly, we also get to demonstrate to the business that proper security *is* actually a process, and not just a point in time review. That you actually *should* be looking at your events/alerts, making sure your backups and logs are in order, that you are doing change management, that you are reviewing accounts...

    Still, even with PCI, businesses everywhere still miss many things, or just do far less than they should. I'm not sure PCI needs more teeth or better QSA roles or what, but at least it's a very good step in the correct direction for those that are open to it.

    But when you're of a mind that security is a battle that is never won and never ends, then there are zero broad requirements guides that will work unequivocally.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

John Shier is a Senior Security Expert at Sophos. John is a popular presenter at security events, and is well-known for the clarity of his advice, even on the most complex security topics. John doesn't just talk the talk: he also gives hands-on technical support and product education to Sophos partners and customers.