What can risk managers learn from the Equifax breach?

Lesson 1 – Have and Use an Incident Response Plan

It is difficult to tell how much of an incident response plan Equifax actually had. Going on the evidence alone I would say that it certainly did not live up to the expectations that I would have for my clients, for the primary reasons that while Equifax hired cybersecurity specialists to deal with the May-June breach, the actions taken after the March incident seem to be wholly inadequate, with the incident being largely ignored.

The May-June event was discovered in July, but those whose data has been compromised were not informed until September. A data breach plan should include the following as an absolute minimum:

Stop the Breach/Attack

The first step is to stop more data being stolen. Inherent in this is a technical understanding and an initial triage of the attack.

Communications Plan

A good data breach response plan will identify the stakeholders for the organisation. Some will be internal (The Board and senior management), some will be trusted third parties (non-exec directors, third parties assisting with the breach, law enforcement if/where required). Others will be customers (those effected by the data breach for example) and for those in regulated sectors or that are subject to data protection legislation by the regulators.

As a minimum, the communications plan should identify the frequency (hourly, daily, weekly etc.), type (email, social media, press, TV etc.) and level of detail of the communication to be provided. The plan is likely to be adjusted with the severity of the breach with guidance on how this should be achieved and included as part of the communications plan. Initiate the Business Continuity and Disaster Recovery Plan An incident response plan has many purposes, but a key one is to initiate the recovery process. This may be based on the initial information and triage but it is imperative to protect the organisation, its people, its assets (digital and physical), and its reputation.

An incident response plan is becoming a mandated required requirement. The NY DFS cybersecurity requirements in the US (NYCRR500), for example, demand this. The requirement is also part of the European data protection (GDPR) and breach reporting requirements that come into place in May 2018.

Lesson 2 – Communicate with Regulators and Data Subjects

The second lesson learnt from Equifax goes back to their communication plan, or seeming lack of one. The news broke and as a casual observer, there seemed to be very little information or PR control.

Data subjects were largely left to contact Equifax for information, which overloaded Equifax’s ability to answer the calls. Their website had stock information that left many people wondering what they should do and whether their information was involved or compromised.

It is also important to mention that this confusion came several months after Equifax had discovered the breach. Even if they only had an outline plan before the breach they don’t seem to have made good use of the time from point of discovery to point of announcement.

72 hours is considered to be the right amount of time from discovery to the first announcement, this is included in data protection and cybersecurity regulations around the world, including NYCRR500 and the GDPR.

Lesson 3 – Be Prepared

I don’t think it is unfair to say that Equifax was surprised by the attack, but given the time between discovery and the public announcement, it is evident that they really were not prepared.

One example of this is the system that they provided to check if details had been compromised (a good idea in its intentions), this required more personal information than was ideal to be passed to another site, which

is concerning. The website itself had a domain name that looked suspicious (www.equifaxsecurity2017.com), and the domain name was registered shortly before being deployed which also made it look suspicious

to the more technically aware.

I’m sure there must be a good reason why they didn’t use something like www.equifax.com/security but all of this points to an organisation that was unprepared and is having to react to a situation rather than following and adapting an incident response plan.

Lesson 4 – Privacy and Security by Design

The system that caused the challenges for Equifax was not a major system at the heart of their network, it was offering a simple service. The trouble is that while the web server software deployed by Equifax didn’t need or use all of Equifax’s assets, it was trusted by those assets and when it was hacked, it was able to access information that it had no business accessing.

This is at the heart of privacy and security by design, which can be summarised as designing systems and permissions to have the minimum access required to do their job. This means that should that system be compromised either by a hacker or perhaps an unexpected bug that the system isn’t a portal to the rest of the enterprise.

Lesson 5 – Patch, Patch and Patch Some More

While information about the cause of the data breach are not fully public and may never be made so, what has

been released suggests that the web server that was compromised had software on it that had not been

updated (or patched). The software vendor had released a fix to a critical security vulnerability in March and this still hadn’t been applied by May when it was fully exploited.

IT teams need to ensure that patches are applied promptly. Once a security patch has been released by a vendor, the details of the issues that it is fixing are very often reverse engineered by bad actors so that they can search for machines that have not yet been updated.