I’ve been seeing tweets and discussions on tech and infosec forums, some of which have queried whether this circumstance would be a breach under GDPR for which regulatory penalties could be enforced. The answer to whether this incident represents a failure of Verelox to meet the requirements of GDPR is going to depend on many details which are not currently available, however as a former infosec professional now turned to privacy; I’d be inclined if asked, to give the standard Data Protection Officer answer: “It depends”. Because it does.

The GDPR requires that organisations take “appropriate technical and organisational measures” to manage risks to the rights and freedoms of individuals whose data is being processed (Article 24.1) and specifically, to protect the confidentiality and integrity of personal data in proportion to the risks to the individual and the capabilities of available technology (Article 32.1).

In this case, it is very likely that Verelox will be a Data Processor rather than a Data Controller for any personal data that was stored/hosted/collected on their cloud platform, since they were providing infrastructure only and not making any decisions about how people’s information would be used. However, GDPR does bring in Data Processor joint liability for data breaches (defined as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed” (Article 4.12)) and places explicit obligations on Data Processors as well as Data Controllers to “ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services”. (Article 82). Interestingly, the right to compensation does not specify “natural persons” in regard to compensation as it does to the definition of personal data, which may leave the door open for Verelox’s customers to make claims under GDPR rather than contract law to recover some of their losses arising from the incident. I’m not familiar with Dutch law, so I’ll leave that in the realms of speculation for the moment. What GDPR does appear to say is that Verelox could potentially be jointly liable with their customers for claims for damages from individuals, as a result of this incident. Whether they are actually culpable is something that will need careful consideration, and this is where I put my infosec hat back on for a while…

Does the fact that this happened therefore mean Verelox’s measures were not appropriate? Well, again the answer is going to be “It depends”. Based on the information available in news reports at the moment, this seems to be a rare and extreme case of a malicious insider with a grudge acting independently and outside the law. Should the company be held responsible for this?

One of the factors to consider will be whether this damage was done while the individual was still an insider (i.e. employed as a systems administrator) or whether it happened later on after they left the role? If the attack was carried out later on there is a possibility that Verelox might have dropped the ball, since the individual should have had their access revoked as soon as their employment came to an end, and in such a way that it would be difficult to trigger such a meltdown from the outside. If the attack was carried out post-employment then the “technical and organisational measures” Verelox had in place may not have been “appropriate”. Questions that should be asked are:

was there a standard procedure for revoking leavers’ access in a timely manner,

was that procedure followed in this particular case,

was there a culture of adherence to security procedures in general?

If the answer to any of these questions is “no” then Verelox might be in for a difficult time ahead.

If the attack was planned and set in motion while the individual was an insider; could/should pre-employment vetting or line management support procedures have identified the possibility? This one is tricky, as any predictive measure of human behaviour is never going to be 100% accurate on an individual level. Previous and similar shenanigans carried out by a prospective or current employee could be an indicator of higher risk of future shenanigans occurring, but that really depends on the person and the circumstances. No record of any previous shenanigans may mean; this person has done it before but was never caught, this person has never been in circumstances where this behaviour could be provoked, or simply that this person just wouldn’t do a thing like this in any circumstances. There’s just no way to tell in advance. Maybe this guy is a nutter who has a tendency to react destructively when upset – but that doesn’t mean we should be advocating for mandatory psychological examinations of all employees who are to be trusted with privileged access as that would be a grossly disproportionate invasion of privacy (and not necessarily accurate enough to be worth the effort either…)

What about Disaster Recovery and Business Continuity Planning? Should these plans have included mitigation for this level of malicious damage by a privileged insider? Again, maybe – but it depends. Does malicious insider damage happen often enough to justify the expense, protocol and monitoring capability that would be required to prevent and detect this activity while managing both false positives and negatives? While this sort of grudge-attack is always a possibility, it may make better business sense to develop, manage and support employees so that the chances of behaviour like this are reduced, rather than make the default assumption that everyone is a potential vandal/criminal and treat them accordingly. In any case; what organisation really has the resources and support available to maintain standby equipment and datastores in a way which make them easy to fail over to in the event of an attack or disaster but too difficult for an admin with a grudge to take out alongside the live system?

Hindsight is always 20/20-sharp and there are plenty of armchair experts gleefully pontificating about what they think Verelox should have done better or differently. In the current absence of detailed information though; there’s no reason to pay any attention to any of them at the moment. It’s easy to say “well Verelox should have done x,y,z; they’re idiots for not doing it” but far harder to balance the management approach for predictable but unlikely risks. Paying attention to managing the risks that can be managed, in a proportionate way that doesn’t stop the business operating, is the fine line that infosec teams must walk; often in difficult conditions – mostly unappreciated, frequently facing opposition from people who don’t understand or have different views of the risks and dependencies, probably under-resourced and constantly firefighting seems to be the norm for most operational infosec roles. There are cases where all you can do is as much as you can to put in place quick-recovery plans and buy insurance against the things that you really have no control over (like some loony destroying your business operations out of pique). This may well be one of them.

TL;DR version – if Verelox can demonstrate that they took reasonable and appropriate precautions to mitigate the risk of the attack, then they are unlikely to be subject to penalties or remedies under GDPR. However, if they can’t demonstrate that their measures were developed and maintained to be appropriate to the risks then they may be subject to regulatory enforcement (unlikely) or civil claims (possible). Whether GDPR would be the appropriate instrument for bringing action under is not something I’m qualified to comment on.

One Comment

Hey there! Tһis post couldn’t be written any better! Reading this post reminds me of my
previous room matе! He ɑlways kept tɑⅼking about this.
I wilⅼ forward this wrіtе-սp to him. Fairly
certain he will have a good гead. Many thanks for sharing!

WARNING - this site sets cookies! Unfortunately, I am unable to disable some of the inbuilt tracking without killing the site content. tell me more

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.