What can charities learn from a recent £3 million data breach?

Back in March, the Information Commissioners Office (ICO) issued a £3 million penalty to software company Advanced following a ransomware cyber security incident which happened back in 2022. Advanced make software used by many Beacon customers for social care and healthcare management.

The findings of the report present a worst-case-scenario for charities and software providers alike: “The investigation found that personal information belonging to 79,404 people was taken, including details of how to gain entry into the homes of 890 people who were receiving care at home.” That’s really scary stuff.

In this article I want to present the three things that led to the incident, how it could have been prevented, and some security tips for your charity. But first, we need to talk about cheese.

Swiss Cheese

The Swiss Cheese Model is a helpful way to think about building secure systems. Every security mechanism is imperfect and will have some holes, much like a slice of Swiss cheese. The solution is to take a layered approach to security, placing several different slices on top of each other. Now it’s far less likely that the holes will all line up, and we have built a robust security system from imperfect slices. This is why when things go catastrophically wrong, you’ll often find that a combination of multiple smaller things have gone slightly awry in sequence. You’ll see this everywhere from data breaches to air crash investigations. So let’s look at the three smaller things that combined to create this incident:

Problem 1: Vulnerability Scanning and Patching Wasn’t Being Done

It’s important to install software updates when we’re told to. On 11 August 2020 Microsoft released a security update including a patch for a critical vulnerability in a protocol called NETLOGON, which can be exploited to allow someone to gain administrator-level privileges.

Microsoft identified the vulnerability and provided a fix in 2020, but in 2022 this exploit was used to gain admin-level access and to extract the data. The breach could have been prevented at this layer by vulnerability scanning (to identify that the vulnerability had not been fixed) and applying the patch that Microsoft had released. It’s worth noting here that Microsoft identified and provided a fix for their vulnerability 2 years before this incident. This should have been more than enough time to find and fix the issue, but unfortunately no evidence was presented to the ICO to demonstrate that regular vulnerability scanning was taking place. You can’t fix something if you don’t know that it’s broken.

Reference: Sections 27 and 53-61

Problem 2: Penetration Testing Wasn’t Actioned

Penetration testing involves getting another organisation to try to hack your systems, and then report their findings to you so you can fix the vulnerabilities they find. The process is actually quite good fun, and is critical to testing security systems in the real world against real experts who are being paid to find weaknesses.

But crucially, this testing needs to be repeated regularly, and you need to fix the vulnerabilities that are found! The ICO report found that penetration testing was “infrequent”, and worse: “where penetration tests were conducted, some of these revealed vulnerabilities which were later exploited in the incident”.

If a remediation plan had been put in place and carried out, the vulnerability would have been fixed when it was identified by a penetration test, even if it was missed by vulnerability scanning.

Reference: Section 63

Problem 3: Two Factor Authentication Wasn’t Being Used

How did the attackers get into the system in the first place? Through an admin customer account which didn’t have 2FA enabled. The layer of security provided by 2FA was not in place because there was a perception that customers would find it too inconvenient to implement.

This didn’t cut the mustard with the ICO, who consider 2FA to be “a fundamental security measure” and found “the lack of (2FA) constitutes an infringement of Article 32(1) UK GDPR”.

The ICO are sending a clear message: They don’t consider the inconvenience of setting up 2 Factor Authentication to be an acceptable excuse.

Reference: Section 122(f)

How do we prevent this at Beacon?

This incident happened because all three of these problems aligned to create a hole right through the block of cheese. Fixing any one of these issues would have prevented the breach, but it’s always good to make sure that they’re all fixed. For example, here’s what we do at Beacon:

1: Vulnerability scanning and patching

At Beacon, we have automated vulnerability scanning from two independent sources of code vulnerabilities. These are displayed to our engineers and we have SLAs in place to make sure that vulnerabilities are fixed quickly. We deploy updates to Beacon several times a day, so we can make sure that everything is up to date. We also use a system called Kandji to make sure that all of the critical software running on our computers is automatically kept up to date, from Chrome to critical operating system updates.

The configuration of our vulnerability scanning and patching is audited as part of our ISO27001:2022 certification.

2: Penetration testing

We run a penetration test every year with a CREST-certified pen test company. They work hard to try to find holes in how we secure Beacon accounts, our API, and Beacon forms. When the report comes in, we create a remediation plan to fix all of the vulnerabilities straight away.

The tests, the remediation plans, and evidence that the remediation work has been carried out are audited as part of our ISO27001:2022 certification.

3: Two Factor Authentication

All Beacon admin accounts are required to have 2FA enabled. As an admin, you can require that all of your Beacon users have to set up 2FA. Additionally, Beacon supports logging in via Microsoft and Google - which adds an extra layer of security on top of a user name and password. You can find out how to set up 2FA in Beacon here, and you can find out more about signing in with Microsoft and Google here.

These features are, as you probably expect, audited as part of our ISO27001:2022 certification, and tested for exploits during our penetration tests.

What can charities learn from this incident?

As a charity, what should you take away from this incident? Here are my suggestions:

1. Keep all of your software up to date regularly - if Chrome tells you there’s a new version available, install it as soon as you can.
2. Enforce 2FA across your organisation - wherever possible all logins to all systems should be using 2FA. Remember, the ICO considers this a “fundamental” security measure and we’ve seen that they don’t look favourably on organisations that don't use 2FA.
3. Sign in to your critical systems using Microsoft or Google - add an extra layer of security, and centralise your account administration for different logins, by using either Microsoft or Google to log in to systems whenever you can.
4. Require that your software suppliers are ISO27001:2022 certified by an accredited certification body (e.g. UKAS) - A good way to make sure that your software providers are implementing best practices is to ensure that they are ISO27001:2022 certified. Watch out for the old version of ISO27001 (ISO27001:2013) which expires in October 2025, and make sure that the certificate is issued by a UKAS accredited auditing body, so you know that the audit is carried out to the appropriate standard.

Conclusion

Security is about layers. A single layer may be imperfect but together they can make a system that’s robust and secure. If you leave out multiple layers, or don’t configure them properly, then you can leave yourself vulnerable to some really awful things happening, like we saw from this incident. Make sure you’re adding lots of simple layers of security in your organisation!

If you’d like to read the full report from the ICO on this incident, you can find it here, and you can find more information on how Beacon keeps your data safe here.

‍