There’s a great story about Van Halen. In their contract rider they insisted that they get a bowl of M&M candy with all of the brown ones removed before the show. It turns out this was a sharp move by the band to make sure that the contract was read and adhered to. If the candies weren’t right there’s a good chance that other things weren’t right too.
PCI DSS has been around for a while. Most CIOs and CISOs that I talk to are firmly of the opinion that its like a military uniform, coming in two sizes – too large, and too small. Nevertheless, the US Treasury have voiced the opinion that PCI DSS has done more to aid in the fight against payment fraud than any other global standard.
I was talking the other day to a developer who was highly amused by his experiences testing his new web commerce app using his personal credit card. And it’s fair to say he is not alone in this. I pointed out that PCI DSS 6.4.3 forbids this, and his defensive riposte was:
Well, this was in 2006 so it was quite a long time ago and anyway, we weren’t handling payment cards, we just used a third party payment service provider so it didn’t apply to us.
A couple of thoughts occurred to me. Firstly, we know that the foresighted crim can hide data away for some time – although payment cards do have an expiry date, there is value in the dataset even post-expiry. And from the point of view of a breach, it’s yet to be tested in court whether fines for expired payment card data still count – but the position of the card associations appears to be that it does. The next point is that you don’t have to handle payment card directly to be involved in a breach. Remember if the transactions are being handled with your merchant ID, you are the liable entity in the contract with the banks (and hence the card associations), which may also be the case if your payment service provider passes the liability back to you. But that’s another story. The point is that if you control the flow of a card transaction, you have some responsibility for the security. The self-assessment questionnaires A and A-EP address these points explicitly – if all you do is control the flow of payment data, you can still be responsible for a breach. I’ve personally had the job of doing forensic investigations on these breaches and the fallacy of thinking that it’s ok to ignore requirements that you don’t understand is a dangerous one.
PCI DSS is in no way perfect, but the requirements that are there are put in as a result of seeing the impact of attacks over the years, and attempting to lock down vulnerable points. So the M&M view is that if you ignore a requirement (or are unaware of it) then you are like the concert promoter who didn’t take care of the venue and caused $480,000 of damage – which Van Halen saw the early warning signs of brown M&Ms backstage. Little things like PCI DSS 6.4.3 speak volumes about your attitude to secure software development.
Anyway, if you’ve read down this far, you probably want to know more about Van Halen. Here’s the video.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.