The 72 hours GDPR challenge

September 4, 2017
Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someone

The 72 hours GDPR challenge. GDPR is nothing if not a dominant force in the cyber security industry’s marketing efforts and direction of travel.

72 Hours GDPR Notification of Breach Period – Is this Achievable?

Many seasoned professionals, are already tiring of the onslaught having gone through repeated compliance regimes in the course of their careers (7799, 17799, 27001, SOX, PCI-DSS, DPA, FOI, SPF etc., there has been no shortage of rule books).

One of the biggest challenges, in terms of the expectations of the regulation versus the current reality is that GDPR requires a breach to be detected and understood such that it can be notified or reported to authorities within 72 hours and to affected data subjects “without undue delay”.  Coupled with this is the expectation that the organisation will itself be capable of detecting it has been breached, rather than hearing about it from a third party or when the data surfaces on an Internet site somewhere.

Cyber security performance is measured in weeks and months

The ‘real challenge’ to achieve the 72 hours GDPR challenge is of course that current statistics (and there are too many to cite) show that breaches typically take years or possibly months (at best) to detect.  Whether you take the worst cases that hit the news media, or the averages found in numerous data breach surveys, the same outcome recurs again and again.This means the 72 hour window to advise authorities of the breach and the details of the breach is more than one order of magnitude away from current reality.  The 72 hours GDPR challenge is 3 days, and is nowhere near the 3 weeks or 3 months that represents the norm for an attack to be detected and understood.

It is also worth noting that this time window isn’t the end of the story. The technical diagnosis and understanding of the scope or impact isn’t where the organisation’s problems are likely to stop.  For example, when notifying data subjects ‘without undue delay’, the letter or email sent out has to detail not only what happened but also the likely consequences and measures to be taken.  In the US, where mandatory data breach notification has been a reality for a while, businesses have been set up specifically to handle the notification process.  These firms are coming to the UK and EU but many businesses today don’t have this third party emergency response service in place.

Incident Response and Breach Notification is non-trivial

Once you have your list of x million affected data subjects, as you draft the email to send them there will be a need to consider:

  • If you are going to provide them with identify theft insurance, how much will that cost, what cover will it provide and do you need their permission to send their details to a third party;
  • If they want to talk to a person to discuss their case, losses and issues, what is the telephone number and where is the call centre to be located;
  • If they need to change their password, how do they do this, can your website cope with that many simultaneous users and how do you avoid phishing scams making the problem worse;
  • If you need to reissue membership cards, credit cards, payment cards or other physical items, when will that happen and how quickly (most issuing processes run at an average run rate and might not handle sudden peaks of demand).

In a nutshell the 72 hours GDPR (and “undue delay”) window has to not only fit in the IT security team figuring out what happened, it also has to allow the business to green-light any responses.  The reality is that firms should look at these time windows in the context of detection, understanding, decision making AND response.

Sadly, in most cases, none of those stages in isolation take less than 72 hours, let alone when combined.  Getting from months and weeks to hours and minutes is possibly the biggest ask, not just for the security function but the whole crisis management strategy.

Most organisations don’t spot cyber security breaches

Many of us in the security field have had conversations where a business claims it hasn’t had a breach.  Some of these claims are feasible, but a percentage are either bravado or delusion.  We know that many businesses don’t detect the breaches they suffer because so many of the breaches that do come to light are reported not by the control functions within the business, but by the affected customers, the fraud victims, the hackers, the Internet forums or the media.GDPR expects businesses to be able to detect breaches and not be reliant on a third party pointing them out.  In one survey the proportion of externally reported (rather than internally detected) breaches was 80% – leaving us with the conclusion that 4 out of 5 companies risk being fined more than they would otherwise wish.With a third party report it is also worth noting that the 72 hours window becomes more challenging.  An investigative journalist could wait days or weeks putting a story together before they go public with the facts, an internet fraudster could go for quick glory or slow long-term financial gains.  A hostile government may never disclose that the data was stolen.  Even the retail and banking community may want to ensure its diagnosis and evidence are correct and clearly point to the culprit before the notification is made.

The fact remains however that being told about a breach is much, much worse than being able to self-identify. So the problem cyber security teams face is not just one of time criticality, its completeness of vision – being able to see what is happening before its effects become evident externally.

Cyber security trends – The ransomware epidemic

The recent spate of ransomware attacks has highlighted this issue in a rather unfortunate way.  Ransomware is in effect “self notifying” as the attack tells the user they are affected in order to try and extricate a ransom payment.  In these cases we have seen worldwide coverage of multiple organisations and individuals being affected, springing up very quickly.Of course the challenge is detecting the presence of ransomware when there is still time to do something about its effects or spread, rather than when the attacker’s code decides it is time to reveal its presence. The ability to detect ransomware when the process of file encryption starts or in between patient zero (the first affected system) and patients 1…n (all the places it spreads to) isn’t a 72-hour target as with GDPR; it is counted in minutes or seconds.  The effect of failure isn’t a larger fine or more embarrassment; it is widespread data corruption and disruption.

GDPR compliant cyber security speed limits

Everything we are seeing tells us that cyber security as a function that provides a service to business must speed up. It is both a marathon and a sprint and at present we are seeing attacks succeed because the technology to detect and thwart them isn’t in common use, and compliance requirements that most businesses operate under, aren’t even close to being achievable.

Security teams, their processes and the technologies they use must become more situationally aware and able to do more to automatically detect and understand issues that arise.  This means that the predefined remedial actions can start to become automatic also – enabling a system to be constructed that has an element of self-healing or damage limitation built in.

Realistically this is the only way to rapidly detect, start addressing and resolving an attack at the kinds of speeds the GDPR regulations, and the wider stakeholders, are expecting.

Fast Track your GDPR Compliance