Equifax and Struts: An Ounce of Prevention Is Worth a Pound of Cure

DZone 's Guide to

Equifax and Struts: An Ounce of Prevention Is Worth a Pound of Cure

Now that we've had a little while to digest what happened, we take a look at what Equifax could have done to prevent its massive data breach.

· Security Zone ·
Free Resource

A few weeks ago, Equifax announced that it had suffered a massive security breach that exposed Social Security numbers and addresses, of up to 143 million Americans and 40 million more people in the UK. Equifax said the breach happened between mid-May and July 2017. It discovered the hack on July 29. It informed the public on September 7.

We're all human. Modern IT organizations make mistakes. Not one of them is perfect.

Inevitably, s!*& happens. And when it does, the one characteristic that separates the best from the rest is having the discipline and courage to stop and ask a simple question:

"What could we have done different to prevent this from happening?"

Up until recently, many in the software industry were speculating on what happened. Many pointed to evidence suggesting the Equifax breach was the result of a previously disclosed vulnerability in Struts. Others speculated that it might have been a zero-day vulnerability. Truth be told -- no one knew for certain.

However, Equifax publicly disclosed that the breach was, in fact, a remote code exploit targeting a known vulnerable version of Struts (CVE-2017-5638) utilized in one of their production web applications.

When did Equifax, and the rest of the world, learn about the vulnerability? In March (six long months ago) when the Apache Struts team disclosed it and provided a free patch -- which, if applied, would fix the vulnerability.

So the billion dollar question is begged. What, if anything, could Equifax have done differently to prevent the Struts breach from happening?

Some people might suggest that they could have used a different model view controller (MVC) framework other than Struts, perhaps Spring, Turbine, or Tapestry. But even if Equifax had used a different open source MVC framework the reality is that vulnerabilities in open source projects are commonly identified and publicly disclosed by the respective project team, including specific instructions on how to fix the defect. Are other MVCs any more secure than Struts? Is this even the right question to be asking? Probably not.

You see, when it comes to open source software development, quality, security, and velocity are directly proportional to your ability to continuously manage the entire software supply chain from end-to-end.

In today's world, top performing development organizations not only automate open source hygiene within the SDLC -- but they also automate open source hygiene in production applications by remediating defects at the time of disclosure.

So, what could have Equifax done differently to prevent this breach?

Utilize a different MVC controller? Maybe.

Remediate CVE-2017-5638 in March at the time that it was originally disclosed? Definitely!

devsecops ,equifax ,open source security ,security ,struts

Published at DZone with permission of Matt Howard , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}