As the Data Protection Act 1998 (DPA98) comes to an end, we have a first! The first maximum fine under the old law was issued in September to Equifax Ltd.
If you’ve heard any of the Data Protection Leads here at Protecture speak about basic security issues facing organisations, you will have heard us talk about patching of systems and devices.
This article examines why Equifax failed with its patching, and in so many other areas of the 7th Data Protection Principle – allowing 15million UK records to be breached.
It provides 12 lessons to learn from the underlying issues that relate to all organisations so that you don’t make the same basic errors. Other data protection principles were breached, but this article focusses on the information security principle.
So what happened at Equifax?
For nearly 20 years, all organisation have had to comply with the 7th Data Protection Principle of the DPA98. This stated:
Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
One of the products Equifax Ltd supplies to its clients is Equifax Identity Verifier. The product allows Equifax clients to verify a consumer’s identity online, for instance, to comply with anti-money-laundering requirements. In doing this, the client enters that individual’s personal information on the system, which is then checked against other sources of data held by Equifax.1
Give the security requirements and the personal data involved, we should expect Equifax to have had appropriate security in place…
The Timeline of Events
On the 7th September 2017, Equifax advised that between mid-May and July of the same year hackers had exploited a “website application vulnerability” which allowed them to gain access to restricted information. The ‘Apache Struts’ website application was the source of the vulnerability — a flaw in the code allowed unauthorised access.
The vulnerability had already been flagged to Equifax Inc on 8 March 2017 by the US Department of Homeland Security Computer Emergency Readiness Team (“US CERT”). It was given the highest score possible, indicating a critical vulnerability that requires immediate attention. US CERT informed Equifax Inc of the need to patch the vulnerability concerned.
On 9 March 2017, Equifax Inc disseminated US CERT’s notification internally among key personnel responsible for installations of Apache Struts within its web estate.
The person responsible for the online dispute portal, which was the attackers’ initial point of entry, didn’t receive the email. The recipient list for the notice was out-of-date and, as a result, the notice was not received by the individuals who would have been responsible for installing the necessary patch.
Lesson 1 – Keep distribution email lists up to date, along with lists of ‘approved users’ with IT suppliers
Lesson 2 – Don’t use email for patching notification, especially for patching zero-day vulnerabilities
Equifax did do vulnerability scanning to ensure they patched the vulnerability. However, the Online Dispute Portal that allowed access to the systems did not show that this vulnerability was an issue; the particular installation on the consumer-facing disputes portal was not identified and was therefore not patched.
It appears that their Asset Management was not quite as joined-up as they’d thought and so this vital portal was overlooked for patching.
Lesson 3 – Use joined up asset management as part of your IT solution.
The hackers gained access to the Online Dispute Portal two days after the announcement of the vulnerability. They used encrypted traffic to gain access to the Equifax systems. Because the security certificate used had expired 10 months earlier, traffic wasn’t examined during this period, resulting in non-detection for three months.
Lesson 4 – Make sure your encryption systems are maintained and security certificates are regularly checked for validity and updated if they have expired.
Because the databases that were attacked were on a flat infrastructure, the hackers were able to move around the system relatively easily. There was little segregation and databases were not separated from each other.
Lesson 5 – Don’t use a flat architecture on your networks. Separate your databases.
Once the hackers were able to run system-level commands on the online dispute portal, they ran multiple queries on other databases to search for data. This search led to a database containing personal data, as well as unencrypted usernames and passwords that provided access to several other Equifax databases. The attackers used these credentials to expand their access beyond the three databases associated with the online dispute portal to an additional 48 unrelated databases.
Lesson 6 – Never store usernames and passwords in plaintext; always encrypt (hashing, salting etc).
In total, around 9,000 queries were run on the databases. Some of these queries returned results containing personal data. The attackers removed the data in small increments, using standard encrypted web protocols to disguise the exchanges as normal network traffic. The attack lasted for about 76 days before it was discovered.
Lesson 7 – Have systems in place to check the nature and volume of queries being run and report pro-actively. Checking logs after the fact does not aid detection helps no-one and increases your risk profile massively.
A file was held in a fileshare, that was accessible by several users (including system administrators and middleware technicians with elevated permissions), for the purposes of maintenance and/or the release of application code. The file contained ‘live’ data taken from the GCS dataset which was created for testing purposes, with the intention of eventually sending it to Equifax Ltd’s Fraud Investigations Team in the UK.
Lesson 8 – Do not use live data for testing purposes. If you absolutely have no other option, then assess and document the risks posed by using live personal data for testing purposes. The data will be accessed and processed by developers and other users; there is likely to be lacking a lawful basis, and you will need to explain this access, processing and re-purposing of data in your privacy notices and any Subject Access Requests etc.
Lesson 9 – Make sure that your service accounts have the right permissions. Don’t allow service accounts to have elevated (admin) privileges.
Prior to transferring UK data to the US (without a lawful basis for the transfer, but that’s a separate issue), Equifax didn’t perform any risk assessments to ensure that there were adequate safeguards in place – in other words, they didn’t check that appropriate technical and organisational measures were in place to sufficiently protect the personal data.
Lesson 10 – Always undertake “due diligence” assessments of potential supplier and partners. Risk assessment and document the outcome. Take actions to manage the risk through to an acceptable level, or document any acceptance of risk (i.e. without treating/mitigating it). The bottom line is that you must be in a position to explain and defend your position if need be.
The data processing agreement between Equifax Ltd (as a data controller) and Equifax Inc (as a data processor) dated from 2014 was inadequate because it failed to provide appropriate safeguards including but not limited to security requirements.
Lesson 11 – Ensure that your contracts and agreements contain the required security information and cover the specific details that you agree should be in place.
Equifax Ltd had full contractual rights to audit Equifax Inc. Despite this, no audits or checks were ever undertaken.
Lesson 12 – If you have the right to audit, use it – so you can be sure that what you think is happening is happening. Check that if an organisation is contracted to protect personal data in a specific way, that that is what they are doing. If you don’t have an audit function or the resource in your organisation, consider using an external auditor.
It is tempting to focus on the patching of vulnerabilities; it is true that if Equifax patched on ALL the relevant systems when they were notified by the US government, then the breach is far less likely to have happened. However, as we can see from the above, there were a number of organisational issues – processes, oversight and controls – across a number of areas that made the breach more likely.
Protecture have developed two tools to assist you in this area
- Information Security Assessment
20 key questions across a range of information security issues.
- Information Security and Governance Framework
The framework requires you to assess the extent to which your current practice, and your existing policies, procedures and/or guidance meet the requirements of the GDPR. The framework addresses eight key themes:
- Physical Controls
- Logical Controls
- Paper Records
- BYOD and Remote Working
- Network and IT
- Cloud Services
To discuss your approach to information security and risk, please log a helpline ticket or call our experts on 0203 691 5731.