PCI DSS – Why it fails

library
crime | hacking | security

PCI DSS – Why it fails

The 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.