Photo d'un immeuble troué de part en partPhoto de Nick Bolton sur Unsplash

Règlement sur la cyber-résilience : les instances européennes en passe de conclure un accord

Cyber résilience 2.0

Avatar de l'auteur
Jean-Marc Manach

Publié dans

DroitSécurité

30/11/2023
10

Photo d'un immeuble troué de part en partPhoto 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 ».

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.

10

Écrit par Jean-Marc Manach

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Des mises à jour disponibles pendant au moins 10 ans

Signaler à l'ENISA, ou aux CSIRT nationaux ?

La sécurité nationale et la réaffectation des amendes

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (10)


Le 30/11/2023 à 11h 51
Le fait que les pays rejettent l'ENISA comme point d'entrée unique, au point d'être en opposition avec une notification en parallèle, indique bien une volonté d'utiliser les notifications par les devs/fournisseurs comme avantage stratégique pour eux-mêmes et non pour organiser la protection de tous les intérêts européens. Avec cette obligation qui met par terre deux décennies de réflexion sur les bonnes pratiques de la divulgation de vulnérabilités, on est juste occupé à alimenter les arsenaux des services de renseignements.

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.
potn Abonné
Le 30/11/2023 à 21h 10
Merci, je me demandais pourquoi ils voulaient tant mettre l'ENISA de côté. C'est maintenant tristement clair...
Le 30/11/2023 à 12h 02
C'était pas avec ça que ça posait problème avec l'open-source ?
Le 30/11/2023 à 13h 09
ça pose pas mal de problèmes pour l'opensource.

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.
Le 30/11/2023 à 15h 23

ragoutoutou

ça pose pas mal de problèmes pour l'opensource.

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.
Les projets open-source sont déjà montés au créneau depuis le mois de juillet dernier quand le texte est sorti du bois : https://magazine.joomla.org/all-issues/august/joomla-and-the-eu-cyber-resilience-act
Le 30/11/2023 à 16h 10

xillibit

Les projets open-source sont déjà montés au créneau depuis le mois de juillet dernier quand le texte est sorti du bois : https://magazine.joomla.org/all-issues/august/joomla-and-the-eu-cyber-resilience-act
J'ai pris les billets les plus récents, pour éviter d'avoir trop de 'oui mais le texte a évolué depuis'...

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/
Modifié le 30/11/2023 à 16h16
Le 01/12/2023 à 17h 17

ragoutoutou

ça pose pas mal de problèmes pour l'opensource.

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.
Cf le brief indiqué en lien dans l'article :
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/
Le 30/11/2023 à 13h 19
Aussi, il me semble que pour l'opensource, c'est IBM et Microsoft qui ont conseillé la commission... en bénéficiant d'un système de certification onéreux et difficile d'accès, ces grandes entreprises pourront prendre de-facto le contrôle de l'écosystème Libre/OpenSource.
Le 01/12/2023 à 09h 41
Un point aussi à considérer, c'est qu'avec une gestion de la signalisation des failles aussi malveillante, il va falloir considérer l’impact sur le rayonnement technologique européen.

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.
Modifié le 01/12/2023 à 09h42
Le 01/12/2023 à 17h 03
Bon, à priori l'accord est passé et si j'ai bien compris l'article d'euractiv, l'ENISA se fait effectivement contourner dans de nombreux cas... on attend le texte final pour avoir les détails.

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...
Modifié le 01/12/2023 à 17h04