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

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

 

9 reacties

  1. “Products with digital elements shall be delivered without any known exploitable vulnerabilities;”

    Handigste is wellicht als de hardware bij aankomst bij de klant alleen maar software kan booten van de verantwoordelijke leverancier, vanzelf de laatste versie zonder bekende fouten.

    Misschien een fysieke knop op elk product waarmee je sowieso de laatste software versie binnenhaalt?

    (Ik sla bewust vele bijkomende problemen over, zo moeten er wellicht certificaten zijn om enigszins zeker te weten dat je niet van een valse leverancier downloadt. Die certificaten kunnen achterhaald zijn… Maar al te vaak bevat een goed bedoelde oplossing voor een probleem ook weer problemen… Hoe kan je eigen software in het product zetten? Als dat ook met een knop moet, met hoeveel knoppen eindig je dan… Wat zijn known exploitable vulnerabilities”, “known” door wie? Komt er dan een EU database die bepaalt dat iets “known exploitable” is? Etc. etc.)

    1. Er zijn wel wat zaken te regelen voordat een IoT apparaat voldoende toegang heeft tot het Internet om te beginnen met het downloaden van firmware. Het makkelijkst is dat te regelen met bedraad Ethernet en DHCP; voor Wifi moet je een netwerk selecteren en wachtwoord invoeren.

      Een fabrikant kan het installeren van “homebrew” software op een device faciliteren door bijvoorbeeld een JTAG poort op de printplaat beschikbaar te maken (na openschroeven van de kast.)

      1. Hoi Mathfox, (Ja je hebt gelijk, allemaal niet triviaal.) Ik heb al weer spijt van mijn op zich goed bedoelde reactie. Laat de EU eerst eens fatsoenlijke normen opstellen voor cylindersloten, zolang de Lockpicking Lawyer bij 95% van de sloten binnen een minuut binnen is valt daar snel veel meer beveiligings-eer te behalen.

        1. chefren, laat je niet intimideren en probeer positieve reacties te blijven posten. Waar je het hebt over certificaten lever je in ieder geval een bijdrage.

          Ik ben een softwareontwikkelaar met redelijke kennis van computerbeveiliging en heb een aantal jaar embedded software helpen ontwikkelen. Ik ben kritisch op wat collega-ontwikkelaars bakken. Naar mijn mening had aansprakelijkheid voor software kwaliteit al een jaar of 30 geleden wettelijk geregeld horen te zijn. (Mijn grootste kritiek op de CRA, het is (te) laat!)

          En ja, een systeem zoals jij suggereert kan gemaakt worden, maar zal een aardige investering aan ontwerp-, implementatie- en verificatietijd kosten om voldoende robuust te zijn. Ik suggereer dat het device zelf gaat controleren of er updates beschikbaar zijn. (Dat voegt een LEDje toe naast de “update” knop.)

          1. OK, positief zijn…

            Wel, de EU moet geen kwaliteits-eisen stellen of steggelen over standaarden (ik onderschrijf de ervaringen van Bert en Arnoud uit eigen archief (afdeling horror)), maar open source implementaties leveren die men vrij mag gebruiken.

            Ofwel ophouden met goedbedoelde maar op voorhand hopeloos falende juridische teksten maar het goede voorbeeld geven.

            Ten aanzien van mijn voorbeeld: EU moet een bootloader voor systemen vrijgeven.

            Inzien dat dit een vorm van infrastructuur betreft, geen woorden maar daden. Dat doen ze voor iedereen begrijpelijk ook boor zeer diverse dingen als wegen en stopcontacten.

            1. Naar mijn mening hebben de overheden een belabberde software kwaliteit te lang op zijn beloop gelaten. En ik zie liever dat de EU aansprakelijkheid of kwaliteitseisen regelt dan een nationale overheid.

              Dat wil niet zeggen dat er op de huidige tekst niets aan te merken is. Ik had graag gezien dat er meer aandacht naar aansprakelijkheid en laat maar zien dat je “best practices” toepast uitgaat an minder naar het optuigen van een papieren tijger van documentatie en audits. Verwijzen naar nog niet bestaande standaards van een nog niet gekozen standaardisatie-consortium is een extreem zwaktebod.

              En ja, dit is wetgeving om het grootste probleem van het vorige decennium op te lossen. Het doet niets aan “supply chain attacks”, “Trojan horses [*]” en “social engineering”.

              [*] Vandaag in het nieuws: Gevaarlijk paard.

  2. Zo’n standaard is inderdaad een enorme uitdaging, mede ook omdat wijzigingen daarin net als in wetgeving altijd langzaam gaan. Je wil ook niet dat de standaard zo restrictief is dat het nieuwe producten of technologieen de toegang tot de markt ontzegt (neem bijvoorbeeld het issue met de electrische step. Omdat het niet duidelijk was onder welke categorie die nu moesten vallen, is dat juridisch nu een bromfiets). Is een open en weinig specifiek opgestelde norm, met daarin opgenomen dat bij twijfelgevallen of conflicten een Commissie van Wijzen de knoop kan doorhakken misschien een idee? Ik voel dat we in Europa behoefte hebben aan meer nieuwe commissies (die dan weer sub-commissies kunnen benoemen met nader te bepalen taken).

  3. Mij is niet helemaal duidelijk of dit ook geldt voor gepubliceerde source code. Dan moet de gebruiker immers nog eerst compileren met een compiler. In een compiler zou ook een exploit zou kunnen zitten. Er zijn nu al initiatieven om dergelijke gevaren uit te kunnen sluiten. Zoek op: Reproducible builds.

    1. De CRA praat over producten en zoals ik de berichtgeving over de regelgeving lees valt computer code (ter lering, discussie, etc.) gepubliceerd in broncodeformaat daar niet onder. Ik voorzie wel dat er een verschuiving zal gaan ontstaan waardoor voorbeeldcode eerder voorzien gaat worden van foutafhandeling.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.