Photo de Nick Bolton sur Unsplash « 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) » , rapporte Euractiv. Cet accord « vise à introduire des exigences en matière de sécurité pour les fabricants d’appareils connectés ».
Les fabricants seront invités à évaluer par eux-mêmes la conformité aux normes de sécurité de leurs produits. Ceux d'une catégorie de produits « importants » devront par contre passer par des organismes certifiés et spécialisés dans l’évaluation de la conformité.
Figurent dans cette catégorie les produits dotés d'une fonctionnalité « critique » pour la cybersécurité d'autres produits, ou susceptibles d'avoir un impact négatif sur un grand nombre de produits ou d’utilisateurs : systèmes de gestion des identités, navigateurs, gestionnaires de mots de passe, programmes de détection de logiciels malveillants, VPN, interfaces et systèmes de gestion de réseaux ou de gestion des événements et informations de sécurité, logiciels de démarrages, de délivrance de certificats numériques, systèmes d’exploitation, routeurs, microprocesseurs, microcontrôleurs dotés de fonctionnalités liées à la sécurité et les circuits propres à une application (« application-specific circuits »).
Des mises à jour disponibles pendant au moins 10 ans
Les eurodéputés ont de leur côté insisté pour y rajouter les produits relevant de l'Internet des objets (IoT), les hyperviseurs et conteneurs, pare-feux et contrôleurs « tamper-resistant ». Le Conseil voudrait pour sa part y rajouter les produits critiques susceptibles d'être soumis à l’obligation d’obtenir un certificat de cybersécurité, notamment les compteurs intelligents ou cartes à puce.
Les fabricants devront effectuer une analyse de risque de leurs produits afin d'en déterminer les exigences de sécurité. Mais également la mettre à jour pendant toute la période de leur maintien en conditions opérationnelles, qui devra être d' « au moins cinq ans », sauf si la durée de vie prévue du produit est inférieure à cette durée.
Les mises à jour de sécurité devront en outre rester disponibles pendant « au moins dix ans », ou jusqu'à la fin de période d'assistance. Et les fabricants devront délivrer leurs produits « avec une configuration sécurisée par défaut, et fournir gratuitement des mises à jour de sécurité aux utilisateurs ».
Signaler à l'ENISA, ou aux CSIRT nationaux ?
Si la plupart des problèmes ont « été réglés sur le plan technique », selon un document interne daté du 24 novembre et consulté par Euractiv, celui du signalement des failles et incidents de sécurité « reste le principal sujet politique encore en suspens ».
Le projet introduit en effet « pour la première fois » l’obligation de signaler non seulement les « incidents graves », mais aussi les failles de sécurité « activement exploitées » par des acteurs malveillants et qui n’ont pas encore été corrigées.
En l'état actuel 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), sauf pour les failles activement exploitées, qui devront être signalées « dans un délai de 14 jours ».
- Le Conseil de l’UE arrête sa position sur la proposition de directive NIS 2
- Cyber-résilience : une lettre ouverte s'inquiète de l'obligation de divulgation des vulnérabilités
- Cyber Resilience Act : une commission du Parlement européen exempte les logiciels libres non commerciaux
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 voudraient confier cette tâche à leurs propres centres de réponse aux incidents de sécurité informatique (CSIRT), actifs au niveau national.
La Commission a proposé comme compromis aux fabricants de déposer leurs signalements sur une « plateforme unique » qui alerterait simultanément les CSIRT nationaux compétents et l’ENISA. Mais le Conseil de l'UE voudrait permettre aux CSIRT nationaux de restreindre temporairement l’accès de l’ENISA aux signalements, « pour des raisons de cybersécurité ».
Les eurodéputés, quant à eux, restent « fortement opposés » à cette mesure qui, souligne Euractiv, « risque d’être le point de désaccord principal lors du prochain trilogue, censé parvenir à un accord ce jeudi 30 novembre ».
La sécurité nationale et la réaffectation des amendes
Euractiv conclut que « la clause d’exemption relative à la sécurité nationale, demandée par le Conseil, doit encore être confirmée ». Reste en effet à trancher si seuls les « produits développés exclusivement à des fins de sécurité nationale ou de défense » doivent en être exclus, ou si ceux ayant été modifiés à cet effet doivent également être concernés.
La proposition des eurodéputés d'affecter le produit des amendes perçu suite aux sanctions au renforcement des activités de cybersécurité, qualifiée de « point mineur » par Euractiv, devra également être réglée lors du trilogue.
Commentaires (10)
#1
Déontologiquement, on se retrouve dans la position intenable où on a l'obligation de mettre en danger ses utilisateurs/ses clients en donnant prématurément les outils permettant de les attaquer à des agences gouvernementales.
Pour le reste, s'il y a aussi de bonnes idées dans ce texte, il reste trop de points à risque pour l'opensource (entre autres la notion de gratuité) et les développements collaboratifs (concept qui passe complètement au dessus de la tête des auteurs du texte).
Aussi, la question de la certification vient avec pas mal de points d'interrogation, et pourrait à elle seule mettre un coup d’arrêt à l'émergence de nouveaux acteurs européens dans certains domaines.
#1.1
#2
#2.1
par exemple:
https://edri.org/our-work/eu-cyber-resilience-act-harm-open-source-software-competitiveness/
https://www.linuxfoundation.org/blog/understanding-the-cyber-resilience-act
https://www.theregister.com/2023/10/13/can_open_source_be_saved/
https://blog.sonatype.com/can-the-open-source-community-save-europe-from-the-cyber-resilience-act
En pratique, le texte risque de provoquer une forte réaction de la communauté opensource au regard des risques juridiques qu'il introduit, et s'il y a trop de risques pour la communauté, il y aura des contingences qui pourraient être très problématiques pour l'économie européenne.
La semaine passée, j'étais invité pour assister à un événement de la commission pour les 15 ans de l'observatoire de l'Open Source... il y avait une belle présentation du https://www.sovereigntechfund.de/ pour parler du besoin de financer les projets opensource (reprenant l'exemple du dev du nebraska https://xkcd.com/2347/)... et je n'ai pas pu m'empêcher de penser que, si cette initiative sert de carotte, le CRA est définitivement le bâton pour quiconque accepterait encore des dons, puisqu’être rémunéré (recevoir une rémunération ou des dons) à un moment semble disqualifier des exemptions "opensource" prévues par le texte.
#2.3
#2.4
et sinon on trouve les premières réactions encore plus tôt que ça:
https://blog.opensource.org/what-is-the-cyber-resilience-act-and-why-its-important-for-open-source/
https://eclipse-foundation.blog/2023/01/15/european-cyber-resiliency-act-potential-impact-on-the-eclipse-foundation/
#2.5
Cyber Resilience Act : une commission du Parlement européen exempte les logiciels libres non commerciaux
https://next.ink/1011/cyber-resilience-act-commission-parlement-europeen-exempte-logiciels-libres-non-commerciaux/
#2.2
#3
Les entreprises qui font leurs choix technologiques en tenant compte d'analyses de risque sur les processus de gestion des incidents sécurité risquent de se détourner des solutions européennes en raison des mauvais standards imposés. De plus, comme le texte se dirige vers une approche nationale plutôt qu'européenne pour cette divulgation forcée et irresponsable des vulnérabilités, il semble clair que les analyses de risque varieront sur base des pays d'origine des solutions.
Des pays européens ayant des législations équivalentes à la "loi de programmation numérique" auront de-facto des évaluations de risque plus élevées dans un tel contexte.
On a vu ces dernières années une levée de boucliers face aux logiciels russes, mais une situation similaire pour les logiciels européens (et plus particulièrement français) n'est pas à exclure.
L’Europe se fourvoie monumentalement avec ce texte et ce n'est pas la peine de crier sur tous les toits qu'on veut améliorer la confiance dans le numérique si on fait sans cesses des textes qui invitent à la méfiance.
#3.1
Il faut donc se poser sérieusement la question de la bienveillance de pays qui préfèrent ne pas être informés de certaines vulnérabilités si ça peut leur permettre d'avoir une connaissance exclusive sur d'autres vulnérabilités.
Et si ce qui les gène, c'est que les autres pays d'U.E. soient au courant, c'est peut-être bien parceque leur obligation de divulgation dans les délais imposés est dangereuse à la base.
Mention spéciale pour l'exemption des logiciels commerciaux liés à la sécurité nationale qui n'auront pas les obligations et pourront continuer à faire n'importe quoi...