Hacking Horror Stories Vol.4 – Morrisons
This article refers to our former reporting, security, and management products. We have now integrated these products into Nova, an all-new Office 365 management platform. Find out more
Our next Hacking Horror Story in our week of data breach spine-chilling tales for Halloween is about the UK supermarket chain Morrisons.
Morrisons is a bit of an old English treasure, the wholesome family-run brand was founded in 1899 by a man named William Morrison, who sold eggs and butter on a market stall in Bradford. His son Sir Ken Morrison then took over the business in 1952, and during his successful career in retail he received a CBE (The Most Excellent Order of the British Empire) and was knighted by our dear Queen. You can’t really get more British than that.
The egg and butter stall soon turned into a supermarket giant and now has 498 stores, an operating income of £468 million and 132,000 employees. Unfortunately for Morrisons, in that workforce was Andrew Skelton. Skelton was a former Senior Auditor at Morrisons HQ in Bradford, who callously trashed his own bread and butter in 2014 by stealing the data of nearly 100,000 Morrisons staff which he then posted online and to the papers. The huge data exposure contained names, addresses, bank account details, and salaries. The clearly disgruntled and devious auditor was quite rightly imprisoned for eight years for fraud and the data breach cost the company almost £2 million to rectify. In the end, they were awarded £170,000 in compensation against Skelton.
This would be any CEO’s nightmare, but it was only just beginning…
Morrisons Data Breach – The Aftermath
So Morrisons thought they lived to tell the tale, until four years later…
In 2018, a group of 5,518 current and former staff have come together, sharpening their pitchforks to sue the supermarket brand. They argued that the brand was vicariously liable for the data breach and that the £170,000 Morrisons were awarded in the court case should have been shared with the other victims involved.
The grocery giant fought back and denied being liable for Skelton’s untrustworthy nature and exposure of their employee’s data. Also arguing that they had already paid a hefty £2 million in their attempts to resolve the issue. Unfortunately, the High Court ruled that Morrisons were accountable for the data breach, therefore meaning they would have to pay out.
The sickening twist of this story is that the data breach didn’t just affect the 5,518 staff who came forward, but another 94,000-people were affected by Skelton’s exploitation. As the court has ruled that Morrisons are legally responsible, this means they are subject to compensate all these people if they were to come forward.
You don’t need to do the maths to work out how many apples and pears the supermarket chain needs to sell to pay this one off. Just know, it’s an awful lot.
Could this breach have been avoided?
Although it seems like this breach was out of Morrison’s control because of Skelton’s actions, there are some ways this kind of situation could have been prevented, or failing that, detected quicker.
User and admin management is an ongoing challenge for organizations, and of course there’s no way for us to know whether Skelton needed or possessed elevated privileges for his role, but he was in the Finance department, and clearly had access to sensitive files. There should have been IT measures in place to minimize this risk.
Someone should have restricted Skelton’s access to just the data he worked with directly. It might be that there was a valid business reason for him to have the access he was assigned, but perhaps there wasn’t. It sounds simple, but it is shocking how many organizations don’t restrict access carefully enough, neglecting to identify and address unnecessary access rights or privileges that could pose a risk.
We have two solutions that could have prevented a similar incident in Office 365. Our new tool Autopilot is a sophisticated SaaS application that simplifies Office 365 administration and management. The solution can be used to automate administrative tasks, delegate control of Office 365 to other users in an organization and keep users compliant to a standardized baseline within their team or group, maintaining compliance and security.
Under the context of Morrison’s situation, Autopilot could have helped avoid misapplied privileges, and improve overall control and compliance. The solution enables Office 365 admins to set permissions and authorizations across Office 365 at a granular level in a way that is standardized and straightforward. Within Autopilot, admins can create virtual Organization Units (vOUs) and bring any existing structures over from an on-premises environment or manage using a hybrid environment. An admin can create vOUs in Autopilot (e.g. a UK Management vOU, or a Finance Team vOU) and apply configuration and authorization policies to those units. This ensures users are always assigned the appropriate settings and (if needed) privileges for their role. You can even create configuration and authorization policy templates, so they’re simple to apply.
Universally, IT teams aim to provide people with the tools and access they need to do their job, and no more. From there, it’s about control and visibility, and achieving the (often elusive) balance between the two. We’ve talked about control with Autopilot, but what about visibility? Autopilot has audit logs for all activity undertaken by admins within the tool, and the actions that their policies trigger, but what if your rogue threat wasn’t an admin?
Our Office 365 reporting and security application, Radar Reporting could have been used effectively in this scenario too. Morrisons would have been able to acutely monitor Andrew Skelton by getting visibility into his access to sensitive files. They would have seen him download or modify the files containing employee data in the Files and Folder Operations Report (featured below), with details of when and where this incident happened. In terms of prevention, if the organization had suspected Skelton might be a risk or wanted to bolster their security practices for his team in general, they could have got a clear view of permissions assigned for this area and configured an alert which triggered when Skelton (or anyone else in his team) accessed, modified, downloaded, or deleted these files.
Are your approaches to Office 365 management and security capable of dealing with a threat like this? If you think your organization could benefit from better control and visibility, why not get in touch for more details on how Autopilot or Radar Reporting could help prevent an incident like this.