Get with the program people!
The PCI standards have been around for almost four years now and you would think with all of the press that has been given the PCI standards that the key participants in the standards would be intimately knowledgeable with these standards. However, the more and more I talk to acquiring banks, the more I am amazed that most acquiring banks still are not with the program. It is time for all acquiring banks to get a clue about the PCI standards and their responsibilities regarding the PCI standards.
Acquiring banks have many responsibilities under the PCI standards. The first of which is to understand and support the PCI standards. However, it is painfully obvious from trying to work with acquiring banks that most are clueless about the PCI standards, let alone do they understand their responsibilities. Card brands and the PCI SSC have focused on educating QSAs, merchants and service providers in the PCI standards to the detriment of educating acquiring banks. I cannot tell you how many conversations I have had with acquiring banks where they have no idea of what their responsibilities are regarding the PCI standards let alone regarding knowledge of the PCI standards themselves. What I dearly love are those acquiring banks that tell me that they have no responsibilities in regards to the PCI standards, that it is a merchant program.
This is not just a problem in the United States, this problem is worldwide. This is a very big issue in Asia where acquiring banks seem to be totally clueless about the PCI standards. It is a bit better in Europe, but because European acquiring banks have been brainwashed to believe that Chip and PIN gives them a security edge, the acquiring banks there are not aggressively promoting PCI compliance. But at least the European acquiring banks seem to have a basic understanding of the PCI standards and some of their responsibilities.
Another responsibility of acquiring banks is to be the final arbiter between merchants or service providers and their QSAs. According to the card brands, if a merchant or service provider is at loggerheads with their QSA over whether a PCI requirement has been met, the acquiring bank is supposed to be the final arbiter of that dispute. Yet in the handful of instances where I have been involved in such disputes, the acquiring bank has provided limited or no assistance with the dispute.
An even bigger problem is with small merchants that are trying to decide which Self-Assessment Questionnaire (SAQ) to file. Again, the card brands have stated that the decision regarding which SAQ to file is the responsibility of the acquiring bank and no one else. Yet time and again, our small merchant clients contact my Firm because the acquiring bank has told them it is up to a QSA to determine the SAQ to file.
Then there is the acquiring banks’ responsibility to follow the PCI standards. Yet time and again, I run into instances where the acquiring bank is transmitting cardholder data insecurely to or from the merchant or service provider. The number of acquiring banks that use FTP or electronic mail for the transmittal of cardholder data is just staggering and after four years of the PCI standards existence is unacceptable. Yet, when you bring this issue up, a lot of the acquiring banks will tell you that PCI standards are for merchants, not for them. The other excuse I hear is that the acquiring bank is working on securing their transfer of cardholder data. Again, after four years of the PCI standards, you are just now getting around to securing the transmission of cardholder data? Unbelievable.
This year we started receiving calls from banks and credit unions that drive their own ATM networks that had been requested by their ATM network interconnection provider such as NYCE and Pulse to obtain a PCI Report On Compliance. What a wakeup call. In a number of cases, the institution was shocked that the PCI standards applied to them and questioned us extensively to confirm that they really had to go through the process.
As a QSA out in the field, these attitudes are just no longer acceptable. The PCI program flounders in part because one of the key constituents is not on board. It is time for the PCI SSC and the card brands to educate the acquiring banks and get them engaged.
PCI Guru 
PCI Guru constantly refers to back-end security breaches where EMV data can be harvested just like magstripe data. I dare say that there are other people who believe this stuff, just because he says it. The fact is that even if the crims were to hack into a transaction databases or intercept transaction data on its way to the banks, this is EMV data we are talking about – it has no value. We don’t get hacked i the UK because the crims with the know-how know there is little point.
My argument would be that if something has no value, you wouldn’t keep it in a safe. The PCI argument appears to be that you wouldn’t not keep it in a safe just because it has no value.
And …
if a merchant chooses to bend the rules a bit and take cards based on the PAN and the Expiry Date, then they do so entirely at their own risk. I have no issue with this at all. The card data that a hacker can pick up, can only be used at merchant sites that bend the rules, and they pay for it. If it looks like it’s costing too much money, change the merchant rules – what you shouldn’t be doing is “securing” the whole world so that the odd merchant can carry on bending.
EMV isn’t a silver bullet (but it’s not far off) but it does present a challenge to hackers, and since the EMV security (PKI etc.) is pretty much the same as that demanded by PCI to secure card data, we might hope that means it’s somewhat invulnerable to attack. Magstripe technology, on the other hand, doesn’t present a challenge to anybody – roll on petrol pump card skimmers, or any other sort of card accepting vending machine; it’s all too easy, not even a good school science project.
Posting about PCI in general in an open letter as you have here, PCI Guru, can be a tough one to pull off fairly. At least the debate that ensued contributed valuable advice all around. I enjoyed reading the thread tremendously partly because it actually serves to educate readers almost better than any one post could have.
My opinion, as a relative ‘newbie’ with EMV and PED, is simply the following:
1. Tie EMV with a specific standard next time – for example bring comments about EMV into a post about PCI PED, as the two are much closer related than for example PA DSS or PCI DSS.
2. Don’t slate EMV outright. Though it may not be the silver bullet, it certainly goes a long way to counter fraud at the point of sale, and due to its encryption it ensures secure data all the way to the back office, as David Griffiths pointed out, especially if all PCI players within a transaction flow adhere to the standard correctly. From what I have read and seen about the Cambridge studies (http://www.lightbluetouchpaper.org/), the system only failed due to legacy choices banks and 3rd parties make within the system. I remember that during the transition to C&P in the UK, we had an extended period where signature was still accepted and the systems needed to be designed to allow for such a choice to give consumers time to adapt to PIN-only transactions, so EMV accommodated this with a flag for offline cardholder verification. The findings at Cambridge found vulnerabilities caused by choices made within the system that EMV did not neccessarily cover, for example whether an offline cardholder verification was done by the merchant or not, and whether the issuing bank was passed on such information correctly by the acquirer and or terminal, and so on. EMV does not cover this extensively as it set out as a PIN inclusive standard. It is forced to leave the option of an offline verification process to the merchant / bank, but does not make any suggestion as to how such an offline verification should be executed to retain the integrity of the transaction. Technically this makes sense I would assume, as a fully implemented EMV system would not have such a forced process within itself. The main thrust of the Cambridge studies have been to keep banks accountable for choices they made that led to compromises of a system sold to their customers as fail-safe. Again, David is correct in pointing out that EMV in itself is pretty much hack-proof (touching wood as I type this…), but its implementation must then be without any compromised transaction process. Other compromises happen when modified terminals are used, replacing the PINPADs originally installed, and therefore bypassing EMV altogether. So EMV received the brunt of the criticism, when in my opinion the APACS branded ‘Chip & PIN’ campaign should have. To me as to many consumers, this campaign was the umbrella branding of a whole new payment network, complete security from card to bank, which of course it turned out not to be. Marketing C&P (the campaign) as infallible when it has been proven not to be or implementing C&P (the campaign) with compromised processes within the system (regardless of where in the transaction flow) made for bad publicity, especially in cases where customers had cards compromised. EMV was one component within the system this campaign sold to the consumer, and to me was the one component that did not fail, though debates rage on about it being required to accommodate the offline verification processes correctly.
3. Focus on the acquiring banks that are slow to implement PCI DSS. In the US SAS70 demands very similar measures as DSS suggests, so possibly this will overtake PCI DSS in terms of pressured compliance. PCI DSS though for me is an excellent guide for the securing of systems, processes, procedures and resources, and should be considered regardless industry.
So, chip and PIN just changes the magnetic stripe to a chip. Here we go, sorry there’s quite a lot, but I think it’s important.
PCI might be a set of best practices rather than a set of requirements, but it does appear that we all need to conform to the set of best practices one hundred percent.
I completely agree with the observation that very few people within the industry understand how to secure financial data, but isn’t it also the case that most people don’t understand which bits of data are valuable and which bits are not?
The banks are not getting involved because they do understand the dynamics at play here. They are, on the whole, aware that increasing their own levels of data security in a PCI-compliant way isn’t really going to make the magstripe data issues go away. Sooner or later, they know that they are going to have to spend the money on EMV, so why would they waste it now?
Is the problem one of having to protect the data just because it is data, or is it because the data has value? If the card data had no value, would you still want to protect it? Is card data really personal? Do you really want to keep your coal in a safe? At the end of the day, if the data has no value, why would you want to secure it, unless you believe in security for security’s sake? Let’s not forget that the US experience is skewed because the data on the cards is valuable; let’s not forget that in the rest of the world this isn’t the case.
I have, as instructed, read the notes on chip and PIN, and since this appears to be the basis of the arguments in favour of PCI, I will explain the misunderstandings, and attempt to explain where and why they originated. This began as a response to the open letter to the acquiring banks – it’s moved into the Chip and PIN arena, but since Chip and PIN is one of the reasons why the Acquiring banks are playing a low profile, it’s probably pertinent. I’ll let you guys be the judge.
One of the points raised by T.Anne goes something along the lines of the weakest link should pay. I completely agree: in the UK the card schemes and the banks introduced the principle of “liability shift” in cases of disputed transactions, which passed liability for the transaction to the party with the weakest security, providing that the fraud would have bee prevented had the security been in place. I think we should extend this globally; at the moment it is extended internationally across EMV regions but extending it to the US might be a good thing: the liability for fraudulent transactions, that would have been prevented had both parties implemented EMV, would then automatically be passed to the party operating the weakest technology. It’s about time this was introduced because the rest of the world is fed up with the fact that compromised magstripe data can still be used in the US.
Let’s not forget, though contrary to popular opinion, that magstripe data cannot be sniffed from an EMV authorisation request, or a settlement file, or any other data that might be held by a merchant (I’ll show why later). It’s because of this that you don’t see news about card data being hacked in the UK. Funny that, don’t you think? The reason for this is the fact that anyone bright enough to know how to hack into financial systems to extract the so-called sensitive authentication data, is also likely to be bright enough to know that there is very little that can be done with it.
I followed the chip and PIN link, and all my questions have been answered.
Now, my thoughts on PCIGuru’s thoughts about EMV. Just stop me when I say something that isn’t correct. :o)
Chip and PIN wasn’t developed by the British Government (I think we would rule the world if we had a government capable of developing something as strong as Chip and PIN). You are correct in saying that it was a standard written by Europay, MasterCard and Visa, and I guess it would be reasonable to say that in the UK, we chose to call it Chip and PIN – it did seem to make more sense to the general population of card users than the alternative of EMV. It is true that the IK Government helped set up an organisation with the responsibility for ensuring a coherent implementation, and it is true that a few mistakes were made (which have been rectified). Chip and (offline) PIN, however, is only one of a number of possible EMV implementations, as I am sure you are aware.
Chip and PIN is a worldwide standard that has only been implemented in Europe – and every other developed nation in the world except the US (well nearly, but you get the point), and let’s not forget that American Express has now joined in.
The information contained in the stripe is NOT duplicated on the chip. Your statement in this respect is wrong. Here’s why you may have misunderstood. I mentioned earlier that we made a few mistakes initially. One of them was not realising the dangers of having the magstripe Track II data duplicated on the chip (there wasn’t much card compromise a the time, so maybe we can be forgiven). As the previous writers have pointed out, thing develop and we live and learn. The error was 100% the responsibility of the idiot issuers (of which I was one) using the same information in both occurrences of the Track II data, even though the standards and the and the Card Scheme guidelines all documented the use of the iCVV. This security loophole has since been closed, and the use of the iCVV has been mandated since January 2008, but obviously not before the anti-EMV campaigners had grasped it as an example of one of the “inherent” weaknesses of chip technology in payment cards.
Moving on, your EMV transaction flow is about as wrong as it could possibly be – very poor for someone who is using the weaknesses of EMV as an argument supporting the global implementation of PCI. For the record, this is what really happens (in simple terms):
The card carries a public-private key pair. The private key is not accessible from outside, the public key is held in a certificate ultimately signed by the card scheme (via a hierarchy of trust within the card manufacturing process). Without going into the fine detail (it’s all in the public domain), the card and terminal engage in a challenge-response dialogue which enables the terminal to confirm that the card is genuine. It is not possible to generate a clone of this card – any security expert will know this, and why (and again it’s all in the public domain). Once the terminal has proved that the card is genuine, the two devices chat and determine what they can do together, that is to say whether or not the transaction can go ahead. If it can, the terminal requests the PIN, which the cardholder duly enters, and the terminal passes it to the chip where it is verified. If all is well, the card and terminal then decide how to proceed based on rules set by the card issuer and the acquiring bank. The options are: approve offline, authorise online and decline. If the decision to approve offline is made, the card issues a Transaction Certificate, allowing the transaction to be “proved” at a later stage should it be necessary. If the decision to approve online is made, the card issues an Application Request Cryptogram, which allows the issuing bank to verify the card and transaction; the bank’s response includes an Authorisation Response Cryptogram, which allows the card to verify the integrity and validity of the response. If the response is an approval, the card then issues a Transaction Certificate. If it is a decline, the the card issues an Application Certificate. If the Application Response Cryptogram is invalid (ie. a spoof response), the card rejects the authorisation and reverses the decision. The card will therefore decline if it doesn’t recognise the response from the bank.
This is nothing like the transaction description given as justification for the weakness of EMV. I hope that I have explained reasonably clearly how it all works, at a high level at least. Now let’s have a look at the issues identified by PCI Guru.
First Bullet:
I am not sure what “open source” means here, I thought “open source” referred to code. Whilst the EMV specification is in the public domain, I am not aware of any public domain code, though I could be wrong. As far as I am aware, all of the EMV code that has been written is proprietary and belongs to the terminal manufacturers and system suppliers.
It is possible to attack the terminals, and the guys at Cambridge University have demonstrated the ability to steal a PIN internally, it’s also possible to extract some of the card data. The problem for the fraudster is that the PIN is useless without the card, and the fraudster can not create a cloned card from the data that can be extracted from a genuine card. The cloned cards referred to in the press and by PCI Guru are magstripe clones, but as we have seen, this loophole has since been closed. The comment relating to computing valid PINs doesn’t merit discussion.
Second Bullet:
Yes, the entry of the PIN can be by-passed by the merchant. This feature was due to an agreed concession whilst the UK population got used to using PINs with credit cards. All PIN by-pass transactions are signature verified, and authorised online as an EMV transaction, generating a Transaction Certificate. All of the EMV processing is therefore maintained, and so it is clearly not the same as a transaction performed on a magstripe credit card, even though it is not PIN verified. As already stated, all PIN by-pass transactions must be authorised online by the issuing bank, and since 14th February 2006, all PIN by-pass authorisation requests are declined.
Third Bullet:
PCI Guru is clearly more in the know then me on this one! I haven’t seen any Daily Mail full page spreads about criminals holding cardholders hostage until they hand over their PIN (I have to say that it did happen once, but I think the motivation was more than just robbery, it certainly doesn’t appear to be the norm). Good story though. Now, on the subject of the card readers: the banks do not send them out to customers when they send out the Chip and PIN cards. The readers are used to secure online transactions, and some other stuff, but this technology is still catching on. More importantly here, the device will not confirm the PIN is correct. The device issues a string of numbers based on the card, its current settings and counters, the time, the result of the PIN verification and other clever stuff. The number is a cryptogram of which one piece of input data is the result of the PIN check. A cryptogram is therefore returned whether the PIN is right or wrong.
Fourth Bullet:
Chip and PIN cards do not enhance online payments. This is the first true (sort of) point that has been made. The reason this is the case is the general mistrust of any device that might be attached to a PC, because PCs are seen as inherently insecure. Chip and PIN authentication tokens on PCs would work fine – the problem isn’t the chip, or the PIN! The statement about some banks not allowing chip and PIN cards to be used online might apply to some specific chip and PIN cards, such as ATM-only cards, but as a general statement, this is rubbish!
Fifth Bullet:
Makes no sense. I think you might mean that in some cases the PIN is transmitted to the chip in an encrypted form, but sometimes it’s in the clear. This is true, and it depends on the card. However, as I said earlier, just having the PIN is of no use whatsoever to anybody – the criminal needs the card as well and the cardholder will spot this!
Bullet Six:
True. The reason for the attack on the merchant terminals was the fact that the Track II data on the chip could be used to create a magstripe card that could be used in the USA. Because of the time it takes to re-issue cards, this took a while to stop, but it went on long enough to be noted. The problem has now gone away. There is now no point in trying to compromise terminals, unless the terminal reads both the magstripe and the chip at the same time (these are around but are disappearing), in which case the real magstripe can be compromised, and a card can be cloned that can be used in the USA. There is a pattern emerging here.
Just one point of order: the “skimmed” track II data doesn’t need decrypting, it’s provided by the chip in the clear.
If you have EMV, where all available data is is of no value, why would you ever want to secure it? You wouldn’t store coal in a safe just because it’s made of carbon, like a diamond, would you? If the data has no value, the hackers are not going to hack, and look, they don’t. We have shedloads of data over here, magstripe data pales into insignificance when compared to EMV data, just tell me what you can do with it if you get hold of it? Mask cardholder data – nonsense! Transmit transactions securely – nonsense!
The last bit I agree with, EMV doesn’t remove all the risks associated with with using a credit card. It has, however, removed all of the risks it was intended to.
The online merchant problem, to which I am sure you will refer, could be resolved if merchants were required to follow the rules: CVV2 and delivery to cardholder address, 3-D secure and one-time passwords provided by those little calculator devices. Ask an online merchant (like Amazon) and they will say that they prefer to take the risk as the extra clicks turn customers away and costs them money. Why then should we pay?
One final thing: once PCI has been implemented throughout the world, don’t forget that the magstripe data is still usable, valuable and accessible. How are all of you PCI supporters going to stop the the Utah throat readers compromising petrol pump transactions over bluetooth? The stripe is too easy to copy.
What really worries me is that people believe PCI Guru because of his (or her) knowledge and experience. If the case for PCI is based on the weaknesses of EMV as given by the expert, and the weakness of EMV is shown to have no foundation, what happens to the validity of the argument for PCI?
Well first, let me say I am no EMV expert – so I will not address most of that. I can’t say I completely agree with all the points, but I know that I don’t understand enough to be able to make a strong argument against them… But I still have a point or two.
I like the liability shift and think we need something like that in order to get the banks and everyone on board so that all parties involved are held responsible and one person doesn’t have the burden of trying to make sure they’re covered on all sides (even areas that aren’t theirs) simply to avoid getting fines. However I still think PCI as a required set of best practices/minimum requirements is wise. Without it some would have no security – and I think the card brands are using PCI kind of like the liability shift in order to hold other’s accountable and provide them with resources to help them protect the detail. The comment “If you have EMV, where all available data is is of no value, why would you ever want to secure it?” says to me you would be one of those people to have no security if it weren’t forced upon you… and even your comment shortly after, “EMV doesn’t remove all the risks associated with with using a credit card” contradicts your first… you’re admitting there is still a risk – if you know there is a risk, why wouldn’t you want to secure it?
One thing I do know of EMV is it has been found flawed and there have been reports of breaches – it is not perfect. So while it may be better now than it was originally – there are still issues with it and it too requires additional security to protect the data.
And since it has its flaws as well – why MUST it be adopted by the US? “Sooner or later, they know that they are going to have to spend the money on EMV, so why would they waste it now?” Now yes, Wal-Mart is pushing for EMVs – don’t know the why behind it, but I do know they are. And it does have some benefits, but what makes it the best option? Why not LENs? Why not better security on what’s in use today that would make the mag-stripe detail useless if stolen? Or any other option? What is it that makes EMV the perfect solution to the fraud issue?
And even IF they did go to EMV in the future – how does that excuse the acquiring banks from not being responsible for protecting the data that is being used now? That’s like saying I know my 2006 car has a fatal flaw but why waste the money to fix it when I know I’ll get a new one in 2011… till then I’ll just drive around and hope nothing goes wrong. Wouldn’t it be smarter to try to ensure that what I have now doesn’t kill me before I can get the new one? One way or another it’s going to cost me money to be safe until 2011 – I can’t just go on ignoring it because I know it will change in the future. That would just be flat out wrong and I could be charged with reckless endangerment. By ignoring things now and not taking action to secure the data, they’re being reckless.
I guess I need to address the “EMV has been found flawed” argument that seems to be prevalent when EMV and the US appear in the same sentence.
There are three “grades” of EMV card, each adding more complexity and security than the previous. They have all been available but cost drove initial implementations down the SDA route (DDA cards cost twice as much at the time) because they were easier to implement but the chip could be “cloned” if you had the ability (still needed the PIN to make anything happen though). The DDA cards (now mandated for all new products) can not be cloned, because they use PKI. The latest chips (CDA) are essentially DDA chips with a bit extra. All of these card specifications are as old as EMV, waiting for their time – contactless cards are CDA.
The weakness of SDA was always recognised, and now the cost differential is virtually nothing, they are being replaced. All of the other “flaws” are the mainly the result of idiot issuers, like me, not spotting some of the nuances of the EMV whole. All of these headline-grabbing implementation issues have now been addressed – that’s the learning curve. We’ve done all that, the US doesn’t have to.
The department at Cambridge have been trying to break chip and PIN since chip and PIN has been available to break. This is the first breakthrough they have achieved! However, the press release doesn’t give the whole picture, like it doesn’t work with CDA cards, and issuer systems can spot it and decline, and you need the real card!
Wal-mart are off down the EMV route because they understand; they are probably coming from the same place as me. They believe security is important, I believe security is important. It certainly doesn’t follow that because I believe that EMV data has no value and doesn’t need securing, that I also believe that data that does have value should equally be available for compromise. Personal data has value: it should be protected. Card data is not personal data in this context – it doesn’t need protecting. But that isn’t to say that the banks shouldn’t be protecting your name and address, for example, but I suspect that they are.
One question that troubles me: why is that people are prepared to accept the Chip and PIN is weak and therefor PCI is good argument on the basis of the EMV “facts” presented by PCI Guru, but are not prepared to accept real EMV comments from real EMV people (and the argument you use is that you are no EMV expert, so therefore I guess you don’t need to judge the benefits).
One more thing: whilst EMV does not address all of the CNP issues, this is not because there is a weakness in EMV, it’s because the current CNP rules allow merchants to bypass the available technology.
I quite like the motor car analogy: wasn’t there a case in the US where a large motor manufacturer judged that it would be cheaper to ignore a known fault on one of its models on the grounds that the ensuing law suits following the predicted number of accidents would cost less than a recall? Good analogy.
What makes EMV the perfect solution is the fact that an EMV card will work securely anywhere in the world. The rest of the world have done all the hard bits, and we have learned how to implement it properly. Got to say that if there were any real problems, I am sure the Prof would have spotted them.
I’m beginning to believe that bringing up EMV was a mistake. However, while there is a lot about EMV being stated here in all of the comments that is good and accurate, at the end of the day, EMV does not solve the breach problem because the backend systems are still the same as in the non-EMV world. And that is where a breach occurs.
As to all of the issues with EMV, these have all been posted over the years as reasons why EMV is NOT the silver bullet as some in the US Congress and other governmental bodies believe.
In the Congressional hearings held last year, a number of Representatives pointed to EMV as the answer to all of the breach problems and no one stood up and called this for what it was, a bunch of BS. Yes, EMV provides some features that we could use, but it does not solve the breach problem if the POS and back office systems still store the data in insecure ways or at all. And this is the frustrating part. Because the hearings were broadcast on C-Span and the various news sources, practically everyone now believes that EMV solves the problem and once we have EMV we can forget about the rest.
Just to clarify – I am not saying that Chip and PIN is weak and useless, I am curious why it is the obvious fix… the silver bullet that gets rid of the need for regulation such as the PCI DSS. And since I don’t know much about it, I don’t know the details behind the flaws that have been found – so I do appreciate the insight there. However, I would still think since Chip and PIN does not answer all the CNP issues (regardless of if it’s due to a weakness or not), that the PCI DSS provides an outline for security to ensure ALL data is safe. Perhaps I’m completely off base, but I would think just because one method is essentially “hack-proof” when implemented correctly does not mean that you shouldn’t prepare/try to protect yourself for instances when it’s not implemented correctly or for other security issues that it does not address.
And unfortunately yes – there was such a case, for the Ford Pinto where their cost analysis found that the monetary value of human life impacted was less than the cost of repair.
First of all, the PCI DSS is a best practices and not a set of requirements. It does not define security, but a general set of guidelines that assume those that have to meet the PCI DSS and work with a QSA understand security. I have been in this industry since 1982 and involved in PIN security since the early 90’s and I can tell you that the number of people that understand how to secure financial data is very limited.
It is my opinion that the acquiring banks (issuers as well) are the biggest part of the problem. Try to get help from either type of bank. I don’t think it is because they do not understand, it is they do not want to assume liability. As long as the merchants and vendor community keep funding and fixing the security issues, nothing will change. The entire PCI set of requirements are trying to fix the issue they have from the bottom up. I guarantee that if the liability was managed top down, there would be a huge demand for more secure products and vendors could compete on value and security. As it is now, “security decisions” are based on price and is the product on a PCI list.
Keep up the good work Guru!
I was referred to this site because some of my security colleagues thought that PCI Guru represented a balanced view of the PCI world and the issues that surround it. I have read the open letter to the acquiring banks and I have had myself a sad laugh – again! One more PCI guru that just doesn’t get it. The acquiring banks are poor at arbitrating because they realise the true nature of the PCI landscape – the whole thing is a waste of time, and what’s the point in getting involved when it’s inevitably going to change in the very near future.
Let’s not forget that for most of its life, PCI was a guideline that most of us viewed as a framework for good practice. It’s only when its profile was raised by the US government that the PCI security bandwagon-jumpers were able to catch a ride and nudge the payment professionals out of the way. We are now driven by people who are trying to implement security systems that can do payments rather than payment systems that are secure. What’s more is the fact that the “security for security’s sake” hype is now taking over the world, for absolutely no good reason.
Having established that we are doing “security” with the blessing of the US Government, we have lost track of where we are really going: security is the goal rather than a solid payment system. The rest of the world appears to have grasped the principles of safe transactions: if the base data has no value, there is little point in spending huge amounts of money on end-to-end security. You wouldn’t store coal in a safe! I am driven to write all of this because of the idiotic statement about EMV – normally I would ignore this sort of thing, but apparently people read and believe this stuff. EMV data is safe. I would be happy to publish the extractable data from my EMV card on the Internet – it has no value and cannot be used to create a spoof card (there is a risk that the PAN and expiry date could be used in merchants that don’t follow the card scheme rules, but they actually do this at their risk, not mine).
Here is the challenge that I have laid down on numerous occasions where idiot EMV statements have been made: tell me how the EMV data can be compromised, and tell me what you can do with it if you get it. No one, and that includes senior security people within he major card schemes, has ever been able to provide an answer that makes sense. They all boil down to “you’ve got to do security!” So here is your chance to shine: tell me how we in the brainwashed EMV world can have our cards compromised.
I can tell you exactly how you in the US can have your card data compromised, and how it will happen in the future bearing in mind that the data you are trying to protect is still there, in everyone’s pocket, in the clear, and available for compromise EVERY time a card is used! Bluetooth-driven, magstripe-reading petrol pumps are one of the growing scam opportunities, but really, any swipe terminal is a potential point of compromise. Watch out in the US as this type of fraud grows, and let’s not forget that given the magstripe data, it’s not difficult to generate an exact copy, which is not possible at all with the brainwashingly weak EMV data.
Here are the signs of US weakness: PCI was “invented” to address cardholder present fraud, but its raison d’etre is now shifting to the protection of CNP fraud, as though this was always the case. EMV stops technical cardholder present fraud, magstripe doesn’t. Walmart have stated that EMV is the way forward in the US, as it is in the rest of the developed world. The card scheme arguments are getting weaker, as their explanations as to the value of PCI are moving away from the technical and more towards the “you’ve got to do security”.
The problem is that the card schemes already know that PCI is a waste of time and money, because the base data (the Card) is still available in the clear, so that once PCI has been forced into operation around the world, the US will still have to go EMV!!! Large organisations have paid out huge amounts of money to develop PCI-compliant systems, and in most cases it is to protect less than 0.01% of transactions. Once the card schemes admit that PCI isn’t actually necessary in an EMV environment, they open themselves up to some pretty hefty compensation claims. Why should the rest of the world be required to pay for this security nonsense because the US refuses to adopt EMV?
So, PCI Guru – tell me I’m wrong. Tell me why EMV is no good.
You obviously did not follow the link to Chip and PIN or you would have had your answer. The bottom line is that Chip and PIN just changes the magnetic stripe to a chip. The rest of the infrastructure is all the same. It’s not cards that get breached, its the back office systems that are breached and those are the same whether we are talking Chip and PIN or magnetic stripe.
Ah! I think I replied in the wrong place. See the entry up top at 23rd July.
Perhaps I am misreading your stance – but when I see comments like, “the whole thing is a waste of time, and what’s the point in getting involved when it’s inevitably going to change in the very near future,” and “PCI is a waste of time and money”, I can’t help but think your issue is against the PCI standards as a whole. They’re not there to be security for security’s sake – they’re there to be a baseline, a guide to security.
Too many people think it’s someone else’s responsibility to protect the data – but if it’s compromised because of something I did, shouldn’t I be responsible for it? Regardless of if I am a merchant, bank, or service provider? As a customer I know I expect all those that get a hold of that information through my consent to take care of it and protect it so those who I haven’t given it to can’t have it. Now, no, I (as the customer) in most cases wouldn’t be liable for it if the detail was breached, but if it was – the someone that allowed it to stolen should be the one having to pay to fix the error their carelessness has caused as well as work to prevent it from happening again to someone else. If cardholder data is lost because of the merchant, then they are responsible to the fines incurred – however if the merchant is compliant and the bank is not – then the bank should be the one held responsible. All those who handle sensitive data which can cause harm by getting into the wrong hands need to be held accountable.
The PCI is not there to tell you to waste your time and money for something that is completely pointless – it’s there to force those who wouldn’t have security standards in place to get them, to help those with security in place to see if they have any weaknesses in their systems or areas they’ve missed, and to provide an overall baseline to build strong security standards off of. It is the foundation of protecting the detail, nothing more – and naturally it does not ensure perfect security if only the bare-bones minimum is met.
Yes, the standards may change over time – but that’s because our environment changes and the way the data is being breached matures as the security systems and standards do. Expecting the PCI to be able to be perfect the way it is and not change with time is like expecting a 10yr old to fit in the same clothes they did when they were 5… Just like they grow and need bigger clothing, so do our security systems – they mature and put on bigger/stronger ways of functioning in order to stay secure in our ever changing environment.
May some ways be more difficult to breach, sure – but does that mean that no security should be in place to secure it? Of course not.
I guess someone missed the man in the middle vulnerability that I believe was found by a group at Berkley. If EMV data is useless, then why is this considered a vulnerability?
Also, you posted some conflicting information. You state “Here are the signs of US weakness: PCI was “invented” to address cardholder present fraud, but its raison d’etre is now shifting to the protection of CNP fraud,…”, yet EMV does not address card not present AT ALL. Several reports show that while EMV does seem to lower card present fraud, the overall fraud levels remain the same because card not present fraud rose. So even if someone deems EMV as the silver bullet for all card present payment security woes, you will still need something like PCI to address card not present data security.
Sorry, it was Cambridge University, not Berkley: http://www.bbc.co.uk/blogs/newsnight/susanwatts/2010/02/new_flaws_in_chip_and_pin_syst.html
Anyone who knows anything about EMV knows that this is headline-grabbing attention-seeking behaviour designed to justify departmental expenditure.
The man-in-the-middle attack is not about collecting card data, it’s about telling the terminal one thing and the card something else, so the card believes the terminal can’t do PIN, and the terminal believes the card has approved the PIN. It needs the real card, some EMV knowledge and some technology; and contrary to the statements made, the issuer can tell what is happening and decline.
Whatever you do with magstripe to secure it, the data is still there on the card. You can’t change the format or structure without changing EVERY card accepting device in the world! Not going to happen for an end-of-life technology.
I agree with your overall assessment of the lack in bank participation or even interest. I wrote a similar article some time ago which I ended up tempering a little to remove any ‘venting’ because I have been THAT frustrated by many of the acquiring banks I have dealt with in Africa and Asia concerning PCI DSS. I think the main problem in these regions for me would be the perceived difference between the certification of just about everyone else in the PCI transaction process and the banks themselves. I have found that their attitude reflects the fact that they believe they need only ‘confirm’ compliance and do not need external auditors to verify this, at least where I work as I mentioned before. This is of course partly true and for me the card associations do need to educate their banking partners much more aggressively to change this perception and get them on-board as much more active participants in PCI DSS. Another problem is the lack of knowledge amongst departments within a bank as to who should be compliant and who not. This is not really a surprise I guess, with my personal experience during a launch of a new ATM business being highly frustrated with the head of security within the acquiring bank for the ISO insisting for example that ISO change all their single length security keys to double length, after which the ISO had to point out to this very officer that their own systems within the bank only worked with single length keys, and the expense to the ISO was to change their system back once again to the older format.
This same acquiring, one of the largest, sent only fully exposed PANs and could not mask them. The ISO had to write a special filtering module to capture the Connect:Direct file from the bank and cleanse it before loading it into the ISO’s ATM switch, or face losing their PCI DSS compliance status! No apologies from the bank and definitely no commitment as to when this process would be replaced by a compliant settlement process from them.
This also happens because in Asia and Africa I often find the PCI is pretty much powerless against the banks that have traded there for years before they came along. This historic imbalance leaves the non-US market almost always lagging behind the US one when it comes to compliance to various PCI programs. What concerns me about the US market though is that CISP there was a great forerunner of what became PCI DSS and therefore I would have expected a much more cohesive and responsible action on the part of US acquiring banks compared to the rest of the world. From your post and some of my own experience they are sadly not any more willing to co-operate than the non-US banks or so is my perception.