Lessons Learned from the Equifax Disaster

143 million U.S. consumers, Equifax.com users who may have been affected by the the worst data breach in history are receiving all sorts of advice (including a free TrustedID product license from Equifax). But despite numerous public reports about the incident, there are still many important questions left unanswered. Among the most important ones: how do we minimize the risk of similar incidents in the future?


Let’s take a closer look at what we know about the mechanics of the incident, and what we can deduce using this knowledge.

Based on the publicly available information, it looks like the criminals exploited a Web Application vulnerability on one of Equifax’s servers. This also means that the hackers could have used an SQL-injection, which gave them access to the database. Another possibility is that they exploited an arbitrary code execution vulnerability, which gave them a direct access to the server and from there, to the database. Some sources like Quartz say that the Apache Struts vulnerability was a reason of this incident. Recently Apache Struts team published an open letter with an explanation of the nature of this issue, and a few practical recommendations.

Moreover, according to our analysis of an Apache Struts vulnerabilities published earlier this year we predicted a new critical issue in the OGNL framework and even proposed a specific signature against it.

If you are unable to update Struts2 immediately you should apply virtual patch to your WAF. It’s essentially similar to the previous OGNL exploits however it’s likely to not be covered by many existing WAF signatures.

Considering that the attackers remained undetected for two months, they could have implement any of these methods in such a long period of time. By the way, this also suggests that the Equifax cyber-security team was not really using proactive security filters, such as a NIDS/NIPS (Network Based IPS/IDS)/ WAF (Web Application Firewall) — which is incomprehensible for an organization of this size.

Equifax is technically PCI DSS compliant and even a member of the PCI Security Standards Council program, which means that regular penetration tests or a Web Application Firewall should have been implemented in the development cycle. Based on our experience, we can also say that such a long reaction time indicates that nobody analysed the events from the WAF because of the high false positive rate. The high false positive rate is a common problem in legacy signature-based WAFs, which is why most of them are used in monitor-only mode and do not block active attacks, which makes it nearly impossible for the security teams to address incidents of this nature.

If proper security measures and solutions were in place, the attackers would have never been able to maintain this intrusion for such a long period of time undetected.

Based on what we know from public sources, we can suggest that the attackers were discovered at the post-exploitation phase when they decided to go even deeper inside the Equifax IT infrastructure after dumping the database. Technically it means that the security architecture failed not only the network-based prevention goal at the NIDS/NIPS/WAF layer but also the host-based intrusion prevention goal at the HIPS/NGAV/AV layer, as well as at the data protection layer. Good application and data partitioning practices would have called for access control separations and alerts on excessive data accesses. The attackers have stayed undetected for about 8 weeks avoiding detection by whatever security tools were in place. Most likely they would have not gotten caught for even longer if not for their own carelessness or overconfidence while breaking some of the application stack components.

According to Equifax, upon detecting the breach they immediately contacted law enforcement and hired an independent cyber-security firm to investigate the incident. I can only hope that this firm (or any other, really) will also conduct a very thorough audit of Equifax’s cyber security systems and policies, including their data handling practices.

To prevent problems of this nature in other organizations, teams should ensure the effectiveness of their network, host and data security architecture as follows:

  • Network layer should have the following controls: firewalls, network-based IDS / IPS and adaptive WAF.
  • Host layer should be protected by HIPS / HIDS and AV.
  • Data protection layer should include data partitioning, encryption and access controls.
  • Operational processes (DevOps and SecOps) should be in place and tested regularly for the team to act on the information received from all these security tools.

However, the biggest lesson we all have (hopefully) learnt from this incident is not really related to technology, cyber-security, or formal compliance required by law (which I am sure was taken care of at Equifax), but about taking the moral responsibility for consumers’ personal data and, in many cases, their very livelihoods, and then neglecting to take proper care of it. Every security professional knows that cyber incidents are sometimes inevitable, but neglect and shabbiness are not, and should never happen at this scale again.

Leave a Reply

Show Buttons
Hide Buttons