Go Carr

I've not always agreed with Heartland Payment System's CEO Bob Carr but in a recent article that appeared on Bank Technology News (The End of the World), Carr mentions with disdain that vendors (referencing payment gateways, banks, payment processors, possibly even POS providers) want to charge merchants additional fees for encryption services; "First Data says it thinks encryption technology should demand a higher price point." To me, this would be a disgusting practice and I fully agree with Carr's distain. Providers that handle credit card data MUST handle it securely and charging merchants additional fees as though it's a luxury is despicable.

Bottom line, whatever solutions you choose, make sure your vendors are not charging additional fees for the luxury of securely handling cardholder data.

Your encryption sucks - here, use mine

I just read an amusing article on SearchSecurity.com: Heartland CIO is critical of First Data's credit card tokenization plan. In this article, Steven Elefant claims front-end tokenization solutions are less secure than end-to-end encryption solutions because front-end tokenization solutions depend on encryption. Huh? "Front-end tokenization, where you take a credit card number and send it up to a token server and then send it back to the terminal, is not good because you are totally exposed from the time you swipe the card until it gets to the token server," Elefant said in an interview with SearchSecurity.com. "If you are not encrypting with very strong crypto and hardware, you don't have security." I like the idea of end-to-end but let’s get some perspective. The end-to-end encryption technology that Elefant endorses uses unproven "hidden" or "format preserving" encryption. Could this be the case of the pot calling the kettle black?

If you're reading this trying to decide on end-to-end vs. front-end tokenization, here are some things to consider. Security should be thought of as layers. A solution that provides or allows for overlapping of end-to-end and tokenization would be the best approach. In lieu of that, true tokens (where the token value is in no way related to the card number other than as a reference) are not considered cardholder data and are not in scope of PCI whereas encrypted cardholder data is still considered cardholder data. Tokenization solutions may be adjusted to allow for repeatability (depending on provider) whereas end-to-end cannot and should not be able to provide repeatability – this comes into play when presenting recurring transactions are using cardholder data for loyalty lookups or risk analysis. End-to-end, in most cases, can work better in remote offline locations whereas most tokenization solutions require online access (but Shift4 does provide offline tokenization capabilities). Most end-to-end solutions use a "keys-to-the-kingdom" approach and therefore require tamper resistant hardware security modules; if these keys are ever breached, all the systems that store this "encrypted" data are vulnerable whereas true tokens are useless even if the token generation logic is known to the world.

PCI SSC Community Meeting and Emerging Technologies

The PCI SSC Community Meeting just concluded. I only attended one of the three days and that was enough for me. I fully admit I have a lot of nerd like tendencies, but apparently not enough to make a three day event on security exciting. To me, there were four highlights: the food did not kill anyone, the cocktail event was hosted, Bob Russo does a decent Elvis, and the Emerging Technologies session.

Highlights 1, 2 & 3, I'll just leave it at that. If you want more details, I urge you to attend the next community meeting.

The Emerging Technologies session had several points of interest but it left me wanting more. In a nutshell, PCI SSC contracted PricewaterhouseCoopers (PwC) to evaluate and create a report on emerging technologies and how they impact PCI. The summary given at this meeting was a 100,000 foot view of various emerging technologies – yes, 100,000 foot view, not the more common 50,000 foot view. While they made it a point that the report in no way endorsed any one technology and the report was not intended to rate the technologies, they did detail the four most popular technologies: End-to-End Encryption, Tokenization, Virtual Terminal, and Magnetic Swipe Authentication.

Magnetic Swipe Authentication technologies address card present fraud, but do not really address any PCI security or scoping issues so I'll skip that one. The other three; yeah and it's about time! While I don't agree with some details of the how they rated cost vs. reward vs. impact in different categories, I gave PwC a little leeway because they were bundling multiple vendor solutions into fairly broad categories.

The only category rating that really stuck out like a sore thumb was the business impact of end-to-end encryption vs. tokenization – they gave end-to-end a less business impact rating (more favorable) than tokenization. Shift4 provides solutions that straddle all three technologies (end-to-end, tokenization, and virtual terminal) and from experience, tokenization has far less impact to the business flow than end-to-end. Reason being, the merchant systems never have access to the card number. While security wise, this is a plus for end-to-end, business impact wise there are a lot of gotchas. One example is that many risk and customer loyalty systems use the card number (or more preferably, a hash of the card number) as a key to look up the customer. Stronger forms of encryption produce non-repeatable results when the same information is encrypted so this simple process of a customer lookup becomes problematic.

All in all, just the fact that the PCI SSC is seriously looking at these emerging technologies is promising whereas heretofore, they have always brushed this off as a risk/compliance judgment call for the acquiring banks. I can't wait to see what PCI SSC does with this information and I hope they publish the PwC report.

I will mention one note that I feel was a lowlight: Some of the questions in the Q & A sessions, I'm pretty sure, were asked in similar events three and four years ago. The root cause of the biggest areas of confusion stems from the gap between security and compliance. Bob Russo is the first to state the PCI SSC has nothing to do with "compliance" – instead, PCI is the keeper of the security standards. Yet the card brands dictate that PCI compliance is mandatory.

Payments Industry Prodigies

WARNING TO THE READER: I guess I'm in a bad mood today so pardon my rant. I'm just airing dirty laundry in this posting so if that's not your cup of tea, skip to the next posting.

The payments industry never ceases to amaze me. My latest amazement is how our prodigies are chosen when it comes to security. Here are three examples and if anyone has any explanation why, please feel free to post your thoughts:

(I'll keep the company and personal names out of this; if you're familiar with the industry, you know who I'm talking about)

First on my hit list, a prominent payment processor promoting a new security technology was a victim of one of the largest data breaches exposing credit card information. This by itself is not an issue because a breach can happen to anyone. What baffles me is that proper deployment and use of existing encryption technology could have prevented their breach. This seems like a deflection tactic: instead of shoring up our security gaps, we'll head up the development of a new theoretical technology where no one needs to be secure. This is the example of a perfectly executed public relations campaign.

Next on my list, the Visa poster child for how a POS company should tackle security is probably the biggest factor in requiring CISP and later PCI. Security was all but completely ignored in all pre-2003 versions of their software; card holder data was stored in plain text in various files, remote access with administration level privileges all shared the same login credentials across the entire merchant base, system level administration access was required for all stations and the installation of anti-virus software was frowned upon (all practices that directly oppose security best practices). Then overnight – presto-chango – the model POS vendor for security (even though their application was not truly PCI compliant out-of-the-box until 2008).

Last on my list is a large merchant and victim of a breach that is now doing the "learn from our mistakes" tour. Don't get me wrong; someone who's been on the breach hot seat is the best speaker for convincing merchants to be secure. But let's get all the facts out. Less than two years earlier the decision makers at the company nixed a proposal that could have prevented their breach. Nixing a proposal is not the issue here, it's the reason given: "we don't need that technology, our systems are already secure." I've not heard this little fact on the "woe is me" tour, instead "we were just an innocent victim."

I promise, I'll be in a better mood next time. ;-)

A FIRST LOOK: Tokenization & End-To-End Technologies Combined

On August 12th, EPX (a third party payment provider) announced that it is joining end-to-end encryption with tokenization. I applaud their effort because I've stated, and I strongly believe that combining these two technologies is the strongest way to secure cardholder data. In the announcement, Matt Ornce, Chief Operating Officer for EPX is quoted: "There maybe are a few entities that have tokenization as a real product today, and there are a bunch of entities talking about doing end-to-end encryption for the merchant, but we haven't heard of anybody combining the two, much less delivering the product to the market." News flash, Shift4 prototyped this in late 2005, the same time they released tokenization to the public domain, and released a product to market in early 2006.

Who Breached Me?

In my last posting "Yet Another...", I wrote about a breach notification from Network Solutions, a payment service provider. Soon after the original posting, Evan Schuman from StoreFrontBacktalk.com pointed me to the actual notification, which prompted a correction to my posting. While my initial ire was based on false assumptions, the final notification letter to consumers still included the merchant name even though Network Solutions was the entity breached and the service provider was accepting the blame.

During this discussion we had a brief debate about whether or not the merchant name should have appeared in the notification. This discussion gave me an idea to have a simple sparring session debating our different points of view using a simple 100 word or less argument for, argument against, rebuttal for, rebuttal against format. Before we begin, I want to thank Evan for participating and spending the time to put his viewpoint down. Here is the final result:

Should the merchant's name appear in breach notifications if the breach occurs upstream from the merchant and beyond the merchant's control?

ARGUMENT FOR the Merchant Name Appearing in the Notification - The retailer's name needs to be on that notification letter for two reasons. First, consumers only know the retailer's name. Give them a letter that doesn't say something they recognize and it will be thrown out. Secondly, a small retailer will be inclined to go with the lowest cost service. If they don't feel some pain if that service screws up, proper choices will never happen. This will insure that retailers make the best available choices, balancing cost versus security. Breach letters aren't supposed to be fun, but can be functional. Some good can be served.

REBUTTAL to Argument FOR the Merchant Name Appearing in the Notification - Consumers do need to know their card number was compromised but the merchant's name does not need to appear for the consumer to take notice. A notification from the consumer's bank is more credible than from TransUnion, the merchant or the provider that was breached. Second, price does not guarantee security. Case in point, Network Solutions is not known as the low price leader yet they were breached and their name appears in Visa's Global List of PCI DSS Validated Service Providers. This list should be of some value to the merchant beyond "you're required to use one of these." The card brands cannot expect the average merchant to spend days vetting providers.

ARGUMENT AGAINST the Merchant Name Appearing in the Notification - The card brands dictate that merchants must be PCI compliant and to be PCI compliant, merchants must use PCI compliant practices, applications and service providers. Visa publishes a Global List of PCI DSS Validated Service Providers. Since merchants are required to use vendors from this list, the card brands should provide some form of safe harbor, even if it's nothing more than not disclosing the merchant's name in the event that the service provider is breached. The card brands shouldn't expect all merchant to physically tour and spend days vetting these providers; the card brands should have done this when preparing the list. The merchant should not have their brand tarnished due to a security breach completely beyond the control of the merchant.

REBUTTAL to Argument AGAINST the Merchant Name Appearing in the Notification - The Safe Harbor concept is a wonderful theory, but in payment security, it doesn't exist, never has existed and truly can never exist. Retailers normally (the Network Solutions situation is the exception) have tremendous day-to-day influence on security, in the same way that a car can pass a state safety inspection but that doesn't mean the driver won't remove his brakes the day after the inspection. Given the influence a retailer has day-to-day, the merchant must assume responsibility. Besides, the breach letter needs to notify in a meaningful way.

Based on the arguments and rebuttals presented here, hopefully you can decide for yourself where you stand. My guess is your stance will be determined by whether you are looking at the issue from the merchant's perspective or the consumer's perspective. Either way, hopefully this gives you insight to the other side of the argument.

That was fun. I enjoyed sparring with Evan and I hope he enjoyed it as well. I'm sure this argument/rebuttal format will be used again to debate other issues. Until next time...

Yet another...

Yet another big name breach -- or is it?
Yet another PCI compliant provider breached -- or was it?
Yet another reason PCI compliance needs an overhaul -- or does it?

On July 27th, it was learned that Network Solutions was breached and 574,000'ish customer records were possibly compromised. Network Solutions supplies payment services, among other things, to thousands of small merchants and is a big name. The full details of the breach, the how's and why's are not yet known as the investigations are still ongoing (and may never be known by the public, but that's another story). The fact Network Solutions was breached does not really surprise me because I know there is no such thing as absolute 100% security and the next breach is just waiting for a name to be associated with it.

Big name?

What caught my eye here was how Network Solution informed the consumers. In an effort to comply with the tangled mess of privacy reporting laws, Network Solutions contracted TransUnion to notify the end-user consumers or cardholders. But instead of saying "we're Network Solutions, we take security seriously but unfortunately...", they sent a letter opening with "TransUnion is contacting you at the request of XYZ Merchant..." where "XYZ Merchant" was a merchant that Network Solution was providing payment services for. To me, this is pure slime intended to protect Network Solutions' brand name at the expense of the merchants they serve. The merchant did not have to be mentioned at all, Network Solutions was breached, not the merchant.
I stand corrected. My original ire was based on feedback from affected merchants about the Network Solutions notification letter sent by TransUnion. Reading the complaints, I got the impression that Network Solutions was hiding their brand name behind that of the merchants. After the original blog posting, Evan Schuman (from StorefrontBacktalk) linked me the proposed notification that the merchants were discussing. In the notification, Network Solutions was clearly taking the blame so as the famous Saturday Night Live line goes -- ...never mind.

Compliant?

Who really cares? According to Visa, "no PCI compliant organization has ever been breached." So it's fait accompli that Network Solutions was not PCI compliant. To me, this means one thing: PCI compliance is not truly attainable.

I never can seem to harp on this enough: Focus on security as PCI compliance is a myth. Reduce your risk profile to reduce the chance of a breach. If you are harder to breach than the guy next door, chances are your name will not be associated with the next breach and compliance will never come into play (after all, if you are breached, it will be determined that you were not compliant).

PCI Overhaul?

PCI is a great list of best practices and it should be used as just that, best practices. The card brands should stop trying to use a list of best practices as definition of black or white, secure or insecure, compliant or non-compliant. Since security is never 100%, Visa's quote highlights the biggest flaw: equating compliance to security.

Since the card brands have essentially stated that only non-compliant companies are breached, I think the whole "compliance" factor should be removed. Instead, simply state, "companies that are breached and found to be not taking prudent steps to secure the data or negligent, will be fined." The PCI Best Practices can be used when deciding prudent or negligent. But I don't expect to see anything simple like this anytime soon. After all, there is too much money to be made by the card brands and banks if they stay focused on compliance.

References:
StorefrontBacktalk: Network Solutions Data Breach Hits 574,000 Consumers
CNET: Network Solutions Breached For 574,000 E-Commerce Account Records