Categorie: Security

About Security

Subscribe Feeds

Mag je als werkgever bepalen wat er op een BYOD laptop geïnstalleerd wordt?

Geplaatst op in Ondernemingsvrijheid, Security, 18 reacties

Een lezer vroeg me:

Bij ons bedrijf is gekozen voor bring-your-own-device, waarbij mensen zelf privé een laptop mogen kopen en de werkgever het bedrag vergoedt via de werkkostenregeling. Nu zeggen collega’s dat ze dus op hun eigendom alles mogen installeren dat ze willen, inclusief applicaties die adminrechten nodig hebben. Dat zie ik als security officer als een groot risico, maar hoe zit het juridisch met deze positie?
Je kunt inderdaad werknemers een vergoeding via de werkkostenregeling geven voor de aanschaf van apparatuur zoals een laptop. Maar dat is inderdaad dan ook een privélaptop, waar de werknemer mee mag doen wat zhij wil. Inclusief installeren van gare software met adminrechten.

Als werkgever kun je dan natuurlijk zeggen dat die laptop niet veilig genoeg is om het werk mee te doen. Dat is je goed recht, alleen moet de werknemer dan wel een andere laptop krijgen om mee te kunnen werken.

Er is een uitzondering, en die heet de gerichte vrijstelling: als de laptop voor 90% of meer zakelijk gebruikt wordt, dan kun je de werknemer deze geven en gaat het bedrag niet uit deze regeling. Wel moet het dan noodzakelijk zijn:

‘Noodzakelijk’ betekent dat de werknemer zonder de voorziening zijn dienstbetrekking niet goed kan uitoefenen. Dat houdt in dat de werknemer de voorziening voor zijn werk nodig heeft en gebruikt. De mate van dat zakelijke gebruik is daarbij niet doorslaggevend.
In die situatie kun je de laptop als werklaptop zien en behandelen, inclusief veiligheidsrestricties die redelijkerwijs nodig zijn. Echt privé is de laptop dan niet: bij uitdiensttreden moet deze teruggegeven worden aan de werkgever.

Arnoud

Ransomware is inderdaad ook een datalek als je niet uitkijkt

Geplaatst op in Security, 1 reacties

De persoonsgegevens van een onbekend aantal ANWB-leden liggen mogelijk op straat door een datalek bij een incassobureau. Dat meldde Nu.nl onlangs. Het gaat om mensen die in contact zijn geweest met Trust Krediet Beheer (TKB), dat namens de ANWB betalingen incasseert bij wanbetalers. Het datalek betreft gijzelsoftware (ransomware) dat gegevens van TKB ontoegankelijk had gemaakt. De ANWB informeerde meteen haar leden, wat heel netjes is maar wel vragen opriep: hoezo is dit nu een datalek onder de AVG?

Meestal denken mensen bij de term ‘datalek’ aan het beschikbaar komen van persoonsgegevens bij onbevoegde derden. Bijvoorbeeld wanneer iemand zonder wachtwoord bij een database weet te komen of als een Excel naar de verkeerde is gemaild. Maar de wettelijke definitie (artikel 4 AVG) is breder:

een inbreuk op de beveiliging die per ongeluk of op onrechtmatige wijze leidt tot de vernietiging, het verlies, de wijziging of de ongeoorloofde verstrekking van of de ongeoorloofde toegang tot doorgezonden, opgeslagen of anderszins verwerkte gegevens;

Ook “vernietiging” en “verlies” zijn vormen van datalekken. Heb je je administratie maar op één datadrager en gaat die verloren, dan heb je dus een datalek in de zin van de AVG: je kunt de status van je administratie dan niet meer reproduceren. Je kunt dan bijvoorbeeld niet meer zeggen wie nog moet betalen of wie geld van jou krijgt, dan zijn persoonsgegevens (informatie over mensen) dus verloren. Dit is dus waarom je een backup moet maken.

In het geval van de ANWB en haar incassobureau TKB lijkt het onwaarschijnlijk dat de ANWB haar ledenadministratie kwijtgeraakt is door de ransomware bij TKB. Hooguit zijn de gegevens bij TKB zelf (wie hebben we aangemaand, wie heeft al betaald, welke reactie kregen we op onze laatste sommatie) verloren gegaan, maar het lijkt me vrij sterk dat men geen backup heeft. Hoewel je dat nooit zeker weet.

Ik vermoed echter dat men dit als datalek behandelt vanwege een andere reden. Al geruime tijd wordt gewaarschuwd dat ransomware niet alleen data gijzelt maar het vaak ook steelt. Als je toch al bij alle data kunt, waarom zou je dan niet even een kopietje trekken om daar achteraf misdadige dingen mee te doen? “Dank je voor het betalen voor de sleutel, dat bewijst dat je je zorgen maakt over deze data, graag nog eens 1 bitcoin want anders zet ik je klantendatabase op internet”. Dus dan is ransomware een datalek zelfs als je nog goede backups hebt.

De ANWB waarschuwt in haar mail (via) dan ook vooral om op te letten voor misbruik van je contact- en facturatiegegevens. Want een nepfactuur voor lidmaatschap 2022 is natuurlijk een leuke bijverdienste voor dit soort criminelen.

Arnoud

Ik wil niet dat mijn klanten mijn identiteitsbewijs scannen!

Geplaatst op in Privacy, Security, 20 reacties

Een lezer vroeg me:

Als ik als IT-medewerker een bepaalde klant bezoek, moet ik me identificeren aan de deur. Fair enough, maar sinds kort moet mijn identiteitsbewijs in een scanner “ter verificatie”. Ik heb daar vraagtekens bij want als bezoeker kun je niet controleren wat de hardware en software (“Paspoort scanner” en een standaard Windows PC) wel en niet doet. Men zegt dan wel dat alles in het apparaat gebeurt en niets wordt opgeslagen, maar hoe controleer je dat? En mijn werkgever zegt dat ik gewoon naar binnen moet. Wat moet ik nu doen?
Een identiteitscontrole van een bezoeker kan gerechtvaardigd zijn, ik denk dat daar weinig discussie over bestaat. En dat je dan wil controleren of het ID-bewijs van die bezoeker echt is, dat snap ik ook. Daar zijn diverse kastjes voor, op de markt vaak bekend onder de term “ID scanner”. Die kunnen echtheidskenmerken controleren en gegevens uitlezen, en soms zelfs daar meteen een bezoekerspas mee maken.

Inzet van zo’n kastje lijkt me op zich geen probleem. Dat ondersteunt de taak die je toch al hebt, en past binnen de goede uitvoering van die noodzakelijke identiteitscontrole. Je had toch al onderbouwd (op papier) waarom je die controle moest doen, nietwaar?

Het is natuurlijk lastig te zien voor mensen wat er gebeurt met hun gegevens. Zelfs als het los kastje met alleen een stroomkabeltje is, dan nog zou deze via wifi van alles door kunnen geven. Dat mag niet als daar geen goede reden voor is.

Er zijn bedrijven die online identiteitsverificatie / ID controle doen; het kastje is dan alleen een scanner en verzendapparaat naar de dienstverlener die dan de resultaten teruggeeft. Als dat is hoe het bedrijf werkt, dan kan dat (dat bedrijf is dan een verwerker immers) maar dat moet dan wel duidelijk uitgelegd worden.

Dat is dan ook het theoretische antwoord: er mag niets dat niet duidelijk is toegelicht, dus op zijn minst moet je kunnen vragen wat er gebeurt en moet de beveiliger/portier/receptionist hier adequaat antwoord op kunnen geven. Bijvoorbeeld met een folder met toelichting.

Voel je je daar niet prettig bij, of heb je twijfels over of het allemaal wel klopt, dan heb je niet zo heel veel mogelijkheden ben ik bang. Je kunt als individu geen DPIA afdwingen, en eisen dat de AP langskomt is ook niet zo kansrijk ben ik bang.

De enige optie die ik zie is dat je naar je werkgever gaat. Die heeft immers een zorgplicht: een goed werkgever laat de privacy van zijn personeel niet in gevaar komen. Die moet dus bij die klant nadere informatie en/of waarborgen eisen, of misschien zelfs wel een ander protocol verzinnen. Ik heb zelf wel eens een klant geadviseerd om de standaardmonteurs een vaste bezoekerspas te geven. Dat is dan eenmalig een handmatige controle van identiteit, en daarna toegang met die pas.

Arnoud

Ticketmaster krijgt boete van 1,4 miljoen euro van Britse privacywaakhond

Geplaatst op in Privacy, Security, 28 reacties

Het Britse bedrijf Ticketmaster heeft een boete gekregen voor een datalek in 2018, las ik bij Nu.nl. Door een kwetsbaarheid in de chatbot op de website konden derden toegang krijgen tot betaalgegevens van 37.000 creditcardhouders, en in theorie zelfs 9.4 miljoen mensen uit de hele EU. Opmerkelijk aan de zaak vond ik vooral dat die chatbot een ingekochte component was en dat de leverancier al enige tijd op de hoogte was van het lek.

Het boetebesluit legt uit dat in 2018 een aantal bank-klanten ontdekten dat hun creditcard frauduleus werd gebruikt, wat te herleiden was tot een aanschaf bij Ticketmaster. (Smoking gun: een testbetaling met gefingeerde expiry date dook met diezelfde datum op in het criminele circuit.) De site van Ticketmaster bleek gehackt en voorzien van malware die gegevens doorstuurde.

De hack bleek mogelijk door een ingezette chatbot van het bedrijf Inbenta. De bot was zo’n typische vraagbeantwoordbot om de menselijke helpdesk te ontlasten, en kwam gezellig mee op elke pagina in het besteltraject. Daardoor kon – na het compromitteren van de code – de bot ook gegevens lezen uit bestel- en betaalformulieren, wat dus de creditcarddiefstal mogelijk maakte. Inbenta was desgevraagd erg verbaasd:

The Javascript we created specifically for Ticketmaster was used on a payments page, which is not what it was built for. Had we known that script would have been used in that way, we would have advised against it, as it poses a security threat.

Deze werkwijze was verder in strijd met de PCI-DSS regels voor het verwerken van creditcardgegevens. Desondanks vond Ticketmaster dat niet haar maar Inbenta verwijten te maken waren, zij mocht contractueel rekenen op een veilige chatbot dus dan is het overmacht als de chatbot onveilig blijkt. Een argument dat ik vaak hoor: “In de verwerkersovereenkomst staat dat de leverancier garandeert veilig te zijn, we hebben de veiligheid dus geregeld”.

De ICO accepteert dat excuus volstrekt niet, en ik zou iedereen ook willen aanraden om wie dat argument gebruikt een stevige schrobbering te geven. Security is niet iets dat je contractueel afspreekt, dat is iets dat je praktisch regelt én verifieert. Security doe je.

Natuurlijk zijn superzerodayhacks altijd mogelijk, en ik kan best accepteren dat dat overmacht zou kunnen opleveren. Maar het ging hier om een simpele Javascript aanpassing waarmee betaalformulieren uit te lezen en te kapen waren, iets dat zeker weten in 2018 tot de gewone stand der techniek behoorde en waar dus gewoon beveiliging tegen hoort te zijn.

Maar maar maar, aldus Ticketmaster: wij hadden netjes compliance geregeld, kijk maar:

At §§8-9 of its Comments, Ticketmaster relies upon its receipt of security certifications provided by Inbenta. At §29.3 of the Comments, Ticketmaster emphasises Inbenta’s ISO 27001 certification. The Commissioner places little weight on the mere provision of such certifications by Inbenta as a mechanism of securing the chat bot in the circumstances. Further, ISO 27001 is an information security management standard, which does not apply directly to software development.

Een certificering is nog geen bugfix, laat staan een securitymaatregel. Een code review of een security audit was dat wel, maar daar had Ticketmaster nul moeite in gestoken. En dat wordt ze serieus kwalijk genomen:

Rather, the GDPR requires that each organisation assess the risks arising in the circumstances of their own implementation and put controls in place to protect the personal data that it processes. Ticketmaster has shown very limited knowledge at the date of the Incident of the risk of implementing third party scripts into a payment page, despite it being widely known and documented at that time. A fortiori, Ticketmaster has not evidenced that it deployed appropriate and proportionate controls to manage this risk.

Verder noemt de ICO dit een serieuze overtreding van de AVG: in theorie hadden 9.4 miljoen klanten hun betaalgegevens gestolen kunnen hebben, en Ticketmaster had geen enkele control in place om hier wat tegen te doen. (Zelfs passieve detectie door wekelijks zelf een nepcreditcard te proberen was er niet.) De boete komt uiteindelijk dus uit op 1.4 miljoen euro. Een terechte tik op de vingers, wat mij betreft.

En ik zeg het nogmaals, want ik weet dat er veel contractsjuristen, FG’s en ander AVG compliance volk meeleest: doe alsjeblieft méér dan alleen contractueel vastleggen dat de veiligheid op orde moet zijn. Zonder daadwerkelijk feitelijk handelen ben je gewoon niét AVG compliant, al staan er honderd garanties en heb je duizend certificeringen.

Arnoud

Mag je de verlichting van de Erasmusbrug op paars zetten?

Geplaatst op in Regulering, Security, 23 reacties

Het systeem om de verlichting van de Erasmusbrug in Rotterdam te veranderen was ruim een jaar via internet toegankelijk, meldde Tweakers onlangs. RTL Nieuws-reporter Daniël Verlaan kreeg een tip over het lek en wist de brugverlichting paars te maken. De brug zelf was verder niet te bedienen, maar de interface van dit systeem bleek zonder beveiliging toegankelijk als je wist wat de netwerkpoort was van de server. Die laatste was via zwakhedenzoekmachine Shodan te vinden. Dat riep dus weer de bekende vraag op, mag dat dan?

Je mag niet binnendringen in andermans computersysteem. Of dat systeem beveiligd is, doet niet ter zake. Enige vraag is of je wist dan wel moest weten dat je daar niet mocht zijn. Het lijkt me evident dat je als Shodan-surfende derde weet dat je niet de verlichting van de Erasmusbrug mag bedienen, dus dat noem je binnendringen.

Natuurlijk kun je per abuis op zo’n server belanden. Je klikte wat rond, iemand deelde een onschuldige server en oeps die brug werd paars. Kan. Maar ik zou zeggen dat het bewijs van jouw bewustzijn een heel eind rond is als jij zegt, ik zat op Shodan te kijken en zag daar de admin van de Erasmusbrug. Je wéét dat Shodan geen rechtmatig gepubliceerde interfaces bevat en je wéét dat jij niet welkom bent in de admin van de Erasmusbrug.

Dit is dus tevens waarom je niet aan de politie gaat uitleggen wat je deed of waarom je dacht dat dat mocht. Gewoon niet. Echt niet. Nee, ook niet vanwege die reden die jij nu in je hoofd hebt. Niet. “Ik wil graag eerst met een advocaat overleggen” is het énige dat je zegt. Serieus. Alsjeblieft.

En ja, het is een vrij onschuldig verhaal want er is niets kapot gegaan, niets bediend en niets ernstigs gebeurd. Maar toch, wees voorzichtig als je geen professioneel journalist bent. Ik benadruk dit omdat in de sfeer van “cybercrime” Justitie vaak overspannen reageert vergeleken met real-life situaties. Als je de controlekamer van deze verlichting was binnengelopen, dan had de portier op z’n kop gehad en was jij eruit gejaagd. Maar nu heb je een cyberhack gedaan. In theorie had je zelfs antiterrorismewetgeving kunnen triggeren met zo’n actie.

In dit specifieke geval betreft het een journalist die een opmerkelijke misstand aan de kaak stelt, en daarvoor het enige middel gebruikt om aan te tonen dat de misstand waar is. De maatschappelijke of persoonlijke schade is nihil en het slachtoffer is geïnformeerd en kreeg de kans de misstand op te heffen voordat dit nieuws werd. Dan en specifiek dan wordt de strafbaarheid opgeheven.

En natuurlijk, journalist is geen beschermde titel, maar journalist ben je pas als je journalistieke activiteiten ontplooit. Dus enkel zeggen “ik wilde erover publiceren” is niet genoeg. Je moet een track record hebben (zoals Daniël, koop dat boek) of daadwerkelijk een journalistieke uiting hebben gedáán. Wilde je nu eindelijk eens journalist worden en was dit je eerste geplande publicatie maar werd je gepakt voordat het online stond, dan vrees ik dat je niet wordt geloofd.

Arnoud

ING hoeft slachtoffer van nep ‘LinkedIn-helpdesk’ niet te vergoeden

Geplaatst op in Security, 15 reacties

ING hoeft een klant die werd opgelicht door iemand die zich voordeed als de helpdesk van LinkedIn niet te vergoeden, las ik bij Security.nl. Het financiële klachteninstituut Kifid oordeelde dat de transactie binnen de risicosfeer van de klant viel en niet die van de bank. De klant had vanwege een probleem met haar LinkedIn-account hulp gezocht en was bij een oplichter terechtgekomen, die haar wijs had gemaakt dat ze twee euro moest betalen en erin slaagde tweehonderd te pakken te krijgen. Eigen schuld, aldus de bindende uitspraak.

De klant was op zoek naar hulp voor een probleem met haar LinkedIn-account, en vond een oplichter die zich voordeed als de LinkedIn-helpdesk. Die had bedacht dat je als authenticatie twee keer een euro moet betalen, die je daarna terug zou krijgen. In plaats daarvan werd twee maal honderd euro afgeschreven. Toen de vrouw eiste dat dit terugbetaald werd, werd ze nogmaals genept en bleek er tweehonderd euro extra afgeschreven in plaats van vierhonderd terug.

Nadat een en ander uitkwam, deed de klant aangifte en eiste bij de ING het geld terug. Dat is niet raar: de wet legt in beginsel álle risico bij niet-toegestane online betalingen bij de bank (art. 7:529 lid 1 BW), zij het met een eigen risico van maximaal €150. Een uitzondering hierop is als sprake is van fraude, opzettelijk handelen of grove nalatigheid aan de zijde van consument.

We spreken van een “niet-toegestane” betaling als de consument daar geen instemming voor heeft gegeven (art. 7:522 BW). Daar kunnen afspraken over de procedure over gemaakt worden, bijvoorbeeld dat je toestemming geeft door via internetbankieren met je authenticatiekastje of -app een bepaalde handeling te verrichten en een code in te voeren.

Nu Consument zelf de betalingen heeft verricht en bovendien de oplichter toegang heeft gegeven tot haar computer waardoor hij de overgeboekte bedragen kon manipuleren, al was zij zich hiervan niet bewust, bestaat voor de Bank geen verplichting de door Consument gevorderde schade te vergoeden.
Dat klinkt wel erg makkelijk, gezien de zorgplicht van een bank. De uitspraak is erg kort zodat details over wat er precies gebeurd is. Ik lees dat de vrouw twee keer een iDeal-betaling aangeboden kreeg, waarmee dus die 200 euro werd afgeboekt. Maar was dit een phishing-iDeal betaling waarbij het leek of er één euro werd betaald, of heeft zij niet goed gekeken dat er 200 stond bij het af te boeken bedrag? En wat moet ik met ” Consument is op verzoek van de oplichter ook naar een website gegaan en heeft de oplichter daarmee (onbewust) toegang gegeven tot haar computer. ” in relatie tot het betalen?

Het maakt voor mij wezenlijk uit of je niet oplet bij het bedrag dat in een eerlijke iDeal-link staat dan wel dat die link nep is en op de achtergrond wat anders naar de bank stuurt. Dat laatste hoort niet mogelijk te zijn en vind ik altijd het risico van de bank. Als ik een transactie autoriseer en het bedrag kan anders zijn dan ik denk, dan is de autorisatie ontoereikend en heb ik geen instemming gegeven. Maar let ik niet op dat er 200 bij “Bedrag” staat (bijvoorbeeld door de mooie praatjes aan de telefoon) dan zou ik het eerder mijn risico vinden.

Arnoud

“Camera met gezichtsherkenning meestal niet toegestaan”

Geplaatst op in Privacy, Security, 15 reacties

Het gebruik van camera’s met gezichtsherkenning is, zo las ik bij Security.nl meestal niet toegestaan voor bedrijven. Dit volgt uit een recente publicatie van de Autoriteit Persoonsgegevens. De privacytoezichthouder gaat daarom sectoren die dergelijke camera’s vaak gebruiken voorlichting geven over de regels. De Algemene verordening gegevensbescherming (AVG) verbiedt in beginsel het gebruik van biometrische gegevens om iemand te identificeren, maar het gebeurt vaak aldus de toezichthouder: Winkels gebruiken gezichtsherkenningscamera’s om winkeldieven op te sporen, terwijl bedrijven in de beveiliging, beurslocaties en pretparken de technologie inzetten voor toegangscontrole.

Het onderwerp is al wel vaker langsgeweest, eind vorig jaar blogde ik over gezichtsherkenning inzetten om een lokaalverbod te handhaven en eerder die sportschool die ’s nachts mensen met gezichtsherkenning binnenliet. De kern van het probleem is dat biometrische gegevens als bijzondere persoonsgegevens gelden, en je daar dus van af moet blijven. Gebruik je foto’s van mensen om ze te herkennen, dan tellen die foto’s als biometrische gegevens (een gewoon kiekje is dus geen biometrisch persoonsgegeven). En dan mag je ze dus niet gebruiken.

Dat ‘herkennen’ moet je breed opvatten: het gaat niet alleen over matchen tegen een database met NAW-gegevens of iets dergelijks. Ook enkel geautomatiseerd constateren “die was hier gisteravond ook” of “die lijkt op foto 31337 uit ons bestand overlastplegers” is al een vorm van ‘herkennen’, waarmee je camerabeelden tot bijzondere persoonsgegevens verworden.

Enige ruimte wordt gegeven door de uitzondering uit artikel 29 Uitvoeringswet: identificatie van de betrokkene die noodzakelijk is voor authenticatie of beveiligingsdoeleinden. En natuurlijk, het doel van deze identificatie (inclusief de 31337-constatering) is voor beveiliging, je wilt overlastplegers, lokaalverbodshouders et cetera niet binnen hebben. Maar is er een nóódzaak? Die vraag is veel lastiger want dat is een hele hoge lat.

Kort gezegd moet er dan geen ander middel voorhanden zijn dat ongeveer zo effectief is, en de maatregel moet ook proportioneel zijn. De AP gaat zelfs nog een stapje verder:

Het moet daarbij wel gaan om een zwaarwegend algemeen [italics AE] belang. Dat is bijvoorbeeld de beveiliging van een kerncentrale. Maar de beveiliging van bijvoorbeeld een supermarkt is niet zó belangrijk dat u daarvoor biometrische gegevens mag verwerken.
Dat algemeen belang haal ik zo niet uit de Uitvoeringswet, maar het is natuurlijk waar dat beveiligen van één winkel geen algemeen belang dient. Ik had zelf altijd het idee dat ook een individueel belang goed genoeg kon zijn (dit is weer die discussie over legitiem belang, geloof ik), maar dat het misgaat op wat ik de innovatieparadox noem.

De innovatieparadox uit de AVG luidt: nieuwe maatregelen voldoen nooit aan de noodzakelijkheidseis omdat er altijd bestaande maatregelen zijn die goed genoeg zijn. Zet een portier neer die het verbod handhaaft, beveilig je supermarkt met detectiepoortjes, doe toegangscontrole met tickets op naam, et cetera. Natuurlijk zitten daar kosten aan, maar zeker in het begin zitten die er ook aan camera-identificatie – aanschaf, onderhoud, testen en beveiligen bijvoorbeeld. Dus “dit is veel goedkoper” is geen argument.

Oftewel: hoe betoog je dat een nieuwe manier van persoonsgegevens verwerken acceptabel is, als deze net zo duur is en zich nog niet bewezen heeft in de praktijk?

Arnoud

Wat kan ik als mijn werkgever mijn bsn en medisch dossier lekt?

Geplaatst op in Privacy, Security, 19 reacties

Een lezer vroeg me:

De laptop van mijn leidinggevende is recent gestolen. Helaas was het systeem niet versleuteld, waardoor gevoelige persoonsgegevens (zoals mijn naam, geboortedatum, BSN, handtekening en medische gegevens) door de dief te lezen zouden kunnen zijn. Ik ben netjes geïnformeerd en het lek wordt gemeld, maar ik vind dit niet genoeg. Wat kan ik juridisch doen tegen mijn werkgever?
Allereerst: erg jammer en vervelend dat er anno 2020 nog steeds werkgevers zijn die dus dit soort gevoelige gegevens rondsjouwen zonder zelfs maar full-disk encryptie. Het is erg pijnlijk om daar via een datalekmelding achter te moeten komen.

De procedure is zo te lezen netjes gevolgd: de werknemer moet worden geïnformeerd en de AP ook, want de gegevens zijn zeer gevoelig en misbruik daarvan kan zeker tot schade bij de werknemer(s) leiden. Ook als het maar een handjevol mensen was – BSN en medische gegevens tellen als zeer gevoelig ook bij kleine hoeveelheden.

Dat wil niet zeggen dat de kous daarmee af is. De werknemer kan desondanks immers schade lijden door het lek, en volgens de AVG is de werkgever daar gewoon voor aansprakelijk stellen.

Het lastige hierbij is natuurlijk aan te tonen wat je schade is, zeker als er nog geen kwaadwillend gebruik van je gegevens is gemaakt. En bij diefstal van een laptop is de kans reëel dat dat ook niet gaat gebeuren; waarschijnlijk herinstalleert de dief Windows en verkoopt hij het ding tweedehands. Je kunt dan natuurlijk gaan monitoren op misbruik maar je zult waarschijnlijk niets tegenkomen.

Het gaat me wat ver om te zeggen dat een werkgever maar gewoon een bedrag moet geven bij wijze van forfaitaire schadevergoeding. Maar zonder concreet aangetoonde schade kan de werknemer verder niet zo veel. Bij financiële gegevens zou je nog kunnen eisen dat de werkgever een monitoringdienst betaalt om op het ahem “dark web” te kijken of je creditcard daar opduikt, maar voor bsn’s of medische dossiers is er niet echt zo’n markt.

Arnoud

Is het ethisch hacken om het Twitterwachtwoord van Trump te raden?

Geplaatst op in Security, Uitingsvrijheid, 7 reacties

De Nederlandse ethische hacker Victor Gevers heeft vorige week naar eigen zeggen het Twitter-account van Donald Trump gehackt. Dat meldde Tweakers vorige week. Het wachtwoord (maga2020!) was eenvoudig te raden, zegt Gevers tegen Vrij Nederland. VN zegt ook dat er sterke aanwijzingen zijn dat Gevers achter een beruchte tweet van de president zat. Het gaf de nodige discussie over ethisch hacken, dingen mogen veranderen en hoe publiek je mag gaan met zo’n ontdekking.

Victor Gevers was ook een van de hackers die in 2016 in wisten te breken op het account van Trump. Daarom kreeg deze inlog zo veel aandacht, hoewel er ook twijfel is over de echtheid. Twitter zelf zegt geen rare inlog te hebben gezien, en bij een screenshot van Gevers dat het interne profiel van Trump toont, ontbreekt het Amerikaanse vlaggetje in de biografie-regel. (Mogelijk kwam dat door de gebruikte browser/OS combinatie.)

Maar dat even terzijde. Stel inderdaad, je weet het wachtwoord van zo’n prominent account te raden en je ziet dat ook alle beweerdelijke extra maatregelen (zoals 2FA) er niet zijn. Wat mag je dan doen? Nou ja, het slachtoffer en/of de dienstverlener informeren natuurlijk, dat past volledig binnen de heersende spelregels voor ethische hackers.

Ermee naar buiten treden is een ander verhaal. Natuurlijk, bij responsible disclosure hoort ook een melding op zeker moment zodat het publiek ook weet wat er mis is. Maar dat is omdat het publiek getroffen kan zijn door het lek dat jij als ethisch hacker had ontdekt. Of omdat ze moeten weten dat die dienstverlener zat te prutsen. Bij een probleem als dit zie ik geen reden om met (responsible) disclosure te dreigen.

Wel is het natuurlijk zo dat het zeer groot nieuws is dat dit oppermachtige Twitteraccount zó slecht beveiligd is. Dan kun je prima naar de pers stappen en melden dat je dit nieuws ontdekt hebt. Ook als je het zelf hebt gemaakt, dat nieuws. Een journalistieke hack is niet hetzelfde als een ethische hack.

Arnoud

Met valse personalia internet bestellen is geen computervredebreuk

Geplaatst op in Regulering, Security, 18 reacties

Onder andermans naam een internetmodem bestellen en een contract afsluiten, is dat computervredebreuk? Je zit dan te internetten terwijl je weet dat je dat niet mag, dus je bent dan willens en wetens ergens binnengegaan (namelijk in de modem en het netwerk van Vodafone) waar je niet mocht zijn. Dat je geen beveiliging hebt doorbroken, is al tijden geen argument meer. Maar nee, toch is dit géén computerdelict. Dat blijkt uit een recent strafrecht vonnis uit Rotterdam.

De verdachte heeft zich met zijn partner op grote schaal en creatieve wijze schuldig gemaakt aan het veelvuldig oplichten van VodafoneZiggo en KPN gedurende een periode van bijna twee jaar, zo opent het vonnis. Hij nam onder valse persoonsgegevens contracten af, nam de modems in ontvangst en kon zo internetten en bellen zonder daarvoor te hoeven betalen. Kennelijk ging er iets mis bij VodafoneZiggo haar fraudecontrole, want “[i]n het huis van de verdachte en in een door hem gehuurde garagebox zijn maar liefst 1161 modems aangetroffen.” Maar goed, uiteindelijk toch gepakt.

Het OM noemde dit computervredebreuk, want “door met valse personalia via VodafoneZiggo modems te bestellen, deze aan te sluiten en te gebruiken en de kosten daarvan onbetaald te laten, is sprake van het wederrechtelijk binnendringen in deze modems.” Een argument dat je wel vaker hoort. Je weet dan dat je niet in die modems (of de bijbehorende servers) mag zijn, omdat je weet dat je geen abonnement hebt.

Toch klopt het niet:

De verdachte heeft niet op een andere wijze toegang gekregen tot en gebruik gemaakt van de goederen en diensten van VodafoneZiggo dan gebruikelijk. Niet kan dan ook worden gezegd dat hij door die gedragingen op een wederrechtelijke manier toegang heeft verworven tot de modems.
In mijn woorden, als je een computer of netwerk gewoon gebruikt zoals het bedoeld is, dan is het geen computervredebreuk. Ook niet als je eigenlijk onder valse voorwendselen opereerde, zoals hier dus met de nep-NAW gegevens. Dat sluit aan bij een eerder arrest uit Amsterdam, waarin de verdachte vervalste betaalopdrachten aan de computer van de Rabobank had aangeleverd:
de verdachte […] gebruik heeft gemaakt van hem door de Rabobank […] ter beschikking gestelde gegevens (pincode, overeenkomstnummer, software etc, met uitzondering van het door hem zelf samengestelde wachtwoord). De verdachte heeft door aldus te handelen op reglementaire, geautoriseerde wijze verbinding gezocht en verkregen met het computersysteem van de Rabobank […] toen hij zijn batch-bestanden verzond van zijn computer naar die van de Rabobank […]. Op geen enkele wijze noch op enig moment is hem de toegang geweigerd, ontzegd of anderszins geblokkeerd, noch is daarbij van de kant van de verdachte sprake geweest van manipulatie van toegangsgegevens.
Valse input geven aan een systeem is dus op zichzelf nog geen computervredebreuk. Pas als je de computer wat anders laat doen dan wat deze normaal gaat doen (zoals bij een SQL injectie) dan kom je in dat strafbare feit terecht.

Oplichting was het natuurlijk wel, wat deze meneer had gedaan. En daarvoor krijgt hij dan ook 18 maanden cel, waarvan 6 voorwaardelijk. De schadeclaim van VodafoneZiggo van een dik half miljoen wordt afgewezen “omdat een volmacht of uittreksel van de Kamer van Koophandel ontbreekt” waaruit kon blijken dat de persoon die deze indiende, gemachtigd was namens VZ te handelen. Auw.

Arnoud