One of the most common questions raised after the recent Equifax breach was “Why wasn’t the Apache Struts 2 vulnerability patched?” The vulnerability issue was widely reported in March 2017, many months before the breach was disclosed.
If you read the security statement issued by Equifax, the company says (emphasis mine):
-
“Specific Details of Incident:
- Upon discovering a vulnerability in the Apache Struts web application framework as the initial attack vector, Equifax patched the affected web application before bringing it back online.”
-
“Questions Regarding Apache Struts:
- The particular vulnerability in Apache Struts was identified and disclosed by U.S. CERT in early March 2017.
- Equifax’s Security organization was aware of this vulnerability at that time, and took efforts to identify and to patch any vulnerable systems in the company’s IT infrastructure.”
These two statements seem to conflict. Either the Equifax team patched but perhaps didn’t validate that the fixes worked, or not all servers were identified and patched.
Why is this such a challenge? The reality is that some companies don’t have a proper application inventory and thus may not be aware of which vulnerabilities are applicable. If Equifax was using a vulnerability scanning platform that automatically looks for applications and newly reported vulnerabilities, perhaps an impacted server could not be patched right away. It may have been necessary to rewrite applications or update applications to ensure the patch didn’t break existing application.
The sad and inconvenient truth is that poor security hygiene is all too common because security teams have too much on their plate and are unsure what to prioritize. Additionally, as we pointed out in this recent blog, even a completely patched system is still vulnerable to attacks, so spending all your cycles patching doesn’t mean you’re secure.
Additionally, recent details on the breach by Ars Technica and Wall Street Journal outline that the hackers took measures once they had infiltrated to ensure they had a backdoor to Equifax even if the vulnerability was patched.
Three Data Breach Prevention Measures
The Google head of security Heather Adkins recently recommended that organizations hire junior security engineers to do nothing but perform patching. This is not viable — we don’t have enough cybersecurity talent today, and vulnerabilities are not the only techniques hackers use. Adkins correctly states that “The techniques haven’t changed. We’ve known about these kinds of attacks for a long time.”
There is a better way. Breach and attack simulation goes beyond security hygiene and actually visualizes the kill chain. It uses automation — an important weapon for security teams to optimize resources. It provides teams with an opportunity to understand their state of security continuously and automatically. And it challenges security controls with a myriad of attacker techniques.
Here are three data breach prevention measures based on our learnings from the Equifax Breach, and recommended best practices using breach and attack simulation:
(1) Continuously identify your weaknesses: In the Equifax breach, the team likely thought they had patched the Apache Struts2 vulnerability. Either they forgot a server, patched incorrectly, or perhaps a new server was spun up that no one knew about. Besides the patching issue, they also used a generic admin/admin user name and password. Meaning, several security weaknesses were not apparent to the team.
Breach and attack simulation enables you to simulate hacker breach methods continuously to ensure that security weaknesses you may not be aware of are identified. These may include exploits of vulnerabilities but also techniques like backdoor shells, credential escalation, brute force and others. You can quickly see via the “Risk Trend” dashboard if things are getting better or worse over time, as well if any new changes have introduced accidental paths for attack.
(2) Break the kill chain based on your strengths: In the Equifax case, we learned the attackers exploited Apache Struts2 and moved laterally to a part of the network that had critical information.
If you’ve deployed a breach and attack simulation platform, you’re already at an advantage because you’ve gained the perspective of your adversary. You can view—across the kill chain—the various ways an attack can infiltrate, move laterally to a deeper part of the network, and exfiltrate data out, allowing you to figure out the best way to break the kill chain. Perhaps start with segmentation to stop lateral movement? Or focus on stopping data exfiltration via data leakage prevention solutions? The good news is once you can see the kill chain, you can break it based on where you perceive your organization’s security strengths are– with appropriate compensating controls.
(3) Prioritize your vulnerabilities: By drilling down into each of the successful breach methods, you can tell that some of them are in fact associated with vulnerabilities. The example below shows the CVE-2014-0322 and CVE-2014-1776. This allows you to prioritize the right set of vulnerabilities that are important for your team to patch immediately because you can successfully show an attack path between two segments exploiting this vulnerability.
Every security team has blind spots in their defenses – places they thought were secure, but that attackers can still exploit. Without some kind of validation, security is only as good as the assumptions it was based on. Instead, using tools to actually validate security, using real attack techniques, can identify unknown weaknesses, eliminate assumptions, and ensure security is working as intended.