Communicating with Customers in the Event of a Breach

Dec 30, 2019

There are three phases of defending against cyber attacks: putting in place sufficient protections and robust authentication mechanisms to try and prevent attacks; appropriately defending against an active attack once it is discovered, and communicating accurately and effectively to customers and shareholders:

  • What happened
  • Why it happened
  • What it means

Let’s examine a major retailer’s response to a recent attack for insights on effective approaches to communication with affected customers.

In a letter to customers, the retailer identified the confidential and highly-sensitive information that was exposed: First name; last name; address (including city and state); phone number; email address; payment card number; payment card security code; and payment card month/year of expiration. In short, anything that the customer typed into the payment area of the site was potentially grabbed by the bad guys. The exposed information is more than enough to open almost any account with any business out there. The takeaway? Complete honesty with customers about the information that was exposed is essential when responding to a breach.

When a cyber thief breaks into a system and tries to capture everything, little will remain untouched. So, it’s critical to respond swiftly and appropriately.

There are three primary concerns to address:

1: The Clone Worries

First, the top concern today isn’t just that the bad guys will open new accounts with the stolen data — it’s also that they can create cloned cards with the data. 

In this particular breach, sufficient information was exposed to create cloned cards, which could be used to make lots of legitimate-looking purchases until someone shuts that number down. In a case like this, it’s necessary to alert the major card brands—Visa, Mastercard, American Express, Discover, etc.—to the numbers impacted so that those card details are shut down immediately. Don’t wait for the consumers to act, given how critical every minute is in closing the opportunity window for the thieves/cloners. And why place that burden on the consumers anyway?

Getting back to the cloned cards, EMV (which includes Chip and PIN, but is almost implemented in the U.S. as chip and nothing, especially for credit cards as opposed to debit cards) makes a cloned card far more difficult to create, but as long as merchants still accept payment using just the magstripe, cloned cards will still work fine. Thieves are dreading the day magstripe is fully phased out. Fear not, thieves. You still have lots of years left to rip off people.

In a situation like this, don’t promise customers that thieves will be unable to open new accounts or clone cards. If this eventually proves untrue, such promises could create additional liability issues.

2: Sufficient Protections

Let’s now get to that initial phase: “putting in place sufficient protections and robust authentication mechanisms to try and prevent attacks.”

The attackers, in this case, appear to have installed malware on the retailer’s main site, along with a couple of key payments/checkout pages, which sent almost all information shoppers sent to those pages to a site controlled by the bad guys. Interestingly, the malware script only exfiltrated the data when payment data was keyed in and a “place order” button was clicked. That’s an intriguing limitation, given that presumably few shoppers would bother to key in sensitive payment data if they were not quite confident they were placing an order.

It’s important to communicate to customers the steps taken to mitigate the attack and to prevent such attacks from occurring in the future. It may be challenging to address these questions because doing so can raise additional questions – the obvious one being, “why weren’t these protections in place before the attack?” But customers need to trust your commitment to the security of their information before they will be willing to again entrust you with their sensitive data.

3: Zero Liability Hurting more than Helping

But more substantively, this all speaks to the purpose of such a letter. It’s supposed to be an explanation for what happened, why it happened and specifically how the retailer will prevent it. Unless you provide the necessary specifics, a letter could do little more than worry customers and make them more inclined to take their business elsewhere. 

As a practical matter, the card brands’ zero liability program—which limits and typically prevents consumer fraud victims from paying anything—has the unintended effect of making retailers less secure. That’s because it limits the ROI for a retailer to make major investments in security. If customers don’t lose anything, they will typically not abandon the retailer. 

If they stick with the retailer, little to no revenue/net income will be impacted, which means little to no Wall Street stock punishment. That, in turn, makes it next-to-impossible for CFOs to justify major security investments.

Ah, the law of unintended consequences comes home to roost.

What to do?

Businesses–and their lawyers–must take disclosure letters extremely seriously. If for no other reason, they need to take such documents seriously because they will rematerialize months or a year later as Plaintiffs Exhibit A. How likely is a class action lawsuit? Send official letters to customers, where the customer will perceive that they are being misled, and the likelihood of class-action increases significantly.

Be completely honest with customers about the data exposed and the actions taken to prevent future breaches, but don’t over-promise. Breach notification letters are not where you want to make claims that are not airtight, nor make promises that you aren’t certain you can deliver.

Concerned about security breaches in your applications? 

Get Your FREE Demo of Kiuwan Application Security Today!

Identify and remediate vulnerabilities with fast and efficient scanning and reporting. We are compliant with all security standards and offer tailored packages to mitigate your cyber risk within the SDLC.

Related Posts