GDPR Compliance Post-Mortems: Lessons Learned from Facebook, Uber, and Others – Part 2

Since the EU General Data Protection Regulation (GDPR) went into force in May of 2018, several organizations have received substantial fines from regulatory authorities. This article discusses the lessons learned from one of those fines and the role of a data protection program in preventing future ones.

In Part 1 of this series, I described data protection failures at Marriott International in connection with their acquisition of Starwood hotels. Those failures precipitated GDPR-related fines of about £99.2M. In this post, I describe such failures at British Airways in connection with its payment processing site.

On July 8, 2019, the UK Information Commissioner’s Office (“ICO”) announced its intention fine to air carrier British Airways about £183.4M. This proposed fine stems from a breach of its web-based payment processing system for processing baggage payments that apparently occurred in June of 2018. Approximately 380,000 – 500,000 people were affected by the breach. Implicated in the theft were customer names, postal addresses, email addresses, log-in data, booking information, and credit card data – including CVV data. If sustained, this proposed fine would be the largest thus far for a GDPR-related data protection violation.

Details of the British Airways Breach

While the scope of the breach is arguably large by contemporary standards, what is remarkable about it is the capture of CVV codes, which were not stored by British Airways. In fact, all or nearly all merchants do not store any credit card data on their own sites, instead directing payments to a secure “gateway” service which connects directly with the credit card processor. So what happened? According to San Francisco-based information security firm RiskIQ, the intruders used a “cross-site scripting” attack to inject 22 lines of code into the web page that accepted the payment information for baggage. That information, including CVV codes, was copied and redirected to the intruders but allowed to continue through to the payment gateway. For a 15-day period, British Airways had no idea what was happening. In addition, their mobile app used the same code as the corrupted web page and was equally compromised.

While the way the attack was executed was certainly clever, the use (and threat) of cross-site scripting attacks is nothing new. If fact, cross-site scripting and SQL injection attacks typically rate as the most common threats to websites. Either of these was used in successful attacks on Marriott/Starwood, Equifax, Adult Friend Finder, and Heartland Payment Systems.

Data Protection and GDPR Articles

While the ICO has not yet cited the GDPR Articles that it has concluded have been violated, almost certainly they’ll cite Art. 5 Principles relating to processing of personal data, which I’ve edited for brevity. Personal data shall be:

  • processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’);
  • collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes…(‘purpose limitation’);
  • adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimization’);
  • accurate and, where necessary, kept up to date…(‘accuracy’);
  • kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed…(‘storage limitation’);
  • processed in a manner that ensures appropriate security of the personal data…(‘integrity and confidentiality’).

While Art. 5(1)f is the leading candidate in the case, given the information security aspect, Art. 5(1)a is also a candidate because a poor security posture can be (and often is) deemed “unfair.”  In fact, “unfairness” or “deceptiveness” are the hooks that the U.S. Federal Trade Commission uses to sanction companies for data protection violations.  They do so because it’s such a low threshold to meet.

The other GDPR Article almost certainly to be cited is Art. 32 Security of processing.  Again, I’ve edited for brevity (and clarity):

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing.

I’ve focused on Art. 32(1)d because the idea of regularly testing controls for effectiveness is an old one, and in fact predates modern computing.  In this matter, the personal data in question included credit card information, which is governed by PCI-DSS.  According to the PCI-DSS requirements, vulnerability scans should be performed on websites that accept credit card information at least quarterly or after significant changes are made.  It’s too early to tell if the company failed to do so or failed to do so properly – the airline states that they are “working continuously with specialist cyber forensic investigators and the National Crime Agency to investigate.”  However, this new tack in exploiting website vulnerabilities may necessitate changing the cadence to from quarterly to monthly.  Given that Equifax allegedly scanned for the “Apache Struts” website vulnerability and missed it, it may be that changes also need to be made to how vulnerability scans are performed.  

In this article I described the breach that took place at British Airways and the fine levied by the U.K.’s data protection authority as a result.  In part 3, I will continue the discussion with an analysis of how an effective data protection program may have prevented it.

Since the EU General Data Protection Regulation (GDPR) went into force in May of 2018, several organizations have received substantial fines from regulatory authorities.  This article discusses the lessons learned from one of those fines and the role of a data protection program in preventing future ones. 

See how Spirion can help you…

Related Blog Posts

Blog Post
Data Privacy and Compliance (CCPA, CPRA, GDPR): A Mid-Year Review and Look Ahead for 2021
Blog Post
Biggest GDPR Non-Compliance Penalties (So Far) | Spirion
Blog Post
History of Google and CCPA’s Data Privacy Rules | Spirion
Blog Post
Episode 3: Privacy Please Podcast with Guest Scott Giordano covering CCPA and GDPR
Blog Post
Do Your DLM and ILM Practices Meet New Data Privacy Laws?
Blog Post
Google Wins in GDPR Data Privacy Case — for Now!