Ce règlement européen a pour vocation d’améliorer la sécurité des produits et services, avec composants numériques, en imposant des exigences à leurs fabricants et distributeurs. C’est un effort louable. Ce serait toutefois anormal si un texte avec cette ambition n’était pas perfectible. Focus sur ce processus qui interroge.
Vulnérabilités, incidents : la notification, c’est maintenant. Parmi les exigences de ce règlement sur le point d’être adopté, on note celles liées à la divulgation des vulnérabilités. L’article 11 du Cyber Resilience Act (CRA) impose aux fabricants/éditeurs de notifier les vulnérabilités activement exploitées à l’Agence européenne pour la cybersécurité (ENISA) et au CSIRT national, désigné en tant que coordinateur.
Cette notification se fera par le biais d’un « guichet unique », une plateforme dédiée développée et opérée par l’ENISA, dans un délai de 24 heures après en avoir eu connaissance. Des éléments complémentaires peuvent être fournis dans les 72 heures puis un rapport final au plus tard deux semaines après la mise à disposition d’un correctif ou mesure palliative.
Une procédure quasi-identique concerne les incidents, sous-entendu de sécurité, dont l’impact est évalué à « sévère », soit à une incidence significative sur le produit/service visé. Le délai de soumission du rapport final est ici porté à un mois après la clôture de l’incident.
Une difficulté majeure qu’on peut déjà anticiper est la confusion (opérationnelle) entre notifier une vulnérabilité activement exploitée, causant des problèmes, et un incident de sécurité résultant de l’exploitation d’une vulnérabilité. Bonnet blanc, blanc bonnet, et double reporting ? Et quelle articulation avec les obligations de notification d’incidents de sécurité dans la directive NIS2 quand les périmètres se rejoignent ?