This is my last post on EMV which I am sure will please a number of people. Although I know this debate will only continue. There are a lot of people out there that have taken large swigs of the Kool Aid and blindly believe that EMV is nothing but good and perfect with no bad side.
After all of these posts bashing EMV you probably believe that I despise EMV, but I do not. What I despise is that EMV is portrayed as the savior and it is not. This is no different than how the card brands portray the PCI DSS as “the be all to end all” of security standards which it is not. Just like the PCI DSS will never eliminate all breaches, EMV will never eliminate all fraud. However, in both cases, they will reduce their number of respective incidents that occur to a more manageable and acceptable level.
In part 2 I pointed out that from a card present fraud perspective; EMV really brings no incentive to change. In part 3 I pointed out that EMV has security issues, so it is not a perfect solution. So what can be done to give EMV a feature or attribute that would improve its adoption through the rest of the world?
I stated in my original post that EMV can be used to also secure on-line transactions, but are not used to secure on-line transactions because the banks, card brands and Web developers could never agree on a standard for such functionality. Not that the banks, card brands and Web developers really tried to come together and create a standard. However, without such a standard, it is impossible for Web sites to cost effectively implement their end of the EMV on-line security solution.
Card not present fraud is out of control. It is growing at 25% to 30% annually around the world, even in those places that have EMV. No one seems to be doing much about it. However, EMV could provide a solution to a tremendous reduction in card not present fraud if such an on-line security standard were developed. The beauty of this solution is that the hardware and software already exist for the most part on the client end. What is missing is the standard between the client and the Web site that would create an authentication between the card and the Web site that would be nearly impossible to replicate.
The bottom line is that EMV could be used to take a lot of the risk and threat out of on-line transactions with little effort. So let us lobby the banks, card brands and e-Commerce vendors to come together and create something good of EMV.
PCI Guru 
Dear Mr Pci Guru,
This is your best post in the series, in being the last, and getting the bottom line right.
The arguments you made in your first post and second posts are null and void, as you acknowledged in part 3 of this series, the numbers you used for your “no financial incentive” arguments were incorrect; while I applaud your for being open and correcting your mistakes (we are all human), I do not appreciate you referring to these posts as argument is this post, part 4. Furthermore many of the comments on part 2 were removed, effectively changing the “Debate” to a “Monologue”.
Thus removing all content in this post related to those arguments, I’m left with “CNP fraud is a growing problem, which EMV can help address”. I agree.
About EMV for “card not present environments”, MOTO, WEB, etc: The has been for almost 10 years a solution based on the combination of EMV and 3d-Secure. It is evident way to secure Internet payment by using the EMV standard security. It requires a card reader for the cardholder with a client. This would bring the security of face to face EMV to remote payment environments.
About PCI-DSS: The problem is not the requirements, the problem is asking the merchants to secure the payment process, where their competence en responsibility is typically focused on the sales system. The payment industry should take care of PCI-DSS itself and secure the payment systems to be integrated by the Merchants in their Sales systems.
The main issues comes from the US or from the pre-EMV world where the payment and sales systems/functions were not separated. With EMV this separation becomes necessary because the payment acceptance system is more complex a new peripheral is necessary, etc.
Also, PCI is seen in many EMV countries as a double sentence. For them even though big investement have been made to raise the security level of payment, but they also have to become PCI-DSS compliant to protect countries that have unsecured payment systems… Tough!
Spot on. Sound analysis. It’s good to know that there is intelligent life on Earth.
:o)
What’s a good layman’s terms description of the difference between the full and early data options of EMV. Any one knows! Thanks
Full data means the issuing bank receives and processes the EMV transaction data.
Early data means the card association (e.g. Visa, Mastercard) receives and processes the EMV transaction data, then sends just magstripe data to the issuing bank (and indicates if the EMV data was valid). This allows a bank to issue EMV cards before their authorization system is ready to process EMV transactions.
There are a lot of people out there that have taken large swigs of the Kool Aid and blindly believe that PCI is nothing but good and perfect with no bad side.
One final thing, if CNP fraud were really out of control, Amazon wouldn’t be allowed to transact using only the PAN and the expiry date. The reality is they can manage it, and their acquiring bank in the UK appears happy that that is indeed the case.
EMV has its holes and weaknesses, and I am probably in a reasonable position to be able to explain them. My reasons for defending EMV are nothing to do with EMV, they are to do only with providing a balanced view. I think it unacceptable and unprofessional for a guru to be giving a technological viewpoint that is debatable, and supporting it with information that is almost 100% incorrect. I hope I have enhanced and balanced the debate.
Now I really am going to bed … Goodnight all!
Let me hit this interesting and spirited debate from another angle, a PCI security one. I am not getting into the EMV debate; do not know enough about it, I am here to defend PCI. First let me state I am not an auditor, nor did I come up through the pencil pusher ranks in I.T., with that said, let me proceed. DG, when you make the comment “There are a lot of people out there that have taken large swigs of the Kool Aid and blindly believe that PCI is nothing but good and perfect with no bad side.” I don’t know who you’re talking about. Seems to me that you do not care for most compliance and/ or regulatory requirements in general, if that is incorrect statement I apologize and please correct me. I agree they all have many flaws, and sometimes in allot of cases can cause more issues than solve. HOWEVER, I believe that most of the time when negatives come out of putting controls in place to meet compliance requirements it is due improperly interpreting the INTENT of the requirement, and/ or implementing the wrong control and/ or implementing that control in the wrong way. Most people I have ever worked with in the states and anyone that matters in our field (including guru) understands PCI is not perfect, nor is any framework, regulatory compliance, and/ or technology.
However I can say that coming up through the security/engineer ranks the last 14 years that if it weren’t for SOX, GLBA, PCI, NIST (and others), that the vast majority of security policies, controls, technologies etc. that have been put in place in many fortune 500 companies the last decade wouldn’t be there now.
I get tired of people complaining about security requirements/compliance like PCI, GLBA, SOX, ect ect. If you carefully breakdown the intent of what a requirement is wanting you to accomplish, consider controls that can not only accomplish that goal, but provide ROI in many other areas (operational, supply chain), implement it intelligently, be able quantify and qualify that control, monitor the effectiveness of that control, so that you can measure its success or failure, then you can turn those compliance requirements into an ally.
Hey.
The “Kool-aid” line was a mis-quote from the PCI Guru’s original post. It’s on the second line if you have read it. Seems to be acceptable if aimed at EMV geezers, but not if “EMV” is replaced by “PCI”. Ho Hum.
Never have I said that I don’t card for compliance or regulatory requirements. What I have said is that I don’t care for stuff that is clearly a waste of time and effort, and is primarily supported by the IT bandwagon jumpers. Most of the PCI people I have met are security people who have stepped up to the challenge – the vast majority of them do NOT understand how payments work. But hey, why would you need to, and what do I know?
PCI has two main flaws as far as I can see. It allows payment systems to be certified PCI compliant, until they are breached, and then it re-asseses and says that they were never properly certified in the first place. The second is that PCI does not address the base problem, hello, the data on track 2 is still there and it’s still usable. What are you guys thinking about? How can you question my approach to compliance or regulatory requirements, when you are all happy to leave the card data there in the clear for everyone to attack. It makes me laugh!
I like the PCI is not perfect argument, but you use this as an indication that it is evolving and getting better all the time. The same argument used in the context of EMV is used to infer that it is not fit for purpose. Let’s not forget again that the data you are protecting is available in the clear on every payment card issued across the whole world. However it’s only useful the card is from the US. It makes me laugh!
You have said that you have come up through the security / engineer ranks, and I do believe that you have made some valuable contributions to security in the 21st Century. I, on the other hand, have come up through the card and transaction processing ranks over the last 25 years, and I know where the vulnerabilities are! Sadly, they aren’t where you are looking.
The bottom line is that the data on the magstripe card is clear and valuable and can be re-used and re-played. After 14 years in the security business, surely your first thought would be to render the card data useless. If you could achieve that, then it would have no value to the crims … job done! EMV card data is hidden, it has no value, it cannot be re-used and it cannot be re-played. Why do you need to secure the rest of the payment system? Why would you keep coal in a safe?
So you would prefer that vendors just take the “trust me” approach to assure you that their software was developed properly and doesn’t short cut security of cardholder data or personal information? And then, what about the sometimes “mindless” people that implement those applications. Should we just trust them as well? IN the end, they couldn’t be trusted and someone had to step up and provide some sort of guidance because the vendors and their resellers sure were not. I don’t like that it had to be that way, but it had to be done before things got too out of control. There were too many organizations doing stupid things in the name of customer service and cost savings and putting all of their customers’ cardholder and private data at risk.
What you seem to forget is that under our current card processing scheme, the cardholder data must be decrypted at some point to be processed. In addition, we have all of this legacy hardware that could not process any other way and none of the card brands wants to have a major retailer dump them because they took a stand. I have worked with a number of retailers that have had serious internal discussions regarding certain card brands and whether or not to continue to accept them because of policy or procedural changes that caused issues, so the card brands are in a very tenable position with large retailers. In addition, you have all of the banks and processors that do not want to reinvest in re-engineering their back-end systems. It definitely doesn’t have to be this way, but it is and we have to work around it until the card brands collectively get off their butts and fix the problem.
I’m focused on securing merchants who are the primary readers of my blog. They are struggling to figure out how to deal with PCI and I’m just trying to explain it and give them some support. But I also want to provide them with an understanding of why things are not as they are necessarily portrayed in the press and by our leaders. When it comes to technology, things are never black and white, there are constant shades of gray and lots of trade offs. The problem is that some trade offs can open you up to all sorts of the bad things and people need to understand those so that they can make more informed decisions.
From a merchant perspective, Chip and PIN is one piece of the solution. But what irritates me is that Congress and the people that testified portrayed it as THE ONLY solution and that nothing else needed to be done after they got Chip and PIN. For those of us that have been in banking and security for years, we know that’s not the whole story, But that is what the public has now been told and they expect that Chip and PIN will solve the breach problem. End of problem, move on. It’s not that simple, but now the public thinks it is that simple. The ramifications are such that I do not want to be anywhere near the first organization that suffers a breach after Chip and PIN is introduced. They will have all hell to pay.