Who’s Data Breach is it Anyway?

Welcome to Whose Data Breach Is It Anyway? The blog post where everything is worrying and traditional security does not matter. That’s right, traditional security is like going home and expecting no one from work to call you. (with apologies to Drew Carrey)

Before we can answer that question, let’s start with defining a few terms.

Traditionally, cyber security is about using firewalls, anti-virus and anti-malware tools and relying on the operating system and software you use to keep you safe, to update itself and to alert you of issues. Sure there is a LOT more that can be done, but the vast majority of companies and users rely on just these. To achieve this all that organisations need to do is create a policy and a set of controls/tasks that deal with security updates – and practice this daily.

A more robust approach is to trust no one (what IT people call “zero trust” or “zero trust networks”). We should have “zero trust” in vendors to push updates, and for vendors to ensure those updates correctly install. We should have “zero trust” that all staff have correctly checked for updates (I will be the first to admit that I have also missed updates before – no one is immune and everyone needs a second set of eyes!) Zero trust also means that we need to be careful who has access to what and for what purpose. This takes a lot of effort and requires periodic reviews of access levels. And – lastly – zero-trust also means we need to be VERY careful what we install – even if its from a known and respected software vendor (afterall, zero trust means zero trust…)

Of course we cannot double check updates for bad code from huge organizations like Microsoft – none of us have the resources at hand to do that. However, we should be aware that all updates and installations carry a degree of risk – supply chain attacks are on the increase (see for example Kaseya in June 2021)

Physical checks of user equipment to ensure patches are correctly installed is a must – non-IT staff may not be sufficiently trained to recognise issues and ensure patches are correct. Doing this is a cultural mind shift – it brings security concerns right to the desk of all staff and makes security top of mind in the organisation. I won’t lie to you – this is a difficult transition. Business people (and I can understand their stance) put clients and business first. What we need to do is ensure that “business people” understand that “security first” is also “business first”. Data breaches are more and more common, and more and more data is being compromised in each breach. As at end September 2021 the number of data breaches for the year already exceeded all the data breaches for the entirety of 2020!

Now that we have discussed what should be done and the limitations imposed on us to ensure things are done regularly and without risk, lets return to the topic of this blog – Whose Data Breach is it Anyway? The simple answer is “the company who loses control of the data is responsible (or accountable) for the breach”. But if we simply accept the short answer then this blog post is over and my work here is done! None of what follows here is a legal defense nor is it advice of any sort – I simply want to explore a topic that has been burdening my mind for some time so that this particular topic gets more attention.

Lets examine some hypothetical / fictional scenarios.

Scenario 1 is when respected, pervasive and well built software leads to an exploit. Here we delve into one fictional world where I want to explore “culpability”. What happens if a security flaw in our operating system, web browser or suite of office productivity tools – as yet unknown to the vendor – compromises our work computer and data is leaked.? Are we responsible for the data loss suffered in this event. A clear argument can be made that you are merely a victim here – the situation is akin to your brakes failing on a brand new vehicle. Are you responsible for an accident? For our hypothetical data breach, “yes” GDPR / POPI will hold you responsible, but what could you have done to limit the data breach? Can you be accused of being negligent? What are the factors involved:

1. How much data was available on your device
2. Was the data actively being used or was it old data you did not archive
3. Are all possible security measures up to date (patches, antivirus, antimalware)
4. Are you able to demonstrate your policies and controls for data retention and security updates

Much like our motor vehicle accident example, culpability can be determined by the level of negligence and the amount of personal responsibility involved. Regardless of the defective braking system, if someone were DUI at the time of the accident they would find it difficult to get a sympathetic ear from the judge! Likewise, having sufficient personal accountability and sufficient additional layers of protection in place in the event of “defective software” would go a long way towards appeasing regulators in the event of a data breach.

Some actions we can take to limit data breaches would be:

1. Limit the data you have access to at any point in time. Ensure that as far as possible you only ever have direct access to data and files you really need at that point. If you have access to 1000s of data files in real time, then so does any hacker or any malware that has access to your computer!
2. Routinely archive and clean up data that is not in use – automated tools to do this exist. Regulators do not look kindly on data breaches that contain many years of “old data” that should have been archived!
3. Update your computer every week – or more often. Check routinely that patches are all up to date by physically running a manual check. Do not rely on automated patches installing – check them (zero trust!).
4. Have solid policies and controls in place to double check compliance and record which files have PII and to check that “old files” are archived securely.
5. If you are in charge of your organisation’s cyber security or data security, ensure the above is done by everyone – check, check, check and record the evidence of having done that!

In this way – even if the breach is a result of a third party vulnerability (the tech equivalent of defective brakes) – you can demonstrate sound security hygiene, sound adherence to data retention regulations, and limit the amount of data a cyber criminal has access to.

So, back to “Whose Data Breach is it Anyway?” and Scenario 2. At the beginning of July 2021 a software provider (Kaseya) were hacked and a vulnerability was packaged into their software. (For the curious this is a “supply chain attack”). This software was subsequently released and hundreds of companies were affected. Companies installing the new software update were victims here – they installed updates to software they had every right to expect to be safe and had no reason to suspect of being malicious. The hypothetical question here is “if significant amounts of PII had been leaked, who is responsible? Is it Kaseya or is it their client?”

Would the situation change if the security incident were not as a result of the injection of malicious code but rather due to a software defect? Imagine a hypothetical company (we can call them ABC Software) that releases an update to their product that accidentally creates a vulnerability that hackers exploited. Again, much like Kaseya, the client had every right to expect the software to be safe and had no reason to suspect anything malicious. If PII were leaked in this event, who is responsible?

There are even a number of zero-click malware exploits in the wild (a zero-click simply means that malware can be installed even if you do not click a link or open a malware executable – your device simply needs to receive the malware. Pegasus hit the news almost world-wide recently for example). I am not going to answer my own hypothetical – this is a thought experiment in how we perceive data breaches and liability. However, once again, like in Scenario 1 above, the scale of the damage can be contained by limiting what can be breached in an attack.

So, regardless of “Whose Data Breach is it Anyway?” it’s important that we know:

1. The organisation that breached the data is responsible
2. Software vendors have an obligation to ensure their software is free of defects, that defects are corrected timeously and that their supply chain is secure. However, at least as of now, software vendors are not being held accountable to regulators for data breaches at their customers which result from their (the vendor’s) flaws.
3. The best way to protect yourself is by limiting what can be breached, by deleting files you no longer need, encrypting what cannot be archived and / or deleted, and by continuously monitoring for data that should not be kept available.

In summary, when it comes to software product defects I will be interested in the future to see if society and the law adopt a “product liability” stance where manufacturers are either subject to “strict liability” or we have “Joint and Several Liability” – especially where such defect leads directly to a data breach. (If a lawyer out there wants to do a mini article on how that could work with software I would happily link or post with full credit!)

Keep safe!