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
“Novar bouwt zonneparken, geen dreigingsanalyses”
Deze partij ken ik niet. Maar onder NIS2/Cyberbeveiligingswet moet kritieke infrastructuur juist wel dreigingsanalyses uitvoeren als ze een zonnepark bouwen. Die Cbw is sinds vorige week in werking getreden en geldt nu al volledig.
Als U kritiek infrastructuurbedrijf meer dan 50 medewerkers heeft Of als u een jaaromzet heeft boven 10 miljoen euro
Is volgens jou een dreigingsanalyse onder NIS2/Cbw niet goed genoeg uitgevoerd als je (net als de rest van de wereld) niet in de gaten hebt dat een leverancier van software gevestigd is ten kantore van een advocatenkantoor met connecties met andere landen dan waar de leverancier zegt gevestigd te zijn? Zo nee, dan helpt Cbw hier niet bij het voorkomen van dit soort risico’s. Zo ja, moeten Cbw-plichtige bedrijven dan ook bijvoorbeeld als risico meenemen dat de ontwikkelaars van andere essentiële software chantabel of omkoopbaar kunnen zijn door malafide actoren? De betrouwbaarheid van veel belangrijke tools hangt af van de blijvende integriteit van slechts één mens! Alles is dus denkbaar. Maar waar houdt de verantwoordelijkheid van een gewone bedrijfsmatige gebruiker (van andermans software of services) om alle denkbare risico’s mee te wegen en alles extreem diep uit te zoeken op? Wetende dat zelfs broncode-analyse door specialisten of keuringsinstanties geen zekerheid kan bieden?
Ik neem aan dat je als bedrijf al een risico-analyse hebt en dat je weet wat de kritieke systemen en processen zijn en welke systemen minder kritiek zijn. Een dreigingsanalyse gaat dieper voor kritieke systemen dan voor minder kritieke, dus het antwoord op jouw vraag is “het hangt er van af.” Bij zeer kritieke systemen in de hoogste veiligheidsklasse zijn audits bij leveranciers bijna onvermijdelijk, maar dergelijke systemen zijn zeldzaam.
Kijk naar wat je als bedrijf doet, waar de dreigingen vandaan kunnen komen, hoeveel tijd en geld de aanvallers voor aanvallen van jouw systemen over zullen hebben. Plan naar de uitkomst van de analyse en voer de plannen uit. Herevalueer regelmatig. (Vergeet ook de typische ransomware hackers niet die het op je kantoorautomatisering voorzien hebben.)
Tja CE markering. Tot nu toe grotendeels zelfcertificering. Wij van WC-eend stellen dat ons product voldoet aan de normen.
Op de onderstaande links en reacties erop kun je zien dat het Russische Kasperski de passwordkluis ook gebruikt heeft om passwords te achterhalen:
https://www.agconnect.nl/business/security/passwordmanager-gaf-twee-jaar-lang-voorspelbare-wachtwoorden
https://www.agconnect.nl/business/security/securityleverancier-kaspersky-verlaat-vs-na-overheidsban