@iced wrote:
My comment is aimed at the oversimplification that people outside of the issue make toward security breaches, often trying to make things out like it was a simple, simple fix that even a third grader would have known to do. While there are instances where this ends up being the case, in the vast majority of the security incidents, it's not so simple.
In this case, it was a simple fix.
"On March 7, the Apache Software Foundation released a patch for the vulnerabilities; on March 9, Equifax administrators were told to apply the patch to any affected systems, but the employee who should have done so didn't."
We don't know how their sensitive data is/was stored, but the probability is extremely high that EaR is already being done. The data they store falls under multiple regulations, some of which already requires EaR. We don't know in what form the breached data was stored
Yes we do: "When asked specifically whether Equifax had encrypted its databases or not, Smith [Richard Smith, Equifax’s then CEO] responded by saying “We use many techniques to protect data: encryption, tokenization, masking, encryption in motion, encrypting at rest. To be very specific, this data was not encrypted at rest.”
. We do know the attackers exploited CVE2017-5638 to get at the data, which as I'm sure you know means they exploited a web application framework associated with their U.S. online dispute portal (Apache Struts) to execute commands/code of their choice. If this particular instance had the appropriate privileges to access data, it likely did so using whatever API keys or service account access it had been granted to do its day-to-day application functions, which would have completely sidestepped EaR anyway. We also know the hackers did not access the data from Equifax’s core consumer credit reporting databases.
One could argue a CASB or CASB-esque solution might (and that's a big might) have been effective, but again unless someone on this thread works for Equifax and chose to breach confidentiality to share further technical details not publicly known, we're just spitballing solutions. At any rate, reducing this issue to something trivial and simple like enabling encryption is armchair quarterbacking.
To be clear, there was a failure of some process or of the leadership at Equifax that resulted in a known vulnerability continuing to be exposed between the vulnerability's publication in March and the beginning of the data breach period in May, and to the extent we'll ever see they are being held accountable for that failure.
But that's a lot less interesting thinking 100+ million identities were breached because someone didn't enable BitLocker. Indeed, in today's social media world everyone's an expert.
It's not as simple as just using hardware encryption. But I do know for certain that if someone gains physical access to our site and steals a 42U rack of drives, the data is going to be useless to them.
I'm a severely overworked and underpaid (by choice for equity stake) senior software developer that has to handle Office365, Azure devops, and general Azure Admin tasks all by myself at the moment. There is no way I can keep up with the security side, so I rely on Azure Security Center for the vuln monitoring. I use things like Tripwire on my development machines at work and at home. I don't even browse the net on my dev machines. We hire experienced people for pen testing. I try to keep up with the latest in IOT security, both in general and with Azure.
No one can keep up with a highly focused group of state actors that do nothing but pen testing all day for fun. I think we all just need to assume that our systems are going to be breached and plan accordingly. Equifax clearly was not doing that in 2017, and at least some of it was really simple.
