Ik hoop dat die orthodontist z’n webbouwer aansprakelijk stelt voor die 12.000 euro boete

De Autoriteit Persoonsgegevens heeft een boete van 12.000 euro uitgedeeld aan een orthodontistenpraktijk omdat die op een aanmeldformulier geen ssl-verbinding gebruikte. Dat meldde Tweakers vorige week. Door het ontbrekende ‘slotje’ liepen patiënten de kans dat gevoelige gegevens, zoals hun BSN, in verkeerde handen zouden terechtkomen. Opmerkelijk dat die basale beveiligingsmaatregel er niet was, maar minstens zo opmerkelijk dat de AP er voor in actie kwam gezien de beperkte scope. Maar goed, ik ben dus fan van kleine boetes voor kleine overtredingen.

De betreffende website bood klanten van de orthodontist gelegenheid afspraken te maken voor een behandeling. Op zich logischerwijs vroeg men om onder meer NAW-gegevens, geboortedatum, BSN, telefoonnummers van de patiënt en de ouders, gegevens over de school, huisarts, tandarts en de verzekeringsmaatschappij.” Dat formulier werd zonder beveiliging (dus SSL-, TLS-certificaat oftewel “slotje”) opgestuurd, wat inderdaad een beveiligings-dingetje is.

Is het heel erg? Mwa. Technisch betekent het dat iedereen die in het netwerk tussen de klant en de orthodontist zit, de data kan onderscheppen. Het klassieke voorbeeld is het internetcafé of bibliotheek, waar je met de juiste software alles kunt zien dat anderen in diezelfde ruimte opsturen naar websites. Door https te gebruiken, is dit niet langer inzichtelijk – de communicatie naar de site is versleuteld en daarmee niet meer te lezen.

Het aantal scenario’s waarin dit een reëel risico is, is dus beperkt. Vanuit huis is dit bijvoorbeeld geen issue, de buren die ook bij Ziggo zitten kunnen sowieso niet meelezen. Huisgenoten mogelijk wel. Werk je met mobiel internet, dan is dit ook geen serieus risico. Maar natuurlijk is er een niet te verwaarlozen groep mensen die alleen via publieke terminals (zoals de bieb) kan werken, en ook die moet gewoon veilig internet op kunnen.

Daar komt bij: al sinds jaar en dag weet iedereen dat zo’n slotje weinig moeite is, zeker sinds initiatieven als Let’s Encrypt die je gratis certificaten geven om het slotje te realiseren. Dus het voelt als “oké beperkt risico maar het is zo gedaan, doe het dus gewoon” voor mij. Ik blogde er ooit in 2013 over en concludeerde dat het eigenlijk onvermijdelijk is, behalve wellicht bij triviale formulieren zoals de plek hieronder waarin u het hartgrondig met mij oneens gaat zijn.

In het boetebesluit kan de AP het nog simpeler houden: het gaat hier om persoonsgegevens in de zorg, daarbij is NEN 7510-2 leidend en daaruit volgt het gebruik van TLS. Punt, klaar, next. En dan gaat het om zeer gevoelige gegevens, ook nog eens (vooral) van kinderen en dan mag dat al helemaal niet gebeuren. Normaal kom je dan op een boete van een ton, maar omdat deze orthodontist dat absoluut niet kan betalen wordt deze gematigd naar 12.000 euro.

En dan gooi ik met dit citaat even de knuppel in het hoenderhok:

[Betrokkene] heeft erkend dat de oude website geen gebruik maakte van een versleutelde verbinding. De ontwikkelaar van de oude website heeft haar nooit gewezen op die mogelijkheid. Anders had zij daar zeker gebruik van gemaakt, aldus [betrokkene].
We hebben het dus over 2019. Let’s Encrypt was toen al best bekend, en het algemene idee dat SSL-certificaten verstandig waren ook. Om dus nog maar niet te spreken van die NEN-norm in de zorg. Dan wil ik van een kleine orthodontie-praktijk nog wel geloven dat die weinig verstand van internet heeft (de nieuwe site heeft geen online formulier meer maar een uit te printen pdf, ik bedoel maar)  maar van de webbouwer mag dit wel verwacht worden toch?

Oftewel, die orthodontist mag de webbouwer op grond van schending zorgplicht aansprakelijk houden voor die 12.000 euro wat mij betreft.

Arnoud

Mag een bedrijf met DPI ons netwerkverkeer inspecteren?

Een lezer vroeg me:

Vraag: Ons bedrijf beheert voor klanten grote hoeveelheden gevoelige data, waaronder persoonsgegevens. Nu is recent een nieuwe firewall geïnstalleerd met DPI, die ook ssl-verkeer kan decrypten en inspecteren. Dit zou zijn om datalekken te voorkomen. Maar nu wordt al mijn beveiligde internetverkeer bekeken! Mag dat zomaar?

Vanwege de Wet meldplicht datalekken van januari vorig jaar, en de aankomende Algemene Verordening Gegevensbescherming in mei 2018 zie je steeds meer bedrijven hard aan de weg timmeren ten aanzien van datalekken en informatiebeveiliging.

Inspectie van in- en vooral uitgaand netwerkverkeer is daarbij een relevant aandachtspunt. Immers, een hoop datalekken of security breaches gebeuren per ongeluk: een bestand naar de verkeerde persoon gemaild, een stukje malware dat iets naar buiten wil smokkelen of een gevolg van social engineering. (Om niet te spreken van mensen die willens en wetens data stelen.)

Diverse moderne firewalls zijn in staat om uitgaand SSL-verkeer open te breken. Logisch vanuit een security-gedachte: het is wel erg eenvoudig om de beveiliging te omzeilen anders. Je moet eigenlijk wel even kijken in die beveiligde verbindingen.

Maar het raakt ook allerlei legitiem verkeer van de werknemer in kwestie, zoals privemailtjes (een SSL-verbinding met Gmail of een privé Outlook adres), bankzaken of communicatie met een verzekeraar. En dan wordt het juridisch ingewikkeld, want je moet óók rekening houden met de privacy van je werknemer.

Hier moet de werkgever dus een balans in vinden. Een belangrijke voor mij is daarbij hoe geautomatiseerd dit proces gaat. Wordt er door een automatisch proces gecheckt op een serie keywords of fingerprints van de te beschermen data, dan is dat privacytechnisch héél wat minder ernstig dan een steekproefsgewijze controle door een persoon.

Ook zou belangrijk zijn dat de data niet wordt gelogd (tenzij de automatische scan natuurlijk aangeeft dat er iets mis is) en dat inspectie bij afgaande alarmbellen onder strikte geheimhouding gebeurt. Dergelijke waarborgen moeten in een reglement zijn uitgeschreven, zodat je als werknemer weet waar je aan toe bent. Maar als het zorgvuldig wordt uitgewerkt en ingevoerd, dan denk ik dat het wel kan.

Arnoud

‘Meeste bedrijfssites versturen gevoelige gegevens onveilig’

Honderdduizenden zakelijke websites laten gebruikers gevoelige informatie verzenden zonder dat daarvoor van een beveiligde verbinding gebruik wordt gemaakt, blijkt uit een onderzoek van domeinbeheerder SIDN en MKB Servicedesk dat woensdag wordt gepubliceerd. Dat meldde Nu.nl onlangs. De ‘gevoelige gegevens’ zijn meestal NAWE-gegevens, maar ook inloggegevens en wachtwoorden komen voor. Maar liefst 86% van de onderzochte sites doet dat zonder ‘slotje’, https dus. Maar is dat dan verplicht?

Het laten insturen van persoonsgegevens – ook triviale zoals naam en adres – via een website of andere internetdienst mag alleen als de eigenaar daarvan zorgt voor adequate beveiliging. Dat staat al sinds 2000 in de wet (artikel 13 Wet bescherming persoonsgegevens), maar nergens staat wat dat dan precies inhoudt. Er is dus geen eis dat je beveiliging gecertificeerd moet zijn of zelfs maar aan bepaalde specifieke eisen moet voldoen.

De vraag wat ‘adequaat’ is, is dus een lastige om in het algemeen te beantwoorden. Je moet een afweging maken van de risico’s bij een lek tegenover de kosten en moeite om maatregelen te nemen. Perfectie wordt niet verlangd, en het kan ook prima zo zijn dat je bij formulier A een andere beveiliging hanteert dan bij formulier B. Waar het vooral om gaat, is dat je kunt onderbouwen waaróm je voor die of die maatregelen hebt gekozen (of juist waarom je die hebt weggelaten).

Specifiek bij contactformulieren kun je je afvragen of het echt wel nodig is, een SSL-certificaat. Ik zie het nog steeds niet, dat risico. Daar staat tegenover dat SSL tegenwoordig best goedkoop is (zowel qua cpu als qua prijs) en dus eigenlijk een no-brainer zou moeten zijn om toe te voegen. Dus dan wordt het wel een beetje theoretisch verhaal, er kan weinig misgaan maar hoe moeilijk is de maatregel nou?

Bij een login/wachtwoord voelt dat net anders. Daar is er voor mij geen excuus om zonder ssl te werken. Met dat account kun je allerlei dingen, en daarmee zijn er reële mogelijkheden voor fraude of overlast. Dan is de afweging snel gemaakt: no-brainer ter voorkoming van overlast, dat moet gewoon.

Arnoud

Mag ik mijn klanten verplichten SSL/TLS te gebruiken?

security-beveiliging-ketting-slot-chainEen lezer vroeg me:

Mag ik, als hostingprovider, klanten dwingen om SSL/TLS te gebruiken? Via een aantal scripts is het gehele proces te automatiseren, zodat er tijdens het aanmaken van een account een certificaat wordt aangemaakt (via Let’s Encrypt, dus geen meerkosten) en verbindingen vervolgens over SSL/TLS forceren (mod_rewrite en HSTS header). Ik heb veel kleine ondernemers als klant die hier écht steken laten vallen en ik wil ze tegen zichzelf beschermen.

Ik denk dat dit in principe wel kan. Je kunt in je algemene voorwaarden opnemen dat je verlangt dat klanten hun websites en software goed beveiligen, en dat jij maatregelen mag nemen, zoals SSL/TLS beveiligde verbindingen, om dat af te dwingen.

Dit is wel een tikje ongebruikelijk (helaas) dus je moet de klant daar wel expliciet over informeren. Ik zou zelf dat heel proactief willen zien: stuur ze een mail dat er wat mis is, vraag of ze dat binnen 14 dagen willen herstellen en anders doe jij het. Aangenomen dat dit geen nadelige effecten heeft voor de site, zie ik dan het probleem niet.

Maak je dingen wél stuk, dan komt dat op jouw bordje te liggen. En natuurlijk heb je als hoster in je algemene voorwaarden je aansprakelijkheid beperkt, maar bij dit soort handelen gaat dat niet zomaar op. Voor opzettelijk handelen ben je altijd volledig aansprakelijk, en dit neigt daar toch wel een tikje naar. Een hoster zou er dan ook voor kunnen kiezen om te zeggen, binnen 14 dagen herstellen en anders de site in een sandbox of op zwart. (Ja, de wet vindt het erger dat je iets half doet dan wanneer je iemand op zwart zet.)

Arnoud

Mag een spamfilterdienst de beveiliging van e-mail afslopen?

spam-verboden.pngEen lezer vroeg me:

Sommige bedrijven bieden een service om alle uitgaande email transparant te scannen op spam/virussen via een soort SMTP netwerk proxy. Als onderdeel van dat proces schakelen ze de TLS encryptie uit, waardoor alle email plain-text wordt afgeleverd naar het internet. Is dat juridisch wel toegestaan?

Er is geen wettelijke regel die expliciet zegt dat e-mail te allen tijde versleuteld moet worden getransporteerd. Je bent als bedrijf dus vrij om te kiezen of en welke beveiliging je hanteert.

Maar wacht. Per 1 januari krijgen we een aanscherping van de privacywet (Wet bescherming persoonsgegevens), die stelt dat persoonsgegevens te allen tijde “adequaat” moeten zijn beveiligd tegen misbruik en ongeautoriseerde toegang. Die norm bestaat al jaren, de aanscherping komt erop neer dat je in theorie acht ton boete kunt krijgen vanaf januari als je hem schendt.

Wat is nu “adequaat” bij e-mail? Helaas zijn daar geen harde regels voor. Het hangt er namelijk vanaf wat voor gegevens er in die e-mail staan. Gaat het alleen om afzender en ontvanger (relatief weinig gevoelig) of worden er in de bijlage medische dossiers verstuurd (nogal gevoelig)? Dat bepaalt voor een groot deel de vereiste beveiligingsmaatregelen om “adequaat” te mogen heten.

E-mail over SSL/TLS transporteren is een simpele maatregel die eigenlijk altijd wel kan. Dus de factor is dat wel het minimum, net zoals SSL op een bestelformulier van een webwinkel de facto vereist is. Als je dat weglaat, dan heb je dus wat uit te leggen.

De logica achter dit proces begrijp ik niet helemaal. Natuurlijk, je kunt geen mails scannen als ze door een beveiligde verbinding lopen, maar waarom zet je dan niet een beveiligde verbinding op naar de virusscannersite?

Arnoud

Xs4all-gebruiker krijgt certificaat Xs4all.nl in handen, mag dat?

xs4all-vals-certificaatEen abonnee van Xs4all is erin geslaagd om een ssl-certificaat voor Xs4all.nl aan te maken, las ik bij Tweakers. Met behulp van het e-mailadres administrator@xs4all.nl, dat hij als alias voor zijn privéadres aanmaakte, wist de gebruiker bij certificaatautoriteit Comodo een ssl-certificaat voor Xs4all.nl te genereren. Comodo dacht kennelijk dat ze met een administrator van XS4All te maken had. Maar is dat nu legaal, met nepgegevens een certificaat aanmaken?

De wet kent geen specifieke regels over het aanvragen van een SSL-certificaat op andermans naam. De enige regel die volgens mij in de buurt komt, is die van valsheid in geschrifte (art. 225 Strafrecht). Oftewel:

Hij die een geschrift dat bestemd is om tot bewijs van enig feit te dienen, valselijk opmaakt of vervalst, met het oogmerk om het als echt en onvervalst te gebruiken of door anderen te doen gebruiken

Een certificaat kun je zien als een elektronisch geschrift (vergelijk art. 6:227a BW en 156a Rechtsvordering), dus aan dat element is wel voldaan. Het certificaat is bestemd om te bewijzen dat je een verbinding hebt met de website van in dit geval XS4All, en dat kun je “enig feit” noemen.

Het certificaat is weliswaar echt, en dus niet nagemaakt/vervalst, maar het opmaken is gebeurd door misleiding en dat is een vorm van “valselijk opmaken”. Dus ook aan dat element is voldaan.

Alleen bij het oogmerk struikel ik. Althans in dit geval: de gebruiker heeft het certificaat meteen ingetrokken en heeft het nergens werkelijk gebruikt. Dan kun je dus niet spreken van een oogmerk om het als echt en onvervalst te gebruiken of te laten gebruiken.

Zou het geen valsheid in geschrifte zijn, dan kun je een vervalst certificaat alleen aanpakken als het wordt gebruikt om daadwerkelijk illegale zaken te doen. Het is dan een middel voor bijvoorbeeld het aftappen van vertrouwelijke communicatie (een man-in-the-middle aanval) of computervredebreuk (valse authenticatie). Ook phishing door een valse webwinkel op te zetten met dat certificaat zou natuurlijk strafbaar zijn (oplichting). Maar daarvan is hier geen sprake.

Daarbij komt dat de opzet van deze actie zodanig is dat het voor mij een evidente journalistieke truc is: een misstand aan de kaak stellen door te laten zien dat het echt mis is.

Dus nee, bij deze specifieke stunt weet ik geen reden waarom het niet zou mogen. Maar het betekent natuurlijk niet dat iedereen nu ‘dus’ ook nepcertificaten mag maken, zeker niet als je daar daadwerkelijk diensten mee gaat leveren. Je moet wel een punt hebben om te maken.

Arnoud

Mag Kliksafe https verkeer openbreken?

kliksafeVia Twitter kreeg ik de vraag:

Kliksafe heeft tegenwoordig een speciaal filter voor HTTPS, waarin ze het verkeer decrypten. In hoeverre is dat toegestaan?

Kliksafe is een aanbieder van gefilterd internet. Wie deze dienst afneemt, kan voorkomen dat er ongewenste websites en diensten opgeroepen kunnen worden. De dienst kent een blacklist, whitelist en contentfilter – dat alle opgevraagde informatie scant die niet van een whitelisted site afkomstig is. (Geblackliste sites kun je natuurlijk niets van opvragen.)

Een handige internetter kan natuurlijk een encrypted verbinding opzetten en zo een dergelijk filter omzeilen. Er valt weinig te contentfilteren als je de content niet kunt lezen. Vandaar dat Kliksafe een https-filter heeft ontwikkeld. Dit filter werkt als een man-in-the-middle: de browser denkt dat hij met de bank of Youtube verbinding maakt, maar in feite gebeurt dat met het filter. Hierbij wordt een sleutel gebruikt die het filter kent, zodat het filter het verkeer kan openmaken. Vervolgens zet het filter een verbinding met bank of Youtube op, waarbij het zich voordoet als de browser. De site heeft dus geen idee dat er iemand tussen zit. Overigens staan banksites op de witte lijst, dus hun verkeer blijft versleuteld.

Het openbreken van dergelijk verkeer is al langer bekend. Bedrijven gebruiken dit nog wel eens om uitgaand werknemersverkeer te kunnen inspecteren op strijd met het bedrijfsbeleid. Of dat mag vraag ik me zeer af. Echter, omdat het decrypten hier gebeurt op speciaal verzoek van de klant zelf, lijkt me er weinig mis mee. Net zoals een slotenmaker best op mijn verzoek mijn voordeur mag openbreken.

Iets dubieuzer wordt het als het gaat om een verzoek van de klant maar niet om zijn eigen verkeer. De internetverbinding kan binnenshuis worden gedeeld, en zo zouden ouders het encrypted internetverkeer van hun kinderen kunnen lezen. Dat voelt ergens toch een tikje gek, net als een slotenmaker inhuren om de afgesloten kast in de kinderkamer open te maken (of een securitybedrijf om een verborgen camera in die kamer op te hangen). Maar dat lijkt me toch vooral een keuze van die klant, en niet iets waar je Kliksafe op kunt aankijken.

Arnoud

Moet mijn contactformulier SSL-beveiligd zijn?

https-secure-secuur-netwerkEen lezer vroeg me:

Op mijn site wil ik een contactformulier toevoegen. Nu las ik dat je dan verplicht een SSL-verbinding (https) toe te passen, dat is nogal een dure grap voor mij. En toen zag ik dat jij op je blog geen SSL-verbinding hanteert, niet bij je contactformulier en niet bij het plaatsen van reacties. Dus mag ik dan concluderen dat het niet hoeft?

Met een contactformulier sturen mensen persoonsgegevens in. De wet eist dat je die persoonsgegevens ‘adequaat’ beveiligt tegen misbruik en ongeautoriseerde toegang. Een SSL-beveiliging is de meest voor de hand liggende en simpelste manier om dit te doen, vandaar dat vrijwel iedereen dat middel toepast bij bestel- en contactformulieren.

De wet zegt echter nergens létterlijk dat SSL-beveiliging verplicht is. Sterker nog de wet bepaalt eigenlijk nergens überhaupt letterlijk welke maatregelen genomen moeten worden. Je moet als beheerder/exploitant van een site zelf bepalen welke maatregelen gepast zijn gezien de aard van de informatie en het mogelijk misbruik daarvan.

Bij een bestelformulier op een website stuur je allerlei gegevens op waarmee je een juridisch bindende bestelling plaatst, vaak inclusief betaalgegevens (creditcardnummer). Die kunnen worden gesnift en hergebruikt, en dat is wel ernstig genoeg om beveiliging bij het verzenden te vereisen.

Maar bij een blogcommentaarformulier? Oké stel iemand zit in hetzelfde internetcafé als jij, monitort het draadloze netwerk en onderschept je naam en reactie. En dan? Dan kan hij ook reageren op mijn blog. En de reactie te weten komen, drie seconden voordat deze online gaat voor de hele wereld. Nou en?

Het enige stukje echt vertrouwelijke informatie is het e-mailadres, dat ik als beheerder wel zie maar de andere reageerders niet. Tsja. Is de kans op misbruik van dat e-mailadres groot genoeg om een SSL verbinding op dat formulier te rechtvaardigen?

Arnoud

Nokia ontsleutelt SSL-verkeer van gebruikers

nokia-xpress-browserDe Nokia Xpress browser voor Asha en Lumia-toestellen heeft een proxy-server die vertrouwelijk HTTPS-verkeer middels een eigen certificaat ontsleutelt, zonder dat gebruikers zijn geïnformeerd. Dat schreef Webwereld vrijdag. Met die proxserver versnellen ze het verkeer naar mobiele apparaten, wat op zich handig is, maar dat bij versleuteld verkeer doen is opmerkelijk: alsof de taxichauffeur je koffers even opnieuw inpakt zodat het beter past in de achterbak. Maar is het verboden?

Het doel van de Nokia-proxy is dataverkeer versnellen. Dat doen er wel meer (Opera is er groot mee geworden) maar opmerkelijk bij Nokia is dat ze het ook doen voor beveiligd verkeer. Dat is bepaald niet de bedoeling, want beveiligd (SSL) verkeer is nu juist bedoeld om niet onderschept te kunnen worden. Maar ja, als je de browser controleert dan kun je zo ongeveer alles. Heel kort gezegd komt het erop neer dat Nokia’s proxy zich voordoet als je browser naar de site (van bv. je bank) toe, en naar jou toe zich voordoet als de bank. Daardoor denkt de browser (met dank aan een speciaal Nokiacertificaat) dat alles in orde is, en meent de bank gewoon met jou te communiceren. In securitytermen heet dit een “man in the middle attack”.

Is zo’n aanval strafbaar als je het als browserbakker doet? Ik zou geen wetsartikel weten eigenlijk. We hadden in 2011 een ietwat vergelijkbare discussie in de KPN DPI-affaire, waarbij het telecombedrijf met deep packet inspection-achtige technieken het verkeer van gebruikers analyseerde om onder meer te zien of men WhatsApp gebruikte. Dit leidde tot de netneutraliteitswet want dit moest toch écht niet kunnen.

Diverse partijen, waaronder ikzelf, hadden toen geroepen dat KPN de strafwet overtrad. Artikel 139c lid 1 Strafrecht verbiedt namelijk

opzettelijk en wederrechtelijk met een technisch hulpmiddel gegevens aftappen of opnemen die niet voor hem bestemd zijn en die worden verwerkt of overgedragen door middel van telecommunicatie of door middel van een geautomatiseerd werk.

Dit artikel gaat nadrukkelijk niet alleen om het afluisteren van inhoud maar ook om analyses van de gegevensoverdracht zelf. Daarmee leek me óók DPI een strafbare zaak. Mar

Bovendien is er lid 2 van dit artikel, dat bepaalt:

[Het verbod] is niet van toepassing op het aftappen of opnemen … ten behoeve van de goede werking van een openbaar telecommunicatienetwerk.

en zeker in de Nokia-situatie zie ik dit wel van toepassing zijn. Het enige doel (nemen we dan maar aan) is het netwerkverkeer versnellen, en dat valt toch wel onder “goede werking”. Een verwerking van persoonsgegevens lijkt het me ook niet echt, en voor zover het dat al zou zijn dan valt dit onder “uitvoering van de overeenkomst”. Wel behoort Nokia dan te melden dat ze dit doen, en het is opmerkelijk dat ze dit nergens documenteren. Maar juridisch gezien heet dat “een slordigheidje”, meer niet.

Ondertussen is Nokia zo geschrokken van de ophef dat ze nu gewoon geen SSL-verbindingen meer opzetten. De data wordt nog wel veilig opgehaald bij de beveiligde site, maar vanaf de Nokia-proxy onversleuteld doorgegeven. Eh. Dat is nou juist mínder handig. Update (15/1): Hoewel? Ze tunnelen https verkeer over deze onversleutelde verbinding. Zo komt het verkeer toch veilig aan.

Arnoud