Former Equifax CEO Blames Breach On One Individual Who Failed To Deploy Patch (techcrunch.com)

Equifax's recently departed CEO is blaming the largest data breach in history on a single person who failed to deploy a patch. TechCrunch reports: Hackers exposed the Social Security numbers, drivers licenses and other sensitive info of 143 million Americans earlier this summer by exploiting a vulnerability in Apache's Struts software, according to testimony heard today from former CEO Richard Smith. However, a patch for that vulnerability had been available for months before the breach occurred. Now several top Equifax execs are being taken to task for failing to protect the information of millions of U.S. citizens. In a live stream before the Digital Commerce and Consumer Protection subcommittee of the House Energy and Commerce committee, Smith testified the Struts vulnerability had been discussed when it was first announced by CERT on March 8th.

Smith said when he started with Equifax 12 years ago there was no one in cybersecurity. The company has poured a quarter of a billion dollars into cybersecurity in the last three years and today boasts a 225 person team. However, Smith had an interesting explainer for how this easy fix slipped by 225 people's notice -- one person didn't do their job. "The human error was that the individual who's responsible for communicating in the organization to apply the patch, did not," Smith, who did not name this individual, told the committee.

Comments

huh?

[kefalonia]

bollocks. Yes, that.

Any security organization which relies on a single individual's action or inaction to remain in good standing is simply fairytale.
Every good process which involves a human in the loop, should always ensure that at least one more is present to enforce check-and-balance objectives.
There is a good reason why all commercial flights have two pilots as a default.

Let me state this: when you see management pointing one single downstream individual for such an event, there are at least TWO levels of management at fault.

Such BS

[gordona]

The buck stops with the CEO! If the CEO knew about vulnerability that needed patching, he should have been expecting a report regarding the application of the patch. If he didn't get that he should have come down on the admin or system owner for not installing it. Unless of course that wasn't in the security policy in which case it still falls on the back of the CEO. DUE CARE and DUE DILIGENCE! Non existent.

$225 million isn't much

[phalse phace]

The company has poured a quarter of a billion dollars into cybersecurity in the last three years and today boasts a 225 person team.

Spending $225 million over 3 years isn't really that much when you consider the type and amount of personal data Equifax has on us.

JP Morgan Chase spent $500 million in 2016 alone, Bank of America spent $400 million on cyber security in 2016 although they have an unlimited cyber security budget, Citibank's cyber security budget topped $400 million and Wells Fargo spends roughly $250 million per year.

Struts being an application framework...

[hattig]

Struts is an application framework, which means it is an application dependency. That means that every Struts-using application within Equifax would have needed to be upgraded, to be tested at least on the new version. That is the job of more than one person!

It is possible that Equifax's application servers (Tomcat, JBoss, etc) were configured with Struts being provided at the container level, but even that would be a full upgrade of multiple application servers within the company - a platforms team responsibility. However I suspect Struts would have been incorporated into the application itself at build time (as a dependency library).

I do not know how many applications Equifax's systems are made up of, but certainly the company I work for has dozens or hundreds to build up a trading platform (or two or three!). I imagine it is similar at Equifax.

I also cannot imagine a security team of 225 people having just one person be responsible to notifying and reminding of critical library vulnerabilities and updates for the entire business.

This smells of "VW Single Rogue Engineer" to me. Clearly bullshit.

Re:I smell bullshit.

[dszd0g]

It's either utter incompetence or bullshit.

At the enterprise level and especially for PCI compliance there should be 3 independent levels where this could have been caught: 1) applying the patch, 2) monitoring patch compliance, 3) vulnerability scanning. Organizations that really care about security also have a Web Application Firewall (WAF) or other Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) which would have been a fourth level that could have prevented this attack.

Blaming this attack on one person when there should have at least been 3 levels of prevention with at least 3 different teams involved is stupid.

1) Patch Management Solution: In the enterprise, this should be a software solution (like Quest KACE or IBM BigFix type solutions) that monitor the patches on each endpoint and apply patches on a schedule after they are tested. Most organizations have a 30 day patch cycle although critical remote vulnerabilities like this should have been escalated sooner.

What would have been reasonably possible is for the person responsible for escalating the patch to apply sooner than 30 days could have missed escalating it. However, the normal 30 day cycle then should have caught it.

a) Patch application
b) Patch monitoring

In some organizations there is one team that applies the patches (and is usually involved in testing the upcoming patches) another team that monitors the patch levels. In other organizations they are the same team although there should still be independent checks for application and monitoring.

2) Vulnerability Scanning: Especially anything that is visible to the Internet should get vulnerability scanned at least every 30 days. A decent remote vulnerability scanning software should have picked this up. Tenable's Nessus which is one of the industry standard vulnerability scanners tests for CVE-2017-5638 which is the vulnerability that effected Equifax. Nessus started testing for it on March 14th.

3) Web Application Firewall: Web Application Firewalls will block known attacks before they hit the application. A decent WAF should block known vulnerabilities such as the one that hit Equifax as long as it was up to date. That said a lot of companies I have worked with tend to run WAFs in intrusion detection mode instead of intrusion prevention mode due to false positives and not wanting to block legitimate traffic. Some companies I have worked with are much better than others at going through the alarms, how quickly they respond to alarms, and filtering out the false positives so that the alarms are easier to manage. Usually for Web applications you will have a WAF rather than a general purpose IDS/IPS as the WAF will have access to the unencrypted traffic although there are ways to have IDS/IPS products have access to the Web server private certificates to decrypt the traffic.