Categorie: Security

About Security

Subscribe Feeds

Boekhouder die illegaal inlogde op server kan zich niet beroepen op noodtoestand

Geplaatst op in Regulering, Security, 14 reacties

Een boekhouder die illegaal inlogde op de server van het bedrijf waarvoor hij de boekhouding verzorgde, om zo gevoelige informatie te verzamelen voor de ontslagprocedure van een collega, kan zich niet beroepen op een noodtoestand, zo las ik bij Security.nl. Wacht, een noodtoestand in het strafrecht, is dat een ding? Jazeker. De Hoge Raad oordeelt alleen helaas voor de boekhouder dat die situatie niet opgaat, en veroordeelt hem gewoon voor computervredebreuk.

Tijdens het ontslagproces van een medewerker van het bedrijf werd ontdekt dat die over vertrouwelijke informatie beschikte, waaronder financiële stukken, offertes, correspondentie, privé mails en zeer geheime stukken. Dat bleek (zoals ik uit het arrest haal) te herleiden tot deze boekhouder, die maar liefst 45 keer had ingelogd op de server en daar informatie had opgehaald die niets met zijn eigenlijke werk te maken had. Weliswaar mocht hij op die server zijn, maar zeker niet bij die bestanden.

Het verweer van de boekhouder was opmerkelijk:

Toegespitst op deze gedragingen, is het beroep op overmacht in de zin van noodtoestand, als volgt nader toegelicht: de verdachte bevond zich tussen conflicterende belangen; hij voelde dat hij de maatschappelijke plicht had om de waarheid van de feiten in de ontslagprocedure van [betrokkene 1] in te doen brengen; [betrokkene 1] had hem hier om verzocht; de verdachte stelt dat [het bedrijf] de financiële positie van het bedrijf doelbewust en valselijk te negatief aan de kantonrechter had gepresenteerd om zo een zo laag mogelijke ontslagvergoeding te moeten betalen; dit moest in hoger beroep worden rechtgezet.
Heel erg meedenkend in de richting van de boekhouder: als je ziet dat een collega bij een ontslagprocedure een te lage vergoeding krijgt op basis van bedrijfsomzetgegevens waarvan jij (als boekhouder dus) weet dat ze niet kloppen, dan snap ik best dat je daar boos om wordt en dat onrecht wilt corrigeren. En ja, het is juridisch erkend dat je vanuit een toestand van nood kunt handelen en dat je dan straffeloos bent:
“uitzonderlijke gevallen kunnen meebrengen dat gedragingen die door de wetgever strafbaar zijn gesteld, niettemin gerechtvaardigd kunnen worden geacht, onder meer indien moet worden aangenomen dat daarbij is gehandeld in noodtoestand, dat wil zeggen -in het algemeen gesproken- dat de pleger van het feit, staande voor de noodzaak te kiezen uit onderling strijdige plichten en belangen, de zwaarstwegende heeft laten prevaleren”. [HR 23 juli 2011, ECLI:NL:HR:2011:BP5967]
De lat ligt alleen wel heel erg hoog, er moet echt op dat moment geen andere optie zijn. Meelezende juristen moeten nu wellicht denken aan het opticien-arrest, waarin een opticien niet strafbaar was door na openingstijd een zeer slechtziende man een bril te verkopen. Die persoon had zó zeer op dat moment een bril nodig, dat het (geringe) belang van de Winkelsluitingswet moet wijken. Maar omdat het hier om een langere periode aan gedragingen ging, ziet de HR dat niet van toepassing:
Het gestelde rechtvaardigheidsgevoel is in deze niet voldoende dwingend, en wordt overigens ook vertroebeld met hetgeen de verdachte zelf bij de politie heeft verklaard: “voor mij geldt het motto: Het doel heiligt de middelen” en “eigen schuld dikke bult”. Daar komt bij dat de omstandigheden die zouden hebben genoopt tot wetsovertreding al geruime tijd speelden. Gesteld noch gebleken is dat niet-strafbare alternatieven om het beoogd doel te bereiken voldoende zijn onderzocht en kennelijk volkomen ineffectief zouden zijn geweest. Van enige geestelijke “worsteling” leidende tot een kennelijk onvermijdelijke wetsovertreding is niet gebleken.
Ik moet zelf wel zeggen dat ik niet meteen weet wat dan die niet-strafbare alternatieven zouden moeten zijn. Het lijkt me erg moeilijk om als buitenstaander informatie aan te dragen over de financiële positie van een bedrijf, dus daarmee kun je die ontslagen medewerker niet echt helpen.

Arnoud

 

Britse politie komt duizenden cybercriminelen op het spoor via loksites, mag dat bij ons ook?

Geplaatst op in Regulering, Security, nog geen reacties

Britse rechercheurs hebben meerdere sites opgezet waar cybercriminelen zogenaamd ddos-aanvallen konden bestellen. Dat meldde Nu.nl onlangs. De politie kon zo duizenden aanvragers noteren en gaat ze allemaal een bezoekje brengen. Het riep bij een paar lezers de vraag op: is dat geen uitlokking, zou dat ook mogen naar Nederlands recht?

DDOS-bestelsites, in het jargon booter sites, zijn Justitie al lang een doorn in het oog. Europol haalde  in 2022 vijftig ddos-booters offline, mede dankzij de inzet van de Nederlandse politie. Zoals ik toen blogde:

Dergelijke diensten leveren DDoS-aanvallen op verzoek en tegen betaling, met het dunne excuus dat bedrijven wellicht hun netwerk willen testen maar dan geen behoefte hebben aan contracten, facturen of betalingen met ouderwets fiatgeld. Of zoiets.
Anders gezegd, er lopen dus veel mensen rond die graag geld uitgeven om een DDoS-aanval uit te laten voeren die in strijd is met de wet. Die mensen eruit pikken voor ze écht schade hebben aangericht, is een legitiem doel van de politie. Alleen kom je dan snel terecht in de discussie over ‘uitlokking’.

De discussie over uitlokking speelde in 2013 bij een nepvuurwerkwinkel, opgezet door de politie met als doel mensen waarschuwingen te geven die daar illegaal vuurwerk meenden te bestellen.

Van uitlokking is in ons strafrecht sprake als je iemand op andere gedachten brengt, hem overhaalt het strafbare feit te plegen terwijl hij dat zelf niet van plan was. In het lokfiets-arrest bepaalde de Hoge Raad dat je iemand niet uitlokt door een onafgesloten fiets neer te zetten op een plek waar vaak fietsen steelt. Een fiets is een fiets, en de dief kiest er nog altijd zelf voor om die te stelen. Zou een agent na het plaatsen naar een stel junks toegaan en zeggen “hee daar staat me een mooie fiets, en onafgesloten ook nog”, dan wordt het al twijfelachtiger.
Ik had er toen een kléin beetje moeite mee, omdat een winkel naar zijn aard producten promoot. Iemand die toevallig aan komt waaien en dan de strijkers, Bengaals vuur en mortierbommen in het gezicht geduwd krijgt, die kan denk ik goed verdedigen op andere gedachten gebracht te zijn door die reclame: hij kwam alleen voor legaal vuurwerk en werd door de reclame effectief overtuigd deze te kopen.

Bij DDoS-aanvallen zie ik dat niet. Natuurlijk, het standaardexcuus van die sites is dat ze zich richten op mensen die hun eigen netwerk willen testen. Maar hier worden de kopers van de diensten aangesproken. En die hebben geen mooi CRA-compliant bedrijfsnetwerk, laat staan dat het opgegeven target IP-adres behoort tot hun eigen serverpark. Dus daar is geen enkel excuus.

Het volgende argument zou zijn dat de koper-in-spe eigenlijk nooit van plan was een DDoS-aanval te bestellen, maar door de site werd overgehaald: het is makkelijk, niet duur, ze zeggen hier “niet te traceren” en dergelijke aanprijzingen. Zonder de precieze site te zien is het lastig te zeggen hoe hard de website mensen probeerde over te halen.

Maar ik zou zeggen: als men de site niet actief adverteerde bij derden, maar ‘gewoon’ als een beschikbare dienst neerzette, dan wordt er niemand op andere gedachten gebracht. Het is immers een bestaande site die de politie overnam, dus eventuele reclame of bekendheid moet je de vorige eigenaar toerekenen. Ik zie er daarom dus juridisch geen uitlokking in.

Arnoud

Nebu moet van rechter informatie over groot datalek verstrekken

Geplaatst op in Privacy, Security, 6 reacties

Softwareleverancier Nebu moet marktonderzoeker Blauw informatie verstrekken over de inbraak op de eigen systemen en de diefstal van data die daarbij plaatsvond. Dat meldde Security.nl gisteren. Dit is het oordeel van de rechtbank Rotterdam in het spoedkortgeding over dat enorme datalek met miljoenen slachtoffers, waarbij het onderzoeksbureau Blauw onduidelijk was wat er nu precies gelekt was en hoe.

Nebu is in dit verband een SaaS-dienstverlener, die een platform aanbiedt waarop partijen als Blauw marktonderzoeken kunnen uitvoeren. Blauw doet dat dan weer in opdracht van partijen zoals de NS, VodafoneZiggo, zorgverzekeraar CZ of de Rijksdienst voor Ondernemend Nederland. De rechtbank laat in het midden of Blauw dan verwerker is of niet (want niet relevant nu), maar is het met Blauw eens dat Nebu in ieder geval een verwerker is. En dan moet er dus een verwerkersovereenkomst zijn, of zoals de rechtbank het juridisch correct noemt een verwerkingsovereenkomst. Daarin staat deze vrij standaard bepaling:

[Nebu] immediately notifies [Blauw] of any incident in relation to the processing of personal data. In the event of an incident, [Nebu] will fully cooperate with [Blauw] and follow the instructions issued by [Blauw] in respect of this incident. This will enable [Blauw] to carry out a proper investigation into the incident, to formulate a correct response and to take appropriate follow-up steps in respect of the incident. If an immediate notification is not possible, [Nebu] will notify [Blauw] at least within 24 hours after an incident occurring.
Deze clausule is een vrij standaard herformulering van de verplichtingen van de verwerker uit artikel 28 lid 3 AVG, meer specifiek subleden f en h die over de bijstands- en informatieplichten gaan. Echter, nadat het datalek openbaar werd, bleek er niet bijster veel informatie te worden gedeeld door Nebu:
Op 13 maart 2023 meldde Nebu aan Blauw en andere klanten van Nebu dat er sprake is van een storing in haar dienstverlening waardoor haar diensten offline gehaald zijn. Ook stuurde zij die dag meerdere updates. Daarin werd nog niet gemeld dat er sprake was van een cyberaanval of een (mogelijk) datalek.

Op 14 maart 2023, 23:13 uur, heeft Nebu Blauw en andere klanten van Nebu bericht dat op vrijdag 10 maart 2023 een cyberaanval heeft plaatsgevonden op de productieomgeving van Nebu in Nederland en dat de diensten daardoor niet beschikbaar waren. Nebu kondigde daarbij een forensisch onderzoek aan.

Nebu zond op 20 maart 2023 een update aan Blauw en andere klanten van Nebu over de herstart van haar RDP (remote desktop protocol) dienstverlening. De update bevat geen informatie over de cyberaanval. Op 21 maart 2023 schreef Nebu aan Blauw dat zij op dit moment geen andere informatie had om te verstrekken dan de informatie uit de update.

Dit is nogal mager inderdaad, zeker als je dat ziet in het licht van de enorme omvang van het datalek zoals die inmiddels openbaar is geworden. De rechter is er dan ook snel klaar mee:
Het instructierecht van Blauw is bedoeld, zo blijkt uit de tekst van artikel 5.1, om Blauw in staat te stellen een incident met persoonsgegevens op behoorlijke wijze te onderzoeken, haar reactie daarop te bepalen en om zo nodig gepaste stappen te kunnen nemen. Daaraan moet Nebu dus meewerken en dat moet zij op loyale en royale wijze doen.
De exacte juridische kwalificatie van “loyale en royale wijze” van nakoming van een verbintenis is wellicht een novum, maar de strekking is duidelijk: je had je niet zo in stilzwijgen mogen hullen en volstaan met generieke uitspraken dat er iets mis is gegaan. Je telefoonnummer van je site halen is ook niet handig voor de beeldvorming, maar belangrijker was niet laten zien dat je meteen serieus op onderzoek uitging.
Bij het voorgaande heeft de voorzieningenrechter meegewogen dat er tot dus ver geen onafhankelijk forensisch onderzoek heeft plaatsgevonden of zelfs maar is gestart. Dit maakt het eerder redelijk dat Blauw informatie wil hebben dan in de situatie dat Nebu direct een onafhankelijk onderzoek had gelast. Dat hierdoor mogelijk bedrijfsvertrouwelijke informatie van Nebu in het bezit van Blauw komt, is het onvermijdelijke gevolg. De voorzieningenrechter gaat er overigens vanuit dat Blauw op prudente manier zal omgaan met de informatie die zij als gevolg van dit vonnis zal verkrijgen.
Dat van die onderzoeker is opmerkelijk. Inderdaad zijn we al een paar weken sinds de ontdekking van het datalek, en kennelijk is er bij Nebu niets gebeurd qua diepgravend onderzoek. In die situatie ziet de rechter het als een redelijke instructie van Blauw aan Nebu dat die laatste een onderzoek laat uitvoeren:
Nebu heeft ter zitting verklaard dat zij nog niet kan aangeven of data van (de klanten van) Blauw is geëxfiltreerd. Dit betekent dat het Nebu in een termijn van enkele weken niet is gelukt om dit zelf te achterhalen. Onder deze omstandigheid, gelet ook op het grote aantal persoonsgegevens waar het in deze kwestie om gaat en in het licht van de aanvankelijk beperkte informatie die Nebu aan Blauw heeft verstrekt, schaart de voorzieningenrechter de vordering tot benoeming van een forensisch onderzoeker onder het instructierecht van Blauw op grond van artikel 5.1 van de DPA.
Nebu krijgt vijf werkdagen (het is Paasweekend, jaja) om een extern forensisch bedrijf te contracteren en binnen vier weken een rapport te laten leveren. De overige gevraagde informatie die Blauw wil hebben moet ook worden verstrekt, mits dat beperkt blijft tot informatie die voor Blauw zelf relevant is en geen juridisch advies aan Nebu betreft.

De gevolgen van dit specifieke lek zullen nog wel even doorlopen. Maar de uitspraak laat mooi zien dat de brede bewoordingen van de AVG en de verwerkersovereenkomst dus inderdaad zo breed toegepast kunnen worden. Vaak wordt daar niet bij stilgestaan omdat men ‘gewoon’ de wet over denkt te schrijven.

Arnoud

Organisaties informeren consumenten onvoldoende over datalekken, hoe moet het dan wel?

Geplaatst op in Privacy, Regulering, Security, 7 reacties

De Nederlandse Consumentenbond concludeert op basis van een steekproef dat veel organisaties consumenten niet goed genoeg informeren bij datalekken. Dat meldde Tweakers onlangs. In de steekproef bleken 37 van de 69 onderzochte waarschuwingen voor datalekken onduidelijk: er staat te weinig concrete informatie in, en vaak ontbraken ook de stappen die je zelf kunt nemen om de schade te beperken. Het riep de vraag op: hoe zou het dan wel moeten, nog meer informatie?

Ik kreeg even juridische jeuk van de passage over modebedrijf Livera, die ik jullie dan ook niet wil onthouden:

In het bericht met de kop ‘Bescherming van persoonsgegevens bij Livera hoogste prioriteit’ wordt eerst de bedrijfsstructuur en de aandacht van Livera voor gegevensbescherming beschreven; pas in de derde alinea wordt vermeld dat het moederbedrijf is gehackt en dat persoonsgegevens van klanten mogelijk zijn ingezien.
Deze is wel erg cru, maar berichten met koppen als “Mededeling naar aanleiding van publiciteit” zie ik ook met enige regelmaat voorbij komen. Gelukkig zijn er ook bedrijven die mensen wel adequaat informeren, door een keurig bericht met uitleg wat er is gelekt, welke stappen men nu heeft genomen en op welke risico’s je nu in het bijzonder zou kunnen letten. Een mooi voorbeeld blijft voor mij het datalek bij de Philips-personeelsadministratie, waarbij men zowaar een dark net monitoring service inhuurde om in de gaten te houden of NAW+bsn gegevens werden verhandeld op het nietdoorzoekbareweb.

Het achterliggende punt blijft natuurlijk: wat zou je nog meer, of nog anders moeten doen? Dan kom je al snel uit bij een schadevergoeding, wat juridisch lastig ligt omdat de schade moeilijk te kwantificeren is. Als de Shell diesel verkoopt vanuit de benzine-pomp, dan kun je vrij eenvoudig je factuur voor het reinigen van je injectiesysteem bij de pomp indienen. Maar bij persoonsgegevens? Ja, je bent kwetsbaarder voor phishing en er zal vast een AI op je profiel worden getraind, maar welk bedrag zet je daar op?

Er zijn vele stichtingen bezig met allerlei massaclaims, waarbij vaak 500 euro opduikt omdat dat eenmalig is toegekend (bij een concreet lek van medische gegevens). Het voelt ergens wat hoog, want is een datalek bij een klanttevredenheidsenqueteur nu dat echt waard? Ook is er altijd die weerstand dat die stichting dan “al dat geld pakt” terwijl het gaat om vergoeding van andermans schade. Maar als de wetgever de bal laat liggen, dan springen particuliere partijen in het gat.

Ik blijf erbij: er moet een staatje komen, het liefst door de AP, net zoals we bij letselschade al lange tijd het Smartengeldboek hebben. Want zelfs als daarin 5 euro had gestaan per betrokkene, dan had de NS nu dus een half miljoen moeten uitkeren en dát maakt niveautje-dassenburcht indruk in de Boardroom.

Arnoud PS: Vergeet je niet in te tekenen voor mijn boek? Zie onder!

Mag een bedrijf van de AVG mijn inzage-data wel via de mail sturen?

Geplaatst op in Privacy, Security, 23 reacties
jarmoluk / Pixabay

Een lezer vroeg me:

Als je data opvraagt waar je volgens de AVG recht op hebt, dan is de organisatie verantwoordelijk voor het veilig versturen van deze data. Wat nu als een organisatie deze via e-mail stuurt? Ze kunnen dan wel TLS gebruiken, maar dat beschermt de data niet als deze eenmaal in mijn mailbox zit.
Inderdaad, een verwerkingsverantwoordelijke (zoals zo’n organisatie) moet zorgen voor een goede beveiliging van die persoonsgegevens. Dat speelt ook bij het afhandelen van een inzageverzoek.

Het gebruik van TLS bij het verzenden van e-mail lijkt me een voor de hand liggende beveiligingsmaatregel tegen meelezen in transit. Ik zou niet weten waarom je anno 2023 als organisatie mail verstuurt zonder TLS naar de ontvangende mailserver.

Natuurlijk beveiligt TLS niet tegen een inbraak in de mailbox bij de ontvanger. Maar op het moment dat de mail bij de (organisatie of isp van de) ontvanger is aangekomen, is de ontvanger zélf verwerkingsverantwoordelijke van die gegevens geworden. Daarmee houdt op dat moment de zorgplicht van de verstrekkende organisatie gewoon op.

Een organisatie zou de gegevens ook anders kunnen verstrekken, zoals een download vanuit een beveiligde site of de bijlage voorzien van een wachtwoord dat via apart kanaal wordt verstrekt. Maar ik zie het wezenlijk verschil niet: zodra ik de download binnen heb of de bijlage ontvang, is de data nog steeds mijn verantwoordelijkheid.

Heel misschien is verdedigbaar dat je mag verwachten dat veel ontvangers niet goed zijn in security, en dat je ze dus een beetje moet helpen. Bijvoorbeeld dus door een wachtwoordbeveiliging met het wachtwoord apart verstuurd. Maar nog los van de vraag of je bij zo’n inzageverzoek wel een tweede communicatiekanaal hébt, ik weet geen artikel in de AVG waaruit zo’n vergaande zorgplicht dwingend zou volgen.

Arnoud

Datalek Nederlandse bedrijven steeds groter: zeker 2 miljoen klanten getroffen

Geplaatst op in Security, 14 reacties

Zeker 2 miljoen Nederlandse klantgegevens blijken betrokken bij een groot Nederlands datalek, las ik bij de NOS. Meerdere marktonderzoekers hebben aan de NOS bevestigd slachtoffer te zijn, en wijzen naar softwareleverancier Nebu. Marktonderzoeker Blauw heeft samen met collega’s al een civiele procedure aangekondigd om Nebu te dwingen meer informatie te verstrekken. Het riep onder meer de vraag op: hoe zit dat met aansprakelijkheid onder de AVG bij zo’n datalek?

Dinsdag wordt er gedagvaard, zo te lezen:

Volgens [Blauw-topman Jos] Vink wil Blauw van Nebu weten welke persoonsgegevens precies zijn weggehaald bij Blauw en hoe het heeft kunnen gebeuren. Als de softwareleverancier voor dinsdag duidelijkheid verschaft, trekt Blauw het kort geding volgens Vink in. “Sinds het datalek is het contact matig en krijgen we niemand te spreken”, zegt hij. Blauw heeft ook een advocaat genomen voor juridisch advies over wat het marktbureau het beste kan doen en hoe het klanten zo goed mogelijk kan informeren.
Een datalek van deze omvang is natuurlijk een AVG-probleem, en het verbaast dan ook niet dat de AP een onderzoek is gestart. Dat zal primair gericht zijn tegen de verwerkingsverantwoordelijken, dus de bedrijven die de marktonderzoeksbureaus inschakelden, zoals de NS, VodafoneZiggo, zorgverzekeraar CZ, de Vrienden van Amstel Live, de Rijksdienst voor Ondernemend Nederland en woningcorporatie Stadgenoot. Maar zowel een verantwoordelijke als een verwerker zijn apart aan te spreken door de AP voor het niet hebben van een adequate beveiliging (art. 32 AVG). De vraag is dus nogal prangend wat er precies gebeurd is, hoe kon de data worden buitgemaakt en had dat redelijkerwijs voorkomen kunnen worden?

Blauw is een marktonderzoeksbureau, dat gebruik maakt van de softwaredienst van Nebu, een ISO27001 gecertificeerd bedrijf dat “[offers] 25 years of experience in building and delivering software solutions for Market Research.” Maar toch ging dat niet helemaal zoals verwacht kennelijk. De collega’s bij marktbureau USP weten meer:

[Directeur Jan Paul Schop van marktonderzoeker USP] zegt dat USP voorlopig blijft samenwerken met Nebu. “We werken al meer dan 15 jaar met Nebu samen en we hebben niet eerder problemen op dit vlak gehad. Feitelijk is Nebu zelf niet gehacked, maar is de moedermaatschappij in Canada gehacked. Via dat kanaal is men bij Nebu binnengekomen”, aldus Schop.
Onder de AVG kan een verwerkingsverantwoordelijke een verwerker aanspreken voor de gevolgen van een inadequate beveiliging (art. 82 AVG). Bij een softwareleverancier kun je niets verhalen, tenzij je dat contractueel zo geregeld hebt. Het is dus even de vraag wat Nebu precies is: leveren die alleen software, of zit er ook dienstverlening bij waarbij persoonsgegevens de database van Nebu in lopen? Want dan zou Nebu een subverwerker zijn, en daarvoor geldt dan dezelfde regel.

Arnoud

Mag en moet ik de fallout van de Acropalypse bij mijn gebruikers op gaan ruimen?

Geplaatst op in Security, 3 reacties

Een lezer vroeg me:

Je zult vast hebben gelezen over de aCropalypse, een kwetsbaarheid in Google- en Windows screenshot apps die bij het croppen weggesneden informatie behielden in het bestand. Wie zo’n screenshot dan publiceert, onthult daarmee meer informatie dan zhij wil. Op forums (zoals die ik beheer) staat het dus vol met potentieel kwetsbare screenshots – denk aan weggeknipte naam- en adresgegevens, privéberichten of misschien wel privéfoto’s. Er zijn tools om dat te doen, ook in batch op alle mediabestanden op het forum. Mijn moderators en ik vragen ons af of wij dat zouden mogen doen, en of we wellicht verplicht zijn vanuit onze ICT-zorgplicht om dit te doen nu we weten van deze enorme kwetsbaarheid?
Dit is inderdaad een hele pijnlijke: in plaats van een afbeelding te vervangen met zijn bijknipsel, worden de twee achter elkaar in hetzelfde bestand gestopt. Wie dus een beetje snuffelt in het bestand, kan zo het origineel terughalen. Concreet voorbeeld in deze tweet, waarbij men de volledige creditcardgegevens haalt uit een afgelakte(!) en bijgeknipte crop van een screenshot van een mail waarin (zogenaamd) de plaatser een creditcard uitgereikt krijgt. Hetzelfde kan dus spelen met huisadressen, herkenbare foto’s van je kinderen of contactgegevens die je niet bedoelde te delen.

Wie dus screenshots ergens heeft gepubliceerd of gedeeld die waren bijgewerkt met deze tools (de Markup tool van Google Pixel, Snip & Sketch for Windows 10 en Snipping Tool for Windows 11) kan dus een serieus probleem hebben. Weghalen en vervangen is dus het devies, alleen waar stonden ze ook allemaal weer?

Een forumbeheerder of image-hostingorganisatie kan in principe bij alle afbeeldingen, en zou ze met een detectie-script kunnen controleren en opschonen. Alle afbeeldingen worden dan ontdaan van de originele informatie, zodat alleen het (beoogde) screenshot met eventuele strepen en andere tekeningen overblijft. Daarmee zou de kwetsbaarheid verholpen zijn, althans voor de kopie op die site – als een derde al een kopie gedownload heeft, dan is daar niets meer aan te doen.

Nergens in de wet staat een expliciet verbod, ook nergens in de wet staat een expliciete plicht om zoiets te doen. Je komt dan inderdaad uit bij de zorgplicht voor een dienstverlener, die bepaalt dat je moet doen wat een “goed opdrachtnemer” zou doen (art. 7:401 BW). Dat is net zo’n vage term als de redelijkheid en billijkheid, dus het komt neer op een geschikte redenering.

Als eerste zullen mensen misschien denken, als beheerder of hoster ben je niet aansprakelijk voor wat mensen op je site publiceren. Dat klopt (art. 6:196c BW en vanaf 1 januari 2024 artikel 6 DSA, zie mijn nieuwe boek) maar betekent niet dat je dus niet mág ingrijpen. Het betekent alleen dat als er claims komen over die inhoud, je daar geen gehoor aan hoeft te geven. De huidige wet zegt “niet aansprakelijk”, de DSA voegt toe dat het moet gaan om “illegal information” maar dat lijkt niet echt een serieuze beperking van de oude regel te zijn. Ook staat er zowel nu als in de DSA dat je geen actieve zoekplicht hebt. Als je dus in het algemeen weet dat de aCropalypse bestaat, of dat er bij jouw forum best eens screenshots kunnen zijn die hieraan lijden, dan nog móet je niet in actie komen. Dat beperkt dus je zorgplicht.

Tegelijkertijd: het mág wel, want niets in de wet verbiedt je om actief te gaan zoeken. En het is ook niet zo dat je dan automatisch aansprakelijk wordt voor de afbeeldingen die je hebt gemist, juist omdat je dit automatisch doet met een tool die checkt op technische kenmerken. Ook over andersoortige claims over de opgeschoonde afbeeldingen maak ik me geen zorgen, je hebt immers geen idee wat daar staat omdat je het met een automatische tool deed, dus hoezo weet je dan ineens dat er iets anders mis kon zijn? Ik zie ook niets in het argument dat je dan ineens ook op criterium X of eigenschap Y zou moeten gaan controleren omdat je hebt laten zien dit te kunnen.

De enige reële tegenwerping die ik kan bedenken is bij afbeeldingen die je incorrect bewerkt. Dan maak je concreet iets stuk in een publicatie van een gebruiker. Maar ten eerste is de kans daarop vrij klein, wederom omdat je het met een tool doet die specifiek dit probleem oplost, en de oplossing is vrij rechttoe rechtaan, namelijk het weghalen van de ‘oude’ afbeelding die technisch eenduidig herkenbaar is in het bestand. Ten tweede zie ik zo even niet de schade: je beoogde een screenshot te plaatsen, wat er nu staat ís een screenshot, wat is er nu precies mis?

Arnoud

Als je klant je broncode wist, dan hou je een leeg auteursrecht over, succes verder

Geplaatst op in Intellectuele rechten, Security, 10 reacties

“Eiser heeft al vrijwilliger software ontwikkeld voor gedaagde.” Een zin in een arrest waar menig ict-jurist rillingen van krijgt: weinig dingen gaan zo vervelend verkeerd als afspraken tussen vrijwilligers. Ook in deze zaak: de software was heel handig, maar op zeker moment is de samenwerking beëindigd, en oh ja oeps, toen “heeft gedaagde de computer waarop haar server draaide laten formatteren en vervolgens verkocht.” Waarna de eiser nu zijn auteursrecht inzet om de broncode terug te zetten. (Dank, tipgever)

Het gerechtshof (ja, dit ging in hoger beroep) legt de feiten kort en zakelijk uit:

[appellant] heeft als vrijwilliger software voor [de stichting] ontwikkeld. Aan die samenwerking is een einde gekomen. Op enig moment heeft [de stichting] de computer waarop de server van [de stichting] draaide laten formatteren en vervolgens verkocht. [De stichting] beschikt nog over een gedeeltelijke back-up. [appellant] wil dat [de stichting] hem de broncode van de door hem voor [de stichting] ontwikkelde software afgeeft en, wanneer dat niet (meer) mogelijk is, dat [de stichting] hem schade vergoedt die hij daardoor lijdt.
De software had als doel het incasseren van donaties, ter vervanging van een commercieel pakket van een derde. Ik zie wel hoe dat enige waarde heeft, ook als de samenwerking ten einde is gekomen – genoeg andere stichtingen die wellicht óók die software willen gebruiken. Daarnaast vermoed ik dat de procedure ook iets te maken had met dat er op zeker moment onenigheid is ontstaan tussen het bestuur en een ander lid dat kennelijk enige band had met de vrijwilliger in kwestie.

Uiteindelijk zette de vrijwilliger zijn auteursrecht in om de broncode terug te krijgen. Er was weinig twijfel dát hij het auteursrecht had, ook al was er een vrijwilligersovereenkomst getekend met daarin een bepaling dat “De werkzaamheden zullen bestaan uit: Bouwen van de IKN Database“. Had daar nou “Alle auteursrechten die ontstaan uit de werkzaamheden komen toe aan de Stichting” bij gestaan, dan hadden we een mooie discussie kunnen voeren.

De stichting had natuurlijk wel een licentie (gebruiksrecht) op die software gekregen, wat uiteindelijk eindigde toen men afscheid van elkaar nam. Dat was ook niet het probleem; de stichting had een andere oplossing gevonden zo meldde men. Maar de broncode bewaren en teruggeven, dat hoort er niet bij.

Of nou ja, niet? Want in de afspraken was ergens wel terug te vinden dat de broncode “in eerste instantie enkel en alleen opgeslagen [wordt] op de daartoe aangeschafte server” die de stichting in huis had. Je zou dat kunnen lezen als een soort van beveiligingseis, het moet bij ons in-house staan zodat anderen er niet bij kunnen. Of misschien was het wel gemakzucht, dan hoeft de vrijwilliger het niet op zijn eigen laptop te beheren. Of controledrift, dan kan het bestuur een ander erbij laten (alleen hadden ze dan het auteursrecht moeten regelen). Of noem nog maar een paar motivaties.

[appellant] heeft op de zitting bij het hof duidelijk gemaakt dat er valide redenen waren om de broncode op de server van [de stichting] te schrijven, maar ook dat betekent niet dat voor [de stichting] duidelijk was of moest zijn dat zij ervoor verantwoordelijk was dat de auteursrechtelijk beschermde creatie van [appellant] op een drager behouden bleef. Op grond van de bewoordingen van de afspraken zoals [appellant] stelt dat die zijn gemaakt, hoefde voor [de stichting] niet duidelijk te zijn dat zij dat risico droeg.
Ik hoor wel eens vaker dat mensen op grond van hun auteursrecht claims leggen op kopieën. Dat is dus een probleem, zoals het Hof het hier formuleert: het auteursrecht legt aan een bewaarder niet de verplichting op om de broncode voor de rechthebbende veilig te stellen. Het auteursrecht is een verbodsrecht, een recht van uitsluiting. Je kunt wel mensen dwingen de broncode te wissen als ze die hebben in strijd met je recht, maar niet om ze je een kopie te laten geven.

Arnoud

Wanneer ben je nou gebonden aan rare bedingen in een disclosurebeleid?

Geplaatst op in Security, 7 reacties

Via Twitter:

Stel: @DIVDnlvind een lek bij veel organisaties en gebruikt security.txt om contactgegevens te vinden en in bulk organisaties te informeren. Wat als één van die organisaties een disclosure beleid hanteert met een eenzijdig geformuleerde geheimhoudingsclausule?
DIVD is het Dutch Institute for Vulnerability Disclosure dat opereert als een tussenpersoon: zij worden geïnformeerd over security issues en berichten dat aan organisaties die daarmee aan de slag moeten. Denk aan leveranciers in wiens software een gat wordt ontdekt, of bedrijven wiens gegevens zijn gelekt. Security.txt is een standaardmiddel voor het informeren van organisaties: je zet dit op je website en plaatst er contactgegevens in van de security-persoon die over incidenten of kwetsbaarheden moet worden geïnformeerd. Dit bestand is machine-leesbaar, zodat je automatisch zaken als het e-mailadres eruit kunt vissen om er vanuit je eigen applicatie een notificatie heen te sturen.

Een van de informatievelden die in een security.txt-bestand staat, is het policybeleid waaronder je meldingen aanneemt. Dit is dus de vulnerability disclosure policy of responsible disclosure policy, waarin een bedrijf uitlegt hoe je tips doorgeeft, hoe ze daarmee omgaan en wat ze van jou verwachten. En dat is dus waar de Twittervraag over gaat: als men daarin zet “gij zult voor eeuwig zwijgen over het gemelde op straffe van eene boete van vijftienhonderd florijnen”, hoe bindend is dat dan en op wie?

Het haakt in op de recente discussie over ethische hackers in België, waar ook verwezen werd naar strenge geheimhouding als je binnen een wettelijk beschermingsregime wilde opereren. Maar een kernverschil is wel dat het daar gaat over een wettelijk regime, waar je het mee te doen hebt. Hier gaat het over privaatrechtelijke regels, juridisch gezien algemene voorwaarden die deel uit kunnen maken van een overeenkomst. Als je een overeenkomst sluit met een strenge geheimhouding, dan zit je daaraan vast. Als professioneel opererende partij is daar weinig discussie over.

Het lastige is natuurlijk, waardoor zit je aan die voorwaarden vast. Een handtekening zet je niet, en je communiceert ook geen akkoord op andere wijze. Je handelt conform het gepubliceerde beleid, maar dat is zeker niet genoeg. Juristen noemen dat “browse-wrap” overeenkomsten, naar analogie met de click-wrap overeenkomst waarbij je door klikken op “I agree” ergens mee akkoord gaat, en met de oudere shrink-wrap overeenkomst waarbij je akkoord gaat (althans, beweerdelijk) door het krimpfolie te verbreken. (Alles hierover in mijn nieuwe boek.)

Hoofdregel uit de wet is dat browse-wrap overeenkomsten niet legaal zijn. Dit haal ik uit een arrest van het Hof Den Haag uit 2018, dat het sluitstuk is van acht jaar procederen inclusief de hulplijn van het Hof van Justitie. Na een zéér diepgravende analyse van internationaal privaatrecht, Iers versus Engels versus Nederlands recht en of een rechtskeuze uit algemene voorwaarden meeweegt bij de vraag of die voorwaarden bindend zijn, komt men met een zeer recht-voor-z’n-raap conclusie over browse-wrap:

Waar deze juridisch onbeschermbare [prijs]gegevens [van Ryanair-vluchten] voor een ieder gratis en vrij toegankelijk zijn openbaar gemaakt op een openbare website [van Ryanair zelf], zal een redelijk persoon niet denken dat PR Aviation, louter door de website te bezoeken en/of deze gegevens te verzamelen, zich wilde binden aan de gebruiksvoorwaarden die haar verbieden om die gegevens te verzamelen en te gebruiken, noch aan de daarin opgenomen rechtskeuze. Ter vergelijking: wie op straat aan een muur, of in een étalage zichtbaar vanaf de openbare weg, een aanplakbiljet heeft opgehangen met een tekst waarvan de eerste regel luidt: “Wie verder leest, moet € 5,- betalen”, mag er niet zo maar op vertrouwen dat een voorbijganger die de tekst verder leest, zich heeft willen binden aan deze voorwaarde.
Zou je ergens in moeten loggen of een aanvraag doen, dan kan men wel voorwaarden stellen. Het ging hier dus goed (voor PR Aviation) omdat de gegevens openbaar én onbeschermd waren. Dat analoog toepassen zou dan zijn: “als iemand gewoon een tip over een kwetsbaarheid wil doorgeven, dan mag je er niet op vertrouwen dat die zich wilde binden aan jouw voorwaarden”.

Daar staat natuurlijk tegenover dat het onderzoeken en uitpluizen van vulnerabilities al snel in de sfeer van computervredebreuk terecht komt, omdat je op plekken komt waarvan je moet weten dat je er niet hoort te zijn. Daardoor heerst het beeld dat je maar beter de policy-regels kunt accepteren, want dan zal men geen aangifte doen of je civielrechtelijk aanspreken op de schade. Dus je gaat dan semi-vrijwillig akkoord omdat het alternatief “nee ik was wel binnen maar ik verwerp jullie regels” neerkomt op een bekentenis van een misdrijf.

Maar is het wel een misdrijf, zo’n ethische hack? Het Openbaar Ministerie denkt daar volgens mij anders over, die focussen op het maatschappelijk belang en je proportionaliteit/subsidiariteit maar niet op de vraag of je keurig de regels van het bedrijf gevolgd hebt. Gezien die regels lijkt het mij zeer onwaarschijnlijk dat je vervolgd wordt als je volgens de algemeen aanvaarde ethische regels werkt maar er gezien de situatie wel voor kiest om na een redelijke periode te publiceren over de vulnerability.

Een civielrechtelijke zaak dan, men dagvaardt je wegens onrechtmatige daad en claimt tonnen aan schade plus een verbod met dwangsom om ooit nog in de buurt van hun IP-range te komen? Dat kan natuurlijk altijd, alleen bij ethisch hacken is er haast per definitie geen schade, dus wat wou je dan claimen? Los daarvan lijkt het me moeilijk te spreken van onrechtmatig handelen als het geen computervredebreuk is omdat je het ethisch verantwoord deed.

Dan blijft contractbreuk over: los van de rechtmatigheid, wij hadden áfgesproken dat jij je mond zou houden toen jij de melding deed, en die afspraak schend je nu. Maar eenzijdig iets afspreken kan dus niet, en dan komen we terug bij die Ryanair-zaak over de vraag of je akkoord was gegaan met die voorwaarden omdat ze ergens te lezen waren. Ik zie ondertussen nog steeds geen reden waarom dat zo zou zijn, als een CVD-melding een gewone, legale actie is dan zie ik dat als analoog aan die tekst op de muur. De enige uitzondering die ik kan bedenken is als je iets extra’s zou willen, zoals een beloning. Dan doe je meer dan alleen een melding en kan er ook meer van je verwacht worden.

Arnoud

 

 

[insert code as law joke here] of hoe de EU Cyber Resiliency Act softwareontwikkeling gaat veranderen

Geplaatst op in Innovatie, Ondernemingsvrijheid, Regulering, Security, 9 reacties
USA-Reiseblogger / Pixabay

“The EU’s new Cyber Resilience Act is about to tell us how to code”, las ik op de blog van Bert Hubert (aanrader). De CRA is een concept-Verordening over cyberbeveiligingseisen voor producten met digitale elementen, zeg maar alles dat we IoT (internet of [st]hi[nt]g?s?) noemen, maar dan breder want netwerkverbinding is niet perse een eis. Dergelijke apparaten moeten eindelijk, eindelijk een goede cyberbeveiliging hebben, maar dat zal nogal wat voeten in de aarde krijgen, zo laat Hubert overtuigend zien. Hoe gaat de toekomst van cybersecurityrecht eruit zien?

De CRA (originele concepttekst) maakt deelt uit van de Europese Digitale Decade, het grote strategieplan van Europa om de wereld te transformeren. Veiligheid van digitale apparaten hoort daar natuurlijk bij, ik zou het zelfs een van de speerpunten van iedere serieuze ict-strategie durven te noemen. En met boetes tot 15 miljoen (of 2% wereldwijde omzet indien hoger) maakt deze Verordening het echt wel een belangrijk onderwerp. Toch is het ook een hele spannende, want afbakenen wat er nu écht allemaal gebeurt is nog razend ingewikkeld.

Neem bijvoorbeeld de uitzondering voor open source, wat een terecht aandachtspunt is omdat je vrijwilligers niet hetzelfde wilt behandelen als commerciële bedrijven. Alleen, hoe baken je dat op een beetje rechtlijnige manier af? Want als ik als bedrijf apparaten gratis weggeef (met alle broncode open source) en geld vraag voor een gekoppelde, verplichte SaaS-dienst dan wil je wel dat die apparaten aan de CRA voldoen. En dan heb je ook nog bedrijven die werknemers opdragen aan open source projecten te werken, omdat ze daar indirect voordeel uit halen bij het implementeren van ict-oplossingen bij klanten. De CRA zegt nu (overweging 10):

In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.
Vervolgens val je onder de CRA als je een product (dus hardware met “digitale elementen” erin) op de markt brengt vanuit een “commercial activity”. Je zou zeggen dat die vrijwilliger die alleen een stuk software op internet zet, hier buiten valt alleen al omdat hij geen producten op de markt brengt. Maar let op: de definitie van een product is “software or hardware product”, dus ook enkel software online zetten kan er al onder vallen, als je daarmee een commerciële activiteit ontplooit. Dat dat bij Microsoft geldt wanneer die gratis software online zetten is dan één ding, een vrijwilliger met een “doneer nu”-knop voelt toch heel anders. Gezien de aard van de verplichtingen is dit wel een zwaar ding, dat echt nog fors op de schop moet. Gelukkig hebben een hoop partijen zich al hierover uitgelaten, dus ik ben benieuwd wat de volgende versie van de tekst gaat zeggen.

Waarom is het dan zo zwaar? De kern is dat ieder “product met digitale elementen” voldoet aan een serie basiseisen, en als je product op een aparte lijst staat dan ben je “critical” en krijg je nog een extra set eisen op je ontwerp-bord. (Stop je er AI in dan krijg je nóg meer eisen, waarover een andere keer.) Het is jouw taak als fabrikant aan te tonen dat je voldoet aan die eisen, en om dat vooraf schriftelijk uitgewerkt te hebben (een cybersecurity risk assessment). Maar alleen een papieren gaapdocument is niet genoeg: je moet gedurende 5 jaar (of levensduur indien korter) een proces hebben om kwetsbaarheden op te lossen (art. 10 lid 6).

Maar er is meer, in die lijst met basiseisen staan namelijk deze twee heel belangrijke componenten:

  1. Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks;
  2. Products with digital elements shall be delivered without any known exploitable vulnerabilities;
Die tweede klinkt meteen héél erg sterk: een product mag niet worden verkocht als er bekende kwetsbaarheden in zitten. Hoe ga je dat doen met een productielijn waarbij het zeg drie maanden duurt van fabriek tot schap in de winkel? Dat kun je zien als een bug, maar ik zie het als een feature: ontdekt men een fout dan moet je dus meteen een update realiseren die direct bij verkoop beschikbaar komt. Of inderdaad je distributeurs instrueren dat apparaat niet te verkopen tot het is opgelost, zeg maar een recall net zoals bij glasscherven in de pindakaas. Ik zou dat wel een goeie vinden, dat we cybersecurity net zo ernstig vinden als glasscherven.

Om dit alles vorm te geven, wordt het aloude CE-keurmerk opgepoetst. Wie dit keurmerk voert, geeft aan dat zijn producten voldoen aan de CRA. Dat maakt aansprakelijkheid een heel stuk makkelijker, zeker in combinatie met de recent besproken AI Liability Directive die gewoon de bewijslast omkeert: wie het CE keurmerk voert en een onveilig product blijkt te hebben verkocht, moet bewijzen dat er niets aan de hand was anders moet hij alle schade vergoeden.

De grote uitdaging, zoals Hubert ook opmerkt, is wie dit alles gaat overzien. Zonder standaarden gaat het niet, maar wie zal de standaard maken over cybersecurity? Hubert:

I have personally been part of a few standardisation processes, and it is extremely worrying how these are dominated by just a few parties, most of them non-European and with strong commercial goals to get a standard passed that works for them.
Dit beeld zal herkenbaar zijn voor iedereen (ikzelf ook) die ooit met standaardisatie heeft meegekeken. Dit zou wel eens het grootste struikelblok kunnen gaan worden. Tegelijkertijd: alleen met een open norm eisen dat een product veilig genoeg is, gaat hem ook niet worden. Dan verzint iedereen eigen criteria en krijgen we jarenlange discussie over waar welke lat zou moeten liggen. Een standaard set eisen is de enige optie. Dus dit gaat nog erg pijnlijk worden, en ik ben bezorgd dat het hierdoor veel langer gaat duren dan nodig is.

Arnoud