Wanneer is een ransomware-aanval eigenlijk een datalek?

| AE 9425 | Beveiliging | 10 reacties

Parkeerbedrijf Q-Park is onder de organisaties die zijn getroffen door de wereldwijde cyberaanval, meldde de NOS. Nou ja, cyberaanval: grootschalige ransomware-infectie. Wat onder meer de vraag via Twitter gaf:

Dat is dus ook een geval van een #datalek omdat ze gegevens “kwijt” zijn toch @ictrecht ?

Ook het verloren gaan van gegevens telt als datalek onder de Wet bescherming persoonsgegevens inderdaad (en straks de AVG). Dat voelt gek, want misbruik is niet echt aan de orde als iets weg is, maar naast dat het formeel gewoon onder de term ‘verwerken’ valt is er gewoon een goede reden: het verloren gaan van gegevens kan je status als klant et cetera aantasten. Als de computer niet meer weet dat jij betaald hebt om te parkeren, dan heb je een probleem.

Natuurlijk is dit geen issue als er een goede recente backup is. En in die situatie noemen we zo’n verlorengaan dan ook geen datalek, althans niet eentje die het melden waard zou zijn. Dus in principe is het antwoord simpel: ja, tenzij men goede backups heeft.

En hier zou je zelfs nog een stapje verder kunnen gaan: welke persoonsgegevens zijn verloren gegaan door de ransomware in die Q-Park garages? Die staan toch op een server ergens, en deze terminals dienen alleen als interface om te betalen? Niet kunnen betalen is heel vervelend maar geen datalek.

Intrigerender -wie erop wil afstuderen moet maar even mailen- vind ik nog de vraag of ingijzelneming van persoonsgegevens wel telt als verloren gaan. De data is er immers nog, je moet alleen betalen om hem weer terug te krijgen. Ik weet het, de Autoriteit Persoonsgegevens vindt van wel, maar om een wat verdergaande reden:

Er moet namelijk toegang tot de bestanden zijn geweest om deze te kunnen versleutelen. … De besmetting kan het hele systeem en alle gekoppelde bestanden raken.Er kan dus toegang zijn verkregen tot veel meer persoonsgegevens. Ook kan er meer met de gegevens zijn gebeurd dan op het eerste gezicht lijkt. De gegevens kunnen bijvoorbeeld zijn gekopieerd of gemanipuleerd.

Kort samengevat: omdat je niet kunt uitsluiten dat ransomware de gegevens ook kopieert, moet je het als een datalek behandelen. Daar ben ik het mee eens, maar wat nu als we wél kunnen uitsluiten dat er gegevens zijn gemanipuleerd of gekopieerd? Stel de ransomware infecteerde een computer via een USB-stick, en achteraf kunnen we met extern opgeslagen hashes vaststellen dat de bestanden in originele toestand zijn hersteld.

Is dit nu zeg maar een heel ingewikkelde backup/restoreprocedure? Of moet je gijzelen zien als verloren gegaan?

De implicaties zijn interessant, want als je zegt dat dit een datalek is dan is het offline halen van een clouddienst met de enige kopie van de gegevens óók een datalek. En dat zit me niet helemaal lekker.

Arnoud

Deel dit artikel

  1. Er is van een datalek sprake bij verlies of onrechtmatige verwerking van persoonsgegevens. Kun je verlies uitsluiten dan ben je er nog niet helemaal. Over het algemeen versleutelen de criminelen de data en ontsleutelen ze deze bij betaling. Althans dat beloven ze. Los van de eerdere ongeautoriseerde toegang (hack) is deze versleuteling (gijzeling) eveneens een vorm van onrechtmatige verwerking. Als het persoonsgegevens betreffen in ieder geval.

  2. Als ik denk aan lek, dan denk ik aan een waterreservoir (bad, waterleiding of stuwmeer). Als het water er uit loopt op een ongewenste plek, dan is het lek. Dat zou analoog zijn aan een datalek. Vooral de voorwaarde ‘ongewenste plek’ is essentieel. Even afgezien van dat data gedupliceerd wordt in plaats van wegstroomt. Als het water niet meer bruikbaar maar wel in zijn container blijft, dan zou ik het niet een lek willen noemen maar een vergiftiging of contaminatie. Die ongedaan kan worden, omdat degene die het gif er in heeft gedumpt weet wat het gif is, en een tegengif bezit/verkoopt. Bij data is het makkelijker om te kijken of het origineel terug is gezet, als je hashes of pariteitbestanden voor handen hebt. Ransomwaremakers lijken mij niet geïnteresseerd om na betaling je nog even een oor aan te naaien door een md5/sha1 collision te veroorzaken. Als ze je toch een oor aan willen naaien dan zou het zijn dat je bestanden na betaling niet ontsleuteld worden. Waarom moeilijk doen als het makkelijk kan?

    Je zou kunnen zeggen ‘mijn firewall registreert elke byte die passeert’ maar kan je daarmee waterdicht aantonen dat er geen kopie doorheen is geglipt? Logs kunnen vervalst worden, met encryptie kan je hetgeen dat passeert onherkenbaar maken, en met compressie kan je de grootte van een gemiddelde database flink kleiner maken, tussen de 80% en 95% in mijn ervaringen. Niet relevant voor dit geval maar in het algemeen, er staat ook geen firewall of andere beveiliging op de USB poort die controleert wat daar precies gebeurt. Hooguit een virusscanner, maar die zal niet aanslaan zolang er geen trojan-achtige code wordt gekopieerd.

    Mijn mening is dat het regelmatig maken van backups een verplichting bij wet mag worden. Dagelijks bij voorkeur, maar minimaal wekelijks. Zeker wanneer je met betaalrecords werkt. Alleen, werk je dan met incremental of full? Het lijkt mij niks om een 2 jaar oude basis te hebben en daar 700 increments boven op te moeten zetten. Een bijkomend probleem is dat het niet verstandig is om backups enkel on-site te bewaren. Stel dat er brand uit breekt? Mag je eigenlijk wel backups, al dan niet versleuteld, doorsturen naar een offsite machine? Dat is namelijk óók een vorm van kopiëren van persoonsgegevens. Als het wel mag, dan lijkt mij dat als je maar op genoeg verschillende plekken dezelfde set aan backups bewaart, dat er nooit een laatste kopie verloren kan gaan. Waardoor dus niet de single-point-of-failure situatie ontstaat waar het offline gaan van een cloud provider meteen de allerlaatste backup verloren gaat.

    • Het gaat er volgens mij bij een datalek niet om of er data worden verplaatst, maar of er mogelijk ongeoorloofde toegang tot data is ontstaan. Waar het hier om gaat is dat die ransomware die data heeft kunnen lezen en dat dat niet de bedoeling was. De term datalek is dan inderdaad verkeerd: datagat zou beter zijn.

  3. Het verdwijnen van de clouddienst waar je bedrijfsgegevens op hebt staan, kun je zeker wel zien als datalek. Dat lijkt me nog een goed argument om je bedrijfsvoering niet afhankelijk te maken van “the cloud”. Je moet je administratie 5 jaar houden, dat is ruim genoeg voor een internetgigant om volledig te verdwijnen.

    • Afhankelijk maken van lijkt me inderdaad ook te ver gaan. Echter, er lijkt me niets mis met een tweevoudige back-up: eentje lokaal en eentje in de cloud. Dan heb je altijd iets achter de hand. Wordt er ingebroken en de computers en servers/back-ups worden gestolen, dan kun je altijd herstellen vanuit de cloud. En als de clouddienst ermee ophoudt, dan heb je altijd lokaal nog (en kun je die back-up evt. weer bij een andere clouddienst onderbrengen).

  4. De gegevens zijn verloren gegaan: Het is niet gegarandeerd dat een gebruiker betaald en de gegevens terug krijgt. Het process is manueel, en dat schaalt niet. Verloren lijkt me ook niet binary: Je kunt iets dat verloren is gegaan later best terugvinden. Tijdelijk verloren is nog steeds verloren. Het lijkt me niet dat iemand die een niet-versleutelde USB-stick met persoonsgegevens in de trein laat liggen, dit niet hoeft te melden, omdat deze binnen 72 uur wordt teruggegeven door een aardige reiziger.

    De gegevensverwerker is grof nalatig: Deze heeft geen goed update-beleid. Waarschuwing op de plaats.

    Ik kijk naar de intentie van de wet: Is er sprake van een inbreuk op de beveiliging? Raakt dit aan persoonsgegevens? Melden!

    We willen toch niet deze wet mank maken, door gegevensverwerkers niet te laten melden als ze slachtoffer worden van een ransomware aanval? Slachtoffer worden van een ransomware aanval betekend de noodzaak om het process aan te scherpen, eventueel onder dwang van boetes.

    • Offline halen van een clouddienst is inderdaad: het verloren gaan van data, echter er is geen sprake van een inbreuk in de beveiliging, daarom is dat geen datalek onder WBP, want deze spreekt over vereiste: een inbreuk op de beveiliging, bedoeld in artikel 13.

      (Wat eigenlijk best raar is, want een USB stick in de trein laten liggen, of per ongeluk persoonsgegevens openbaren op de website, is ook technisch gezien geen “inbreuk op de beveiliging”, mits je zelf geen inbreuk kan plegen)

  5. Er is sprake van een datalek als er (risico op) inbreuk op de bescherming van persoonsgegevens bestaat. En dan moet het voor de meldplicht gaan om ‘gevoelige gegevens’. Dus als je een USB-stick bent kwijtgeraakt met het telefoonboek van Nieuwe Pekela, dan is dat wel een datalek, maar die hoeft niet gemeld te worden. Immers, het gaat niet om ‘gevoelige gegevens’. Als je een USB-stick bent kwijtgeraakt met daarop bijvoorbeeld patientgegevens dan gaat het wel om ‘gevoelige gegevens’. Dit valt in beginsel onder de meldplicht. Immers, het risico op ernstig nadelige gevolgen voor de patient lijkt aanwezig indien de gegevens niet versleuteld waren en/of de gegevens niet zijn terug te halen met nadelige gevolgen voor de patient. In de melding moeten o.m. de feiten en omstandigheden worden vermeld waaronder de inbreuk zich heeft voorgedaan.

  6. De gegevens op een betaalpaal zouden zich normaal gesproken toch beperken tot transactiegegevens en eventueel het betreffende nummerbord (voor parkeerplaatsen die met nummerbord werken). Aangezien die palen normaal gesproken niet om extra toestemming vragen is het behoud van die gegevens alleen toegestaan voor beperkte doeleinden (systeembeheer, financiële administratie, etc.) en zouden normaal gesproken snel gewist moeten worden. Is het feit dat het “wissen” nu iets eerder gebeurd dan een probleem in de zin van de wet? Recht op inzage geld alleen op gegevens die nog bestaan, niet op gegevens die gewist zijn.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS