Being curious

13 May 2019

Report on Equifax Data Breach Incident

Copy of a paper I wrote as part of my postgraduate studies on Social Engineering.

Introduction

Background

As a credit reporting agency (CRA) Equifax must meet the requirements of the US Federal Fair Credit Reporting Act (FCRA). Part of meeting these obligations requires Equifax to maintain reasonable procedures to allow consumers to dispute and have corrected inaccuracies on their credit report (Wikipedia, 2019).

Equifax uses the Automated Consumer Interview System (ACIS) application to meet this requirement. Members of the public use the ACIS portal to submit information on their credit file disputes and track resolution progress. Access to ACIS is available from the internet.

Between mid-May and end of July 2017 the Equifax ACIS system was compromised by remote attackers. During the attack significant amounts of personally identifiable information (PII) belonging to members of the public was stolen (Equifax, 2017).

Document Purpose

This document summarises the incident and provides recommendations Equifax can adopt to prevent a reoccurrence.

Document Audience

Audience for this document is Equifax management needing to understand the incident causes, steps taken to respond and recommendations arising.

Definitions

Definition of key terms used in this document are below.

Term Meaning
US-CERT United States Computer Emergency Readiness Team
GTVM Global Threat and Vulnerability Management
ACIS Automated Consumer Interview System
CRA Credit Reporting Agency
FCRA Fair Credit Reporting Act

Executive Summary

Between mid-May and end of July 2017 Equifax systems were compromised and personally identifiable information (PII) belonging to approximately 145 million members of the public was stolen (Equifax, 2017). A summary of the types and quantity of information stolen is detailed below (Equifax, 2018).

Information Type Quantity of records accessed
Name 146.6 million
Date of Birth 146.6 million
Social Security Number (SSN) 145.5 million
Address Information 99 million
Gender 27.3 million
Phone number 20.3 million
Driver’s license number 17.6 million
Email (w/o credentials) 1.8 million
Payment card number with expiry date 209,000
Tax ID 97,500
Drivers license state 27,000

The attack was enabled by an unaddressed vulnerability in the public facing Equifax ACIS application. The vulnerability allowed remote attackers to gain access to infrastructure supporting the ACIS application. Attackers used illegally obtained access to extract data from internal Equifax databases and steal considerable Equifax held PII.

Addressing these types of vulnerabilities requires prompt action from all parties. Based on post incident analysis it took 72 hours from the vulnerability being announced to initial probing attempts on the Equifax systems (RBS, 2017). By comparison Equifax took a total of 138 days to detect the vulnerability, resulting compromise and take remedial action.

It was in Equifax’s power to prevent this incident. Prolonged exposure to the vulnerability and magnitude of the following incident was due to multiple internal failures. These all stem from a current low security posture at Equifax. Key findings:

  • Failing to identify and respond to the vulnerability in the ACIS application. Addressing this involves addressing root causes around lack of accountability for vulnerability management, lack of system ownership & software inventory.
  • Failing to maintain monitoring infrastructure which may have detected the vulnerability. Fixing this requires organisational change to ensure monitoring infrastructure is correctly maintained.
  • Operating legacy infrastructure and systems which magnified opportunities for attackers. Fixing this requires a longer-term overhaul of platforms and systems.

Lastly Equifax took 117 Days after the breach had been detected to notify the public. This delay and the cause of the incident has left Equifax exposed to ongoing impacts from regulatory sources and members of the public.

Incident Details

Incident Analysis

Malicious actors gained access to Equifax ACIS system using a known vulnerability (CVE-2017-5638) in Apache Struts. The vulnerability allowed allows internet-based attackers to execute arbitrary commands via crafted HTTP requests (MITRE, 2018). This ability was used by attackers to gain remote access to infrastructure supporting the ACIS application. Once remote access had been obtained attackers were able to access customer data in internal Equifax databases and extract it from the environment.

Incident Analysis

Apache Struts Vulnerability and Initial Compromise

Apache Struts is an open-source framework used to build Java web applications (Apache Software Foundation, 2018). Frameworks like Struts are commonly used to speed up development processes as they minimise the need for ‘reinventing the wheel’. Unfortunately, when a significant vulnerability is discovered in a common framework it can have broad wide-ranging impacts.

CVE-2017-5638 is a vulnerability disclosed on 6th March 2017 (Lenart & Gielen, 2017) which affects the Jakarta Multipart parser in Apache Struts. To trigger the vulnerability an attacker sends a crafted request which includes a user specified command to the web application. Example shown below (includes request for site to execute ‘whoami’ command’).

Triggering struts vulnerability

The crafted request is designed to trigger an error in the Struts application. As a result of the vulnerability the web server executes the user specified command. Attackers used this vulnerability to obtain remote access to the Equifax Infrastructure used to host the ACIS application.

Obtaining Customer Data

Once remote access had been obtained to ACIS infrastructure attackers were able to progress through the Equifax IT environment. After locating system credentials attackers were able to access sensitive data held separate to the ACIS application. Attackers were able to send approximately 9000 queries across 48 databases (U.S. House of Representatives Committee on Oversight and Government Reform, 2018). The output of this was then assembled for extraction.

No specific vulnerability was used to extract the data. It was made possible via several general poor security practices. These included unencrypted storage of credentials, poor network segmentation, not encrypting sensitive data while stored at rest & insufficient monitoring of environment.

Extracting Customer Data

To extract stolen data from the Equifax environment attackers first moved it back to the compromised ACIS Infrastructure. Attackers then downloaded the information either via direct means (i.e. wget) or through using the infrastructure used to establish initial access.

Extraction of the data was not noticed by Equifax due to the ACIS monitoring infrastructure being unmaintained. The monitoring infrastructure required a current Secure Sockets Layer (SSL) certificate to correctly analyse traffic from ACIS. The current SSL certificate on the infrastructure had expired so the attack was not detected. As soon as the certificate was updated the attack was noticed by Equifax staff and Incident response work commenced.

Detailed Timeline

A detailed timeframe of key milestones around the incident are noted below:

Detailed timeline

Key items of note from the detailed timeline:

  • From the vulnerability being announced it took approximately 1 day for proof of concept exploit code to be available on the internet.
  • From the vulnerability being announced it took approximately 3 days for Equifax systems to be probed using the proof of concept code.
  • Attackers were active in Equifax systems for approximately 78 days before detection.
  • From announcement of the vulnerability Equifax took approximately 138 days to contain the incident.
  • It took 117 days after the breach was discovered for members of the public to be notified. This gave attackers a considerable head-start to mis-use the data.

Assessment of Threats and Risks

Due to the nature of the business Equifax holds significant amounts of personally identifiable information (PII) belonging to members of the public. This data is required for Equifax to provide products and services to its end customers. One key threat to the Equifax business is loss of this data via a malicious action of an outside actor.

Key risks to consider which have a bearing on the realisation of this incident are below. Overall these items demonstrate a low level of security maturity inside Equifax environment. Security culture was such that earlier security reports were not adequately addressed (RBS, 2017). There were findings from previous reports and investigations that were still in the process of being resolved at the time of the incident (Franceschi-Bicchierai, 2017).

Risk Impact on Incident
The Equifax IT environment is highly complicated and has considerable legacy components. This is due to age of Equifax systems and speed at which technical debt was being addressed. It is also due to Equifax’s aggressive growth strategy between 2005 to 2017 (U.S. House of Representatives Committee on Oversight and Government Reform, 2018). In acquiring other companies Equifax also acquired their IT Infrastructure and had to integrate it. These are both demonstrated by the age of the ACIS application and inadequate network segmentation used by it. An appropriate environment will have multiple integrated levels of security controls. A failure in one control (i.e. patching) should not have led to total compromise of the environment. In this instance attackers were able to exploit multiple vulnerabilities present in the environment and successfully steal the target data.
A misaligned organisation structure governing Security Policy and IT systems management. Security is part of Legal and did not report into IT. This showed in a lack of accountability and no clear lines of authority in Equifax’s IT management structure and a disconnect between policy writers and implementers. (U.S. House of Representatives Committee on Oversight and Government Reform, 2018). If the approved patch management policy had been correctly implemented the incident may have been avoided.
Equifax holds inadequate asset inventory details. This would be a formal defined list showing what applications Equifax has, who owns them and what components they were comprised of. Lack of this impeded the correct implementation of the patch management policy. Use of Struts in ACIS application was not understood by the business. If this has been captured the business could have ensured it was patched.
Lack of maintenance across IT monitoring infrastructure, including renewal of SSL certificates. SSL certificate used to monitor ACIS application had expired. Once this was renewed the incident was detected rapidly. If the certificate had been renewed prior to expiry the incident may have been detected immediately and corresponding impact would have been reduced.

Organisation Response

Initial Response

SSL certificates used on ACIS application monitoring infrastructure were updated on 29th July 2017. Suspicious internet traffic was immediately noticed. Equifax incident response team choose to immediately block ISP used to access ACIS application from China (U.S. House of Representatives Committee on Oversight and Government Reform, 2018).

Vulnerability analysis was then completed on the ACIS application. The Incident response Team identified that testing conducted in April 2017 had missed multiple instances of Struts. The Incident Response team confirmed that PII was likely being stolen so took the decision to take the ACIS application offline. The application was taken off offline on 30th July 2017 and Senior management was then notified (U.S. House of Representatives Committee on Oversight and Government Reform, 2018).

Initial response was handled well, once incident was identified managing team successfully contained the incident in under 36-48 hours. Once the initial breach had been contained Equifax setup Project Sierra and Project Sparta to eradicate and recover from the incident.

Project Sierra

Project Sierra Established was established on 31st July 2017 (U.S. House of Representatives Committee on Oversight and Government Reform, 2018) to handle the overall response to the attack (Brewster, 2018). Work conducted by Project Sierra was kept confidential inside Equifax and only members of the crisis response team were kept appraised of progress.

Part of the Project Sierra work included engaging Mandiant to conduct a forensic review of the breach, notifying the FBI & engaging King & Spaulding Law firm to prepare for the eventual public disclosure.

Project Sparta

Project Sparta was established around the middle of August 2017 to prepare for public notification of the breach (U.S. House of Representatives Committee on Oversight and Government Reform, 2018). It included setting up public facing contact points and a suite of protection tools to be used by affected consumers (Brewster, 2018).

The main point of contact established was the website https://www.equifaxsecurity2017.com/. The setup was of this was criticized by consumers as checking if they were impacted would often return contradictory results. The site setup was also criticized by Security experts. The site was setup separate to the main Equifax website. This made it straight forward for a Security researcher to clone the site (RBS, 2017). It was demonstrated (https://www.securityequifax2017.com/ was created) and the cloned site was then incorrectly communicated to the market by the Equifax social media team.

The other main point of contact setup was Call Centres. These were criticized by the public as being overloaded, people calling in experienced excessive wait times and agents had difficulty in answering basic questions.

Follow on Impacts of Security Incident

Several impacts have or will affect Equifax following the breach.

The incident generated significant negative publicity for the Equifax business and brand. All actions by Equifax following the incident were and continue to be put under the microscope and examined (Smiley, 2017). These include:

  • Planned activities like sale of Shares (Moyer, 2017) (Melin, 2017). Equifax executives sold stock days before the incident was announced to the public. Accusations of insider trading soon followed.
  • Choices in responding to the breach that would have commercially advantaged Equifax over the longer term (RBS, 2017). Only a year of credit monitoring was initially offered to members of the public. This would have generated ongoing revenue for Equifax – members of the public saw this as a ‘cash grab’.
  • Attempting to blame the breach onto a single employee rather than systemic internal issues (Whittaker, 2018). Members of the public saw this as Equifax not owning its mistakes.

These concerns were magnified by the low public perception of the credit reporting agency industry.

The increased scrutiny has led to short term enforceable regulatory undertakings and signalled a number of longer-term changes. Equifax is required to comply with enforceable undertakings coming from the incident. Additionally, regulatory entities and signalling changes, for example:

  • Canada is looking to shift treatment of sharing of data between entities as disclosure, not reporting (Office of the Privacy Commissioner of Canada, n.d.). This would require changes in how the Equifax US and Canada business arms interact.
  • Timeframes for responding to breaches may be shifted from a voluntary option to a mandatory obligation. This would include a regulatory enforced timeframe. Given Equifax took 117 days to notify the public of the breach this would be challenging to adopt.

Lastly data stolen during the incident has not been located and identity of the attackers not confirmed (Fazzini, 2019). Without understanding the purpose the attackers had in stealing with the data, it is impossible to determine longer term impacts. Addressing this requires a rethink from Equifax on how this data is protected and how members of the public can be supported ongoing.

Recommendations

The below recommendations are provided address learnings arising from the incident. These are separated into short term tactical and long-term strategic recommendations.

Key to these recommendations is duration between the vulnerability being announced and first attempted attacked on Equifax systems was ~72 hours. This timeframe is not under the control of Equifax, so business priority needs to be given to beat it.

Short Term Recommendations

Recommendation # 1 – Create accountable Equifax group to manage IT detection controls.

The breach took considerable time to be due to basic maintenance of detection controls being allowed to lapse. If the traffic analyser for the ACIS application had been appropriately maintained it is likely the breach would have been detected in a significantly shorter timeframe.

An accountable group inside Equifax should be created with the purpose of ensuring detective security controls are up to date and functioning correctly (Piovesan & Cognitive World, 2019).

Recommendation # 2 – Make Business Owners accountable for application vulnerability management.

Each application held by Equifax must have an associated business owner (one must be assigned if not present). The Business Owner must be made responsible for vulnerability management of applications under their control.

Equifax was aware of the initial vulnerability used in the breach and had appropriate patch management policies in place to address it. Making the business owner accountable for acting on this clarifies the current ambiguity.

Recommendation # 3 – Prioritise completion of centralised software Inventory for all applications

Each application is made up of multiple software components. Work is currently underway to complete an inventory of all software components used in these applications. Completion of this must be accelerated. This inventory must then be maintained ongoing.

Work was undertaken by Equifax to patch the announced struts vulnerability. If the presence of Struts in ACIS had been known, it would have been possible to take remedial action.

Recommendation # 4 – Update Equifax playbook for responding to loss of PII

Equifax playbook for responding to loss of PII must be updated. Updates must incorporate customer experience and practical elements learnt from the incident. This includes:

  • Considering actual impact of data lost (Smiley, 2017). Offering customer, a credit freeze has reduced value if the stolen data can be used by an attacker to reverse the freeze.
  • Consider impact of exposed data over time. If stolen data cannot be changed (i.e. SSN) then misuse of it will impact a customer for the rest of their life.

Long Term Recommendations

Recommendation # 5 – Assemble inventory of data sets held by Equifax & establish data governance program.

A consolidated inventory of data sets held by Equifax needs to be established. This needs to reflect what actual data is held, where it is held and who the business owner of the data is. Priority needs to be given on identifying data that is either unchangeable (i.e. date of birth of member of the public) or used for backstop purposes (i.e. password reset questions).

To control, rationalise & improve this data an appropriate data governance program needs to be established (Piovesan & Cognitive World, 2019). When responding to the breach it was unclear what data had been accessed and where that data was held inside Equifax.

Recommendation # 6 – Update network & system design to improve segmentation & segregation

Equifax network and system design must be changed to boost segmentation and segregation (Office of the Privacy Commissioner of Canada, n.d.). During the breach attackers were able to move laterally inside the Equifax environment due to lack of appropriate network segmentation. There were also lack of appropriate segregation controls that could have provided additional points for detection of the intrusion.

Recommendation # 7 – Rationalise and update public facing applications

Equifax maintains multiple public facing applications. In part due to its age the ACIS application was the entry point for the breach. Existing web applications first need to be rationalised – applications no longer required or that can be rationalised elsewhere need to be decommissioned.

Applications that are required to support the Equifax business ongoing need to be updated to use contemporary platforms, tools and methods.

References