The Whole Story? Understanding the Causes of the Equifax Hack, Part 2

Last week, we talked about how every major hack comes with its own narrative. In outlining the Equifax hack narrative, I left out a key point – patch your servers. While it sounds like a simple solution, there’s more to it than meets the eye.

A keyboard in a dark room with red and blue reflectionsLast week, we talked about how every major hack comes with its own narrative. And I outlined the six parts of the Equifax narrative. But now, let’s take a closer look at that missing seventh part – patch your servers. While it sounds like a simple solution, there’s more to it than meets the eye.

I understand, in some ways, why the Apache Struts problem wasn’t patched quickly. Most production systems in major companies have tons of custom code to handle transactions and make the business possible. You can’t just quickly patch a system and hope that it doesn’t break all of that custom code.

The Challenges of Patching Custom Code

In speaking with two different cybersecurity professionals, they’ve explained that it’s not exactly simple to apply a patch to a web server. One oversees 40,000 endpoints and hundreds of web servers for the State of Washington (United States). The other works for the UK Office for Nuclear Regulation.

They’ve both experienced a simple web server patch taking months to properly implement. Why? Because all of that custom code takes hundreds, if not thousands, of project hours to create. That custom code is written for a specific implementation of that web server, and it relies on libraries and APIs that can’t simply be changed willy nilly.

It wouldn’t do much good to patch a web server to handle one problem (e.g., the Apache Struts vulnerability), only to introduce hundreds of additional errors due to the presence of custom code. So, I’m not going to pull out the “Gee, all they needed to do was patch the server” card. That’s not a good way to understand the underlying problems, here.

The Dog Ate My Homework

The Equifax hack is so interesting, mostly because their response to the hack has been so poor. Equifax blames the massive data leak on open-source software. Given the speed at which developers need to produce software these days, they're using more third-party components, libraries and other building blocks. So, it’s easy to blame the software, especially if you don’t have a good response ready.

Blaming a hack on any sort of software issue – open source or proprietary – is simply part of the inadequate response. It’s kind of like hearing a student say, “The dog ate my homework” to her teacher. Somehow, I can’t help but think of someone at Equifax saying to a reporter, “Our dog software revealed 143 million accounts. Not our fault.” That’s not much of a response or explanation, especially considering that Equifax disclosed this problem on September 7 after knowing about it since July 29.

Let me emphasize my point: I find it fascinating that the Equifax folks have created a new type of zero-day attack. How? Well, with a traditional zero-day attack, hackers are able to exploit a software flaw because they have discovered the flaw before anyone else, even the vendor who created it. But in this case, the Apache Struts problem was known in March of this year. So, the Equifax attack doesn’t count as a classic zero-day attack. Yet, in some ways, it does. Instead of quickly disclosing the issue, Equifax waited for over a month to disclose the problem. As a result, millions of individuals were further victimized because the hackers were able to exploit the information they gained for over a month. In a sense, Equifax’s improper response has sucker-punched up to 143 million people, who were vulnerable to identity theft attacks for over a month without their knowledge.

I have it on pretty good authority that the security team at Equifax has done some terrific work, actually. Many of them have left recently, but the Equifax security folks were considered a top team. In this case, I can’t help but think that the security team wasn’t able to function properly because someone wasn’t able to make the proper ROI argument stick at some point with management when it was time to review and/or monitor software implementations.

Lots to think about, huh? Let’s continue this discussion on Twitter – contact me @jamesstanger.

Do you have the skills to protect your organization from its next attack? Check out CompTIA Cybersecurity Analyst (CySA+) to validate those skills and keep them up to date.

Email us at blogeditor@comptia.org for inquiries related to contributed articles, link building and other web content needs.

Read More from the CompTIA Blog

Leave a Comment