Announce A Data Breach And Say It's No Big Deal?

This column was written by Evan Schuman, the editor of StorefrontBacktalk, a site that tracks retail technology, e-commerce and security issues. Retail Realities appears every Friday. Evan can be reached at e-mail and on Twitter.

Our tale is about an interesting startup called Blippy. (Note: A very prominent co-founder of Blippy's is Philip Kaplan, the Pud of F*cked Companies fame. Yes, that makes one of the deepest ironies in Silicon Valley coming up the street right now.)

On Friday (April 23), Kaplan announced on the company's blog that four customers had their credit card numbers exposed on the site because Google cached some of its early testing. For some reason, Blippy publicly tested with live payment card numbers.

"We are serious about security and want to assure Blippy users that this was an isolated incident from many months ago in our beta test and doesn't affect current users," Kaplan penned, before adding: "Also, this was not the result of a hack or security breach." Apparently, he added that last part because customers think it's much better to be exposed for doing something really dumb.

Kaplan's post is the one that said the incident was "a lot less bad than it looks." On Monday (April 26), Blippy Co-Founder and CEO Ashvin Kumar took to the site to offer the least-surprising post in the history of blogs: After further investigation, he said, following the script of every retail data breach CEO, it turns out that it was worse than Blippy's management initially thought.

Kumar opened his revised post by saying: "It has been a rocky weekend for Blippy. The weekend began with a front-page article in The New York Times announcing our Series A financing. The elation didn't last long. A few hours later, reports surfaced about the discovery of credit card numbers within Google's cached search results." The only problem is that the Times piece actually appeared early Thursday morning (April 22). Guess Blippy likes to start its weekends early. And the first post said the breach was discovered Friday morning (April 23), which doesn't jibe with "a few hours later."

"In early February, due to a technical oversight on our part, some raw transaction data appeared within the HTML code on some Blippy pages for about half a day," Kumar said. "Up until that day in early February, based on the raw transaction data we had observed during our beta period, we incorrectly considered raw data fairly harmless. It typically is." (When it comes to credit card numbers, raw data is typically fairly harmless?)

"What we did not realize until Friday morning [April 23] was the fact that in that half-day period, Google had crawled and indexed a portion of Blippy's pages. Even though the sensitive information was hidden in the HTML and not visible in plain view, the Google crawler observed it and recorded the information to put into its search index," Kumar posted. "Google effectively took a snapshot of Blippy during that half-day period. Though our site has changed considerably since early February, Google's snapshot of these pages did not update, which effectively extended a half-day exposure into a three-month exposure."

The problem here is that Kumar is suggesting the problem is with Google having captured, as opposed to Blippy having exposed, the data on the site when it was publicly viewable. That distinction is rather alarming. It's akin to a security guard getting in trouble because someone used a smartphone and recorded him sleeping on the job. And then building management addresses the problem by banning smartphones.

Kumar reported that his team worked with Google "to remove the search snippets and search results on Google for the discovered cards. Google removed these 200 or so URLs promptly." He also said: "On Saturday morning [April 24], upon the discovery of an additional card, we requested Google remove all snippets and cached pages related to Blippy. We were extremely conservative in viewing the data for potential exposure (even if we were unable to confirm that such exposure had taken place). As a result, we reached out to a total of eight individuals."

Love a post that raises more questions than it answers. On Friday (April 23), we had four customers impacted and after "the discovery of an additional card," it doubled to eight. I think we missed an update in between.

It's not clear, though, if all eight had payment card exposed. Even if it's eight people, how does that map to "200 or so" URLs? With cache, the same page could certainly have appeared repeatedly, but 200 or so URLs for eight people?

Blippy's problems got worse. Kumar again: "Naturally, when users learned of the issue this weekend, some wanted to disconnect their credit card accounts or delete their entire user account. At the same time, Blippy's servers had been under increased load due to the media attention. This resulted in many failed requests to delete accounts because we had not invested sufficiently in making our account deletion process as programmatically efficient as it could be." He's right. Blippy was having a bad weekend.

Kumar ended his post with a list of five things Blippy will do to address these problems: Hire a Chief Security Officer; have regular third-party infrastructure and application security audits; continue to invest in systems to aggressively filter out sensitive information; control caching of information in search engines; and "create a security and privacy center."

Those actions are all fine things, but the caching effort still feels like the sleeping security guard. What's missing, though, is a strict pledge to not expose any payment card data ever-even in a testing mode, even in a testing mode limited to Staging, even in a testing mode limited to Staging that can only be accessed from within the LAN.

Of potentially greater concern is the original post by Kaplan. The "less bad than it looks" comment was ill-advised and, in fact, that line was removed from the post after some negative feedback. We initially suggested that if Kaplan still feels it's no big deal, maybe he should post his card data on the site and see how inconvenient it feels.

Beyond even that is Kaplan's other comment: "It's important to remember you're never responsible if someone uses your credit card without your permission. That's why it's okay to hand your credit card over to waiters, store clerks, E-Commerce sites and hundreds of other people who all have access to your credit card numbers."

We couldn't put it any better than did Patricio Robles at EConsultancy: "Most cardholder agreements protect the cardholder against unauthorized charges provided that the cardholder has taken reasonable measures to protect his or her card against loss or theft. Can individuals willingly sharing purchasing information with a service like Blippy really claim to be exercising reasonable care to safeguard their credit card details?"

Robles also points out that Blippy-and data-sharing services like it-are an odd duck in the payments space, a point that PCI Columnist Walt Conway elaborates on wonderfully. By the way, we noticed that Blippy management chose to turn comments off on their postings about the data breach. Given what you were telling your customers and their likely response, that move-turning off comments-was quite wise.

(The opinions expressed in this commentary are solely those of the author.)
By Evan Schuman
Special to CBSNews.com