“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:
- 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;
- 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