The Equifax data breach: a case study on how NOT to handle a breach

By now we all have heard and read about the Equifax data breach, that has exposed the personal details and credit record of 143 Million Americans; that’s nearly 44% of the U.S. population.

While we are now used to hearing much larger breach numbers, e.g. 500 million from Yahoo, what is devastating about this breach is that it gives the hackers all that they need to commit identity and financial fraud. There’s not much the victims can do to mitigate the risk, other than credit monitoring, since you can’t really change your name, SSN, date of birth etc.

Even as details are awaited on the mechanics and timelines of the infiltration and breach, today I want to focus on the way Equifax handled the breach – in all the wrong ways.

Here are some major things that Equifax handled wrongly or inadequately: 

1. They waited too long to disclose the breach to the victims whose data was compromised. By accounts read so far, the breach was discovered on July 29th and they waited (it is unclear why) for six weeks before announcing it publicly on September 7th. This delay gave enough time for the hackers to sell the information to other bad actors on dark web and they in turn would have been misusing this information with impunity.
2. They launched a breach response site – https://www.equifaxsecurity2017.com/– that was hosted on a newly registered domain (not on their primary domain). This caused confusion among the victims looking to find out the extent of damage and remedial steps. It also exposed the victims to potential phishing attempts by sites that could have been put up with similar words or typos as the legitimate new domain.
3. The breach response site used a free Cloudflare ssl certificate instead of an EV certificate. In a time of crisis, when the victims are looking for safety and security assurances, they should be provided critical next-steps information via a highly secure site. Equifax should have used an Extended Validation (EV) certificate for this site. This requires time due to the due-diligence involved on part of the CA and hence should be something prepared in advance and ideally be a sub-domain of the main site.
4. There were reports of long hold times when people called the helpline Equifax provided. And when folks finally go through, the CSRs were found to be an outsourced company who had just been brought on-board and were not in a position to give either account specific or any other kind of tangible help, other than directing people to the breach response website.
5. If victims discovered from the breach response site that their data was compromised, they were invited to sign up for Equifax’s “TrustedID Premier” credit monitoring service. In the TOS of this service there was a clause that said subscribers give up their right to sue Equifax via a class action suit. This is bad at so many levels that I don’t think needs elaborating.
6. One of the first steps victims of a data breach are asked to do is freeze their credit so someone cannot open new accounts with their identities. This process typically uses PINs that can be used to freeze or unfreeze credit as needed. These PINs should be unique, random and unguessable. Turns out Equifax site was simply using the timestamp (when someone signs up for the freeze) as the PIN. This is such an elementary security mistake that it casts a serious doubt on the credibility of the entire service. To make matters worse, this flaw had been reported to Equifax a year ago.

So what can CEOs/CIOs/CSOs learn from this debacle?

I recommend the following takeaways:

1. Prepare for the breach. Number of data breach incidents are setting new records, already up 37% over last year. So the likelihood of a breach at your enterprise is very real and you must prepare for that event. You must have people, processes and documentation in place and conduct drills for the breach event.
2. Have a breach response sub-domain ready. During normal times, you could pre-populate it with proactive security information and best practices for your customers. Turn the home page into a breach response guide when the time comes. Avoid using a new domain as it would open your customer to potential phishing attacks.
3. Use Extended Validation (EV) certificate on this breach response site. This is a time when you want to convey a message of confidence and stability to your customers, besides providing them a safe and secure method for finding out if and how they are affected and what actions they can take. Using an EV is much more reassuring and secure, as compared to using standard certificates or free certificates generated by the likes of CDN services.
4. Have a vendor selected for handling the customer queries that will come in the event of a breach. They should be able to handle queries via phone, Twitter, Facebook, and email. You must have a detailed breach response guide and FAQs ready to bring your vendor’s (or your internal) CSRs on-board with accurate, up-to-date and helpful information for your customers. This information should be detailed, actionable and must cover both standard and non-standard situations.

Update: By the time I got around to posting this, I see that Equifax has corrected most of the critical issues I mention above. Kudos to them for reacting quickly to fix these issues in a matter of days.

The lessons highlighted above will still help other enterprises avoid the kind of bad PR and negative market reaction that Equifax had to face.

We would love to hear from you, in the comments, your thoughts on this breach or in general about the best practices in handling data breaches.