Wie is aansprakelijk voor dat #cloudbleed-lek van Cloudflare?

| AE 9280 | Cloud, Privacy | 11 reacties

Door een bug in de html-parser van CloudFlare konden gevoelige gegevens van klanten van het bedrijf lekken en stond data in de cache van zoekmachines. Na een melding van Google heeft de dienst voor optimilisatie van websites het lek in zeven uur gedicht. Dat meldde Tweakers, met meer details in The Register. De clouddienst had een klassieke buffer overflow-fout, waardoor willekeurige data van andere websites of databases meegestuurd kon worden bij een opvraging van een webpagina. En via Twitter de vraag (dank, Sven): “Is CF responsible for ‘breaches’ at each of those exposed companies?”

Volgens Tweakers zou er geen misbruik zijn gemaakt van de bug, die ontdekt werd door Google’s anti-zerodayproject Project Zero. Maar het lijkt mij nogal ernstig: de bug zorgde voor een abusievelijke opname van data in webpagina’s, maar onzichtbaar voor gewone gebruikers. De data kon echter van alles bevatten, van wachtwoorden tot persoonsgegevens. En dat wordt dan ook nog gecrawled door Google en collega’s, dus in caches overal zit nog dergelijke data. Auw. Wie gaat dat vergoeden?

In het algemeen is er geen wettelijke regeling wie aansprakelijk is voor het lekken van vertrouwelijke informatie. Dit wordt dan ook eigenlijk altijd contractueel geregeld: klant en leverancier spreken af welke data vertrouwelijk moet worden behandeld, welke schade of boete mag worden geclaimd en wanneer sprake is van een overtreding (dan wel overmacht of andere situatie zonder aansprakelijkheid). Dat kan gaan van “leverancier vergoedt elke cent van elke gelekte byte” tot “leverancier is nooit aansprakelijk, hooguit bij opzettelijk lekken”. Of klanten Cloudflare kunnen aanspreken, is dus een kwestie van in de contracten duiken.

Specifiek voor persoonsgegevens ligt dat iets anders in Europa. Daar zegt de wet (de Wbp, en straks de Privacyverordening) dat de aansprakelijkheid voor schade door datalekken ligt bij de (verwerkings-)verantwoordelijke, oftewel de partij die bepaalt waarom die gegevens zijn verzameld en wat daarmee gebeurt (juridisch: die doel en middelen vaststelt van de verwerking). Dat is dus in principe de partij die zaken doet met de personen, bijvoorbeeld een webwinkel of forum die klant- of gebruikersgegevens krijgt.

Alle partijen die die gegevens vervolgens opslaan of gebruiken in opdracht van die verantwoordelijke, heten bewerkers en zijn naar de betrokkenen toe op dit mnoment niet direct aan te spreken. Het is de verantwoordelijke die de claims krijgt – maar hij kan ze wel verhalen natuurlijk op die bewerkers. Daarvoor wordt het juridisch instrument van de bewerkersovereenkomst gehanteerd, een aanvulling op het ICT-contract die specifieke afspraken over persoonsgegevens bevat. Als klant moet je je dus melden bij je webwinkel, forum et cetera met je schadeclaim, en zij kunnen het dan bij hun hoster verhalen die het weer bij Cloudflare gaat halen.

Onder de Privacyverordening wordt dat strenger, dan kun je ook bij verwerkers (zoals ze dan gaan heten) direct een schadeclaim indienen als benadeelde partij. Dan mag je dus als klant of gebruiker van een internetdienst die bij Cloudflare zit, direct bij Cloudflare je schade gaan halen. En ja, Cloudflare valt onder de Privacyverordening ook al zitten ze nog zo hard in de VS.

Het blijft bij privacyclaims echter altijd een hele lastige wat die schade dan precies is, in geld uitgedrukt. Daar zijn ook onder de Verordening geen concrete handvatten over. Ik blijf het herhalen: het wordt tijd voor een staffel met forfaitaire schadebedragen, van zeg 50 euro voor lekken NAW gegevens tot 2.500 voor lekken medisch dossier.

Arnoud

Deel dit artikel

  1. Waarbij je in dit geval waarschijnlijk nooit kunt bewijzen dat jouw gegevens in die cache hebben gestaan want daarvoor moet je toegang hebben en moet je gaan graven in de potentiële privacy data van anderen en dat mag je niet? En je moet dan ook nog weten dat webshop x y of z cloudflare heeft gebruikt.

  2. van zeg 50 euro voor lekken NAW gegevens tot 2.500 voor lekken medisch dossier.

    50 euro voor NAW-gegevens: misschien redelijk voor de gemiddelde Nederlander. Voor iemand die gevaarlijke vijanden heeft (bijvoorbeeld criminele organisaties) mag het echt wel wat meer zijn (denk aan de kosten die snel verhuizen met zich mee brengt). 2500 euro voor een medisch dossier? Als het gevoelige informatie bevat (zoals SOA’s) mag het best 2.5 miljoen zijn. Ook moet schade door verlies aan carrière-mogelijkheden toegevoegd worden.

  3. Het probleem bij CloudFlare is dat we niet eens weten welke data er uiteindelijk is gelekt. Wel heb ik ondertussen van twee websites al bericht ontvangen dat ze alle wachtwoorden hebben gereset. Maar verder is het onduidelijk welke data uiteindelijk is gelekt en hoe bruikbaar deze gegevens uiteindelijk waren voor hackers.

    Een boete voor datalekken klinkt verder wel leuk, maar dat geld gaat dan in de Staatskas en niet aan de gedupeerden. Sowieso, een standaard schadeclaim bedrag van €50 per persoon bij een datalek zou extreem kostbaar kunnen worden voor bedrijven met 10 miljoen of meer gebruikers. Of, zoals recentelijk bij Yahoo, als de gegevens van een biljoen gebruikers plotseling op straat ligt! De boete van 50 biljoen euro zorgt direct voor een faillissement, lijkt mij. En is eigenlijk ook enigszins onredelijk. Mede ook omdat de daadwerkelijke schade waarschijnlijk niet zo hoog zal zijn.

    Je zou eigenlijk moeten aantonen dat de gegevens van een datalek al zijn misbruikt en dus schade hebben opgeleverd voordat het datalek was gevonden en was dichtgegooid. Maar ook dat zal ongewenste effecten hebben. Want software bevat altijd wel allerlei foutjes die misbruikt kunnen worden. Software wordt gemaakt door mensen en mensen maken fouten. Als een enkele fout al forse schadeclaims kan opleveren dan gaan steeds meer bedrijven proberen om zich in te dekken tegen dergelijke schade. Dit kan via clausules in hun algemene voorwaarden en het weigeren van consumenten en dus alleen B2B zaken doen.

    Sowieso leveren datalekken al onkosten op voor bedrijven, omdat ze nu opeens het lek moeten dichten en moeten onderzoeken hoeveel schade er uiteindelijk is. En het versturen van een wachtwoord reset zal ook kostbaar zijn omdat er dan genoeg bezoekers gewoon wegblijven omdat ze niet de moeite willen nemen om hun account weer in te schakelen. Of erger, bezoekers die het bericht niet eens kunnen ontvangen omdat ze een verouderd email adres hebben opgegeven bij registratie dat nu is verdwenen. Ook Yahoo is door deze datalekken al fors in de problemen gekomen nu de consument hun vertrouwen in Yahoo begint te verliezen…

  4. Ik zie een paar problemen met forfaitaire schadebedragen. Gegevens zullen altijd lekken. Of dat nu door fouten of opzet komt, vroeger of later zal ieder bedrijf of instelling te maken krijgen met een datalek.

    1) Het wordt voor kwaadwillende (tegenstanders, concurrenten of scriptkiddies) erg makkelijk een bedrijf failliet te laten gaan. 2) Als iemand data in handen heeft kunnen ze heel simpel een bedrijf of instelling chanteren. 3) Als burger heb ik er dan baat bij er voor te zorgen dat mijn gegevens bij zo veel mogelijk bedrijven en instellingen terecht komen, ieder lek is immers kassa.

  5. Ik blijf het herhalen: het wordt tijd voor een staffel met forfaitaire schadebedragen, van zeg 50 euro voor lekken NAW gegevens tot 2.500 voor lekken medisch dossier.
    50 euro voor gegevens die vaak gewoon in het telefoonboek staan? Of op iemands Facebook pagina? Is er dan uberhaupt sprake van schade?

  6. Hoe zit het met art 44/ 45 en 46 van de AVG? Ik weet niet hoe Cloudflare precies werkt, maar Cloudflare biedt toch een soort van kopie van je website op een Cloudflare server die het dichtst bij jou zit zodat je redelijk snel de content te zien krijgt? Deze kopieën kunnen dus ook op niet EU server staan. Even een aanname voor dit voorbeeld dat er inloggegevens mee gemoeid zijn met een set van persoonsgegevens binnen het account van de gebruikers.

    Heb je dus een bewerkersovereenkomst nodig met Cloudflare en moet je dus extra maatregelen treffen, omdat de data ook buiten de EU verwerkt kan worden?

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