Interventions sur "vulnérabilité"

Cet article renforce les exigences de transparence qui s'appliquent aux éditeurs de logiciels, en contraignant ces derniers à informer l'Anssi et leurs utilisateurs en cas de vulnérabilité significative ou d'incident informatique susceptibles d'affecter un de leurs produits. Le groupe Horizons et apparentés a déposé plusieurs amendements en commission et en séance afin d'apporter des précisions ou d'en demander. Ainsi, nous avons déposé un amendement, retravaillé à l'issue de l'examen du texte en commission, visant à définir l'éditeur de logiciels de manière claire dans le projet ...

Nous partageons l'objectif visé mais, aux termes de l'article 34, il est de la responsabilité des éditeurs de logiciels de déclarer leurs vulnérabilités. Or, ceux-ci ne sont pas habilités à apprécier l'atteinte à la sécurité nationale, qui est une prérogative de l'État. En commission, nous avons néanmoins souhaité mieux définir ce qu'est un incident informatique et préciser le caractère significatif des incidents et vulnérabilités visés, par trois amendements que nous allons examiner dans quelques instants. Par ailleurs, j'émettrai un avis favo...

La question qui se pose ici est celle de savoir si les éditeurs de logiciels transmettront les informations relatives aux vulnérabilités que présentent leurs propres produits, sachant, comme vient de l'expliquer notre collègue Bernalicis, que le public risque alors de se montrer peu enclin à les utiliser. Par conséquent, si l'on ne prévoit aucune sanction pour non-respect de l'obligation de signaler les failles de sécurité, le plus vraisemblable est que ces dernières ne seront pas rendues publiques ni communiquées à l'Anssi. Aus...

...tre discussion, de maintenir un équilibre entre, d'une part, la sécurité nationale et, d'autre part, nos libertés fondamentales, notamment la liberté d'agir et d'entreprendre, qui nous incite à limiter les contraintes pesant sur nos entreprises. En l'espèce, je souhaite que nous nous en tenions au dispositif prévu dans le texte, à savoir qu'en cas de non-respect de l'injonction de communiquer les vulnérabilités constatées à l'Anssi, celle-ci pratiquera le fameux name and shame. Au demeurant, aucune entreprise n'a intérêt à les dissimuler : son intérêt commercial est que le produit qu'elle vend fonctionne. Cela étant dit, le dispositif est au début de son existence : rien ne nous empêche de le faire évoluer par la suite si l'on considère qu'il est insuffisant. En tout état de cause, j'estime, po...

...pliquant les différentes autorités nationales concernées, à l'instar de ce que nous avons fait avec le règlement général sur la protection des données (RGPD). En outre, dans le cadre européen, la menace de sanction est beaucoup plus forte du fait de l'extraterritorialité. Sans être hostile sur le principe à la logique de ces amendements, je pense qu'il serait bon que nous soyons au clair sur les vulnérabilités, les backdoors – sans parler de Palentir, entouré d'une certaine opacité –, et que le bon vecteur en la matière est NIS 2. Si jamais la directive faisait l'impasse sur le sujet, alors nous l'inscririons dans le droit national afin de donner à l'Anssi un pouvoir de sanction administratif – je rejoins ici ce qu'a dit Ugo Bernalicis : les sanctions administratives ne sont pas l'apanage des a...

Il ne faut oublier personne car il y va de la portée de la coercition pouvant peser sur les éditeurs de logiciels. Puisque vous avez refusé les sanctions financières pour défaut de communication d'une vulnérabilité, il faut à tous le moins que les éditeurs en informent les utilisateurs ou, à défaut, l'Anssi. Il ne faudrait donc pas que la rédaction actuelle rate la cible, et c'est la raison pour laquelle, en commission, je faisais partie de la minorité qui aurait préféré que l'on se réfère à tous les utilisateurs. Il n'y a pas toujours de consensus dans la fabrique de la loi, et il arrive que le débat reco...

...r il s'agit d'un amendement très simple ayant pour objet de contraindre les éditeurs de logiciels à transmettre dans les plus brefs délais les informations nécessaires pour assurer la sécurité des données sensibles. L'amendement vise ainsi à introduire la notion d'immédiateté à l'article 34, en imposant aux éditeurs d'agir « dès que » leurs produits sont affectés ou susceptibles de l'être par une vulnérabilité significative.

En complétant les propos de notre collègue Chassaniol, je répondrai aussi à l'amendement n° 847 rectifié. Nous avons une vraie difficulté de temporalité. S'il faut en effet que l'Anssi ne traite pas les éditeurs de manière discriminatoire, ce qui suppose un encadrement, il faut aussi qu'un correctif soit apporté à chaque vulnérabilité car, dans le cas contraire, des attaquants seraient à même de s'en saisir : c'est ce que Mme Ménard soulevait en proposant l'ajout des mots « dès que ». Or, si nous avons besoin de correctifs, leur développement peut être plus ou moins long, ce qui nécessite de laisser de la souplesse à l'Anssi. Par ailleurs, comme je viens de le dire, il nous faut aussi garantir que les décrets d'application de...

Il est favorable. Ces amendements s'inscrivent dans la continuité de nos travaux en commission et permettraient d'encadrer la fixation du délai d'information sans nuire à l'opérationnalité de la correction des vulnérabilités.

Nous restons sur le même thème. Ces amendements visent à obliger l'Anssi à enjoindre aux éditeurs de logiciels d'informer leurs utilisateurs en cas de vulnérabilité ou d'incident compromettant la sécurité de leurs systèmes d'information. Collègues, nous avons, tous, certainement, été déjà victimes de fuites de mot de passe, parfois même sans que nous en ayons été informés par les entreprises concernées. Or, aux termes du projet de loi, monsieur le ministre délégué, vous souhaitez qu'il soit simplement possible d'enjoindre aux éditeurs de logiciels de commun...

Nous sommes ici dans un cas de figure où une faille de vulnérabilité a été constatée et, je l'espère, communiquée à l'Anssi. Celle-ci doit donc, aux termes des amendements que nous venons d'adopter, fixer un délai à l'éditeur concerné pour qu'il fournisse un correctif et informe ses utilisateurs professionnels de cette faille. Voilà où nous en sommes. Or imaginons que, patatras, l'éditeur du logiciel ne fasse pas ce que lui a demandé l'Anssi : dans ce cas, l'Agenc...

...nous fait revenir à la discussion précédente –, celles-ci dépendant de la taille de l'entreprise, de ses relations avec l'Anssi, voire avec l'État, ou encore de la présence en son sein de personnes ayant travaillé à l'Anssi par le passé : les choses de la vie, en somme. Voilà pourquoi nous préférerions nous prémunir contre la décision potentiellement arbitraire de publier ou de ne pas publier une vulnérabilité, alors même que l'Anssi – une fois de plus je ne fais que reprendre les termes du texte et des amendements que nous examinons – aurait déjà enjoint à l'éditeur de le faire.

J'estime pour ma part qu'une publication obligatoire rigidifierait trop le texte. Comme précédemment, il faut laisser un peu de latitude à l'Anssi pour apprécier les vulnérabilités et prendre ses décisions en conséquence. En commission, nous avons adopté un amendement de notre collègue Belhamiti visant à ce que le délai d'information des utilisateurs soit déterminé par l'Anssi. Et nous venons d'adopter les amendements n° 1634 et 1673 qui viennent préciser que ce délai dépend de l'urgence, des risques pour la sécurité nationale – je rappelle à nouveau que nous examinons une...

Une fois de plus, votre raisonnement ne tient pas. Nous sommes dans le cas où un éditeur, après avoir été enjoint par l'Anssi d'avertir ses utilisateurs professionnels d'une vulnérabilité dans certains délais et de fournir le correctif adapté, ne le fait pas. Or si elle le lui a demandé, c'est que c'était pertinent, ou alors c'est que quelque chose ne tourne pas rond dans ma tête ou dans le raisonnement.

L'article 34 vise à permettre à l'Anssi de publier les vulnérabilités d'une entreprise. Il s'agit non seulement d'une méthode contestable, mais qui est, en outre, de nature à mettre en danger une entreprise en l'exposant potentiellement à d'autres attaques. En effet, ce serait une occasion en or pour les hackers : on leur offrirait sur un plateau d'argent une voie d'entrée dans les systèmes d'information. Ils s'en donneraient à cœur joie, puisqu'il leur suffirait ...

Attendre que la vulnérabilité soit résorbée annulerait tout l'intérêt du dispositif,…

Le débat montre bien la nécessité de définir ou de préciser les contours de l'article. L'amendement vise à préciser l'alinéa 8 en prévoyant qu'un référentiel définira les critères permettant « l'évaluation objective » – j'insiste sur ce terme – « du caractère significatif » des vulnérabilités et incidents, l'article ne faisant référence, en l'état, qu'à « des standards internationaux communément admis ». Il semble en effet difficile de demander à des entreprises de respecter certains critères de protection sans que ceux-ci soient clairement définis.

L'amendement tend à réécrire un alinéa que j'ai déjà complété en commission : l'exposé des motifs de mon amendement précisait, que parmi les standards internationaux, figure le CVSS – système standardisé de notation de vulnérabilité.

La notion de standards internationaux n'étant pertinente qu'en matière de vulnérabilités, mon amendement tend, comme l'a indiqué M. le ministre délégué, à préciser qu'ils ne s'appliquent pas aux incidents.