What the Equifax Hack Tells Us About Cybersecurity – Linux Security Podcast Ep. 6
The Equifax data breach quickly arose to become one of the most notorious in history. It was large. Over 147 million people had their financial records exposed to hackers. At least as of March 2018 that was the number. It has been revised upward a number of times and there could be more. The breach was also severe in data terms because it exposed information about individual’s names, birth dates, addresses, driver license numbers and the kicker, social security numbers. All of the information needed to commit financial fraud via identity theft was stolen in a single breach.
Everyone agrees this was a bad breach. However, that is only part of the story. The audit of the Equifax breach revealed that the point of entry was a known vulnerability in Apache Struts. It was a vulnerability that even Atomicorp’s free WAF product protected against and there was a published patch that Equifax had installed…on all but one server. Bad luck? Maybe. The story continues.
Blame it On the Engineer?
Equifax’s CEO then goes before U.S. Congress and says the entire breach was the fault of a single engineer that inadvertently missed installing the Apache Struts patch on a single server. Everyone needs a scapegoat when the sh*! hits the fan. Atomicorp Mike Shinn says, “not so fast.” He knows this vulnerability intimately since he wrote the original Modsecurity WAF rule to protect against it years ago. The real culprit is a cybersecurity approach overly reliant on patching. Patches always arrive after vulnerabilities exist, so it is only a matter of time before every patching-centric enterprise is exposed. Mike breaks down the Equifax hack, how the breach was conducted and the risks of patching culture in this week’s Linux Security Podcast.