Dossiers voor afhandeling van kwetsbaarheden onder de CRA

Sytance · Bijgewerkt

Registraties over kwetsbaarhedenafhandeling laten zien hoe de fabrikant tijdens de ondersteuningsperiode kwetsbaarheden opspoort, documenteert, beoordeelt, verhelpt, openbaar maakt en communiceert.

Procesverplichting

Wanneer fabrikanten een product met digitale elementen in de handel brengen en gedurende de ondersteuningsperiode, zorgen zij ervoor dat kwetsbaarheden van dat product, met inbegrip van de componenten ervan, doeltreffend worden afgehandeld en in overeenstemming met de essentiële cyberbeveiligingseisen in bijlage I, deel II.

Verordening (EU) 2024/2847, artikel 13, lid 8

De verplichting begint zodra het product in de handel wordt gebracht en loopt door tijdens de ondersteuningsperiode. De verplichting omvat het product en de componenten ervan.

Belangrijkste soorten registraties

Voorbeeld: van een waarschuwing over een component tot afsluiting

Neem een fictieve kwetsbaarheid in een parser in een firmwareversie van een controller. De zes onderstaande registraties vormen een voorbeeld van een casushistorie. Ze laten zien hoe een team de melding, de productimpact en het herstel met elkaar kan verbinden; deze reeks is geen door de CRA voorgeschreven formulier.

  1. Ontvangst: leg vast wanneer het bericht is binnengekomen, wat de bron was, om welke component en kwetsbaarheidsidentificatie het gaat en welke informatie toen beschikbaar was. Bewaar het oorspronkelijke bericht.
  2. Productimpact: gebruik de SBOM en buildregistraties om mogelijke releases vast te stellen. Controleer voor elke ondersteunde configuratie of een aanvaller toegang kan krijgen tot de getroffen parser; leg zowel het bewijs als de resterende onzekerheid vast.
  3. Meldbesluit: beoordeel artikel 14 onmiddellijk als er aanwijzingen zijn voor actieve uitbuiting of een ernstig productbeveiligingsincident. Leg de momenten van kennisneming vast en dien vereiste meldingen binnen de toepasselijke termijnen in, terwijl het technische onderzoek doorgaat.
  4. Behandeling: beoordeel het productrisico, wijs de oplossing of risicobeperkende maatregel toe en stem waar relevant af met de beheerder van de component. Bewaar de gekozen actie en de reden daarvoor.
  5. Verificatie en release: test de aangepaste parser en de getroffen productfuncties, bewaar de geteste build en koppel deze aan de beveiligingsupdate, bewijs van distributie en gebruikersinstructies.
  6. Afsluiting en vervolg: leg de geverifieerde uitkomst, de bijgewerkte componenteninventaris, communicatie met gebruikers en openbaarmaking vast. Houd een getroffen ondersteunde versie waarvoor geen doeltreffende oplossing bestaat open voor verdere actie.

In het casusdossier moet onderscheid worden gemaakt tussen het voltooien van de interne oplossing, het indienen van eventuele verplichte meldingen en het leveren of installeren van de update. Een oplossing kan bijvoorbeeld zijn gepubliceerd terwijl sommige getroffen gebruikers deze nog moeten installeren, zodat opvolging nodig blijft.

Verband met bijlage VII

Bijlage VII vereist dat de technische documentatie de nodige informatie en specificaties over processen voor kwetsbaarhedenafhandeling bevat, waaronder de SBOM, het beleid voor gecoördineerde openbaarmaking van kwetsbaarheden, het meldcontact en veilige verspreiding van updates.

  • registraties ter ondersteuning van de kwetsbaarheidsgeschiedenis van het product;
  • registraties die uitleggen hoe kwetsbaarheden worden getrieerd en verholpen;
  • registraties waaruit blijkt hoe updates worden verspreid en gebruikers worden geïnformeerd;
  • test- en beoordelingsrapporten ter ondersteuning van de conformiteitsbeoordeling.

Het ontwerp prEN 40000-1-3 wordt op deze pagina nader toegelicht.

Registraties zijn niet de meldtrigger

Deze registraties ondersteunen de kwetsbaarhedenafhandeling. De meldplicht van artikel 14 is een afzonderlijke verplichting die wordt geactiveerd door actief uitgebuite kwetsbaarheden en ernstige productbeveiligingsincidenten.

Bronnen