US-EMV Deadlines

And yet again, it's been a while since I posted to my blog and, in turn, it's been a while since I ruffled some feathers. So, let's start 2017 with a bang!

Over the Christmas break read an article in Digital Transactions News: How EMV-Related Chargebacks Drove Florida Merchant Duo to Sue Networks And Issuers. While reading the article, my initial thought was, "There's nothing new here. They're simply documenting how the EMV rollout went (and still is going) for many U.S. merchants." Then, in the final paragraph I read a quote from Molly Wilkinson, executive director of The Electronic Payments Coalition, a Washington, D.C.-based lobbying group that represents card networks and issuers: "Merchant groups have known about the transition to EMV cards for five years but instead of getting their act together they have tried to delay, obfuscate, and reject this solution – all while leaving customers exposed to hackers and counterfeiters." This statement has so many flaws that I'm not sure where to start, and it clearly demonstrates the ignorance of the coalition – or is altogether pushing a blatant lie.

Let's start with the merchant groups. Simply put, they are advocates for the merchants, not tools for the card brand mandates. They have no control over what the networks support, the various requirements of physically performing an EMV transaction, or the certification requirements of EMV solutions. Merchant groups have little to no role in the supposed five-year preparation window – more on this later. I would be interested in hearing exactly how these merchant groups delayed or obfuscated the U.S. EMV rollout. Now let's discuss this "rejection of the solution." They had reasons for the rejection, as I will explain.

IMHO, the largest factor of the U.S. EMV rollout failure was a lack of forethought by the card brands and EMVCo in recognizing the differences in the U.S. marketplace. EMV for the most part has been a great success in Europe and it was assumed that EMV "plans" could be lifted from Europe and plopped onto the U.S. as-is. The problem here is the plan included a thorough end-to-end testing of the "solution." In Europe, a majority of the solutions are simply stand-beside terminals with little or no integration, so certifying a couple terminal solutions with a couple of banks in each country, no big deal – project complete. Here in the U.S. , there is a much bigger diversity of banks, processors, and terminals, and a majority of the marketplace uses fully or semi-integrated solutions with the point-of-sale (POS). This translates into an exponential number of "solutions" to certify in the U.S. compared to its European counterpart. Now before people get bent that I'm bashing one or the other, my point is not that one is better than the other, my point is they are simply different and that there was a failure to plan for this difference – and the blame certainly doesn't fall on merchant groups.

Let's revisit the five-year EMV preparation window. The card brands scheduled out various deadlines for banks and processors to be EMV ready within this preparation window, and before the October 1, 2015, liability shift deadline for merchants. There were two issues here. I don't know the wording of the mandate to the processors, but from what I experienced, as long as a processor could demonstrate a working EMV solution (I'm unsure if certification was required or not), then the deadline was met. For many processors, host specifications supporting EMV were not published to integration partners (like gateways) until around May or June of 2015. And, none that I am aware of had solidified their certification process, which is a big part of an EMV solution. Most EMV solutions back then took between 4-12 months to certify. It's a little better now, but not by much. Assuming the specs were published in May, allowing for a 30-90 day development cycle plus a six-month certification, means the average "solution" would have been certified and production ready no earlier than February or March of 2016 – this is a good 4-5 months after the EMV merchant deadline.

Then we have the October deadline. Why October? Who picked this deadline? Just before the holiday shopping season when most merchants (at least larger merchants) have technology freezes in place in preparation for their busiest time of year. I'm not sure what the merchant groups were or were not conveying to the card brands or the coalition, but if I were in charge, this would have been a no-go issue.

Now, the doozy: "all while leaving customers exposed to hackers and counterfeiters." This propagates the misbelief that EMV secures the account information. EMV does not protect the card data. EMV is an authentication mechanism only. You must add point-to-point-encryption (P2PE, sometimes also referred to as end-to-end-encryption or E2EE) to secure the data. Authentication guarantees (relatively speaking) that the card is authentic and was not forged; it does not stop prying eyes from seeing the account number and expiration date in the clear. P2PE hides the data from prying eyes. The U.S. was already making a shift to P2PE, but the problem was that incorporating EMV meant a new batch of uncertified terminals entering into the solution certification chain.

Hopefully this clarifies some of the misinformation flying around about how merchants are to blame for the U.S. EMV rollout failure – or at least the missed deadline.

Computer Security Day

It's been a long while since I posted here. Time is flying by. A colleague at work sent the following security PSA to all Shift4 employees and he was gracious enough to let me re-post here for the world. Good info...

COMPUTER SECURITY DAY

Computer Security Day is observed annually on November 30.

Identity theft, credit card fraud, ransomware, and more endanger our online experiences every day.

History of Computer Security Day
Computer Security Day began in 1988, around the time when computers were becoming commonplace in business and government and in the home…when they no longer cost $10,000.  The Internet, as we know it today, was also an infant.  While hacking and computer viruses have been around since the early days, evolving and increasingly sophisticated malicious technologies will continue to be a threat to online computer activities forever.  Computer security had already become a major concern by the end of the 80s so Computer Security Day was created to educate users and raise awareness.

Here is a checklist you can follow to help secure your computer at work and at home:

·         A password is required to access my computer.

·         Windows Update is enabled.

·         I use antivirus software and make sure it is updated daily.

·         My Windows Firewall is on.

·         I keep my computer applications patched up to date.

·         I remove unused computer applications.

·         I always use strong passwords.

·         I don’t share or write down passwords.

·         I log off my computer when I’m not using it.

·         My home wireless network is secured with a strong password and strong encryption.

·         I regularly backup my important data to an offline device.

·         I use caution when I browse the Internet.

·         I suspect foul play when my browser is redirected to another web site.

·         I don’t allow my web browser to store or remember my passwords.

·         I regularly delete temporary Internet files.

·         I don’t open attachments or click on links in email from people I don’t know.

·         I make online purchases only on well known, reputable web sites.

·         I look for “https” in the address bar before submitting personal and payment information.

·         I don’t save my credit card information on web sites.

·         I don’t use my debit card online.

·         I don’t use the same password for all online services.

Enjoy!

Shift4 Secure Payment Processing DOLLARS ON THE NET®     IT'S YOUR CARD®    4Go® Stephen Ames, CISA, CISSP Senior Director, Security Compliance
Shift4 Corporation 1491 Center Crossing Road Las Vegas, NV 89144-7047	702.597.2480 ext. 46700 fax 702.597.2499 www.shift4.com sames@shift4.com

"In the pursuit of security assume nothing." -sga

Why All QSAs Must Lie

A fellow blogger referred me to yet another blogger's post "Why All QSAs Must Lie". While the title sounds like a QSA bash piece, it definitely grabs attention and the post is definitely not a dump and QSAs and is worth the time to read.


On another note, I'll start writing again soon. I have several ideas but time has been hard to come by of late. Until next time...

Bob Russo: Breached!

There is a brief article that I found on CardNotPresent.com where Bob Russo, outgoing general manager of the PCI Security Standards Council, describes an incident where he was robbed (really burglarized but everyone misuses "robbed" – pet peeves of mine). Bob uses this story to illustrate how PCI-compliant companies are breached.

Before reading my punchline, please read the article: Bob Russo: Breached!

Stop. Go back; you didn't really read it…

Ok, anyone notice something missing from Bob’s story? Immediately following the police investigation the DA (DA playing the part of the card brands) didn’t levy fines for PCI non-compliance. His HOA (HOA playing the part of an acquirer) didn't kick him out for not properly securing the premises. He was not required by various states (cameo appearance, playing the part of themselves) to send out breach notifications to all the contacts stored on his laptop. He didn't make headline news with "Russo Exposes PII!" Lastly, he was not hit with one or more class action lawsuits for the stolen Personally Identifiable Information before the ink had a chance to dry on the police report.

Hmmm… I wonder if my name and email address was contained in his contact list.

Tokenization IS Encryption - NOT! - Part 5 (pre-release teaser)

The saga continues. As PCI SSC continues redefining and clarifying its newly redefined definition of tokenization via the PCI Tokenization Task Force, EMVCo apparently decided they liked the term "tokenization" so unbeknownst to anyone else, a new EMVCo definition was necessary. Last month EMVCo released the EMV Payment Tokenisation Specification v.1. Luckily they misspelled it, probably on purpose, so-as not to confuse EMVCo Tokenisation with PCI Tokenization whereas PCI Tokenization always gets confused with TrueTokenization®.

I find it funny that just like PCI SSC, EMVCo didn't bother to approach the inventors of tokenization during the development of their definition. Hindsight being 20/20, I really wish Shift4 had trademarked the term tokenization prior to releasing the concept to the public domain. At least then we could have better controlled the definition and limited the misuse of the term. Instead we now have everybody and their brother coming forth with their custom definition, complicating and confusing a concept that was designed to be simple, easy to explain and secure. Anyway, I'm currently reading and analyzing the EMVCo document. Stay tuned for a detailed report…

The Economics Of EMV

A fellow blogger PCI Guru created an informative post on his blog explaining some of the reasons why EMV adoption is so slow in the US:

• http://pciguru.wordpress.com/2014/01/10/the-economics-of-emv/

If you have any comments on the post, feel free to post them on his site -- I won't be offended.

Earth to Media, Earth to Media, Come in Media…

Target breached, and EMV would have done nothing to prevent it. Period! I realize there are a lot of EMV fans out there stating differently, but please reference people that really know EMV -- its advantages and its limitations -- before releasing propaganda pieces painting EMV as the silver bullet it is not and calling it news.

What EMV cannot do: EMV does not protect the PAN, expiration dates, CVV2 or even PINs in anyway. While information as to whether or not PINs were stolen in the Target breach is sketchy, all the other information was stolen and EMV does not protect any of this.

What EMV can do: EMV is very good at preventing the stolen information from being used to create forged cards to be used for card-present (swiped) purchases, but if history repeats itself, the stolen information will primarily be used for card-not-present (ecommerce) purchases. Until EMV and/or the card brands address card-not-present purchases, EMV is nothing more than a one legged stool.