Categorie: Security

About Security

Subscribe Feeds

Als je wordt afgeperst met je persoonsgegevens, kun je het losgeld dan verhalen op de datalekker?

Geplaatst op in Privacy, Security, 18 reacties
Photo by RoyBuri on Pixabay

Hackers persen klanten boodschappendienst Flink af: betalen of data gepubliceerd. Dat kopte de NOS vorige week. Dus niet de organisatie, maar de klanten die dachten dat hun data daar veilig was. Voor diverse lezers aanleiding te vragen: kun je dat als schadevergoeding claimen bij Flink?

Het gaat niet om grote bedragen: men wil 10 tot 15 euro, “een klein bedrag voor je gemoedsrust” zo citeert men de criminelen. Er zouden gegevens van een miljoen klanten buitgemaakt zijn, en 15 keer een miljoen is toch aantrekkelijk voor criminelen.

Moet je betalen? Nee, natuurlijk niet, zo luidt het verstandige advies. Je hebt geen zekerheid dat ze later niet terugkomen, net zoals je dat bij ‘ouderwetse’ chanteurs en afpersers niet hebt. Aangifte doen, chantage is strafbaar (art. 318 Sr) en gelekte persoonsgegevens kunnen een ‘geheim’ zijn onder dat wetsartikel.

Maar goed, iemand betaalt dan toch. Is dat schade die je bij de verwerkingsverantwoordelijke kunt claimen? Op geld waardeerbare schade komt voor vergoeding in aanmerking (aangenomen dat het datalek verwijtbaar is). En hier heb je een direct hard getal in geld.

Juridisch is het probleem dat losgeld betalen niet direct voortvloeit uit het datalek zelf. Het is een nieuw feit, ontstaan door acceptatie van het chantage-aanbod. Een hardvochtig jurist citeert dan artikel 6:101 BW en noemt het “eigen schuld”: jij koos er voor te betalen, daar kan de gehackte partij niets aan doen.

Ik heb daar moeite mee, en zou dit dus pareren met een beroep op de billijkheid uit de omstandigheden van dit geval. Wie bedreigd wordt met publicatie van gevoelige persoonsgegevens, kun je niet verwijten een onlogische keuze te hebben gemaakt. Die persoon had niet in die situatie gebracht moeten zijn, en dat dat wel is gebeurd, is (bij een verwijtbaar datalek) de schuld van de verwerkingsverantwoordelijke.

Dus ja, ik zie die schade wel als verhaalbaar op de partij die de gegevens lekte. Natuurlijk moet dan wel vaststaan dát die gegevens daar vandaan zijn verkregen, maar de criminelen zeggen dat er kennelijk netjes bij.

Arnoud

AI-agents die in het wilde weg bedrijven hacken: is dat strafbaar?

Geplaatst op in Innovatie, Security, 5 reacties
Photo by jamesmarkosborne on Pixabay

Excuses voor de kop, maar Tweakers deed het ook: “De ene na de andere organisatie wordt geteisterd door hacks die ongehoorzame AI-agents uitvoeren.” Alsof agents agency hebben en dingen doen. Het zijn scripts, die nalatig beheerd worden. Punt.

Het artikel gaat in op de vraag of het strafbaar is wat hier gebeurt. Terecht wordt de nuance gemaakt dat je je kunt afvragen of de beheerders van die diensten “opzettelijk” handelden. Hun bedoeling was het waarschijnlijk niet, tenzij je in de rabbit hole zit dat OpenAI haar beursgang wilde uitstellen om eerst flink angst te zaaien over rogue agents en dan de oplossing op de markt te brengen.

Voorwaardelijke opzet dan, zeggen strafrechtadvocaten meteen. Nam je bewust het risico op de koop toe dat dit gevolg zou gebeuren? Ook die lijkt me lastig. Het leest vooral als te snel tevreden zijn: bij de laatste uitbraak kon via DNS toegang tot internet worden verkregen. Dat is niet je eerste gedachte bij het dichttimmeren, maar dit helemaal vergeten is ook weer slordig.

Onder artikel 350b Strafrecht is al lang strafbaar dat je door nalatigheid (“schuld”) malware schade laat aanrichten. Vroeger ging dat om virussen (dingen die zichzelf repliceren) maar wat mij betreft leest dit sinds de laatste wetswijziging vrij letterlijk op agents:

Hij aan wiens schuld te wijten is dat gegevens die door middel van een geautomatiseerd werk of door middel van telecommunicatie zijn opgeslagen, worden verwerkt of overgedragen, wederrechtelijk worden veranderd, gewist, onbruikbaar of ontoegankelijk gemaakt, dan wel dat andere gegevens daaraan worden toegevoegd, wordt, indien daardoor ernstige schade met betrekking tot die gegevens wordt veroorzaakt, gestraft met gevangenisstraf of hechtenis van ten hoogste een maand of geldboete van de tweede categorie.
De enige vraag is dus: is er schade in de zin van veranderen, toevoegen of beschadigen. Malware die alleen informatie downloadt, valt buiten dit artikel en inderdaad is voor computervredebreuk opzet nodig. Ik kom er niet helemaal uit wat er nu stukgegaan is. Maar op papier is enkel een bericht op een messageboard plaatsen al genoeg voor dit artikel.

Kan de AI Act hier wat mee? Nee, want is primair gericht op productveiligheid en een experimentele agent-setup zoals van OpenAI is geen ‘product’ of ‘AI-systeem’ zoals de wet dat noemt. Ik zou het wel een GPAI-model willen noemen, en dan kan het worden aangewezen als met systeemrisico. Dat betekent dat er gerichte maatregelen moeten komen (artikel 55, een passend niveau van cyberbeveiligingsbescherming). Helaas ontbreekt het vooralsnog aan criteria om deze norm (artikel 51) mee in te vullen.

Arnoud

Moet een supermarkt het melden als ze met AI winkeldieven opsporen via het camerasysteem?

Geplaatst op in Ondernemingsvrijheid, Privacy, Security, 20 reacties
Photo by ElasticComputeFarm on Pixabay

Een lezer vroeg me:

Sommige winkels gebruiken beveiligingscamera’s met AI om gemaakte beelden te analyseren. Dit zou winkeldiefstal moeten tegengaan. Hoewel vrijwel iedereen keurig waarschuwt voor cameratoezicht, heb ik nog nergens bordjes gezien dat er ook een AI-analyse plaatsvindt. Is dat eigenlijk niet verplicht onder de AI Act?
Per 2 augustus jongstleden is de zogeheten transparantieplicht uit de AI Act (artikel 50 lid 1) van kracht geworden. “AI-systemen die voor directe interactie met natuurlijke personen zijn bedoeld” moeten die personen duidelijk maken “dat zij interageren met een AI-systeem”. Primair is dit bedoeld tegen misleidende chatbots die zich voordoen als mensen.

De AI Act definieert niet wat “directe interactie” betekent. De Richtsnoeren van de Commissie, die in juli verschenen  (sectie 3.1.1), vullen de term nader in: het moet gaan om realtime of near realtime interactie, waarbij de AI-uitvoer direct bij de betrokken persoon terecht komt. “Interactie” is dan een bidirectionele uitwisseling van informatie, waarbij iedere partij ten minste één bericht naar de ander stuurt.

Dit is waar het op misgaat met een antidiefstal-AI: die communiceert niet met shoppers, dus de shoppers hoeven niet te weten dat die AI wordt ingezet. Hooguit moet het personeel dat weten, als we “het scherm geeft een waarschuwing en jij moet op Ok klikken” lezen als een interactie. Maar als professioneel gebruiker zal dat wel duidelijk voor ze zijn, en dan hoeft een aparte melding niet.

Dat is alleen niet het hele verhaal. Zo’n AI-signalering is onder de AVG een vorm van geautomatiseerde besluitvorming. Ik ben er nog niet uit of dit onder het verbod van artikel 22 valt, want is dit “in aanmerkelijke mate treffen”? De AVG noemt zaken als automatisch een kredietaanvraag weigeren of een sollicitatie afwijzen, en de Richtsnoeren (WP251) geven als aanvullend criterium of het “de omstandigheden, het gedrag of de keuzen van de betrokken personen in aanmerkelijke mate [treft]”. Zeg het maar.

Maar los van die discussie, als er persoonsgegevens worden verwerkt met als doel te komen tot een signalering “mogelijk winkeldief” dan moet dat duidelijk worden gemeld (artikel 12 en 14). Op zijn minst vereist dat een toelichting in de privacyverklaring, maar ik denk dat je niet ontkomt aan een bordje gezien het nieuwe en bijzondere karakter van deze verwerking. Wie er eentje ziet: ik ontvang graag de foto!

Arnoud

Als Morris zijn worm een AI-agent had genoemd, was hij dan straffeloos gebleven?

Geplaatst op in Security, 4 reacties
Bron: Go Card USA, Creative Commons BY-SA 3.0

OpenAI ontdekte de hack van een agent die uit een ‘sandbox’ zou zijn gebroken en Hugging Face hackte pas na een week, nadat de FBI daarover was ingelicht. Later bleek er nóg zo’n incident te zijng eweest, ook bij Anthropic ging het in juli mis. En iedereen rapporteert erover alsof het een weersverschijnsel is. ICT-recht herhaalt zich niet maar het rijmt wel, zeg ik dan: weten jullie nog van de Morris-worm?

Op 2 november 1988 zette de 23-jarige informaticus Robert Morris een programma op het toenmalige internet. Het programma moest beveiligingszwaktes aantonen door zichzelf naar andere computers te verspreiden. Daarvoor gebruikte het vier routes: een fout in Sendmail, een kwetsbaarheid in fingerd, misbruik van vertrouwde hosts en het raden van wachtwoorden.

Ondanks een beveiliging tegen overbelasting sloeg de software op hol: computers kregen meerdere exemplaren van het programma, liepen vast en het netwerk raakte verstopt. Toen Morris zag wat er gebeurde, probeerde hij zelfs via een vriend instructies rond te sturen waarmee beheerders het programma konden verwijderen.

Morris kreeg drie jaar voorwaardelijk en een forse boete. Destijds had hij niet echt een excuus: hij had het niet zo bedoeld, maar de Computer Fraud and Abuse Act maakt dat onderscheid niet. Als ik de berichten van nu lees, dan had hij iets moeten zeggen van

Ik heb een autonome cybersecurity-agent ingezet met als objective het ontdekken van zwakke plekken in computernetwerken. De agent maakte daarbij gebruik van tooling voor credential discovery, lateral movement en exploitation. Tijdens de evaluatie vertoonde het systeem onverwacht emergent behaviour, waarna het containment doorbrak en zelfstandig externe systemen benaderde.
Ik snap dit dus niet in de berichtgeving van nu. Waarom zegt de media niet “OpenAI liet experimentele software autonoom cyberaanvallen uitvoeren, waarbij zijn technische beveiligingsmaatregelen niet voorkwamen dat die software systemen van een derde binnendrong”?

Arnoud

 

EU verplicht elektronicafabrikanten om cyberincidenten binnen 24 uur te melden

Geplaatst op in Security, 2 reacties
Photo by Kindel Media on Pexels

De eerste verplichting uit de Europese Cyberweerbaarheidsverordening geldt sinds 11 september. Dat meldde Tweakers vorige week. Fabrikanten moeten actief misbruikte kwetsbaarheden en grote beveiligingsincidenten voortaan bij Europese en nationale toezichthouders melden bij Enisa, het European Union Agency for Cybersecurity, en bij het lokale Computer Security Incident Response Team (Csirt).

De Cyberweerbaarheidsverordening of Cyber Resilience Act (CRA) is een van de wetten uit het pakket van de Digital Decade. De wet staat naast de Nederlandse Cyberbeveiligingswet, want die implementeert de bekende NIS2 richtlijn. Kort gezegd: NIS2 gaat over kritieke infrastructuur, de CRA gaat over apparaten die over netwerken praten.

De kern van de CRA is “producten met digitale elementen”, mits ze “een directe of indirecte logische of fysieke gegevensverbinding met een apparaat of netwerk” hebben. De robotstofzuiger van het plaatje bijvoorbeeld communiceert met het basisstation links, maar die praat weer via wifi met de thuisrouter en daar weer mee met de clouddienst van de aanbieder. Elk van die afzonderlijk is genoeg om die stofzuiger onder de CRA te laten vallen.

Doel van de CRA is de cyberbeveiliging van dergelijke producten te waarborgen. Essentiële eisen daarvoor staan in een bijlage, en je moet als fabrikant een conformiteitsbeoordeling (die van de CE-markering) doorlopen om vast te stellen dat je daaraan voldoet. Je aansprakelijkheid voor fouten daarbij kun je niet beperken.

De eerste twee plichten uit de CRA (de rest komt in december volgend jaar) zijn de meldplicht kwetsbaarheden en ernstige incidenten, beiden uit artikel 14. Eerst maar die eerste.

Een fabrikant doet tegelijkertijd aan het overeenkomstig lid 7 van dit artikel als coördinator aangewezen CSIRT en aan Enisa melding van elke actief uitgebuite kwetsbaarheid in het product met digitale elementen waarvan hij kennis krijgt.
Dat is een “zwakheid, vatbaarheid of gebrek” waarbij “betrouwbare bewijzen bestaan dat een kwaadwillige actor die heeft uitgebuit in een systeem zonder toestemming van de systeemeigenaar”. Binnen 24 uur na ontdekking daarvan moet je het melden.

Daarnaast moeten ook zogeheten ernstige incidenten worden gemeld:

Een fabrikant doet tegelijkertijd aan het overeenkomstig lid 7 van dit artikel als coördinator aangewezen CSIRT en aan Enisa melding van elk ernstig incident dat gevolgen heeft voor de beveiliging van het product met digitale elementen waarvan hij kennis krijgt.
Een “incident” is dan weer in NIS2 gedefinieerd als een “gebeurtenis die de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van opgeslagen, verzonden of verwerkte gegevens of van de diensten die worden aangeboden  … in gevaar brengt”.

Het incident is ernstig als aan een van deze eisen is voldaan:

  1. Negatieve gevolgen voor de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gevoelige of belangrijke gegevens of functies;
  2. Injectie of executie van kwaadwillige code in een product of netwerk daar omheen.
En let op, we noemen het wel “de meldplichten” maar óók het moeten adresseren is al van kracht. Binnen 72 uur na ontdekking van een uitgebuite kwetsbaarheid moet je een oplossing of in ieder geval workaround publiceren. Binnen 14 dagen (en bij incidenten 30 dagen) een finale oplossing.

In theorie kún je voldoen door te zeggen “dit is er gebeurd, wij hebben geen patch dus we stellen voor dat je het apparaat uitzet”. De bedoeling is dat niet, maar er staan momenteel geen boetes op het niet daadwerkelijk fixen wat gefixt kan worden. Dat komt pas eind volgend jaar.

Arnoud

Mag de organisatie van een Facebook-winactie haar schade voor datalekken uitsluiten?

Geplaatst op in Privacy, Security, 7 reacties
Photo by Markus Winkler on Unsplash

Een lezer vroeg me:

Een bedrijf organiseert op Facebook een winactie waarbij je een mooie prijs kunt winnen. Bij het doorlezen van de voorwaarden viel me op dat de organisator daarin stelt dat het niet aansprakelijk is voor schade veroorzaakt door een datalek. Nu vraag ik me af of je in de actievoorwaarden een AVG-recht, namelijk het recht op schadevergoeding, mag uitsluiten.
Het korte antwoord is natuurlijk: nee, dat kan niet. De AVG-plicht om je klanten tegen datalekken te beschermen, kun je niet contractueel inperken of buiten werking stellen. Als je die plicht geschonden hebt, en de klant heeft schade, dan moet jij die vergoeden. (Bewijzen dát er schade is, is lastig, maar staat hier los van.)

Niet ieder datalek maakt dat je schadeplichtig wordt, zeg ik er dan meteen bij. Dat geldt alleen bij datalekken die het gevolg zijn van inadequate beveiliging. Een datalek door overmacht maakt dat de betrokken personen zelf hun schade moeten dragen.

Daarnaast is het bij dit soort acties vaak zo dat de persoonsgegevens aan een ander worden overgedragen. De organisator van de actie is dan niet aansprakelijk voor wat die ander er mee doet, en dus ook niet voor diens datalekken-door-nalatigheid. Specifiek voor dat laatste geval is een disclaimer nuttig, al is het maar voor de duidelijkheid.

Arnoud

Mag ik als cybersecurity-specialist een collega monitoren omdat de baas dat zegt?

Geplaatst op in Ondernemingsvrijheid, Privacy, Security, 11 reacties
Photo by Matheus Bertelli on Pexels

Een lezer vroeg me:

Als cybersecurity-specialist monitor ik het netwerk van ons bedrijf (een middelgrote IT-dienstverlener). Hierbij heb ik toegang tot bepaalde gegevens van collega’s, waaronder e-mail onderwerpen, inloggegevens en bijhorende IP-adressen (en dus ook geolocatie van dat IP), gebruik van bepaalde apps op beheerde apparaten etc. Nu heeft een directeur aangegeven dat enkele collega’s zich niet aan afspraken houden rondom omtrent op tijd komen, eerder weg gaan en thuiswerken. Mijn opdracht is nu regelmatig de logs te analyseren voor bewijs hierover, inclusief nagaan of hij een mouse jiggler gebruikt. Mag ik deze opdracht wel uitvoeren? Dit valt buiten mijn takenpakket volgens mij.
Al deze genoemde gegevens zijn persoonsgegevens. Het is logisch (en toegestaan onder de AVG) om die te verwerken met als doel cyberbeveiliging. Maar wat deze directeur nu opdraagt, is in feite een hergebruik voor een ander doel, namelijk persoonsgericht monitoren en beoordelen van gedrag van een werknemer.

Hergebruik van gegevens mag eigenlijk alleen als je binnen hetzelfde doel blijft, of een nieuw doel hebt dat daar direct aan vast hangt. Aangifte doen van een cyberincident bijvoorbeeld. Maar dit andere doel ligt daar zo zwaar buiten dat het bedrijf er een aparte grondslag voor moet hebben.

Monitoren van personeel met it-middelen ligt gevoelig, en dat is maar goed ook. Op zijn minst moet het bedrijf een duidelijk it-reglement hebben dat ingaat op wanneer je persoonsgericht mag monitoren, hoe dat wordt uitgevoerd en hoe zaken als geheimhouding en inspraak worden geregeld. Zonder vooraf opgesteld reglement is dit eigenlijk altijd onrechtmatig.

We weten niet of er een reglement is, maar ik vermoed van niet gezien de wijze van vraagstellen. Als dat inderdaad niet zo is, dan is de opdracht dus onrechtmatig. Lastig is dan: moet je hem uitvoeren? Puur formeel juridisch zeg ik nee, maar ik snap goed dat je als werknemer niet die escalatie aan wilt gaan.

Een eerste stap kan zijn vragen om dat reglement, zodat je op de juridisch juiste manier verzamelt wat je volgens het reglement moet verzamelen en de directeur daarmee het bewijs krijgt dat hij echt kan gebruiken. Malicious compliance, maar met een sterk argument: het bewijs is niet bruikbaar als het verkeerd is verzameld.

Daarnaast is zorgen dat de opdracht in de mail gegeven wordt (en niet alleen mondeling) erg belangrijk, mochten er tegenclaims komen. Want dan is er een kans dat die directeur ineens vergeten is dat hij die opdracht had gegeven.

Een signaal aan de OR geven (als die er is, middelgroot bedrijf) is een mogelijkheid maar kan goed tot een conflict met die directeur leiden wanneer de OR met hem in gesprek gaat over illegaal monitoren van personeel. Want duidelijk is dan wel van wie dat signaal kwam.

Arnoud

Op staande voet ontslagen omdat je al je werkbestanden in Google Gemini wilde schuiven (vanwege een arbeidsconflict)

Geplaatst op in Ondernemingsvrijheid, Privacy, Security, 6 reacties
Photo by Riedelmeier on Pixabay

Oh jee. “Een senior directeur heeft meerdere bestanden uit de bedrijfsomgeving naar zijn privé e-mailadres verzonden en heeft daarnaast het hele bestand van zijn zakelijke computer willen uploaden.” Nee, dat vond de rechter niet leuk en de directeur mocht op staande voet worden ontslagen. Wat was hier aan de hand?

Het vonnis is kort en kernachtig. Zo te lezen waren er beëindigingsonderhandelingen bezig, wat wijst op een al bestaand arbeidsconflict. Het is dan op zijn zachtst niet handig om grootschalig bestanden te gaan downloaden, want dat wordt gelogd en komt op tafel.

Hier ook:

[verzoeker] heeft meerdere bestanden uit de bedrijfsomgeving van [werkgever] naar zijn privé e-mailadres verzonden en daarnaast op 19 november 2025, in de ochtend om 07:00 uur, zo blijkt, het hele bestand van zijn zakelijke computer willen uploaden naar Gemini (Google AI).
De reden dat het aan het licht kwam, was dat er een intern security systeem dit detecteerde en ingreep. Logisch en standaard bij zulk bulkwerk.

Mag dat? Alleen al uit het arbeidsrecht algemeen volgt al dat zoiets niet mag. Maar hier stond het ook “met heldere bewoordingen in de arbeidsovereenkomst van [verzoeker] en in de Code of Business Conduct Policy”. En dan ben je af, zeker als je een hoge functie “met een bijbehorend salaris” bij zo’n bedrijf hebt.

Omdat die tweede stap gebeurde nádat hij was aangesproken op het privémailen, en hij daar niets over zei, is het bedrijf alle vertrouwen in hem verloren. En de rechter wijst het ontslag op staande voet dan ook toe.

Het wrange gevoel dat ik bij zulke zaken vaak wel heb, is dat je als werknemer op een forse achterstand staat. Alle informatie is digitaal, dus als je ineens in een geschil zit met je werkgever dan moet je van alles gaan downloaden. Gericht zoeken kost tijd, en misschien gaat je account zo op nonactief, dus bulkdownloaden is dan logisch. Maar dat kan dus wel leiden tot dit soort situaties.

Zoals ik in 2023 al blogde:

Daarom blijft het advies: kopieer bewijsstukken die jouw positie ten opzichte van de werkgever kunnen beïnvloeden. Een risico daarvan is natuurlijk weer dat je dan beschuldigd kunt worden van stelen van bedrijfsgeheimen. Beperk zoiets dus tot dingen die evident jou aangaan, zoals mails van HR of directie met toezeggingen, niet hele bergen documenten van projecten om aan te kunnen tonen dat je daaraan had gewerkt en niemand ooit had geklaagd.
Arnoud

Wat zijn nou de belangrijkste aandachtspunten voordat je AI in je bedrijf gaat inzetten?

Geplaatst op in Innovatie, Ondernemingsvrijheid, Security, 4 reacties
Photo by Albert Stoynov on Unsplash

Een lezer vroeg me:

Iedereen gebruikt inmiddels AI op de werkvloer. Wat zijn volgens jou de belangrijkste juridische aandachtspunten waar bedrijven momenteel rekening mee moeten houden voordat ze AI inzetten binnen het bedrijf?
Mijn allerbelangrijkste aandachtspunt is dat je begint met kwalificeren wat je bedoelt met “we gebruiken AI op het werk”. Dit is een wereld van opties, van “werknemers gebruiken op hun telefoon een gratis account bij OpenAI” en “Wim heeft een self-hosted Chinees model op zijn oude laptop” tot “onze workflows zijn geautomatiseerd via OpenClaw agents met een ingeregeld soeverein self-hosted taalmodel”.

In de kern heb je twee smaken AI: self-hosted en SaaS. De meeste mensen gebruiken die laatste, en dat behandel je gewoon als iedere ict-dienst die je inkoopt. Kwaliteit, aansprakelijkheid, data-toegang, veiligheid, exit zijn dan de belangrijkste aandachtspunten. Plus verwerkersovereenkomst als de dienst persoonsgegevens verwerkt.

Specifiek bij AI-diensten is het grootste aanvullend risico hoe vertrouwelijk men omgaat met je data. De klassieke zorg is dat men al je chats gebruikt om het taalmodel mee te verbeteren, dus zorg dat je inkoopt op een niveau waarbij dat contractueel uitgesloten wordt.

Daarnaast is anno 2026 soevereiniteit een aandachtspunt. Blijft de data in Europa? En zo niet, hoe makkelijk kunnen we dan mét data en al weg zodra het Hof van Justitie (of de Commissie) zegt dat de US cloud niet meer adequaat is?

Bij self-hosted AI modellen blijven kwaliteit, veiligheid en data-omgang van belang, maar vanuit een ander perspectief. Heb je je beheer op orde, wat is de uitwijkoptie als de dienst het niet doet, enzovoorts. Wie let op actualiteit en verbetering, gebruikerstraining en zulke zaken. Wederom: hetzelfde als bij andere ict-diensten.

Mocht je te maken hebben met hoogrisico-AI onder de AI-verordening, dan wordt dat vanaf december 2027 een extra aandachtspunt. Kopen wij dit in met een CE keurmerk, en hebben wij toezicht en gebruik goed ingeregeld met training en bevoegdheden voor iedereen die er mee te maken krijgt?

Bij bovenstaande ben ik uitgegaan van zakelijk afgenomen AI-diensten. Populair is de privé afgenomen dienst die dan onzichtbaar voor werk wordt ingezet. Dit is ook niet nieuw, de term “shadow IT” bestaat al 20 jaar. Maar er zijn nu ineens veel meer redenen voor individuele werknemers om zulke tools in te zetten, dus komt het veel vaker voor. Hier beleid, educatie en toezicht op hebben is wat mij betreft dus essentieel.

Arnoud

Als je Europese passwordkluis ineens uit Rusland komt

Geplaatst op in Security, 6 reacties
Photo by Sam Riz on Unsplash

De Europees ogende wachtwoordsoftware Passwork komt in werkelijkheid uit Rusland, aldus Nu.nl onlangs. Geen van de Europese klanten wist het. Over twee maanden gaat de meldplicht van de Cyber Resilience Act in, maar de vraag “wie zit er eigenlijk achter mijn software” heeft in heel de Digital Decade-wetgeving nog steeds geen goed antwoord.

Passwork maakt wachtwoordkluizen voor bedrijven. Op de website: “Made in EU”, hoofdkantoor Barcelona, voldoet aan Europese privacywetgeving. In werkelijkheid werd het bedrijf in 2014 opgericht in Rusland, en die banden zijn er nog. Het “hoofdkantoor” bleek een brievenbus bij een Russischtalig advocatenkantoor. Onder meer een grote Nederlandse zonneparkbeheerder, een Frans havenbedrijf en Ierse overheidsinstanties waren klant.

Passwork zegt dat wachtwoorden alleen op de servers van klanten staan, versleuteld, met een “zero-knowledge architecture”. Ze kunnen er zelf niet bij. Althans, zeggen ze: de encryptie en decryptie vinden plaats in code die Passwork zelf schrijft en via updates beheert. Wij kunnen het niet zien. Een extra kanaaltje naar de FSB kan er dus zomaar zijn.

Password managers worden expliciet in de Cyber Resilience Act (CRA) genoemd als in-scope softwareproducten. Vanaf 11 september moet Passwork actief misbruikte kwetsbaarheden binnen 24 uur melden bij ENISA, en tegen december 2027 moet het bedrijf een volledige SBOM leveren — een stuklijst van alle softwarecomponenten, inclusief herkomst.

Maar een SBOM vertelt je wat er volgens de leverancier in de software zit. Niet wat er daadwerkelijk draait. Ken Thompson beschreef dat probleem al in 1984: een compiler die zichzelf compileert kan een achterdeur bevatten die in geen enkele regel broncode zichtbaar is, maar die zich bij elke compilatie reproduceert. Het punt is veertig jaar oud en nog steeds onopgelost.

En daar raakt het technische probleem aan het politieke. Want als je de broncode niet kunt vertrouwen en de SBOM niet kunt verifiëren, dan valt je terug op de enige vraag die overblijft: vertrouw je de partij die de software maakt? Dat is een soevereiniteitsvraag.

Soevereiniteit kent vele betekenissen. Als ondergrens hanteer ik: wie software levert aan vitale infrastructuur moet kunnen aantonen vanuit welke jurisdictie de broncode wordt beheerd en wie de update-pipeline bezit. Maar leg die last niet bij de afnemer. Novar bouwt zonneparken, geen dreigingsanalyses. Dit soort risico’s moet gevangen worden in de CE-certificering, niet in de due diligence van elke mkb’er.

En ja, de nervositeit is nu ingegeven door het woord “Rusland”. Maar het zou precies hetzelfde moeten uitpakken bij Amerikaanse software. De soevereiniteitsvraag is dus eigenlijk: wie willen wij vertrouwen voor onze ict-infrastructuur?

Arnoud