I was/am interested into the whole Equifax hack and how this happened. To this end I posted a
brief link yesterday to the Struts teams response. A simple case of failing to patch! Case closed..
But then I've been thinking that's not really very fair.
This was (apparently) caused by a defect that's been around for a long time. The developers had reacted very quickly when the problem was identified (within 24 hrs) but Equifax - by all accounts - had failed to patch for a further 6 months.
What did we expect? That they'd patch it the next day? No chance. Within a month? Maybe. But if the issue is embedded in some third party product then they're dependent upon a fix being provided and if it's in some in-house developed tool then they need to be able to rebuild the app and test it before they can deploy. Struts was/is extremely popular. It was the Spring of its day and is still deeply embedded in all sorts of corporate applications and off the shelf products. Fixing everything isn't going to happen overnight.
Companies like Equifax will also have hundreds, even thousands, of applications and each application will have dozens of dependencies any one of which could have suffered a similar issue. On top of this, most of these applications will be minor, non critical tools which have been around for many years and which frankly few will care about. Running a programme to track all of these dependencies, patch applications and test them all before rolling them into production would take an army of developers, testers, sys-ops and administrators working around the clock just to tread water. New features? Forget it. Zero-day? Shuffles shoes... Mind you, it'd be amusing to see how change management would handle this...
So we focus on the priority applications and the low hanging fruit of patching (OS etc.) and hope that's good enough? Humm... anything else we can do?
Well, we're getting better with build, test and deployment automation but we're a long way from perfection. So do some of that, it'll make dealing with change all the easier but its no silver bullet. And again, good luck with change management...
Ultimately though we have to assume we're not going to have perfect code (there's no such thing!)... that we're not able to patch against every vulnerability... and that zero day exploits are a real risk.
Other measures are required regardless of your patching strategy. Reverse proxies, security filters, firewalls, intrusion detection, n-tier architectures, heterogenous software stacks, encryption, pen-testing etc. Security is like layers of swiss-cheese - no single layer will ever be perfect, you just hope the holes don't line up when you stack them all together. Add to this some decent monitoring of traffic and an understanding of norms and patterns - at least something which you actually have people looking at continually rather than
after the event - and you stand a chance of protecting yourself against such issues, or able to identify potential attacks before they become actual breaches.
Equifax may have failed to patch some Struts defect for six months but that's not the worst of it. That they were vulnerable to such a defect in the first place smells like.. well, like they didn't have enough swiss-cheese. That an
employee tool was also accessible online and provided access to customer information with admin/admin credentials goes on to suggests a real lack of competency and recklessness at senior levels.
Adding insult to injury, to blame an open-source project (for the wrong defect!) which heroically responded and addressed the real issue within 24 hrs of it being identified six month earlier (!?) makes Equifax look like an irresponsible child. Always blaming someone else for their reckless actions.
They claim to be
"an innovative global information solutions company". So innovative they're bleeding edge and giving their,
no our!, data away. I'm just not sure who's the bigger criminal... the hackers or Equifarce!
