While we already knew details of the 2017 Equifax data breach, the full report from the House of Representatives (House Oversight Committee) was released yesterday, which offers a technical deep dive into what occurred. The report can be found at the link below, however I wanted to highlight ten lessons learned for any organisation looking to prevent the somewhat inevitable.
Source: https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf
Key Insights
1. Certificate Management
The biggest takeaway is to concentrate efforts on renewing SSL certificates well before they expire. The system that was the target of the initial point of infection, ACIS, had their certificates “expire 19 months prior to the discovery of the breach”; in addition to this system, “at least 324 SSL certificates” had also expired across the network.
While there are some services such as LetsEncrypt that allows you to auto-renew certificates, the minimum baseline would be to have monitoring in place and a clear process to have them renewed. Equifax knew they were expired well before the breach, but a lack of roles and responsibilities here was the key failure.
2. Legacy Systems
If you cannot invest in modernising critical IT systems, at least do the due diligence of ensuring legacy systems are protected. ACIS was a critical “internet-facing business system” built in the 1970’s, and was difficult for Equifax to patch, scan, and modify it. A system that stores sensitive customer and corporate data should not be built from legacy IT, but rather from tools or solutions that allow for upgrades, automation, security updates, and monitoring of it’s use.
Why would an attacker choose to waste resources creating a custom exploit for a modern application/system that’s well protected, when they can target the low hanging fruit that hasn’t been properly secured in years?
3. Vulnerability and Patch Management
We hear about this time and time again, but that doesn’t mean we should stop talking about it. Let’s get some critical quotes out of the way:
“Failure to patch a known critical vulnerability
[Apache Struts, CVE-2017–5638] left its systems at risk for 145 days”“Vulnerabilities were not adequately tracked, prioritized, and monitored to ensure timely remediation”
What this boils down to is poor and ineffective patch management. It is an absolute necessity to have system owners who follow a clearly defined process when it comes to patches, and to assess each against your environment’s assets. Not to mention that this CVE was rated as critical, and by following best practice (example: ACSC publication), this should have been patched within 48 hours.
When we start to talk about vulnerability management, Equifax did actually scan their Apache Struts servers prior to the breach, however did not find any vulnerabilities as “the scan was run on the root directory”. While configuring your tool properly (i.e run recursively) is the obvious suggestion here, I would also submit that it may be prudent to run a second tool to validate your findings. These don’t have to be vendor specific, there are plenty of open source tools as well.
4. Asset Management
Loosely linked to point 3 is the lack of asset management by Equifax which caused confusion within the organisation at the very least. It was revealed that “no system owner was designated” for ACIS, and other critical assets. There was “no up to date inventory of assets across the business”. Some key questions here:
- How do you then go about assessing risk to the business?
- How do you determine priorities of investment, resources, and effort?
- How is it possible to know your network better than an attacker would in ten minutes?
Recommendation: establish and maintain an inventory of assets (whether this be a CMDB or a simple Excel spreadsheet, something is better than nothing), map these to an owner, evaluate the risk each asset has to your organisation, and make each system owner accountable and responsible for the security of these assets.
5. Network Segmentation
From a network security standpoint, Equifax had not segregated critical systems from the rest of the network. Naturally, when an attacker gains access to the environment, they love nothing more but to pivot, have a look around, see what else they can steal while being completely undetected. Unfortunately for Equifax:
“The ACIS application required access to only three databases”
“ACIS was not segmented off from other, unrelated databases”
The result? The attackers “used the [ACIS] application credentials to gain access to 48 unrelated databases outside of the ACIS environment”. It is important to ensure that employees only have access to what they need for their job, for systems to only be able to communicate with other parts of the network that they have to communicate with, and restrict network access outside of these requirements.
6. Principle of Least Privilege
Similarly, let’s discuss least privilege. Again.
“Sun systems have a shared file system across the environment that allows for access to any of the administrator files from one system to the next”
A startling comment, but this was Equifax’s reality.
File systems must be restricted to only allow certain employees, or roles to gain access to business critical files such as configuration files, files pertaining to sensitive customer information etc. What’s more is that these servers should be hardened to not allow file sharing requests from any source port, but only from specific privileged ports.
7. Web Application Development and Testing
Equifax had discovered flaws in the ACIS code rendering the system vulnerable to SQL injection and Insecure Direct Object Reference attack
What this made it vulnerable to was direct access to customer and system data without even requiring authentication or authorisation. This is exactly what occurred in 2017.
As previously mentioned, ACIS was a business critical, internet-facing system. If this how your organisation chooses to deploy such a server, ensure that it is thoroughly tested before being fully deployed.
There are thousands of people (skills shortage? nah.) who are able to penetration test your web applications and servers, and probably more vendors claiming to do the same. You could also give one of your engineers a challenge, or have them up-skilled to take on this task.
8. Endpoint/Host Monitoring
It was identified that 30 unique web shells were installed and utilised by the attackers throughout the timeframe of the incident. Data was exfiltrated from numerous parts of the network, completely undetected.
There was no file integrity monitoring built into Equifax’s legacy systems, which enabled attackers to modify, create, and copy files with personal customer data unnoticed by Equifax. More so, a distinctive lack of endpoint monitoring meant that Equifax could not have detected malicious activity taking place inside their network. With the lack of SSL certificates AND monitoring, it comes as no surprise that this incident lasted for as long as it did.
9. Incident Response Plan
It became quickly evident throughout this report that while there may have been an incident response process, it was not followed accordingly by all employees involved within the incident. A lack of clear communication channels was identified as a source of pain for many Equifax staff, which led to decisions to be made way too slowly. This is not ideal for any organisation suffering an incident.
It would be suggested, no matter the size of your company, that you go through a practice incident response (i.e. tabletop exercise) and highlight any issues with the current plan. Whether you completely outsource your incident response or not, it is still important to go through these steps and ensure each employee involved realises the role they play and what they are responsible for.
10. Policies, Processes, and Procedures
“At Equifax, the IT and Security organizations were siloed, meaning information rarely flowed from one group to the other.”
“Communication and coordination between these groups was often inconsistent and ineffective at Equifax”
It was interesting to read that Equifax’s security function moved from being under the CIO straight to the legal office under the Chief Legal Officer. While I will restrain from being sceptical about this change, I would rather point the focus on the lack of policies, processes, and procedures after this organisational shift took place.
I’ve spoken about how Equifax did not have clear processes in place for vulnerability, patch, and asset management, and the security of their network suffered greatly because of this. We’ve come to the stage of this world’s timeline where cyber security has to be a priority if you’re storing any kind of customer data. These compliance mechanisms are not to be taken lightly, given how often data breaches and incident’s are occurring. They have to be understood by every employee, and every department or function, to ensure it’s success.
For this reason, individual employees should not be blamed for a data breach, even if it was the result of a human error. Cyber security is a people problem, not an IT problem; we all need to work collaboratively to prevent an incident. As we evidently saw with the Equifax breach, it was the result of many errors and failures, some human based, others technological. These can be remediated by having the proper procedures established and followed, according to standard guidelines.
