Another week, another breach. SuperValu is the latest entity to suffer a breach involving credit cards, and I saw a tweet over the weekend that inspired this post. It was along the lines of “I’d hate to be the guy who has to explain how PCI DSS is effective against breaches.”
While there is some humor in the tweet, there is more than just the standard in play here.
PCI DSS by itself is a good baseline for handling cardholder data. I’ve written articles, blogs, books, and given talks on the merits of PCI DSS1. PCI DSS also has flaws, compared to other compliance initiatives, that are very difficult to fix. To make matters worse, there are a number of companies who don’t take PCI DSS seriously and simply go through the motions when it comes to compliance. This hurts the entire ecosystem. For example, while there is not a requirement that specifically lists out all of the “advanced attacks” that are causing these breaches, companies should be catching them if they are complying with the spirit of Requirement 6.5.
This also means, in a sliding slope kind of way, that if you do fall victim to a memory scraping attack and you didn’t catch it, you probably were not compliant with PCI DSS. PCI DSS is too complex to be treated casually. If your company does not have the resources to truly address it (and you will know in your gut if this is the case), you should be outsourcing your payment processing (which will probably cost you more per transaction, but way less than a breach).
Compliance initiatives tend to create adversarial relationships between the Assessor and those being assessed. Since we all have to do more with less, at times we try to get creative with assessors. It becomes a game of cat and mouse, to use a colloquialism.
So far, my experience with PCI DSS is that you will get out of it what you put into it. Meaning, you must work hard to make sure you are truly (you have to be honest with yourself here) meeting the letter and spirit of each requirement in a way that mitigates or eliminates the risk. Then, look for additional ways to reduce risk where it makes sense. Doing this will get you a great compliance result (QSA will be happy), and ensure you are taking steps to additionally secure your environment.
As the ecosystem continually improves, the players in the ecosystem must also improve (as the lowest hanging fruit is plucked from the proverbial tree). If the ecosystem does not want federal regulation, it will need to fix itself; unfortunately, well tested theory suggests that it will not. This, perhaps, leads to the manifestation of an unintended, but significant, flaw in PCI DSS.
There is a classic piece of literature called the Tragedy of the Commons (go get it from your local library) that can be adapted to fit this situation perfectly. Even though it is in the best interest for the entire payment ecosystem to improve payment security, individual firms that invest in security won’t see a marked return over companies that choose not to invest. Since all of the firms in the space will receive the same economic impact, they are stuck in an ecosystem that compels their management to do the bare minimum and hope that someone else gets hit instead of them.
As we gather in Orlando in a few weeks to discuss PCI DSS, perhaps we can also brainstorm ideas on how to improve the payment security ecosystem as a whole. Those who issue, accept, process, and manage payment data are all in this together with the consultants, QSAs, and vendors in the space. I’m looking forward to some lively discussions!
Want to see my follow-up to this? Click here.
Edit: James Adamson rightfully pointed out that I am not using the Tragedy of the Commons properly here, in the pure sense of the theory. Hopefully, my illustration comes through when considering if there is significant incentive to invest in security.
- If you are on the Council reading this, remember, I’m an on-record supporter [↩]