Is het een datalek om een domeinnaam te laten vervallen?

| AE 9491 | Domeinnamen | 29 reacties

Door het laten verlopen van een domeinnaam heeft Samsung miljoenen gebruikers risico laten lopen, zo laat de Portugese beveiligingsonderzoeker Joao Gouveia op Twitter weten. Dat las ik bij Security.nl. De domeinnaam hoort bij een door Samsung opgeheven dienst (S Suggest), die gebruikers populaire applicaties laat zien die gegarandeerd compatibel met hun apparaat zijn. De onderzoeker ziet nu miljoenen verzoeken vanaf Samsung-telefoons naar de domeinnaam. Is dat nu ook al een datalek?

Het is natuurlijk een blunder eerste klas. Een domeinnaam kost een paar euro, en een simpele “This service is not available anymore”-autoresponder moet ook geen bakken geld kosten. Maar zelfs de domeinnaam nergens heen laten wijzen had gekund, dan waren mensen ook wel snel gestopt met die app. En nu zou een kwaadwillende het protocol kunnen reverse engineeren en nepdata sturen, bijvoorbeeld suggesties voor phishing-apps die mensen dan klakkeloos installeren “want Samsung zegt dat deze compatibel is”.

Maar of het een datalek is? Daarvoor is vereist dat via dit domein persoonsgegevens lekken. Enkel dat een telefoon verbinding maakt met een app is denk ik niet genoeg daarvoor. (Tenzij je zegt dat headers zoals X-Asid persoonsgegevens zijn.)

Als de verbinding succesvol is en er wordt dan persoonlijke informatie opgestuurd door de app, dan komt die nu dus bij een ongeautoriseerd persoon terecht. Dus dan zou ik het wel een datalek noemen. Maar dat is wel een stevige als, en bovendien eentje die zich pas ruime tijd later kan voordoen.

Desondanks kan ik er niet bij dat Samsung dit heeft laten vallen.

Arnoud

Geldt de meldplicht datalekken ook voor defaced websites?

| AE 9315 | Aansprakelijkheid, Privacy | 7 reacties

Tweakersgebruikers melden maandag defacement van verschillende websites, waarbij de site zelf is vervangen door een boodschap die afkomstig lijkt te zijn van een Turkse groepering. Dat las ik op Tweakers gisteren. Of er een link is met de gebeurtenissen rond de Turkse minister van Familiezaken Kaya, is onduidelijk. Maar diverse lezers vroegen me wel: moet je dit nu melden aan de klant, valt dit onder de meldplicht datalekken?

De meldplicht datalekken geldt voor alle datalekken waarbij persoonsgegevens zijn betrokken. Een datalek is een inbreuk op de beveiliging van persoonsgegevens waardoor deze kunnen worden misbruikt, of gebruikt op een manier die niet toegestaan is. Doet zo’n datalek zich voor, dan moet dat in principe worden gemeld bij de toezichthouder (tenzij de impact minimaal is) en vaak ook bij de betrokkenen (tenzij de data encrypted was of de impact wederom minimaal is). Dit geldt nu onder de Wbp, en vanaf volgend jaar ook onder de Privacyverordening.

Voor andere data of andere soorten misbruik van persoonsgegevens geldt de meldplicht niet. Mijn standaardvoorbeeld is de hack bij een accountant waarbij de nog geheime jaarcijfers van een bv of nv worden gestolen: heel vervelend maar géén datalek in de zin van de wet en dus ook niet meldingsplichtig.

Bij een defacement worden pagina’s vervangen door andere teksten en/of afbeeldingen, in dit geval dan met een politieke strekking. Ik vraag me af of daarbij persoonsgegevens worden geraakt. Het kan natuurlijk altijd, maar het ligt voor mij niet voor de hand dat iemand die inbreekt om een tekst/afbeelding ergens neer te kwakken, ook persoonsgegevens van gebruikers kopieert of zelfs maar die langs ziet komen. Dus ik zou dit niet direct als datalek aanmerken.

Het is natuurlijk wel zo netjes om dit als bedrijf te melden aan je klant. Ik zou zelf vinden dat je dit verplicht bent vanuit je zorgplicht als goed opdrachtnemer. En vaak staat het ook in de algemene voorwaarden: bij gebleken misbruik of inbraken zal de hoster de klant informeren over genomen maatregelen, daaruit volgt dan ook een plicht tot melden dat een defacement heeft plaatsgevonden. Maar een datalek is het niet.

Arnoud

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

Hoe kun je voldoen aan een beveiligingsplicht én een achterdeurplicht?

| AE 8879 | Beveiliging | 52 reacties

Een lezer vroeg me: Sinds kort hebben we een wet tegen datalekken. Die zegt dat je je beveiliging zo goed mogelijk moet regelen. Maar nu lees ik dat er allerlei voorstellen in de maak zijn om end-to-end encryptie te verbieden. Hoe kun je nu aan twee zulke tegenstrijdige wetten tegelijk voldoen? Van tijd tot tijd… Lees verder

Is een datalek pas een datalek als je zeker weet dat er data is gelekt?

| AE 8662 | Beveiliging | 3 reacties

Een lezer vroeg me: Onze webwinkel is gehackt. We kunnen uit de logs achterhalen dat men via een zwakheid in het CMS is binnengedrongen en diverse bestanden heeft opgevraagd. Eén van die bestanden bevat het pad naar een backup-bestand met daarin onder meer klantgegevens. Helaas hebben wij geen logging op bestandstoegang, dus wij weten nu… Lees verder

Mag je systemen testen met productiedata met persoonsgegevens?

| AE 8523 | Privacy, Software | 8 reacties

Een lezer vroeg me: Bij mijn laatste klant kreeg ik te horen dat ik bij de update van hun software wel mag testen, maar alleen met nepgegevens. Het argument was dat hun klanten geen toestemming hadden gegeven voor gebruik van hun data voor testdoeleinden. Deed ik dat toch, dan zouden ze de boetes wegens datalekken… Lees verder

Is verlies van data ook een datalek?

| AE 8504 | Privacy | 8 reacties

Een lezer vroeg me: Dat je verlies van persoonsgegevens moet melden onder de meldplicht datalekken begrijp ik. Maar waarom ben ik het ook verplicht te melden als er gegevens verloren gaan? Er kan toch per definitie geen identiteitsdiefstal of fraude plaatsvinden als gegevens wég zijn? Voor veel mensen is het niet echt intuïtief dat verloren… Lees verder

VTech wil dat gebruikers erkennen dat gegevens bij zijn dienst onveilig zijn

| AE 8423 | Aansprakelijkheid | 24 reacties

In de categorie ergernissen waar je ’s ochtends van gaat bloggen: VTech, de maker van elektronisch speelgoed, heeft in zijn algemene voorwaarden opgenomen dat gebruikers erkennen dat informatie die ze via de Learning Lodge-portaal sturen onderschept kan worden. Dat las ik bij Tweakers gisteren. Om scheve jeuk van te krijgen. Ja, het is een standaardzin… Lees verder