Card Data (In)security

There's been a lot in the news lately about this press release from Mastercard about an enormous breach of card data security at 3rd party card data processor CardSystems. Having just finished helping an organization assess their software and systems in order to prepare for an upcoming Payment Card Industry (PCI) audit, I thought I'd share a few thoughts on the topic.

PCI is a consortium of card companies (e.g. Visa, Mastercard, etc). They sponsor the Card Industry Security Program (CISP) -- a set of standards and procedures -- including a self-assessment questionnaire -- for determining proper card data security. If you handle payment card data, you must comply -- sort of.

I don't think the problem with card data security is the standard. It seems well thought out. For example, it encourages that applications be built in accordance with the Open Web Application Security Project (OWASP) guidelines; provides clear guidelines for handling cardholder data (we'll get to that in a minute) and takes pains to review insecure networking approaches. It encourages strong encryption and explicit key management. It points out that insider access should be carefully restricted. In short, the standard is comprehensive, and would serve well as guide for organization's who want to secure their handling of card data.

No the problem is that organizations aren't motivated to secure card data, but to comply with the standard.

IOW PCI auditing seems to have alot in common with level envy problems faced during Capability Maturity Model (CMM) assessments: the standard may be OK, but the industry cares about compliance, not actual security. I suspect most organizations care more about getting the rubber-stamp of approval, than actually being secure. But having proper documentation doesn't ensure that their system actually doesn't store the Card Verification Code (CVC) -- that's the 3-digit code on the back of your card. Incidentally, it sounds like this code was being stored by CardSystems. In case you were wondering, the PCI standard says don't do that: in section 3.2.2 to be precise. In fact, they shouldn't have kept the data at all -- that's what section 3 in its entirety says (section 3.2 says get rid of it when you are finished authorizing the transaction).

Now, I can't imagine that CardSystems didn't know about the standard before this happened. They clearly were a level-one service provider and so required to comply with the CISP, be audited annually, and so forth.

So what went wrong? I think the answer is that while the PCI standard is pretty good, and the card companies want to be seen as committed to security, in practice the standards process is about shifting blame. If MasterCard can point the finger at CardSystems and say "they weren't compliant, its their fault", MasterCard looks like the hero, and CardSystems the villian. But as long as "compliance" means "all the necessary documents are in order, move along, there's nothing to see here" there will continue to be news headlines like this. Also, while CardSystems is being fined $500,000 dollars by PCI, this "cost of doing business" approach to compliance does little to protect the interests of the people whose information was accessed.

I am happy to say that the client I was working with was more concerned with actually not violating the standard, than having their compliance documented -- ironically that might very well lose them points with the auditors, who seemed much less interested in what I was finding in the code, and a lot more interested in assuring that the company had all the proper software design documents.

So, my (granted small) sample-based advice is two-fold: 1)To PCI: audit the code, not the documentation and 2) To card holders everywhere: until those all those entrusted with our information can be held accountable in ways that actually deter leaks, this will continue to happen. Support accountability regulation.

I.e. MasterCard et al shouldn't be able to shift the blame to CardSystems -- MasterCard et al allowed CardSystems to handle card holder data on their behalf, MasterCard et al failed to audit the actual state of CardSystems, they were content to get legal protection in the event fo a breach, rather than working to minimize the effect of one. On CardSystems front: They get to pay a fine, and promise to do better next time -- I wonder if they would've been content with that solution if their officers were to be held criminally or civally liable for losing my personal information.

Security breaches will occur, this isn't an attempt to say otherwise, but the fact remains that while we cannot prevent security breaches, we can mitigate their effects. the CISP standard is very savvy on this point, but the auditing and repurcussion portions of the CISP leave a lot to be desired.