GDPR raises the stakes on data breaches

Another week, another list of data breaches resulting from vulnerabilities in third-party contractors for high-profile companies.

But since May 25, at least in the European Union (EU), it is more than just another week. There is the potential for something both more harsh and more expensive than unhappy customers, brand damage, or even class action lawsuits when a breach compromises customer information—the mandates in the General Data Protection Regulation (GDPR).

Article 32 and data security

While most of the publicity surrounding GDPR’s implementation has focused on personal privacy, there is also a security component.

Article 32, besides requiring anonymization and encryption of personal data, also mandates “the ongoing confidentiality, integrity, availability and resiliency of processing systems and services.”

That comes with a few caveats. Article 32 says regulators will take into account “the state of the art [in security], 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.”

But it also says that organizations that don’t adhere to a “code of conduct” or put in place an “approved certification mechanism” to demonstrate that they have taken “measures to ensure a level of security appropriate to the risk” could be in trouble.

That surely is on the minds of the ticket-selling giant Ticketmaster and of FastBooking, a third-party service provider based in Paris that sells booking software to about 4,000 hotels in more than 100 countries. Both acknowledged in late June that they had been breached and that personal information of customers had been compromised.

There is no way to know yet if those incidents will result in financial penalties or other EU government sanctions, but they are classic examples of the damage that can result from third-party vulnerabilities.

Ticketmaster—victim or villain?

Ticketmaster said last week that it discovered on June 23 that its U.K. site had been breached, affecting what the company said was less than 5% of its customers, or nearly 40,000 people.

Several had already reported being scammed.

The compromised data included log-in information, user payment data, addresses, names, and phone numbers.

And while the vulnerability was reportedly fixed by June 26, the blame game about who is at fault and when the flaw should have been discovered and fixed began immediately.

Monzo, a mobile-only bank in the U.K., said it had found evidence that Ticketmaster had been breached more than two months earlier, on April 6, when about 50 of the bank’s customers reported fraudulent activity on their bank Mastercards. It turned out that 70% of them had used those cards with Ticketmaster between last December and April.

“This seemed unusual, as overall only 0.8% of all our customers had used Ticketmaster,” wrote Natasha Vernier, Monzo’s head of financial crime, in a June 28 blog post.

She said that over the next several days, there were attempts of fraud on eight more cards, six of which had been used at Ticketmaster.

Monzo notified a Ticketmaster security team, which visited the bank April 12 and said they would conduct an internal investigation, but about a week later said the investigation showed no evidence of a breach.

That is essentially what Ticketmaster told The Register when it acknowledged the breach.

“When a bank or credit card provider alerts us to suspicious activity it is always investigated thoroughly with our acquiring bank, which processes card payments on our behalf,” it said in a statement. “In this case, there was an investigation, but there was no evidence that the issue originated with Ticketmaster.”

Ticketmaster accuses Inbenta

On its website, where Ticketmaster U.K. created a customer page with information about the breach and advice about things like changing passwords, there was no mention of Monzo’s warning more than two months earlier.

Instead, the company merely said that “as soon as it was determined that there was potential unknown third-party access to certain personal information, Ticketmaster took swift action to address the issue and protect customers.”

And that was also the launch of a second blame game. Ticketmaster said it had “identified malicious software on a customer support product hosted by Inbenta Technologies, an external third-party supplier.”

The company said it “disabled the Inbenta product across all Ticketmaster websites” to eliminate the vulnerability.

Inbenta accuses Ticketmaster

But according to Inbenta, it was a bit more complicated than that, and Ticketmaster bears some of the responsibility.

In a post on the Inbenta website, CEO Jordi Torras said the source of the breach was “a single piece of JavaScript code, that was customized by Inbenta to meet Ticketmaster’s particular requirements.”

That code was meant to be used with a chatbot on the Ticketmaster site. But Torras said Ticketmaster “directly applied the script to its payments page, without notifying our team. Had we known that the customized script was being used this way, we would have advised against it, as it incurs greater risk for vulnerability.”

He added that the vulnerable code “is not part of any of Inbenta’s products or present in any of our other implementations.”

Either way, consequences likely for Ticketmaster

However the blame shakes out, the bottom line is that whether the “issue” originated with Ticketmaster or not, it is Ticketmaster customers who are affected.

And that means it is not just unhappy customers that could be trouble for the company. Adam Brown, associate managing consultant with Synopsys Software Integrity Group (SIG), said if the JavaScript code vulnerability “was really a niche exploit,” then company officials could argue that they had done what they could, given the caveats in Article 32, like “state of the art” and “costs of implementation.”

But if it is determined that the flaw was something that could have been detected with a vulnerability assessment, with a penetration test, or by avoiding the use of vulnerable components, “then they can expect to have the law read back to them—and not by Judge Judy,” he said.

And it appears likely, given the conflicting versions of how this happened, that GDPR regulators might indeed ask Ticketmaster why it used software code from a third-party contractor for a different purpose from its original intent, without asking.

FastBooking—open and shut

In the case of FastBooking, that company itself is the third party, the victims being the hotels that use its booking software and their guests.

While there wasn’t anything apparent on its website, BleepingComputer and others reported last week that FastBooking had sent emails to affected hotels—possibly hundreds of them—notifying them that unknown attackers had exploited a vulnerability on one of its servers to plant malware and, from there, to steal data that included names, email addresses, booking information, and in some cases, payment card data of guests.

The breach reportedly happened June 14, and the company closed the vulnerability after discovering it five days later, on June 19.

While there was no final count of the number of hotels or customers affected, officials at one of those chains—Prince Hotels of Japan—said the hackers stole data on more than 124,000 of its customers who had stayed at one of its 43 locations between May and August 2017.

How to prevent data breaches

Should, or could, these breaches have been prevented? Experts say the only way to know for sure is to do the forensics yourself. But Ian Ashworth, sales engineer with Synopsys SIG, said that at a minimum there ought to be “well-maintained antivirus and malware detection software running on these servers that would hopefully detect these types of malicious programs either from their code signatures or from their unusual and unexpected network connectivity.”

Companies also ought to maintain principles of least privilege and use sandboxes.

But he noted that attackers can be highly sophisticated—that there is now “fileless” malware that doesn’t leave any footprints on disk drives and so can’t be detected by tools that sweep the disk for suspicious software.

There is no way to avoid every attack, Brown said—especially when attacks are constantly evolving and improving.

The only way organizations have a chance, he said, is if they have “a deliberate and effective software security initiative driven by management of the company.”

Interested in reading more about data breaches under GDPR?
Read this post: Timehop breach provides GDPR response template