There’s a cheesy quote by Norman Vincent Peale which goes; “Shoot for the moon. Even if you miss, you’ll land among the stars.”

This does not apply if PCI compliance is your end goal.

Set PCI compliance as your goal and miss, and you haven’t even made it out of the barrel. However, if you shoot for REAL security, there is a very good chance you’ll achieve compliance with almost any standard or regulation along the way.

PCI has always been, and will always be a minimum set of security controls and nothing more. The SSC has said as much themselves, as have the card brands, as has anyone else who actually knows what they are doing. This is not meant as a criticism of the standard, they don’t have a lot of choice, and any organisation treating PCI as an annual project, and/or is bitching about how difficult it is, deserves what they get.

As I’ve said more times than I care to admit; “Take the phrase ‘cardholder data’ out of the DSS and replace it with the phrase ‘personal information about your family’. Now name ONE requirement you don’t want in place? Seriously, name one. So if you agree that these are nothing more than the most basic security controls, why have you not put them in place already?

In every section of the DSS there is a LOT of room for better practices, for example:

DSS Section 1 – Do you to have device-to-device-only rules configured, or just a business justification for the ones you have?

DSS Section 2 – Do the testing procedures for a system require a configuration standard for every device type, or every individual device?

DSS Section 3 – Can you really perform manual key management well?

DSS Section 6 – Should you include ONLY the OWASP Top 10 in your app security testing?

DS Section 10 – Do you have to log centrally, and can you really perform manual reviews of your log files on a daily basis?

…and so on and so on. And let’s not forget this is still just about credit card data, validated just once a year, and [potentially] only on a small sub-set of your environment.

If you were to perform a business wide risk assessment, then a security controls gap analysis, you would come up with many deficiencies in your security programme. Then, IF you were to actually take this seriously and not just seeing security as an expense, you would come up with a remediation plan that I can [almost] guarantee would achieve PCI compliance on the way to your goals.

Chances are better than even that you have not even performed the risk assessment, so you have no idea what you goals ARE, and look at PCI compliance as something to get out of the way as soon as possible. You will achieve PCI compliance as a tick-in-the-box exercise, throw good money after bad, and start all over again next year.

This is unfortunate, as your appropriate security goals would most likely have kept you compliant throughout the year, saving you a significant amount of time, effort and cost on re-certification. Oh, you would also be a lot more secure.

I bet Target, Neiman Marcus and Michaels wish they had done security properly.

Every time you go above an beyond what PCI requires, you are building a database of compensating controls. The more compensating controls you have, they less constrictive PCI becomes, and the closer you get to applying the expense of PCI to your actual business goals. Eventually there will be no waste.

This marks the beginning of a 12 part series where I will explain the intent of the 12 main sections of the PCI DSS, as well as provide guidance and options on how to go above and beyond PCI so that you can you can focus on the meaning of PCI and not just the words. More importantly, you can focus on your business.

[If you liked this article, please share! Want more like it, subscribe!]