Equifax – A Cascade of Management Failures
[column width=”1/1″ last=”true” title=”” title_type=”single” animation=”none” implicit=”true”]
It is amazing that a company the size of Equifax (EFX) can do so many things wrong in a row. This is a well established, global company that is headquartered right here in Atlanta with approximately 9,900 employees worldwide. Since the breach, their market cap as plummeted from $17.7 billion to $13.3 billion. They lost 25% of their market value or $4.3 billion in the blink of an eye!
Here is the chain of failures that could have been handled much better.
Domino 1: A data breach occurred where hackers found a way into the system. This alone is a potential brand destroying domino.
Domino 2: Equifax won’t come forward with specifics on the exact nature of the breach. They are blaming the use of open-source software, particularly a package from the Apache Project named Struts. Struts is an open-source project that allows developers to greatly accelerate value creation by providing them with ready-to-use, off-the-shelf, modules that have been improved and hardened by thousands of independent developers world-wide. Here is Apache’s side of the story. In a nutshell, Apache says that when breaches occur, they work swiftly to replicate and patch the error. It may have been a “zero-day” exploit (meaning no one knew the bug until the hacker found it and exploited it on the spot), but the more likely explanation is the Equifax development team did not have an adequate process to immediately patch their servers as new software patches are released.
Domino 3: Senior executives sold large blocks of stock after the breach occurred but before it was made known to the public. Not much to say here. Did the executives use inside information? Time will tell. This points to a larger problem in the ranks of senior management. A cancer in the culture that needs to be removed immediately.
Domino 4: Lack of a game plan for this type of brand damaging scenario. This is where it really gets interesting. They secured a site called www.equifaxsecurity2017.com Really? Hahahaha! Is it just me, or does that look like a hacker site just waiting for someone to steal your personal info? Why not something like www.equifax.com/security-breach-2017 ? That would put it in the trusted security zone of the top level domain (TLD). Then they asked for the last 6 digits of a social security number and a last name. You can’t make this stuff up!
Domino 5: When a scared consumer entered their last 6 digits and last name to find out if they were part of the breach, they had to click on a legal agreement stating they wouldn’t sue Equifax. No, they really did!!
Domino 6: It took senior management well over 60 hours to come up with a response that should have come within 24 hours or less of this breach occurring. They have now switched the equifaxsecurity2017.com site to a war-room status update page to let worried customers know the progress that is being made to rectify the problem. But it’s still on an external domain. Google can find any site these days. A unique TLD is not necessary. A trusted TLD is necessary.
Here is a game plan for prevention:
#1: Hold your development team accountable for all security patches and agree to a maximum service level agreement (SLA) for the implementation of security patches after they are released by the originator. It doesn’t matter if it’s open-source software or vendor software. (The US Government is a strong backer of open-source software primarily due to the ability to harden the software against security vulnerabilities.) When the business team and the development team agree to the future work to be done (roadmap, agile cycle, etc.), patching and maintenance of the underlying software systems should be integral to that conversation and should be adequately funded and staffed.
#2: Have a contingency plan in place for security breaches that can be executed without much thought. Speed is the essence! This plan should be detailed and should be jointly agreed to by the development team, the marketing/branding team(s), and general counsel. It’s basically a disaster recovery plan. This is a disaster, correct?
In this particular instance, a dual-path should have been pursued where the development team immediately reported the breach and the details of the breach with the Apache Struts community and worked towards a software fix. (There are many other remediations that the development team should pursue that I will leave out of this discussion for sake of simplicity). The marketing/branding path should have set up a channel to calm customers fears in a way that didn’t add insult to injury in a non-trusted way. If the marketing and legal team had played this scenario out before a breach, I don’t believe it would have been as badly handled.
Clients rely on me to transform their technology from a growth inhibitor into a growth accelerator.
© Mark Travis – All Rights Reserved http://www.travis-company.com
[/column]