11 July 2019 (Crete, Greece) – This week there was a lot of attention focused on the UK data privacy watchdog (formal name, the UK Information Commissioner) which flexed its GDPR enforcement muscles for the first time, fining British Airways a record fine of £183m for last year’s data leakage (1.5% of its annual turnover), and fining Marriott £99m (3% of its annual turnover).
It is early days. We still need to run a lengthy appeals process. All companies that have been assessed large GDPR fines, and appealed, have structured their appeals in a way that some questions will need to be referred to the Court of Justice to the European Union for interpretation. And given that Court’s growing backlog and agenda on data protection it’s hard to predict the eventual outcome.
Plus, as I noted in my weekly newsletter to clients, there are a few other factors at work:
1. At first glance the British Airlines fine seems quite harsh given the airline did report the fine within the required 72 hour window when they became “aware” of the breach. However, it is also a sign (a warning) that inadequate security measures by organizations will be penalized by supervisory authorities.
2. The British Airlines case is also a peak into the dark side we see more and more: cyber attackers compromising 3rd party suppliers which seems to have happened in this case. The sophisticated card skimming group Magecart has been blamed for the airline’s data slurp. The group is believed to have exploited third party scripts, possibly modified JavaScript, running on BA’s site to gain access to the airline’s payment system. Such scripts are often used to support marketing and data tracking functions or running external ads. We are going to see, time and again, how complicated this stuff is, how sophisticated these cyber attacks are that lead to data breaches, through 3rd party data security compromises. [Note: at the end of this post I have a short explainer on how these web-based credit card skimmers work, provided by my cyber security partner FireEye]
3. Then there is the Brexit issue. I will assume the UK will need to maintain/achieve “data protection equivalence” which means keeping GDPR-equivalent regulation in place as part of its trade negotiations with the EU. Whether such sanity will prevail in the UK these days is anybody’s guess. And post-Brexit, I presume any fines will not be shared with other EU countries so the UK authorities might be more willing to strike a deal and take less into account to settle a case than an EU regulator might otherwise apply.
But far more interesting is the ICO’s “Regulatory Sandbox” to help businesses comply with the GDPR. I wrote about it last March (“The UK data protection authority tries to “inform” GDPR compliance“) and I attended an ICO webinar last week (the first beta phase ended at the end of May; we are now into the second beta phase) so here are some further thoughts I’d like to make:
The premise behind this “Sandbox” is fairly simple: successful applicants will work with the ICO team – there are three full-time staffers on the Sandbox project – as they develop their product or service, with the aim making sure they comply with data protection rules. The plan is part of the ICO’s efforts to be taken seriously by the tech firms it regulates as it pushes the message that data protection shouldn’t get in the way of innovation. It has also indicated it wants to play a part in building up public trust in the use of personal data.
And (surprise!) the effort has stirred debate in data protection circles as many argue the regulator should dedicate more of its limited time and resources to enforcement, echoing complaints that too much was spent on the high-profile Facebook-Cambridge Analytica case. Critics say the ICO’s job is to keep organizations in line, not to champion innovation – and have questioned how often data protection rules have genuinely prevented innovative products from being a success.
But I think the response to that criticism by the ICO’s head of assurance, Chris Taylor, who is leading the Sandbox project, is a good one:
“Prevention is better than cure. The only way for us to keep pace with the increasingly varied and complex uses of personal data was to get our hands dirty and work with people genuinely trying to do innovative stuff with personal data. For multiple cases and enforcement actions in the past, it would have been much better to be involved early on, rather than run expensive enforcement action afterwards.”
Over time, I assume the aim is to develop a bank of knowledge that the ICO can use for guidance and practical case studies. Although the ICO doesn’t control the law, one can see where it would be possible for the ICO’s work to eventually allow it to provide advice “further up the chain”.
Based on the first beta results, most interest has come from the healthcare and patient administration sector, making up about 16 per cent of responses. Others areas included legal, education, financial, advertising, insurance and recruitment, as well as government departments and regulators. About half of all responses were from micro-organisations, and a quarter from larger bodies, which the ICO said was an “encouraging” spread.
One interesting piece (it deserves its own post) is a proposal for the ICO team to sit in on a startup’s sprint to observe and advise on the data protection rules.
And the big idea behind all of this: if an organization works with transparency and in good faith, and takes action quickly if a breach of some kind happens, the starting point would not be to take enforcement action. But if someone in the Sandbox goes completely off-script, “that’s completely different” said an ICO representative.
And here’s something different: the ICO will also offer a “negative assurance” letter that will effectively say that when the product left the Sandbox there weren’t any glaring data protection concerns. But this isn’t long-term assurance or endorsement:
“The ICO can never offer an entire carte blanche, or a safe space. We’re all grown-ups. It is the organisation’s responsibility to ensure they comply, this won’t be a way of providing endorsement.”
CONCLUSION: An alternative approach to regulatory engagement
From a privacy perspective, the Sandbox encourages an alternative approach to regulatory engagement. Currently, the majority of EU data protection authorities have a tendency to operate in a primarily reactive manner. Most organizations will only come into contact with an authority if there has been a complaint issued against them by a data subject, or when they are required to report a personal data breach. This approach means that too much focus has been on contentious enforcement action that occurs after-the-event, as opposed to there being constructive engagement from the start which aims to encourage and guide compliance and determine best practices.
The results of this effort undertaken by the ICO indicate that there is considerable appetite for the Sandbox initiative from the commercial organizations that responded. This shouldn’t be a surprise. DPOs and in-house counsel continue to contend with how to apply the somewhat vague concepts of privacy by design and default to their businesses and being able to find an appropriate balance between the rights of individuals to privacy and their companies’ commercial interests. They will therefore no doubt welcome the opportunity to further understand how the regulator expects companies to act.
And, look: as a cynic to this whole GDPR process and having interviewed 200+ companies and data protection practitioners, I know that practically none has really achieved compliance with the legislation anyway. After all, to business, “compliance” has for ages typically meant “what’s the least we can get away with doing to [keep the regulator off our backs; get the certificate; what you will]”, and the approach to the new data protection legislation seems no different.
And one can also say this initiative seems to be another instance of profile raising by the ICO. They’re grossly under resourced (all data protection authority offices are under resourced) and thus effectively unable to deal with high volume complaints from ordinary folks, so they’re already cherry picking “big breaches” for action. The ICO is so short of people that, as I was recently told by a staffer, it currently takes three months to assign a case officer to a complaint. Consequently failures to comply will probably proceed on their merry way.
So I will give the ICO some points here. And, yes, I have avoided questions about how principles such as fairness, data minimization and accountability should be applied in a practical environment, particularly to new technologies such as machine learning, blockchain and the internet of things.
However, in the absence of approved industry codes of practice and context-specific regulatory guidance, the principle-based nature of the GDPR can create uncertainty and ambiguity. Companies that look to benchmark what they are looking to do against their peers, in order to determine market practice, will often find that approaches diverge significantly, with the key variable often being the degree of regulatory risk an organisation considers to be acceptable. Therefore, even for the majority of organisations that are not involved in the beta phase, the Sandbox still promises to offer tangible benefits.
So opening a constructive channel of communication allows companies to build trust with supervisory authorities and understand what steps they should be taking in order to ensure that their commercial operations are privacy compliant. This step shouldn’t be taken lightly though. A hat tip, nonetheless, to the ICO.
I’ll keep my eye on it for a “lessons learned” update.
* * * * * * * *
Magecart: a familiar adversary
Since 2016, FireEye has reported on the use of web-based card skimmers operated by the threat group Magecart. Traditionally, criminals use devices known as card skimmers – devices hidden within credit card readers on ATMs, fuel pumps, and other machines people pay for with credit cards every day – to steal credit card data for the criminal to later collect and either use themselves or sell to other parties. Magecart uses a digital variety of these devices.
Magecart injects scripts designed to steal sensitive data that consumers enter into online payment forms on e-commerce websites directly or through compromised third-party suppliers used by these sites. Last year, Magecart operatives placed one of these digital skimmers on Ticketmaster websites through the compromise of a third-party functionality resulting in a high-profile breach of Ticketmaster customer data. Based on recent evidence, Magecart set their sights on British Airways, the largest airline in the UK.
Finding the Breach of British Airways
Our first step in linking Magecart to the attack on British Airways was simply going through our Magecart detection hits. Seeing instances of Magecart is so common for us that we get at least hourly alerts for websites getting compromised with their skimmer-code. Customer notifications through our products are automated, but our research team searches for any instances outside of these workspaces manually and adds them to our global blacklists. In the case of the British Airways breach, we had no hits in our blacklist incidents or suspects because the Magecart actors customized their skimmer in this case.
One challenge of digging through crawl data manually is the scale of the data FireEye. We crawl more than two billion pages a day, which accumulates over time. Another is that modern websites tend to run with a lot of functionality built out in JavaScript. Just loading the main British Airways website spins up around 20 different scripts and loading the booking subpage bumps that to 30. While 30 scripts might not sound like much, many of these are minified scripts spanning thousands of lines of script.
For this research, we decided to focus our efforts by identifying individual scripts on the British Airways website and examining their appearance over time – we would verify all the unique scripts on the website and only look at them again if their appearance changed in our crawling. Eventually, we recorded a change in one of the scripts.
Opening up the crawl, we saw this script was a modified version of the Modernizr JavaScript library, version 2.6.2 to be precise. The script was loaded from the baggage claim information page on the British Airways website, So, we easily tracked the modified, malicious version of Modernizr the timestamp which matched closely to the timestamp given by British Airways as the beginning of people getting victimized.
And one last point: on websites, mouseup and touchend are events (which can be tracked) for when someone lets go of the mouse after clicking on a button or when someone on a touchscreen (mobile) device lets go of the screen after pushing a button. This means that once a user hits the button to submit their payment on the compromised British Airways site, the information from the payment form is extracted along with their name and sent to the attacker’s server.
This attack is a simple but highly targeted approach compared to what we’ve seen in the past with the Magecart skimmer which grabbed forms indiscriminately. This particular skimmer is very much attuned to how British Airway’s payment page is set up, which tells us that the attackers carefully considered how to target this site instead of blindly injecting the regular Magecart skimmer.
We have more to tell but I think that’s enough of a trip through the weeds.