Reporting de vulnérabilités dans le Cyber Resilience Act : une fausse bonne idée ?

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 ?

Conçue comme une mesure de responsabilisation, l’exigence de notification des vulnérabilités entend inciter les fabricants de produits et services numériques, au bilan de sécurité contestable, à rechercher activement les vulnérabilités et à les colmater pour amortir les chocs. Bien intentionnée, cette exigence risque d’avoir des conséquences négatives inattendues pour les fabricants de ces produits, pour les autorités et pour les utilisateurs.

Urgences artificielles cherchent bénéfices réels

L’article 11 du CRA exige donc que les éditeurs/fabricants notifient les vulnérabilités non corrigées et exploitées aux autorités dans les 24 heures. Cela signifie que des dizaines d’agences gouvernementales auraient accès à une base de données en temps réel de vulnérabilités non corrigées, sans pouvoir les mobiliser pour protéger l’environnement en ligne.

Accélérer le processus de divulgation et avoir une connaissance généralisée des vulnérabilités non corrigées comporte plusieurs risques. Celles qui entraînent de graves conséquences pour la sécurité des utilisateurs sont souvent gardées confidentielles jusqu’à ce que les correctifs existent, voire appliqués adéquatement. La correction de ces vulnérabilités peut prendre des semaines, voire des mois, ou elles peuvent ne jamais avoir de correctif réaliste.

De plus, le texte porte sur un reporting détaillé à fournir. Il n’y a cependant aucune obligation à ce que les actions de corrections et leurs conséquences apparaissent dans ce rapport. Les correctifs traitant de la cause première prennent en effet du temps et peuvent être difficilement déployables, notamment quand elles concernent de nombreux composants ou touchent des produits et services complexes ou difficilement accessibles. Dommage : le bénéfice réel, notamment dans un dispositif aussi centralisé et se voulant démonstratif de la résilience au niveau européen, viendrait de la visibilité du parc patché.

Fais ce que je dis, pas ce que je fais ?

Une obligation de reporting dans des délais aussi courts ne manquera pas de créer des embouteillages et mettre en situation d’échec de nombreux CSIRTs nationaux manquant de maturité opérationnelle. Cette crainte est d’autant plus forte qu’il n’existe pas de seuil de criticité des vulnérabilités à notifier. Il semble que toute vulnérabilité, indépendamment de son score CVSS, devra être notifiée à partir du moment où elle est activement exploitée.

À ce catalogue d’insuffisances se greffent la collecte et l’accumulation de vulnérabilités exploitées par l’ENISA et les CSIRTs nationaux. La connaissance par des acteurs étatiques d’une série de vulnérabilités est loin de susciter l’unanimité, d’autant plus que ces acteurs seront exclusivement européens. Mais les fabricants/éditeurs, soumis à cette exigence, sont internationaux.

La logique de la démarche dénoncée rappelle le « Règlement sur la gestion des vulnérabilités en matière de sécurité des produits en réseau » chinois, publié en juillet 2021 et entré en application en septembre 2021. D’après ce règlement, les vulnérabilités touchant les produits et services doivent être signalées au ministère chinois pour l’Industrie et les Technologies de l’information, dans les 48 heures suivant leur découverte par l’éditeur/fabricant.

De même, publier des informations sur les vulnérabilités avant qu’un correctif ne soit disponible est interdit, à moins qu’une concertation entre l’éditeur/fabricant et le ministère en décide autrement. Il est également interdit de publier un PoC d’exploit pour montrer comment exploiter une vulnérabilité. En pratique, le cadre chinois pousse tous les rapports sur les vulnérabilités sans correctif vers les autorités, crée un vivier de failles potentiellement mobilisables à des fins offensives et prévient une action coordonnée au sein de l’écosystème.

L’inquiétude est donc réelle de voir une telle logique s’installer à travers l’article 11 du CRA, tant sa rédaction actuelle privilégie la notification à un ensemble d’entités gouvernementales opérant par le biais d’une plateforme centralisée. En effet, outre diriger le reporting vers des agences, l’article 11 reste évasif sur la divulgation publique des vulnérabilités remontées.

Il n’y a pas de délai spécifié, et le fabricant/éditeur doit notifier seulement les utilisateurs concernés. Le CSIRT national pourrait se charger de l’information et la distribution d’éventuels correctifs aux concernés si le fabricant/éditeur ne communique pas publiquement. Les délais et critères de décision de communiquer ou pas sont à la discrétion du CSIRT, sans qu’un délai soit mentionné. Une telle logique reste suffisamment floue pour complexifier ou rendre inopérante une information aux utilisateurs. Communication pourtant nécessaire pour maintenir en condition de sécurité des produits et services concernés.