La Commission, le Parlement et le Conseil de l’UE sont sur le point de parvenir à un accord politique concernant le règlement sur la cyberrésilience (Cyber Resilience Act), les dissensions sur le pouvoir attribué aux autorités nationales pour restreindre l’accès aux failles de sécurité identifiées étant le dernier point à éclaircir.
Le règlement sur la cyberrésilience vise à introduire des exigences en matière de sécurité pour les fabricants d’appareils connectés. La proposition de loi se trouve au stade des négociations interinstitutionnelles (trilogues), dernière étape du processus législatif au cours duquel les trois institutions majeures de l’UE tentent de s’accorder sur la version finale du règlement.
Les négociateurs devraient parvenir à un accord lors d’un trilogue politique qui se tiendra jeudi (30 novembre), mais la plupart des aspects du dossier ont déjà été réglés sur le plan technique, selon un document interne daté du 24 novembre et consulté par Euractiv.
Cependant, l’aspect épineux du signalement des failles de sécurité et des incidents identifiés reste le principal sujet politique encore en suspens.
Signalement des failles de sécurité
Le règlement sur la cyberrésilience introduit pour la première fois l’obligation de signaler non seulement les incidents graves, mais aussi les failles de sécurité activement exploitées, c’est-à-dire les points d’entrée dans les systèmes IT activement utilisés par des acteurs malveillants et qui n’ont pas encore été corrigés.
Dans la version actuelle du texte, les délais de signalements ont été alignés sur ceux de la directive révisée sur les réseaux et les systèmes d’information (Networks and Information Systems Directive, NIS2), mais pour les failles activement exploitées, le signalement final devra être effectué dans un délai de 14 jours.
La proposition initiale, soutenue par le Parlement, prévoyait que ces failles soient notifiées à l’Agence de l’Union européenne pour la cybersécurité (ENISA), mais les États membres souhaitent confier cette tâche à leurs centres de réponse aux incidents de sécurité informatique (CSIRT) actifs au niveau national.
Un CSIRT est considéré compétent là où le fabricant a son siège principal, c’est-à-dire dans le pays où les décisions relatives à la cybersécurité sont prises ou le lieu où le nombre d’employés est le plus élevé. Les entreprises qui n’ont pas de siège au sein de l’UE seront tenues de se référer au pays où elles ont le plus d’utilisateurs.
Mi-novembre, Euractiv a révélé que la Commission avait proposé comme compromis aux fabricants de déposer tout signalement par le biais d’une plateforme unique prévue à cet effet, qui alerterait simultanément les CSIRT nationaux compétents ainsi que l’ENISA.
Alors que cette approche semble en voie de mettre tout le monde d’accord, le Conseil de l’UE insiste pour que les CSIRT puissent restreindre temporairement l’accès de l’ENISA aux signalements, pour des raisons de cybersécurité. Les eurodéputés sont quant à eux fortement opposés à cette mesure, qui risque d’être le point de désaccord principal lors du prochain trilogue.
De plus, les États membres ne semblent pas entièrement satisfaits du compromis proposé par la présidence espagnole du Conseil, estimant que celui-ci ne rentre pas dans les compétences de son mandat. Une autre source de tension pourrait résulter du fait que le Parlement européen souhaite inclure une clause visant à augmenter les ressources de l’ENISA.
Catégories spéciales de produits
Dans le cadre du règlement sur la cyberrésilience, les fabricants seront en mesure d’évaluer eux-mêmes leur conformité aux normes de sécurité des produits. Toutefois, pour certaines catégories de produits considérés comme « importants », le contrôle devra être effectué par des organismes certifiés spécialisés dans l’évaluation de la conformité.
Les catégories de produits « importants » sont énumérées en annexe du règlement, et le Conseil a réussi à introduire une méthodologie permettant de classer les produits dans cette catégorie. Ainsi, pour être qualifié d’« important », un produit doit avoir une fonction critique pour la cybersécurité d’autres produits ou présenter une fonction qui comporte un risque majeur d’avoir un impact négatif sur un grand nombre de produits ou d’utilisateurs.
La liste des produits importants, autre point de friction durant les négociations, a désormais été consolidée.
La première catégorie de produits importants comprend les éléments suivants : les systèmes de gestion des identités, les navigateurs, les gestionnaires de mots de passe, les programmes de détection de logiciels malveillants, les réseaux privés virtuels (VPN), les systèmes de gestion de réseau, les systèmes de gestion des événements et des informations de sécurité, les logiciels de démarrages, de délivrance de certificats numériques, les interfaces réseaux, les systèmes d’exploitation, les routeurs, microprocesseurs, microcontrôleurs dotés de fonctionnalités liées à la sécurité et les circuits propres à une application.
Les eurodéputés ont insisté pour que les produits de consommation tels que les maisons intelligentes, les jouets connectés et les accessoires personnels soient également inclus dans la classe 1. Dans la classe 2, la liste finale inclut les hyperviseurs (également appelés moniteurs de machines virtuelles) et de virtualisation des systèmes d’exploitation, les pare-feu ainsi que les microprocesseurs et les contrôleurs infalsifiables.
Le Conseil a également introduit une liste supplémentaire de produits critiques qui pourraient être soumis à l’obligation d’obtenir un certificat de cybersécurité, notamment les équipements physiques (hardware), comme les compteurs intelligents ou les cartes à puce.
Obligations pour les fabricants
Les fabricants devront procéder à une analyse de risques qui leur permettra de déterminer les exigences de sécurité qui s’appliquent à leur produit. L’évaluation des risques doit être mise à jour pendant toute la période de maintien en conditions opérationnelles du produit, dans la mesure où cela s’avère nécessaire.
La période de maintien en conditions opérationnelles est le délai au terme duquel les fabricants doivent s’assurer que les failles des produits ont été résolues. Elle doit être d’au moins cinq ans, sauf si la durée de vie prévue du produit est inférieure à cette durée.
En outre, le texte adopté prévoit que toute mise à jour de sécurité effectuée pendant la période d’assistance doit rester disponible au moins dix ans après son déploiement ou jusqu’à la fin de la période d’assistance, la durée la plus longue étant retenue.
Le texte précise désormais que les fabricants doivent proposer leurs produits « avec une configuration sécuriser par défaut et fournir gratuitement des mises à jour de sécurité aux utilisateurs ».
Exemption en matière de sécurité nationale
La clause d’exemption relative à la sécurité nationale, demandée par le Conseil, doit encore être confirmée.
La question est de savoir si seuls les produits développés exclusivement à des fins de sécurité nationale ou de défense doivent être exclus des règles, ou s’il faut également exclure ceux qui ont été modifiés à ces fins.
Logiciels open source
La question de l’inclusion des logiciels libres (ou « open source ») a fait l’objet d’un large consensus au niveau technique.
Comme Euractiv l’a précédemment rapporté, les responsables politiques de l’UE ont introduit la notion de gestionnaires de logiciels libres soumis à la documentation et au traitement des failles.
Répartition des revenus issus des sanctions
Un point mineur qui doit être réglé lors du trilogue est la proposition des députés européens visant à obliger les pays de l’UE à réinvestir les recettes générées par les sanctions prévues par le règlement dans des activités de renforcement de leurs capacités en matière de cybersécurité.
