Ransomware is (according the National Cyber Security Centre) ‘a type of malware that makes data or systems unusable until the victim makes a payment’. This type of Cyber threat has been growing steadily for a number of years and the NCSC (and others) have produced a range of guidance for organisations to try and tackle the rise of the cyber warfare.
On the 10th March 2022 the Information Commissioner’s Office (ICO) announced a monetary penalty for a private law firm, Tuckers Solicitors LLP. What makes the notice particularly interesting is that it was a series of failings surrounding the Ransomware attack Tuckers suffered in August 2020.
The first thing of note is that the period of time that the ICO says the enforcement covers starts from the 25th May 2018 (GDPR implementation date in the UK) and the 25 August 2020 when Tuckers reported the breach to the ICO.
It appears that Tuckers suffered a ransomware attack that had ‘encrypted’ (and therefore rendered inaccessible) the civil and criminal legal case bundles stored on an archive server, including the backups. According to the notice, “In total, 972,191 individual files were encrypted. Of these, 24,711 related to court bundles. Of the 24,711 court bundles, 60 were exfiltrated by the attacker and published on an underground market site (the “dark web”).”
It was confirmed that many of the bundles contained Special Category Data relating to a number of civil and criminal cases that the law firm had been involved in. Some of the cases were ‘closed’ however Tuckers did highlight that a handful of cases to which the data related were still live.
Tuckers had attempted to be certified under the Cyber Essentials scheme but had failed the assessment and not then actioned the points to re-assess as soon as possible. Meaning that at the time of the breach they did not meet the standards of the CE scheme.
Tuckers have now moved to a new server environment but they were not able to restore the lost data which, although the notice doesn’t state this, one would presume is still on the Dark Web and with the attackers.
Although Tuckers had brought in outside help to investigate the Cyber Breach and produce a ‘Cyber Incident Response Report’, a definitive cause was not identified. However some ‘known vulnerabilities’ were highlighted that could well have been a key factor.
Tuckers had deployed a patch to fix said vulnerability but for a period of 5 months it was ‘unpatched’ and it is likely the attacker exploited the vulnerability during that time to gain access to the network and place the tools they needed to encrypt the server and its backups.
The ICO states that Tuckers is ultimately responsible for the impact of this incident because of the following reasons:
- A lack of multi-factor authentication on its network/remote access tools. While this doesn’t stop completely exploitation, it does make it much harder for attackers to exploit. Several frameworks from the NIST, NCSC & the ICO’s own guidance recommends installing it. Especially for ‘high risk’ areas where ‘sensitive’ data is being stored/accessed.
- Lack of patch management meaning that the specific vulnerability was alerted to the public domain in January 2020 via the NCSC (and others) and was rated as ‘critical’ by them however Tuckers installed the patch 5 months later. The ICO, NCSC, NIST and the Solicitors Regulation Authority (SRA) all advise ensuring up-to-date IT systems so a an argument of ‘lack of awareness’ or ‘priority’ doesn’t seem to hold much water with the ICO here. It is also worth noting that the patch was free so the ‘cost’ would have been testing and change management time which the ICO states should not have been a barrier to deployment.
- Lack of adherence to their own policies and standards on Data Protection that outlined that “all software, operating system and firmware shall be updated on a regular basis to reduce the risk presented by security vulnerabilities”.
- Failure to encrypt data at rest. The ICO also outlined that had the data been encrypted at rest it may have mitigated some of the impacts of the breach. For example, if the attacker cannot get the data then the threat to confidentiality is reduced and what is left is the issue of the data now being ‘lost’. Given the sensitive nature of the data, and the guidance from the ICO and others, the ICO believes that to not have even considered encryption at rest for this sort of data was an important factor here.
- Duration of the lack of controls. In their arguments for ‘severity’ of the infringement, the ICO has outlined that these lack of controls were in place from the 25th May 2018 up to the date the incident was reported to the ICO. So the ICO hasn’t just taken into account a lack of controls during the period of the incident, but also the context that these controls were not in place from the ‘starting point’ of GDPR being in place and requiring such measures.
- Turn on MFA as soon as you can. It’s advice for organisations and individuals and is perfectly sound advice. Depending on the operational challenges, explore turning it on as soon as you can or overcome the barriers to doing so as soon as you can.
- Have an informed patch management policy. If you can’t apply patches etc in a timely manner then manage the risk. But do it from an informed position. Advice and resources from the NCSC and others can educate your decisions. Awareness in this case may well have resulted in a more pressing need to resolve the matter.
- Risk assess your assets. While the ICO isn’t dictating the use of encryption here, have you risk assessed the threats to your datasets? What other controls are you relying on to mitigate the need for such encryption? Do they work? Are they tested or externally validated where appropriate? Otherwise sometimes planning for the worst case might be the best and most cost effective option.
- Time is not your friend. Just because it hasn’t happened yet, doesn’t mean it won’t. Unnecessary delays to your patching, compliance programmes, assessments etc won’t help you in the long run. Especially if an external assessment says you have some key issues, delays should only be where unavoidable and priorities should be agreed based on the level of risk.
- If everyone is telling you something, you might want to do it. This is another example where the argument of not knowing any better also doesn’t hold much. As we saw with the BA enforcement, if the NCSC, ICO, industry bodies and others are all saying the same thing (and giving free advice and tools), what is stopping you from actioning it? Especially when that thing is a major issue/threat that is affecting more and more organisations.
Am I surprised by this enforcement action? No, not really. With the rise of such technology it doesn’t surprise me that incidents and enforcement is starting to come out of the ICO case load woodwork.
What is interesting is the approach of taking into account that these controls were in effect from the starting point of GDPR. That is an interesting approach and one that I think I agree with. When GDPR came in there was a lot of noise and guidance around many thing, including Cyber Security. So to not have effective controls in place from the 25th May 2018, or to not have a risk management strategy in place for where controls can’t be put in place, does make it a fair point to raise (in my opinion).
Will we see more of these sorts of ransomware enforcement? I do hope not, but I am not convinced that we won’t. From pure personal experience and exposure I know of schools, councils, businesses and others that have all fallen victim to Ransomware. While the attack itself isn’t necessarily your fault, the lack of planning for it is. I am always split when it comes to using an organisation as an ‘example for others’. We do learn from it (or try to for most of us) but it does seem a little like the ‘sacrificial lamb’ for that organisation that is used as the example.
So hope for the best, plan for the worst, and react in the best way you can if and when the proverbial does hit the fan.