72 hours to doomsday - GDPR armageddon peddling from Splunk

Profile picture for user mbanks By Martin Banks October 4, 2017
Summary:
Splunk’s security evangelist Matthias Maier posits some thoughts on what is important when it comes to managing GDPR in action.

data protection sovereignty
Multiple surveys suggest that the majority of organisations, both large and small, are not ready for the arrival of the new GDPR (General Data Protection Regulation) regime next May. As a result, the hype rate from vendors and consultants is starting to get a bit manic.

Just about every vendor of any product that is remotely related to the subject of security is on the case, thumping their tubs of 'buy this' and 'install that'. And with 2018 now less than three months away, the hype and hysteria is only going to get worse.

Splunk's security evangelist  Matthias Maier has his own views of GDPR issues that are of importance. The main issue here is that one of the fundamental laws of security management has now become 'a breach is inevitable, so what are you going to do about that?’.

Anti-malware and anti-virus tools will stop a huge number of attacks, it is true, but they can only be reactive. They can only work against the malware and virii that have been identified, and that means someone, some business somewhere, will be the first to be targeted with a new type of attack, and will be breached.

At this point the bigger issue for the breached organisation is not how they manage to stop the loss of information and remediate the damage done, but how they prevent the authorities starting the process of imposing truly swingeing financial penalties?

Traditional methods of dealing with breaches, which often include the tactic of saying nothing and hoping that the need to publicly admit to disaster never occurs will, when GDPR becomes effective in May next year, only make matters – and the eye-watering nature of the punitive penalties – much worse.

Doom could be just 72 hours away

In fact, according to Maier, taking action against any breach, apart from doing everything possible to stop it dead, is very much a secondary activity:

Detailed remediation of the malicious attack, once it has been quarantined, can wait for more important actions, for the key driver is the maximum 72 hours allowed to inform everyone (usually customers or staff) who’s personal data is put at risk. Fail to do that and the punitive pain will start to be applied.

To start with there is a need to make some organisational changes, if only to demonstrate that the business is prepared for the worst to happen. First amongst these is the development of an incident investigation process, and a communications plan, for informing users and authorities on what kind of breech has occurred and who is affected within that 72-hour time limit is a core requirement:

The key requirement here is information, and the more that is available the less the chance of a punitive response by the authorities.

An organisation will need to identify an attack and stop its further action. It must also be able to lock down all the data affected by the attack so that it can be analysed together to identify what actually happened. And given the nature of some forms of attack, where a penetration, and the uploading of the malicious code, takes place sometime before the attack is actually triggered. So, Maier suggests, this can involve locking down then analysing Terabytes of data going back weeks, and even months.

The need then is to identify what type of data has been accessed and who should actually be informed of the breach. This will include all individuals that can be specifically identified, but may also need to include all those whose data may have been put at risk. If a complete folder has been accessed it may be necessary to then back-track through the creation of all the files and records the folder contains.

The reason is simple. Everyone with data that is at risk from a breach has to be informed within that 72-hour period. In practice, that will usually mean an obligation to go public with information about the breach, including the type of attack, the extent of the data accessed and, for the authorities at least, what actions have been taken and how successful have they been.

What this constitutes is in effect an audit of operations before, during, and after the breech. It is only then that lower priority actions such as removing the malicious code and other remedial, restorative actions should be considered. Maier says:

It is possible to conduct privacy audits at any time, and this is certainly a constructive idea. But it is still not known what form these audits will need to take. It may be possible that self-assessment audits will allowed.

These may be of only partial benefit in practice but they will have the advantage, if conducted regularly, of demonstrating that a business at least has its heart in the right place and is trying to remain on top of its security regime. And showing that a business is trying its best can also be a help if trouble strikes.

Logs of evidence

The Splunk position on such issues is, of course, pretty obvious. The analysis of machine data is one of the best ways to determine what has happened: its timing, its sequence, and its impacts, consequences and, most importantly, what steps a business took to provide and manage risk mitigation processes before and during any breach:

Even with all the latest security technology in place, it is still going to be possible for a company’s security defences to be breeched and important data accessed. And if that happens it is quite possible that that business will face a significant fine. And that fine will be worse if the business cannot show what happened, what data was accessed, what steps were taken in advance and during the breech to prevent or contain it, and whether the appropriate people were informed at the right time.

There is a need to be able to prove what you knew, when you knew it, what defences were in place and how they were working, and what actions you took to contain the attack. And if you can prove that the business did all that could be expected of it in terms of security defences, then there is a chance it will not be fined.”

New methods of breaching security will always emerge, but he acknowledged that most of them are the result of, to be blunt, sloppiness in terms of the implementation of security policies, or even fundamental weaknesses in the policies themselves.

Splunk’s security tools and analytics can, he suggested, by applied equally to small businesses and right on up to the big, global enterprises. This is in fact a useful advantage for those larger businesses, and Maier observes:

GDPR is now a global thing, for it is now a global marketplace.

One final thought from Maier does point to an interesting – and freeing – direction. If GDPR is effectively a global imposition, then issues such as data sovereignty should, over time, disappear. No longer will it be necessary for German companies insist that corporate data is held within, at the very least, the EU borders, for every major enterprise with global pretentions should soon enough be governed by the same security regulations and the same financial penalties.

My take

The Splunk position highlights a more general condition that many businesses may well find themselves facing when GDPR comes into force. They will have invested in an array of defensive tools that should be capable of stopping anything that gets thrown at them. And only too late will they find out that, no matter how much they have, it will not forestall either a breech or the punitive fine which follows. When it comes to managing GDPR, having evidence and knowing how to use it will, in the end, be far more important.