Essentiële cyberbeveiligingseisen van de CRA
Sytance · Bijgewerkt
Bijlage I is de basis van de CRA voor producten met digitale elementen die binnen de scope vallen. Deel I beschrijft de cyberbeveiligingseigenschappen van het product zelf. Deel II beschrijft het proces van de fabrikant voor afhandeling van kwetsbaarheden tijdens de ondersteuningsperiode.
Structuur van bijlage I
Bijlage I bestaat uit twee delen. Deel I gaat over het product. Deel II gaat over het proces van de fabrikant voor afhandeling van kwetsbaarheden. Artikel 6 verbindt beide: een product mag alleen op de markt worden aangeboden als het product voldoet aan de toepasselijke eisen van deel I en de processen van de fabrikant aan deel II voldoen.
Deel I: producteigenschappen
Veilige standaardinstellingen, beschermde gegevens, gecontroleerde toegang, veerkrachtige functies, de mogelijkheid om updates uit te voeren, bewaking van activiteiten en het veilig verwijderen van gegevens en instellingen.
Deel II: afhandeling van kwetsbaarheden
Processen voor het opsporen, documenteren, verhelpen en bekendmaken van kwetsbaarheden in het product en de componenten ervan, en voor communicatie daarover.
Artikel 13 vereist dat de fabrikant cyberbeveiligingsrisico’s beoordeelt. Die beoordeling bepaalt hoe de eisen van deel I op het product van toepassing zijn.
Deel I: cyberbeveiligingseigenschappen van het product
Deel I begint met het algemene resultaat dat voor het product wordt verlangd en noemt daarna beveiligingseigenschappen die gelden op basis van de risicobeoordeling van cyberbeveiliging en waar van toepassing. De lijst is breed omdat de CRA veel soorten software, hardware, componenten en verwerking op afstand omvat die productfuncties ondersteunen.
Producten met digitale elementen worden zo ontworpen, ontwikkeld en geproduceerd dat zij een passend cyberbeveiligingsniveau op basis van de risico’s waarborgen.
Verordening (EU) 2024/2847, bijlage I, deel I, punt 1
Een consumentenapp, een industriële VPN en een herbruikbare hardwarecomponent kunnen met verschillende risico’s te maken hebben, ook als een eis met dezelfde woorden is geformuleerd. De risicobeoordeling legt uit hoe deel I op het product van toepassing is en waarom een eis niet van toepassing is wanneer de fabrikant dat concludeert.
Deel I vraagt hoofdzakelijk of het product kan:
- op de markt komen zonder bekende uitbuitbare kwetsbaarheden en met een veilige standaardconfiguratie;
- kwetsbaarheden verhelpen met beveiligingsupdates, waaronder automatische updates wanneer die bij het product passen;
- toegang, vertrouwelijkheid, integriteit, beschikbaarheid, opdrachten, programma’s, configuratie en verwerkte gegevens beschermen;
- het aanvalsoppervlak beperken en de impact van een incident verkleinen;
- relevante beveiligingsactiviteiten registreren en bewaken met een mogelijkheid voor gebruikers om zich af te melden;
- gebruikers in staat stellen gegevens en instellingen veilig te verwijderen en gegevens veilig over te dragen wanneer overdracht wordt ondersteund.
Dit zijn producteigenschappen, geen vast implementatiepatroon. Dezelfde eis kan tot verschillende technische keuzes leiden voor een consumentenapparaat, een professioneel netwerkproduct, een SDK of firmware die in andere producten wordt geïntegreerd.
Deel II: afhandeling van kwetsbaarheden
Deel II gaat over het proces van de fabrikant. Het geldt wanneer het product op de markt wordt aangeboden en gedurende de ondersteuningsperiode. Het omvat ook kwetsbaarheden in opgenomen componenten; inzicht in componenten en communicatie met upstream partijen zijn daarom van belang.
De fabrikant moet kwetsbaarheden en componenten identificeren en documenteren. Bijlage I noemt uitdrukkelijk een software bill of materials in een gangbaar, machineleesbaar formaat dat ten minste de directe afhankelijkheden omvat.
Kwetsbaarheden moeten zonder onnodige vertraging worden aangepakt en verholpen in verhouding tot de risico’s voor het product. Beveiligingsupdates moeten waar technisch haalbaar losstaan van functie-updates.
Deel II vereist een beleid voor gecoördineerde bekendmaking van kwetsbaarheden en een contactadres voor meldingen. Artikel 13 vereist ook dat de fabrikant de persoon of entiteit die een geïntegreerde component onderhoudt informeert wanneer daarin een kwetsbaarheid wordt gevonden.
Updatemechanismen moeten correcties veilig en tijdig verspreiden. Beschikbare beveiligingsupdates moeten zonder vertraging, gewoonlijk kosteloos, worden verspreid met informatie die gebruikers helpt actie te ondernemen.
Normen en bewijs
Geharmoniseerde normen kunnen alleen bijdragen aan een vermoeden van overeenstemming wanneer de relevante verwijzing in het Publicatieblad van de Europese Unie is bekendgemaakt. Ontwerpen, mappingtabellen en sectornormen kunnen nog steeds nuttig bewijs zijn, maar vervangen de productspecifieke risicobeoordeling van artikel 13 niet.
Met normalisatieverzoek M/606 vraagt de Commissie Europese normalisatieorganisaties om horizontale en verticale normen. De FAQ over de uitvoering beschrijft horizontale resultaten voor het risicogebaseerde productkader, producteigenschappen van deel I en afhandeling van kwetsbaarheden van deel II, plus verticale normen voor belangrijke en kritieke productcategorieën.
De technische documentatie moet toelichten hoe de geselecteerde normen of andere technische maatregelen reageren op de risico’s die voor het product zijn vastgesteld. Vervolgens moet zij laten zien welke producteigenschappen en processen voor afhandeling van kwetsbaarheden deze maatregelen uitvoeren.
Lees Openbare materialen voor prEN 40000-1-4 voor actuele openbare informatie over de geplande norm met generieke beveiligingseisen, en Afhandeling van kwetsbaarheden volgens prEN 40000-1-3 voor het huidige ontwerp over afhandeling van kwetsbaarheden.