De Cyber Resilience Act introduceert Europese cybersecurityvereisten voor bepaalde hardware- en softwareproducten met digitale elementen. Een belangrijk uitgangspunt is dat beveiliging niet alleen bij ontwikkeling of verkoop relevant is. Ook onderhoud, ondersteuning en kwetsbaarheidsbeheer gedurende de levensduur van een product spelen een rol.
Dat kan gevolgen hebben voor de manier waarop organisaties naar afhankelijkheid van software- en technologieleveranciers kijken.
Als onderhoud alleen mogelijk is met middelen waar één leverancier exclusief toegang toe heeft, ontstaat een continuïteitsrisico.
Wat is escrow?
Escrow is een regeling waarbij vooraf bepaald materiaal bij een onafhankelijke derde partij wordt ondergebracht.
Bij software kan het bijvoorbeeld gaan om broncode, documentatie en build-informatie.
Bij andere digitale producten kunnen ook firmware, configuraties, certificaten of cryptografische sleutels relevant zijn.
De onafhankelijke partij bewaart het materiaal en stelt dit alleen beschikbaar wanneer aan vooraf bepaalde voorwaarden wordt voldaan.
Het uitgangspunt is dat de leverancier zijn vertrouwelijke materiaal niet standaard aan de gebruiker hoeft over te dragen, terwijl de gebruiker wel een fallback heeft voor uitzonderlijke omstandigheden.
Waarom wordt dit relevant bij de Cyber Resilience Act?
De CRA verlangt van fabrikanten dat zij cybersecurityrisico's gedurende verschillende fasen van de productlevenscyclus beheersen.
Fabrikanten moeten bovendien een supportperiode vaststellen waarin kwetsbaarheden effectief worden behandeld.
Wanneer onderhoud gedurende die periode noodzakelijk blijft, is ook de continuïteit van de daarvoor benodigde middelen van belang.
Dat betekent niet dat de CRA escrow verplicht.
Het betekent wel dat organisaties kunnen onderzoeken of bepaalde technische afhankelijkheden voldoende zijn geborgd.
Voorbeeld: cryptografische sleutels
Een FHI-bijeenkomst over cybersecurity benoemde cryptografische sleutels als praktisch voorbeeld van zo'n afhankelijkheid.
Sleutels kunnen nodig zijn voor secure boot, firmware-updates, authenticatie en beveiligde communicatie. Als een leverancier wegvalt en niemand anders toegang kan krijgen tot de noodzakelijke sleutel, kan onderhoud of productie worden belemmerd.
Key escrow kan in zo'n situatie worden gebruikt om een sleutel onder gecontroleerde voorwaarden onafhankelijk te bewaren.
Vanwege de gevoeligheid van cryptografische sleutels moeten toegangs-, beveiligings- en releaseprocedures daarbij zorgvuldig worden ingericht.
Depot, verificatie en continuïteit
Bij de beoordeling van een escrowregeling helpt het om drie verschillende onderwerpen uit elkaar te houden.
Depot
Het depot beschrijft welk materiaal onafhankelijk wordt opgeslagen.
Het moet aansluiten bij de onderdelen die daadwerkelijk nodig zijn om het product te onderhouden of herstellen.
Verificatie
Verificatie controleert het gedeponeerde materiaal.
Dat kan variëren van een controle op aanwezigheid en leesbaarheid tot een technische test waarbij wordt vastgesteld of software vanuit het materiaal reproduceerbaar kan worden gebouwd.
Continuïteit
Continuïteit gaat over de situatie nadat zich een verstoring voordoet.
Daarbij spelen bijvoorbeeld de volgende vragen:
- Wanneer mag het materiaal worden vrijgegeven?
- Wie krijgt toegang?
- Welke rechten krijgt die partij?
- Welke leverancier kan het onderhoud overnemen?
- Zijn aanvullende infrastructuur of diensten nodig?
- Kunnen beveiligingsupdates daarna nog worden geproduceerd en verspreid?
Een goed gevuld depot zonder uitvoerbare vervolgprocedure biedt niet automatisch continuïteit.
Voor wie kan dit relevant zijn?
Escrow kan worden overwogen door organisaties die afhankelijk zijn van bedrijfskritische software of digitale producten.
Dat kan relevant zijn voor softwaregebruikers, leveranciers, procurementafdelingen, legal teams, riskmanagement en productverantwoordelijken.
De relevantie neemt toe wanneer:
- het product gedurende lange tijd ondersteund moet worden;
- één leverancier essentiële technologie beheert;
- broncode niet elders beschikbaar is;
- firmware alleen door één partij kan worden ondertekend;
- overdracht aan een alternatieve leverancier complex is;
- uitval aanzienlijke operationele gevolgen heeft.
Checklist voor beoordeling
Breng eerst de technische afhankelijkheden in kaart.
Controleer daarna:
- welk materiaal voor onderhoud nodig is;
- wie het materiaal beheert;
- welke derde partijen noodzakelijk zijn;
- welke onderdelen niet eenvoudig vervangbaar zijn;
- of onafhankelijk depot noodzakelijk is;
- welke verificatie passend is;
- welke omstandigheden tot release mogen leiden;
- welke rechten na release nodig zijn;
- wie de continuïteit praktisch kan uitvoeren.
Pas daarna kan worden bepaald of software escrow, key escrow of een andere continuïteitsmaatregel passend is.
Belangrijke CRA-data
De CRA trad op 10 december 2024 in werking.
De rapportageverplichtingen uit artikel 14 zijn vanaf 11 september 2026 van toepassing. De hoofdverplichtingen van de verordening worden vanaf 11 december 2027 volledig van toepassing.
Conclusie
De Cyber Resilience Act maakt cybersecurity tot een onderwerp dat gedurende de levenscyclus van digitale producten moet worden beheerd.
Daarbij kan ook afhankelijkheid van leveranciers relevant worden.
Escrow is geen wettelijke standaardoplossing, maar kan worden toegepast wanneer continuïteit afhankelijk is van broncode, documentatie, firmware, sleutels of andere middelen die bij één partij geconcentreerd zijn.
Welke vorm passend is, hangt af van het product, het risico en de technische keten.
Wie een escrowoplossing overweegt, kan verschillende escrowvormen en onafhankelijke escrow-agents vergelijken en laten beoordelen welke vorm bij het specifieke continuïteitsrisico past.
Bronnen
