Approach to Encryption within PCI DSS

Dave Whitelegg raises a point that’s been niggling me for a while. For all the good in the PCI DSS, the whole process gets considerably weakened by the Acquiring banks insistance on the transmission of data from merchant’s system to acquiring bank’s systems in plain text. Sure, the transmission channel is SSL encrypted over a point to point / VPN link but the data is still unencrypted and then transmitted (albeit over an encrypted channel). This is a subtle difference but important nonetheless.

From the title, Dave questions whether this means the “PCI Encryption Practice is flawed”. I say “no”, it isn’t flawed but the implementation of the solution to the requirement may well be. As I said in my comment on his blog, I need (and have been meaning to for ages) to study the PCI DSS with this issue in mind. But, logic dictates that the standard would require the data to be encrypted everywhere.

If this is the case then the Standard isn’t at fault, the implementation of the solution is.

I’ll look into this and give my thoughts in due course.

The "maintaining compliance" issue

There’s an interesting discussion over on PCI Compliance Demystified about maintaining compliance after you have initially achieved the “tick in the box”. The discussion is primarily about PCI DSS compliance but could be had about any compliance requirement.

To paraphrase, the question was raised: “how is compliance maintained?” which has developed into a “what’s being done about maintaining compliance?” question.

I find this interesting because when we first started looking at PCI DSS Compliance at my company I made more emphasis of the “maintaining compliance” requirement than the “achieving compliance” requirement. It was a hard sell, and not fully accepted as yet.

PCI DSS requires that you achieve compliance and continue to remain compliant from then on. If your company suffers a security breach and the investigators are sent in by the card schemes, they will not just assess your compliance when they turn up. What they will do is investigate the state of compliance for as long as the security breach occurred and even prior to that to identify whether a failure in maintaining compliance contributed to the breach. If it did, big money fines are on their way.

Take the TJX situation for example. Initially TJX reported that the security breach happened “over a period of a few months at the end of 2006”. After the investigators went in they found that the hack had been on going for a period of a couple of years. This being the case, the investigators will be assessing whether TJX was compliant for the whole of that time. From reports it appears they were not.

My company has accepted the “maintaining compliance” requirement to the extent where they have agreed to completely redesign the payment processing platform from the old legacy system (which was difficult to support and maintain) to a nice shiny new compliant and maintainable platform. Good news. However, the question of compliance management thereafter is still being discussed.

Without the compliance management process existing, the initial achievement of compliance is fairly pointless. 2 days after you tick the box, a new member of staff joins and unwittingly blows your achievements away by introducing a new business practice that ignores some fundamental PCI DSS requirement. Worse still are the creeping changes which in isolation are perfectly fine and compliant. However, over time, one thing leads to another and bang, a vulnerability slides in which “no one could possibly have foreseen….”

Compliance management is a functional process and requires not only resources but also an agreed corporate approach. Perhaps this is the issue, no one wants the responsibility monkey on their back.