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 responsible for personal information and data. The ICO states that the GDPR legislation clearly mandates organizations to consider how data is stored and what happens over the entire life cycle.
In both cases, the ICO cites significant lapses in information security practices for the reasoning behind the fine. Without knowing the details, 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 loaded external resources used to skim the payments forms for credit card details from over 380,000 victims.
Fundamentally, from an engineering standpoint, this could be classified under the family of software supply chain attacks due to the fact that a third-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 attacks do not rely on a single weakness in the chain, but typically result from several corresponding incidents. In this case, an unpatched version of Magento was leveraged to further down the software supply chain and poison a seemingly standard third-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 learn here.
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 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 require a complete reconstruction of servers on deployment. As containerization has become more common, fully redeploying that part of the software would've likely erased the malicious appendix from the software.
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 that you know what is deployed and its compliance.
Post deployment in an ideal world, one might also consider verifying the deployment target is still what it was meant to be.
This shows GDPR legislation finally getting its spurs in terms of larger fines, and paves a direction for future breach fines. As more recent breaches are disclosed and investigated, we're sure to see larger fines assigned based on the legal power of the legislation.
It's also worth noting that in both cases, the fines seem to not reach the maximum 4% of top line revenue revenue allowed by GDPR. This means the ICO has considered 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 prevent and detect such issues slipping unnoticed. As the ICO case proves, we now have 282 million reasons why.
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 that gained 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.