GDPR Gets Teeth: British Airways and Marriott Fined

Yesterday the UK’s Information Commissioner Office proposed record setting fines under GDPR for £183 million to British Airways, followed by today’s announcement of a proposed £99 million fine to Marriott International following their data breaches.

ICO representatives clearly stated their intention of enforcing GDPR fines for these breaches is to send a message to organizations that they are to be held responsible for personal information and data. The ICO states the GDPR legislation clearly mandates organizations to both consider how data is stored and what happens to it over the entire lifecycle.

What Went Wrong?

In both cases the ICO cites significant lapses in information security practices for the reasoning behind the fine. Without knowing the specifics we can still infer several facts from the BA breach.

It was widely reported to be in the family of Magecart attacks which saw old versions of an ecommerce platform called Magento automatically exploited. In most cases, just as in BA’s, they injected extra malicious code at the end of a widely used javascript library (modernizr).

These 22 lines of code proceeded to load external resources that were used to skim the payments forms for credit card details from over 380,000 victims.

Software Supply Chain Attack

Fundamentally, from an engineering standpoint, this could be classed under the family of Software Supply Chain attacks due to the fact a 3rd party library was tainted in the BA case. Setting aside the obvious questions of PCI compliance with payment forms loading external code, this illustrates how deceptively hard it can be to observe changes in one’s supply chain.

These sort of attacks do not rely on just a single weakness in the chain, but typically are a result of several corresponding incidents. In this case, an unpatched version of Magento was leveraged to proceed further down the software supply chain and poison a seemingly standard 3rd party library. By all accounts the javascript file was in place for several weeks without being further modified. In most cases it is not just the initial weakness, but a series of vulnerable services and systems in tandem that lead to such breaches.

Preventing such attacks can seem complicated but there are a few lessons to be learnt here.

Continuous Delivery?

The fact that the modified file stayed in place for several weeks seems to hint at the file not being updated for at least as long. This most likely means there were no deployments onto these production services, or they were merely incremental changes.

This can be problematic. Modern incident management best practices call out for a complete reconstruction of servers on deployment. As containerization has become more commonplace, fully redeploying that part of the software would’ve most likely erased the malicious appendix from the software.

Verify Your Software Supply Chain

Another lesson that can be gleaned from the situation is that what was deployed yesterday is not necessarily good today. Knowing what you have based on a manifest is as important as verifying it still exists as it was yesterday. Plenty of files can be included before, during, and after deployment time outside managed dependencies. It is important to keep verifying you know what specifically is deployed and it’s compliancy.

Post deployment in an ideal world one might also consider verifying the deployment target is still what it was meant to be.

GDPR Gets its Spurs

This shows GDPR legislation finally getting it’s spurs in terms of larger fines, and paves a direction for future breach fines. As more and more of the more recent breaches are disclosed and investigated we’re sure to see larger fines being assigned based on the legal power of the legislation.

It’s also worth noting in both cases the fines do not seem to reach as far as the maximum 4% of top line revenue revenue allowed by GDPR. This means the ICO has put consideration in assessing the size of the fine and opens the door for larger and larger fines in the future.

In the age of the ubiquitous software supply chain it’s more important than ever to implement controls early to be able to prevent and detect such issues slipping by unnoticed. As the ICO case proves, we now have a grand total of 282 million reasons why.

Try Out a Real Software Supply Chain Attack

If you’re interested in simulating a software supply chain attack, check out our synthetic container. It shows how a simple unpatched version of a framework and an older unpatched server can lead to an attack gaining full control of a server in less than 40 lines of code. The GitHub repository simulates a seemingly innocuous project that simulates what most projects could do, but with dreadful consequences.