The Equifax Security Breach and What It Means for You and Your Cloud Provider

Home » Blog » The Equifax Security Breach and What It Means for You and Your Cloud Provider

It’s been almost a month since Equifax revealed on Sept 7th the 4th largest security breach of the 21st century so far. This time it’s huge, with personal information including social insurance numbers, birthdates, addresses and sometimes driver’s license numbers of over 143 million customers at risk. Equifax customers in the UK as well about 100,000 Canadian customers were also impacted. In addition, about 209,000 customers had credit card numbers exposed. Not only that but the Equifax CIO, CSO and CEO have been fired because of it. What lessons can be learned from this breach, both for your own IT shop and/or your cloud provider?

Equifax Inc. is a consumer credit reporting agency which collects and aggregates information on over 800 million individual consumers and more than 88 million businesses worldwide. It is the oldest of the big 3 credit agencies which include Experian and TransUnion.  Aside from offering credit and demographic related data and services to business it also sells credit monitoring and fraud-prevention services directly to consumers. So how did this breach occur to a company who should be on top of data security and fraud prevention?

The breach occurred back in mid to late May 2017 through vulnerability in Apache Struts. Apache Struts is a popular web application development framework for developing JAVA EE web apps. The remote code execution (RCE) vulnerability CVE-2017-9805 allows an attacker to run code on any server running an application using the Struts framework and the REST communications plugin. It can be fired off through a malicious XML file.

Here is the first lesson, stay current with patches. A patch was available from Apache in March for the vulnerability, so Equifax had more than two months to apply the patch and take precautions, to protect the data of over 143 million customers. They failed. According to Rene Gielen the VP of Apache Struts, “Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years.” You must keep on top of patches, whether they are for Microsoft Windows, Apache servers or IBM i or AIX. Currency is safety.

The second lesson is to have a proper well planned and timely response procedure. Equifax did not release the fact that a breach had occurred until 6 weeks after the breach was discovered. In Georgia where Equifax is based, there are no regulations covering when customers must be notified of a breach, but the GDPR (see the previous blog GDPR is Coming – Time to Prepare) which comes into effect in Europe in May of 2018 requires notification 72 hours after discovery. When they did announce the breach, they issued instructions to go to a website on a different domain – instead of a page on their own trusted website Bugs were found on the website, and their official twitter account even mistakenly tweeted a phishing link to The later website had been set up by a security developer to prove how easy it was to take further advantage of the breach and why it was wrong to use a second domain. The page actually had over 200,000 page loads! Where was the Equifax IR (Incident Response) team?

Lesson number 3 is encrypt data in transit and at rest. Always. No exceptions. It is uncertain at this point whether Equifax had encryption – with some sources such as The Street stating that either there was no encryption or others like CipherCloud that some data was encrypted in AWS but the keys were kept with the data. Many organizations use encryption for data when it leaves the premises and is sent to the cloud provider; however this is not enough, as most breaches occur when hackers utilize web server vulnerabilities to obtain credentials and access unencrypted data being used by the application.  Don’t rely on your cloud provider ONLY for security and encryption. Look at the various security  capabilities built into IBM i 7.2, 7.2 and 7.3 including column level encryption in DB2  at IBM i 7.1, Row and Column Access Control in IBM i 7.2 and Network Auditing and Authority Collection at IBM i 7.3 and the equivalents for AIX and Microsoft products.

To summarize, keep your IBM i, AIX & x86  critical servers current with patches, ensure you have a current Incident Response team and plan, and always encrypt your data both at rest and in flight. Contact Mid-Range regarding  security scans we can perform (on the IBM i it’s no charge) on your systems and how we can help you with remediation if there is a problem and encryption implementation in flight and at rest if you don’t already have it in your shop.

Please follow and like us:
Posted on