The Equifax hack is spectacular in many ways and is forcing serious introspection on the part of developers and security managers. The current culprit is an Apache Struts Vulnerability that was reported (and fixed) in March 2017 but apparently the patch was not applied on the Equifax website.
As you’d expect, a lot of people are up in arms, dusting off their soap boxes to stand on and explain how unacceptable that is and how someone needs to be gallows bound!
Not an exception
Having, in a previous life, performed basic online vulnerability audits for some big companies, I can attest that this is far from being the exception and that most people in charge feel more comfortable in a « plausible deniability » situation than in seeking to eliminate all risks.
According to the US Computer Security Resource Center’s National Vulnerability Database, there are 2872 new high severity vulnerabilities in 2017 so far.
Hackers have mastered the art of automatically scanning for online systems that still have them and either extracting monetizable data or enrolling them in DDoS farms and other malicious purposes.
Firewalls may just provide a false sense of security and in the case of the Equifax breach, the traffic looked perfectly legit to the firewall!
As a matter of fact, this morning the customer web sites of Equifax and Experian, its main competitor, still fail on 3 security factors according to upguard.com!
Only the paranoid survive
Truth is that if you’re a developer or an IT manager, you get more recognition for adding a new system or new features to existing ones than avoiding an attack. There is nothing more unspectacular than a non-attack! Yet if and when one happens, you would be on the receiving end of blame and people will find it easy to point out very simple things you could have done and ask why you didn’t do them!
In fact most people in charge, are scared to break the system if they upgrade a component in order to deal with a vulnerability threat. In an ideal world, they would like to be able to retest everything before going live but because of tight schedules and limited testing resources, they will arbitrage against a security patch. Moreover, because often the components that need patching are part of some lower infrastructure software layer, only few people can perform an accurate impact analysis.
In addition to dedicated teams and efforts, managers should create incentive schemes that reward the security mindfulness of their IT teams and instill awareness and practices based on peer and external reviews.