What went wrong with First Data?

There is an interesting article in TheDeal.com, "What went wrong with First Data?"

Under the challenges that First Data faces, one BIG challenge that was not addressed in the article is that First Data definitely falls under the current administrations definition of "Too big to fail." While absolute numbers aren't published, an estimated 50-65% of all US credit and debit card transactions go through a First Data host somewhere along the line. To me, power hungry politicians stepping in and taking over First Data in their "challenging time" makes all the other challenges moot.

Anyone else have thoughts on this topic -- even just to tell me I'm a paranoid schizophrenic?

Heartland Lawsuit Dismissed - Secure Enough

A lawsuit initiated by shareholders against Heartland Payment Systems was dismissed on Monday. The judge ruled that the plaintiffs didn't prove their case that Heartland lied about their security measures that were in place. The story can be found on the StorefrontBacktalk blog "Heartland Lawsuit Dismissed, 'Insufficient Evidence' Of Weak Security."

There is a very interesting quote by the judge on the third page of this article: "The fact that a company has suffered a security breach does not demonstrate that the company did not ‘place significant emphasis on maintaining a high level of security.’ It is equally plausible that Heartland did place a high emphasis on security but that the Company’s security systems were nonetheless overcome..." Juxtapose this statement to comments from Adrian Phillips, Visa International’s Deputy Chief Enterprise Risk Officer and Regional Head of Risk for North America: "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." I go further in stating that when push comes to shove, in one way or another, all breaches will be found to be compliance failures. Not because companies are ignoring PCI, but because the fact that PCI is so all-encompassing that it's impossible to be in compliance 100% of the time. Hackers are like terrorist in the fact that hackers only need to be successful one time whereas merchants need to be secure 100% of the time.

The reason I found this interesting is that it appears that the judge in this case is distinguishing between security and compliance, and rightfully so. I think "best effort" is what is missing with PCI, at least in terms of compliance. There should be some "best effort" allowances otherwise some unscrupulous stakeholders in the industry will view PCI as nothing more than a revenue generation scheme upon a breach (a breach, cool, free money!). Unfortunately, I think there are some in the industry already treating breaches this way.

Now that there is precedence separating security from compliance, will this change the landscape? Or will it just change the wording of the plaintiff's complaints; instead of "did not do all they could to be secure," you might see "did not do all they could to be compliant."

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

I Hate to Say I Told You So…

Back in 2007, Shift4 held a Security Summit for its customers. One of the topics discussed was the link between credit card fraud and terrorism. Most people were surprised to hear this information and most attending this Summit were grateful that there security endeavors were making a bigger impact than they ever imagined.

Some people however, were appalled to hear this information. An interesting fact is that most of the naysayers were PCI security experts. But these PCI experts weren't the only one appalled. One of the major card brands (who shall remain nameless) was going to speak at this Summit but backed out at the last minute when they got wind of this topic. “That's just a fear tactic that Shift4 uses to sell their wares,” was a common theme when discounting any terrorism ties. The funny thing is, we were not “selling” anything at this Summit -- this was a security awareness event for our customers. In fact, the new products we debuted were and still are free for our customers.

Now fast forward a year and a half, The Green Sheet publishes an article on February 23, 2009, Data breaches, more than bad publicity which links credit card breaches with (drum roll please…), international terrorism. One snippet from the article: “The card scheme of choice: ‘carding.’ Carding is an umbrella term used to describe the theft and sale of personal financial information via the Internet for card or identity fraud.”

On March 31, 2009, the House Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology, which is part of the Homeland Security Committee, chaired by Yvette Clarke (D-NY) held a hearing titled “Do the Payment Card Industry Data Standards Reduce Cybercrime?” You'll never guess what one of the topics discussed in this hearing.

Hmmm, I think there are some appalled experts in this industry that need to open their eyes. I'm fine being called out when I'm wrong about something. I just don't like being told I'm wrong just because someone does not want to hear what I'm saying. Ok, I got that off my chest. Now I'll be the mild mannered programmer my mother raised.

I Am Still Alive

I'm currently writing a next blog posting, hopefully to be posted by the end of the week. In doing some research, I noticed that some sites have linked this blog when referring to tokenization. I do have published a white paper on this topic and I should have published a link to it from this blog at the same time. Sorry, better late than never:

Tokenization in Depth (PDF)

The white paper is distributed by Shift4 Corporation. It does require a registration and once complete it will be mailed to you directly and automatically.

Do as I Say, Not as I Do

The latest breach involving Heartland Payment Systems is all the buzz. Some are surprised and/or appalled “yet another high profile breach.” Others question the timing of the announcement theorizing some public relations attempt to hide the announcement within the presidential anointment, oops, inauguration ceremony. What caught my eye is the latest campaign: Heartland CEO Calls For Industry Cooperation To Fight Cyber Criminals And Adoption Of End-To-End Encryption. While I agree with end-to-end encryption, I feel this is nothing more than a case of “do as I say, not as I do.”

My issue is the last paragraph of the above linked press release: “For the past year, Carr (Robert O. Carr, Heartland’s founder, chairman and CEO) has been a strong advocate for industry adoption of end-to-end encryption — which protects data at rest as well as data in motion — as an improved and safer standard of payments security. While he believes this technology does not wholly exist on any payments platform today, Heartland has been working to develop this solution and is more committed than ever to deploying it as quickly as possible.”

The technology already exists, just not in the terms that Carr may be implying. I think Carr is referring to chip cards of one sort or another, but there is nothing stopping a company from doing end-to-end encryption within their own network. While PCI does not currently require end-to-end encryption within a LAN, PCI is meant to be a “minimum” security standard – it is not a be-all, end-all blueprint for secure payments.

I try not to advertise for Shift4 within my blog, but Shift4 internally does end-to-end encryption within its network. The weakest point in the whole chain is the final hop to the bank or processor (which we have compensating controls in place to isolate and minimize the exposure at these points – but this is beyond the scope of this rant). Here, I would argue side-by-side with Carr to force all banks and processors to require application layer encryption at this hand-off point instead of solely relying on VPN encryption. Shore up the weakness of this layer, problem solved provided that the banks and processors internally do end-to-end encryption and you don’t have to wait for PCI rule change, nor do you have to toss out the baby with the bath water by switching to chip cards.

Switching to chip cards may solve some issues, but viewing chip cards as a panacea, I feel, will be a big and extremely costly mistake for merchants if other layers in the end-to-end data path are ignored. If merchants think PCI is expensive now, wait until they need to purchase and deploy all new hardware and fork out the POS software upgrade fees required to support this new hardware platform.