Our cyber security products span from our next gen SIEM used in the most secure government and critical infrastructure environments, to automated cyber risk reporting applications for commercial and government organisations of all sizes.
The looming EU GDPR requirements around privacy, data breach notification and data protection (along with the equivalent UK legislation that will inevitably mirror EU regulations after Brexit), are causing bow waves through IT delivery, cloud hosting, security, compliance and privacy across organisations of all types and sizes. How bad will a data breach notification actually be?
One of the reasons for this is the size of the fines that could be incurred. The maximum fine for a data breach is €20m or 4% of global turnover which is a large enough figure to get the board of any company to take notice.
There are also requirements around the “right to be forgotten”, the onus on having consent to process data and the potential joint liability between a data owner/controller and a data processor when a breach or failure happens (previously processors weren’t liable, only the controllers, so the effects were often limited by the contracts in place).
One of the main talking points, comparing the pre- and post-GDPR world is around the need to notify the authority (in the UK this would be the Information Commissioner’s Office, ICO) when there is a data loss, breach or other issue.
This requirement is, without a doubt, a big change to the way data and privacy breaches are handled. However, it is not without precedent – in the UK for example telecoms companies have had some breach notification obligations for a while and in the US many states have a law requiring them to inform people whose data they have lost or leaked.
It is worth noting that while the EU regulation will apply directly and should be consistent across the EU (and UK), different authorities in member states may have subtly different policies, objectives and motivations in how enforcement happens.
In any case, while GDPR is not something to panic about, and the rules are intended to be “proportionate” according to the ICO; there are topics that are genuinely worrisome for businesses and security teams.
It is not true that all breaches must be notified, instead there is a criteria for notifications to be made. To quote Article 33 you don’t have to notify the authority if:
“the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons”
So there will be cases where the extent of the data, or the nature of the business, or the content involved can be deemed “not risky”. Hence a business could, as now, decide to handle things internally and potentially more quietly should the impacts not be too severe.
One difficulty is that the above criterion is highly subjective. Does a business play safe and report any situation where they might need to, or can they make assumptions that mean they don’t have to – possibly assumptions which might turn out to be incorrect but are still defensible. Would a privacy officer feel that a breach should be notified but be overruled by more senior management who disagree?
Take a dating site – one that aims to find relationship matches for single people; a data breach of users and email addresses might be deemed to be unlikely to cause embarrassment. As a dating site/database of people who want to meet someone, there’s no harm, or shame, or stigma. However, if those names and email addresses include people that turn out to be married (as in the more specific case of Ashley Madison) then suddenly for those individuals you have issues with a higher degree of impact and risk.
The general guidance in any regulatory situation is to be prompt, truthful and complete in reporting issues – so this will be an important decision point in the incident handling process where the right balance must be achieved. The challenge of handling these notifications, if they become overdone, could be onerous and we must be watchful as a society that we don’t suffer from “data breach notification” fatigue.
The 72 hour window to send notifications is, by any measure, a tight deadline. See The 72 hour GDPR challenge.
It is unlikely that your local regulator/authority/commissioner is going to expect a fully detailed incident investigation within that time window – but gathering the data, analysing it and forming an opinion as to whether to notify or not is a piece of work in its own right.
The decision as to whether you need to notify the authority and what to say is unlikely to be a decision taken by a front-line security operations analyst who might be able to rapidly decide that an issue should be routed to the firewall team, or to HR, or to the web team. For GDPR data breaches, even with a defined playbook or set of (hopefully objective) criteria, there is going to be a need to discuss and consult based on collected and available information – and quickly!
If we refer once more to the Regulation text:
It is easy to see that while not all of the information might be available within 72 hours to populate your data breach notification, there does need to be some initial awareness, conclusions or possibly educated guesses and likely hypotheses as to:
The worrisome nature of the 72 hour figure is not one to underestimate; breach detection and response is typically measured in months, weeks and days – not hours. As such, mobilising the right people and focussing them on questions that relate specifically to the data breach notification as part of the initial incident response is important, particularly when there could be competing priorities like bringing affected systems down, getting restored ones back up, resetting user passwords or answering other less pressing questions such as, “Whose fault this was?” or “Why did you allow this to happen?”.
One challenge that forms part of the incident resolution process is finding out what information was actually affected, and hence the people concerned and the scale of risk faced.
In some cases the breach emerges as a result of thousands of names, credit cards numbers and passwords being posted on the web somewhere. This gives you both the breadth and depth of the data loss (in theory) but it isn’t always that straightforward.
Consider a medical insurance database (or generic data set). There will be information on customers, but also most likely former customers. S ome of this will be sensitive (at various levels) and some non-sensitive (effectively already public).
For example, there are different severities for different types of data associated with the people in the database that you will want to ascertain before you make a data breach notification – partly to understand the severity :
The reality of both the “what happened?” diagnostics process and the “what do we do about it?” response highlights the criticality of information from monitoring of systems, networks, applications and users.
The value of an historical record, for both detection and diagnosis – and having it in an easily accessible, central place – cannot be underestimated. Attackers may obfuscate their attacks by destroying local logs, compromised systems may not be accessible, malware might render systems unusable and insiders may have covered their tracks very effectively.
Additionally, it is not uncommon to find that local systems or specific monitoring technologies may only hold diagnostic or log information for a short period of time before it is rotated out or purged, or they may provide a subset of the network flow and system activity information rather than a full record in its entirety.
A good example of this is a network packet capture solution – the network trace(s) pertaining to an attack might be highly valuable to see what the initial access was, where it came from, what commands or accounts were used, what database queries or attack strings were involved and – crucially – what volume of data left the network or was accessed. Clearly an information source that is of value!
It may be that the network itself is the only source of information on the size or scope of a breach if database query or file access logs can’t give the answers needed. Network session information (even if obfuscated) might give a clue as to the data volumes and hence number of records – in particular if the attack was noticed promptly and the data flow interrupted mid-way through.
If a data file/database compresses at a set ratio of 40% (on average) and there was an intercepted data loss of 8Gb (compressed and encrypted) then you are talking about a 20Gb total data volume. Work back from that with the size of an individual record and there may be an initial estimate of the number of affected subjects or customers.
These calculations all require monitoring of a variety of data sources ahead of time, before and during an attack– otherwise trying to work out what happened afterwards won’t be possible.
As well as notifying the authority itself there is a need to notify affected data subjects “without undue delay”.
Assuming the investigations above have resulted in a list of (potentially) affected people then there is the task of communicating with them and deciding what to say. As data breach notification laws or regulations have been in existence in some sectors and jurisdictions already there are often services available that can be called upon to assist with this.
If the number of people affected reaches into the thousands or millions then this might be the best way to handle the notifications, the questions and any response.
To give a rather ironic example, given their own recent data breach, here are the services one provider offers in this space:
Difficulties abound in handling communications with large numbers of, often upset, people. For instance:
In short, no part of this process is easy. Even if you have actually decided what you are going to say, what advice you are going to give and what promises, discounts, compensation or insurance cover you are prepared to offer.
Feedback from past breaches seems to imply that a breach handling service is one of the better ways to deal with the scale problem – most companies just don’t have a facility to communicate en masse with every customer/data subject at the same time and in a short window.
It also seems to be accepted good advice to tell people that they will be written to or contacted if they were affected with details of what the impacts are, what to do and to be reassured that you will “fix things” – this both slows down the hyperbole, takes the sting out of criticisms of slow response and constrains the burden of dealing with individual questions or angry callers to the switchboard trying to ascertain if their data is part of the affected subset.
The chosen approach needs to be flexible enough to deal with a range of scenarios. It also needs to be accompanied with internal guidance for staff so they know the process and what to say.
Social media can work fast, it is also unconstrained by the truth, widely used as a discussion and news channel and likely to operate more noisily and actively than your more measured and cautious diagnostic processes, messaging decisions and PR sign off steps.
Social media is a great medium to communicate with customers or to push out reassuring, apologetic or advisory messages. For a company affected by a breach, while all the investigation and notification is going on internally, the public channels need to be observed as well. The data breach notification to the relevant authority must be accompanied by this more customer/data subject centric message.
Ensuring that sentiments and opinions about the breach are being factored into the communication messages for potentially affected subjects and that failings in call-centre operations that get reported are followed-up and can be responded to, gives you a fighting chance of heading off the negative frustrations.
This might not be required directly by GDPR, but the overall handling of the breach and level of public/media outcry is a facet of the response that you will want to be on top of in parallel with the regulatory requirements. Being slow to notify people when public opinion is racing ahead can only make the handling look ineffectual.
It is likely that the effective use of social media will be one way to justify reductions in fines and mitigate the exposure risks as part of an effective communications strategy. Hence this is a complex dimension of the breach notification process that is crucial to consider.
Is the breach deliberate or accidental? The answer may well be key to the scale of the problems a breached organisation faces. An attacker who steals information with the aim of making money, or extortion or causing embarrassment might be a completely different prospect to the effects from an accidental leak of data to the public. However, the secondary motives around stolen, lost or misplaced data might only become apparent once it has been posted on-line or flagged as such when further parties gain access to it.
Data captured and hosted on an Internet forum or dark web site might be accessed by a range of people with various motives, or could be used to spawn phishing or social engineering attacks. Additionally, where passwords are involved, and given the frequency of password reuse; there could be other sites and systems that suffer knock-on effects of breaches that happened elsewhere.
A breach caused by a clever, determined, motivated attacker might be easier to explain or justify where effective (but circumvented) risk controls could be demonstrated to have existed. Certainly this scenario is arguably more defensible than sloppy network defences or poorly secure web code allowing a low-sophistication dump of the entire customer database.
The motivations of the attacker and any impacts from stolen credentials, credit card details or medical/sensitive information will depend more on the data content and the ingenuity with which it can be exploited, rather than the skills or motive of the original data thief.
In any of these cases, the data breach notification you make is going to have to present some understanding of both the original attack and the potential future implications. The route of compromise and the likely future impacts will shape the response and, in all likelihood, any fine incurred.
In this post, we have explained 7 ways in which data breach notification proves challenging.
The reality is that breaches won’t happen (hopefully) too often, but these considerations need to be thought about ahead of time and the necessary processes, training, technology and planning must be undertaken now so that the breach and associated notification process is as risk-free as possible. The requirement for data breach notification and the timescale make for some very different challenges when conducting an incident response.
If you need some reassurance around your level of risk, or if this blog post has convinced you that data breach notifications are a big deal and you need to start justifying some investment, the Huntsman Security GDPR Risk Tool is worth using to get some answers as to the possible size of the problem you might face when you lose some data, get hacked or suffer from an insider threat and are trying to pull your first data breach notification together. It is free to download from the link below.
A recent KPMG Report suggests that protecting against and dealing with cyber risks will be the major challenge for senior executives in 2024. It is clear that despite high levels of security investment, organisations continue to suffer from cyber attacks.Read more
The Australian Signals Directorate’s (ASD) recent publication of their Cyber Threat Report 2022-2023 unearthed a range of areas for concern for government departments and critical infrastructure entities at local, State and Federal level.Read more
As cyber risks increase, organisations are encountering the longer life cycle of insurance renewals and the need to demonstrate better management of security controls and their effectiveness.Read more
Highlights and insights from the recent Managed Services Summit in London & the ISACA Central Chapter Conference on Digital Trust, in Birmingham, UK. With two recent conferences in the space of three days, some interesting challenges were very evident in the topics discussed. Being very different events, the challenges were quite different, but interestingly they […]Read more
In early August 2023, the latest joint advisory on persistent vulnerabilities was issued by the intelligence and security agencies of the “Five-eyes” community. These joint advisories are becoming more common. Perhaps recognising the growing importance of shared security information and the common nature of many of the threats faced – the weight they carry makes […]Read more
The quality of your risk assessment and the security information it provides is important; if you plan to use it to actively manage your operational and cyber resilience activities. Organisations are constantly exposed to a rapidly changing threat environment, so you really need a similarly rapid evidence-based feedback system that informs you of the ongoing […]Read more
The UK market has its own regulators, security standards and challenges. And while rulings from SEC in the US or the Australian Prudential Regulation Authority (APRA) in Australia don’t apply to UK companies, for the most part, the observations are undoubtedly relevant and the resulting advice instructive. It would be wrong to think UK financial […]Read more
<<< Part 2a: Australia’s Essential Eight: Beyond Endpoint Control <<< Part 2b: Activating UK NCSC & US NIST Guidelines: Beyond Endpoint Control Part 4: Systematic Measurement of Cyber Controls >>> As much as we invest into cyber security controls, external threats are inevitable. In a recent Notifiable Data Breaches Report from the Office of the […]Read more
Keen campers, scouts and even the Swiss Army know – that a good penknife is indispensable. This simple device has mitigated many a disaster at one point in time or another. Whether it’s to cut through a bit of string, tighten a screw or simply to solve the problem of no bottle opener in the […]Read more
Supply chain risk is an area of cyber security that demands the ongoing attention of every enterprise; because it can make the difference between being resilient or not. It’s no surprise that insurers warn that the vulnerability of supply chains is potentially a systemic risk that can quickly propagate across supply chain dominated industries. Organisations […]Read more
Read by directors, executives, and security professionals globally, operating in the most complex of security environments.