by Bharat Mistry
No organisation is breach-proof: we all know that the odds are stacked too high in the attackers’ favour. However, by following industry best practices we can make it as difficult as possible for hackers, and discourage all but the most determined and well resourced. That’s why it will dismay many in the industry to learn that Equifax knew about the vulnerability that it claims led to a massive breach at the firm this year, all the way back in March. However, it was apparently only fully patched months later once the damage had been done.
Given the scale of the breach, and the fact the firm could have been hit with fines of over $60m under the forthcoming GDPR regime, this should serve as yet another cautionary tale to IT leaders. Best practice security, including effective patch management, is called “best practice” for a reason.
In a lengthy update on Friday, Equifax revealed that the attackers exploited a vulnerability in an Apache Struts web server (CVE-2017-5638) running its online dispute portal web application. This led to a breach of sensitive PII related to 143 million Americans, as well as 400,000 Brits, from May 13 to July 30, 2017.
However, the credit reporting agency goes on to say the following:
“The particular vulnerability in Apache Struts was identified and disclosed by US 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.”
In fact, the vulnerability appears not to have been patched at that time – at least not effectively – because Equifax claimed it took the offending app offline on July 30 after identifying suspicious network traffic.
“The company’s internal review of the incident continued. 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.”
It’s not clear exactly why the security team didn’t fix the vulnerability in question back in March, but it certainly seems as if its patch management programme was not fit-for-purpose.
We can’t overstate the importance of automated patch management tools, based on a comprehensive and well-thought out policy. Yes, sometimes it can be challenging for firms to patch promptly, especially on mission critical systems where fixes need to be tested first. But that’s where virtual patching comes in; allowing organisations to protect key systems while this sometimes lengthy process can be completed. Virtual patching also works in the same way to keep no-longer-supported systems safe.
Effective patch management should go alongside incident response; strict access controls; end user education; and continuous monitoring as part of a best practice cybersecurity strategy.
GDPR looms large
The fall-out for Equifax has already been huge. There’s a criminal investigation underway into the breach; the firm’s share price has fallen by more than a third since the breach was revealed; its CIO and CSO have retired; and class action suits have been filed. The long-term impact on customer confidence in its brand could be significant.
However, things could have been much worse had the incident occurred after the European General Data Protection Regulation (GDPR) comes into force next May. It’s likely regulators would have taken a dim view of the events which led to a known vulnerability being left open to exploitation for months, resulting in a major breach of PII for hundreds of thousands of Europeans.
To make matters worse, Equifax failed to notify for over a month. This alone could have resulted in a maximum fine of 2% of global annual turnover; around $63m based on 2016 figures. Although it wasn’t required to notify within 72-hours, as the GDPR demands, Equifax and other firms like it will certainly need to get their act together before May 2018 if they want to avoid the scrutiny of regulators.
While the firm is keen to stress that “the company’s review of the facts is still ongoing”, it’s clear that something went seriously wrong: perhaps internal policies weren’t fit for purpose, or they weren’t implemented correctly. Either way, it should be cause for IT security leaders to reassess their own policies and security controls to ensure they stand up to scrutiny – because after 25 May 2018, a lot more could be at stake.