03:04 PM
Mike Rothman
Mike Rothman

PCI: Dead Man(date) Walking?

Is Visa's program to eliminate the requirement for assessments in lieu of EMV (chip and pin) transactions the death knell for PCI? Not yet, but the writing is on the wall

They say all good things come to an end, and the truth is most bad things end at some point as well.

So when I read Branden Williams' blog post on Visa killing PCI Assessments in exchange for originating 75 percent of transactions from EMV-enabled terminals, I immediately jumped to the conclusion that PCI is now on death row. The final execution date will appear when MasterCard and AmEx making a similar pronouncement.

If we have to write an obituary for PCI, what would it say? Overall, I think PCI has been very good for security. It provided a significant amount of funding to do the fundamentals. Even better, it actually spelled out the fundamentals with a specificity we hadn't seen from other regulation. It forced a number of midsize companies (Level 2 and 3 merchants) to have assessments, to take security (more) seriously, and to make some positive changes in their security posture.

So if PCI is very good, why is it a dead mandate walking?

It all gets back to the economics. Remember, few organizations on Earth do as much analysis on fraud as the card brands. Operating within an acceptable range of losses due to fraud is a critical success factor for a card brand. As such, when PCI emerged, the brands were at risk of blowing past that range and starting to cost some real money. Obviously that's unacceptable, so changes happened.

The brands mandated certain security controls in the form of the PCI-DSS and then used that as a mechanism to transfer responsibility for any data loss (and its cost to clean it up) to the merchant. But it seems that PCI has outstayed its welcome. First, let's look at the control set, which, due to a preponderance of political wrangling and winging on the part of the large merchants, is now updated every three years. As we all know, three years is a lifetime in this business, so the control set is getting old. Fast.

Second, most of the merchants that have not implemented PCI and maintained compliance aren't going to do so. They either are incapable or don't care. So there isn't a lot more to gain by continuing to shove PCI up the merchant chain's backside.

Now let's look at transference of responsibility. There has been this idiotic stance by the PCI Council that no breached corporation could be PCI-compliant. They didn't want to (or couldn't) publicly accept that the control set just wasn't good enough. That it was a lowest common denominator, but in no way sufficient to deter today's attackers. That would give the merchant standing to push back on having to accept responsibility for a data breach. So after every high profile breach, the PCI Council would maintain the breached organization wasn't compliant -- ROC or not. It's compliance by time machine, and it's ridiculous. How long before you think a merchant starts litigating when they get a huge bill?

Remember that the card brands are all about reducing fraud losses, and it's unlikely they have an attachment to the PCI Council. In the presence of a new shiny object that promises to reduce loss, they'll go in that direction and their experience in Europe with EMV must lead them to the conclusion that EMV (Chip and PIN) equipped cards reduce the likelihood of fraud. Visa's program says they will waive the PCI assessment if 75 percent or more of a merchant's transactions happen on EMV chip-enabled terminals. So it's an either/or type of thing, but given the amount of money most organizations spend on PCI compliance, it really means go to EMV.

What if you like the status quo and equipping all the stores with EMV capable devices isn't a good option? It'll cost you, starting in late 2015, with a liability shift and likely higher transaction costs -- which is always how the card brands incent the behavior they want. They make it a lot more expensive to not do what they say. Amazing how that works.

Of course, as Branden points out, MasterCard and AmEx have not yet made similar pronouncements, so you can't fire your PCI Assessor yet. But it's just a matter of time. You know it and I know it. And we security folks will have to find another compliance muse to fund our projects. Or maybe just start wielding the APT FUD hammer a lot more aggressively. Maybe bring Richard Clarke in for a board meeting or something. He's like the Thor of FUD nowadays.

Mike Rothman is President of Securosis and author of the Pragmatic CSO. Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
5/4/2012 | 8:19:15 AM
re: PCI: Dead Man(date) Walking?
PCI-DSS isn't quite dead yet. Don't forget that one important reason the DSS probably exists is to keep government regulation away. And in that, it's done a great job so far. And PCI in all its various standards probably isn't going anywhere, even after/if all the cardbrands adopt EMV. They'll still need the PA-DSS standard and the PIN transaction standard. Especially as more and more business is done through mobile devices - what Bob Russo called "the most insecure device in the world" (

But the DSS and the QSA program obviously have their flaws. Like the lack of quality control on assessments, beyond just making sure the documentation is in the right format. There's no accountability for QSAs who have provided ROCs for companies that turn out later to be non-compliant. To my knowledge, the PCI Council has not come out and said that just because someone is breached means they were non-compliant. I think it's only after investigation of the root cause that they determine this. But I agree, that the standards leave room for compliant organizations to get breached.

And in general, PCI auditing suffers from some of the same issues as other audits. Other audit standards (particularly the financial services industry and regulated securities) have a longer history than Infosec of audits. As I point out, we could learn something from Enron.
User Rank: Apprentice
4/26/2012 | 8:17:32 PM
re: PCI: Dead Man(date) Walking?
This solution is helps when the card holder is present at a terminal the leverages the chip capability. What happens when you are calling in a transaction via phone? Where is the chip when you have a recurring transaction against the card? For services that pay online? Technology (EMV) is only part of the solution. The people involved and the processes that participate in transactions are also points of threat or attack.-á
User Rank: Apprentice
4/26/2012 | 12:34:42 PM
re: PCI: Dead Man(date) Walking?
Maybe I am wrong but EMV is no silver bullet and PCI is far from dead.-á The chip and PIN-átechnology protects data at time of authentication but that's it.-á Visa only waives the assessment of the merchant.-á That back end database and data center-áis still full of credit card information that needs to be protected.-á And even if EMV encrypted all of the data and it was unreadable end to end there is still the Issuing side of this equation where someone has to store all of this information so that the card can even be used and hence PCI will still be required for that.-á Additionally you will still need processors that will need to be PCI compliant, network and gateway providers, and other card related services-áas well.-á EMV is to help relieve the burden of PCI compliance on the small merchant and retail outlets with many end points.-á EMV will-áhelp to protect the end point and the customer-ábut there is-ástill a lot of data stored outside those end points that will need to be protected and PCI will still be there to guide companies on how to protect that data.-á Sorry Mike but I disagree that PCI is going to be going away anytime soon.-á Personally I think articles like this create just as much FUD and makes the security professional's job even harder.-á If PCI goes away does that means you can start posting card data on the Internet?
User Rank: Apprentice
4/25/2012 | 9:05:05 PM
re: PCI: Dead Man(date) Walking?
This isn't the case for Visa Europe.
EMV is only part of the battle, we've had it over in the UK since 2006 and its been great at helping to reduce face to face card fraud, but there are still issues that need to be addressed in the service provider community when they handle card holder data as well as in e-comm / MOTO merchants that are more actively-átargeted by miscreants.
It would have been nice if the US had got on board with EMV earlier so that we could all get rid of magstripes!-á
Any merchant that does multi channel sales will still require a QSA assessment annually and as multi channel integration is a major plus for retailers the TIP process will have a-ádiminishing-ánumber of eligible merchants in real terms. -áI personally think that Visa Inc should take a similar approach to Visa Europe - encourage EMV adoption, acknowledge that it doesn't solve all the problems, push point to point encryption (P2Pe) coupled with EMV and adjust the reporting goalposts accordingly. -á

To say PCI is dead I think is a little premature. -áIt does need to evolve, and the delay with getting a P2Pe standard released didn't help. -áP2Pe + EMV should offer significant risk reductions to those merchants that use it exclusively. -áI've never seen the SSC say that "no breached entity can have been compliant". -áIn fact one of the discussions at a recent QSA event in the UK the SSC said they acknowledged that with 0-day exploits it is perfectly possible to have been compliant and still get breached. -áAs security professionals we know that the process needs to be cyclical and involve continuous improvement, which is why I am so surprised at Visa Inc and their dropping of the validation reporting (either by saq or QSA!). -áWhich as you rightly say will lead to a number of entities just not bothering with PCI at all. -áRather than remain a pro-active measure Visa Inc appear to be making things re-active as in the event of a breach there will no doubt be a QFI involved, and then the compliance status will need to be re-validated by a QSA. -áSurely from a security-áperspective we should be encouraging people to have an-áindependent-áset of eyes review their controls. -áWhilst Visa Inc are waiving the mandatory requirement to send them a RoC, -áthey are still expecting people to maintain compliance and are reserving the right to restart validation if they choose. This bit is of most concern "Acquirers retain full responsibility for merchantsGÇÖ PCI DSS compliance, as well as-á
responsibility for any fees, fines or penalties, which may be applicable in the event of a data breach"(á). -áCan't see the acquiring community taking the hit if suddenly people stop doing PCI.. -á
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-07-02
Unspecified vulnerability in IBM Java 8 before SR1, 7 R1 before SR2 FP11, 7 before SR9, 6 R1 before SR8 FP4, 6 before SR16 FP4, and 5.0 before SR16 FP10 allows remote attackers to gain privileges via unknown vectors related to the Java Virtual Machine.

Published: 2015-07-02
IBM Java 7 R1 before SR3, 7 before SR9, 6 R1 before SR8 FP4, 6 before SR16 FP4, and 5.0 before SR16 FP10 allows remote attackers to bypass "permission checks" and obtain sensitive information via vectors related to the Java Virtual Machine.

Published: 2015-07-02
Unspecified vulnerability in IBM Java 8 before SR1 allows remote attackers to cause a denial of service via unknown vectors related to SSL/TLS and the Secure Socket Extension provider.

Published: 2015-07-02
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

Published: 2015-07-02
fusermount in FUSE before 2.9.3-15 does not properly clear the environment before invoking (1) mount or (2) umount as root, which allows local users to write to arbitrary files via a crafted LIBMOUNT_MTAB environment variable that is used by mount's debugging feature.

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report