Table of Contents
La LPM 2024-2030 oblige désormais tous les éditeurs distribuant du logiciel en France à notifier leurs vulnérabilités significatives à l’ANSSI et aux utilisateurs.
On pourrait penser que la Loi de Programmation Militaire ne concerne que les corps d’armée, mais loin s’en faut. La nouvelle itération de la LPM amène son lot d’obligations pour certains acteurs du civil, dont les éditeurs de logiciels.
C’est quoi, la LPM 2024-2030 ?
La Loi de Programmation Militaire (LPM) est une loi qui fixe les dispositions relatives à la défense nationale, telles que les dépenses militaires. La dernière édition en date a été publiée au Journal Officiel le 1 Août 2023, et porte sur les 7 années suivantes, soit 2024 à 2030. Le texte officiel de la LPM est disponible sur Légifrance.
Quel est le rapport avec les éditeurs de logiciels nous direz-vous ? C’est bien simple : le volet cybersécurité amène son lot de nouveautés, dont une qui concerne directement tous les éditeurs qui distribuent du logiciel en France. Oui, tous.
Éditeurs de logiciels : une obligation de notifier toutes les vulnérabilités significatives à l’ANSSI…
L’Article 66 de la LPM 2023 introduit un nouvel article dans le Code de la défense, qui répond au doux nom de L. 2321‑4‑1. En voici les premières lignes :
“En cas de vulnérabilité significative affectant un de leurs produits ou en cas d’incident informatique compromettant la sécurité de leurs systèmes d’information et susceptible d’affecter significativement un de leurs produits, les éditeurs de logiciels notifient à l’autorité nationale de sécurité des systèmes d’information cette vulnérabilité ou cet incident ainsi que l’analyse de ses causes et de ses conséquences. […]” –Code de la Défense, Article L. 2321‑4‑1
Pour résumer, les éditeurs de logiciels doivent donc :
- notifier l’ANSSI
- en cas de vulnérabilité significative dans un produit
- OU en cas d’incident affectant leur SI et susceptible d’affecter significativement un produit. Un incident est ici entendu comme étant “tout événement compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données”.
- et fournir une analyse des causes et conséquences de la vulnérabilité ou de l’incident
… et aux utilisateurs !
Et puisqu’une bonne nouvelle ne vient jamais seule, la LPM 2023 introduit une double obligation de réponse. À l’ANSSI donc, mais aussi aux utilisateurs du produit affecté par une vulnérabilité significative. Là encore, on ne fait que paraphraser le texte de loi :
“Les éditeurs de logiciels informent les utilisateurs de ce produit, dans un délai fixé par l’autorité nationale de sécurité des systèmes d’information et déterminé en fonction de l’urgence, des risques pour la défense et la sécurité nationale et du temps nécessaire aux éditeurs pour prendre les mesures correctives.”
Il appartient donc à l’ANSSI de fixer le délai de notification aux utilisateurs.
Sous peine de divulgation publique par l’ANSSI
Vous pensiez pouvoir faire l’impasse sur cette obligation de signalement aux utilisateurs sans conséquence aucune ? Raté, la LPM 2023 prend ses dispositions pour sanctionner les mauvais élèves.
“À défaut, l’autorité nationale de sécurité des systèmes d’information peut enjoindre aux éditeurs de logiciel de procéder à cette information. Elle peut également informer les utilisateurs ou rendre publics cette vulnérabilité ou cet incident ainsi que son injonction aux éditeurs si celle‑ci n’a pas été mise en œuvre.” – Code de la défense, Article L. 2321‑4‑1
Autrement dit : si vous ne prévenez pas vos utilisateurs vous-même, c’est l’ANSSI qui le fera à votre place. Cette divulgation publique pourra même être assortie d’une note qui expliquera à vos clients que vous n’avez pas respecté vos obligations. Reste à savoir qui vous préférez pour prévenir vos utilisateurs : vos services juridiques et relations publiques, ou l’ANSSI ?
Quels sont les éditeurs de logiciels concernés ?
Disons les choses clairement : sont concernés TOUS les éditeurs qui conçoivent ou distribuent un produit logiciel en France (ou font concevoir ou distribuer). Peu importe la taille de l’entreprise, l’emplacement de son siège social, que le logiciel soit distribué SaaS ou On-Prem, à titre onéreux ou gratuit.
La LPM 2023 est on ne peut plus clair sur le sujet :
“Cette obligation s’applique aux éditeurs qui fournissent ce produit :
- Sur le territoire français ;
- À des sociétés ayant leur siège social sur le territoire français ;
- Ou à des sociétés contrôlées, au sens de l’article L. 233‑3 du code de commerce, par des sociétés ayant leur siège social sur le territoire français.”
Simple et efficace. Le maillage est fait de manière à ce qu’aucun éditeur avec une présence sur le territoire ne puisse passer au travers, des GAFAM étrangers aux PME locales.
LPM 2024-2030 : à partir de quand ?
La nouvelle LPM a été officiellement adoptée mi-Juillet 2023, et la loi promulguée le 1er Août 2023.
Concrètement, quels sont les délais des obligations de signalement à l’ANSSI pour les éditeurs de logiciels ?
Pour l’instant, il est difficile de répondre à cette question. La LPM 2023 dispose qu’un décret en Conseil d’État fixe les modalités d’application de l’Article L. 2321‑4‑1 concernant les éditeurs de logiciels. Wait & see donc. Mais sans trop s’avancer, on peut déjà supposer que le plus tôt sera le mieux.
Les plus zélés d’entre vous peuvent s’inspirer des obligations de réponse à l’autorité compétente – l’ANSSI en France donc – introduites par la directive européenne NIS2. Après tout, il est peu probable que les délais de notification amenés par la LPM 2023 soient plus stricts que ceux dictés par NIS2, qui s’adresse à des entités aux profils sensibles. Si vous souhaitez creuser la question, vous trouverez une partie dédiée aux obligations de réponse dans notre guide de conformité à la directive NIS2.
Directive NIS2 : Guide de conformité étape par étape
Un guide de 40 pages pour accompagner les RSSI, les DPO et les services juridiques dans l'application de la directive. Aucun blabla, rien que des conseils pratiques et des analyses exploitables.
Et la remédiation des vulnérabilités dans tout ça ?
En l’état, la LPM 2023 n’officialise pas une obligation de corriger les vulnérabilités découvertes, même si c’est bien là l’objectif. Après tout, prévenir l’ANSSI et les utilisateurs n’est pas une finalité en soi.
Dans l’idéal, les éditeurs de logiciels qui prennent connaissance d’une vulnérabilité significative doivent s’atteler à déployer un patch au plus vite. On ne vous fait pas un dessin, mais prévenir le grand public qu’un produit est toujours sujet à une CVE exploitable n’est pas vraiment une bonne idée. Un acteur mal intentionné pourrait décider de passer à l’offensive.
Pour concilier la prévention des utilisateurs et les besoins de sécurité, nous ne pouvons que vous conseiller d’adopter une politique de divulgation responsable.
Notification aux utilisateurs : adoptez la divulgation responsable
La divulgation responsable – ou Responsible Disclosure – est un vaste sujet qui mériterait un traitement complet, mais l’idée générale est simple.
Avec la divulgation responsable, les entreprises et les organisations s’engagent à communiquer aux utilisateurs les éventuelles vulnérabilités dans un produit, mais pas avant qu’un correctif ne soit disponible. Les utilisateurs peuvent alors adopter les mesures de correction, sans être à l’entière merci d’une CVE exploitable.
En France, la LPM 2023 officialise la divulgation au public pour les éditeurs de logiciels et les vulnérabilités significatives. Ils n’ont pas le choix, et doivent prévenir leurs utilisateurs dans les meilleurs délais. Il n’est donc plus possible d’ignorer indéfiniment un problème de sécurité. La divulgation responsable s’impose alors comme un standard en la matière, qui respecte cette injonction de communication tout en tenant compte de la sécurité continue des utilisateurs.
Un processus né de la relation entre les entreprises et les hackers éthiques
La divulgation responsable est un processus, et un état d’esprit, qui est né de la relation entre les entreprises et les hackers éthiques. Si certains hackers souhaitaient exposer les vulnérabilités sur la place publique pour prévenir les utilisateurs, certaines organisations préféraient quant à elles les passer sous silence indéfiniment. En règle générale, aucune de ces deux attitudes ne sert correctement l’intérêt général et la sécurité de tous.
La divulgation responsable s’est alors imposée comme un bon compromis, qui satisfait à la fois l’intérêt général et celui de toutes les parties prenantes. Ce processus est parfois appelé Divulgation Coordonnée des Vulnérabilités, ou CVD pour Coordinated Vulnerability Disclosure. Si vous souhaitez creuser le sujet, nous vous recommandons la lecture d’un des documents de référence en la matière : le CERT Guide to Coordinated Vulnerability Disclosure de l’Université Carnegie Mellon.
Signaler c’est bien, détecter c’est mieux
Tout le monde connaît le proverbe “ce qu’on ignore ne peut pas nous faire mal.” C’est probablement vrai pour tout un tas de choses, mais certainement pas en cybersécurité. En matière de vulnérabilités, ce que vous ignorez risque un jour de vous causer du tort – beaucoup de tort.
Les éditeurs de logiciels sont particulièrement concernés par le sujet, pour la simple et bonne raison qu’ils produisent du logiciel. Tout est dans le nom après tout. Et qui dit logiciel dit vulnérabilités : aucun actif numérique n’est totalement exempt de faille de sécurité, c’est la triste vérité. Pour autant, il n’est pas question d’accepter son sort et de déployer des produits bardés de CVE.
Il faut réduire le risque en identifiant et en remédiant à un maximum de vulnérabilités dans votre SI et vos produits. Il est impératif de prendre conscience de vos propres faiblesses avant les cybercriminels, afin de pouvoir les corriger au plus vite. Il en va de la sécurité de vos utilisateurs, de votre réputation et – disons les choses franchement – de votre gagne-pain.
Lire aussi : Éditeurs de logiciels, la cybersécurité comme levier de confiance
La Sécurité Offensive pour les éditeurs de logiciels
C’est là qu’intervient la sécurité offensive, ou OffSec pour Offensive Security. L’idée derrière les tests OffSec est simple : se mettre dans la peau d’un attaquant pour identifier les vulnérabilités exploitables. Et chez Yogosha, c’est notre spécialité depuis 2015.
Cet article est déjà bien assez long, et nous irons donc à l’essentiel. Nous proposons deux approches distinctes de la sécurité offensive :
- Pentest as a Service: un audit de sécurité lancé en moins d’une semaine et pour un prix fixe. Défrichez la plupart des vulnérabilités dans un produit et évaluez son niveau de sécurité à un instant T, ou planifiez plusieurs pentests tout au long de votre cycle de développement dans le cadre d’une approche DevSecOps.
- Bug Bounty: une chasse aux vulnérabilités en profondeur avec les hackers d’élite de la Yogosha Strike Force. Identifiez les failles les plus critiques avec une logique de paiement aux résultats. Pas de vulnérabilités = pas de dépenses, vous ne récompensez que les résultats exploitables.
Lire aussi : Pentest vs Bug Bounty, quelle approche choisir ?
LPM 2024-2030 et éditeurs de logiciels : ce qu’il faut retenir
La LPM 2024-2030 oblige maintenant tous les éditeurs de logiciels à :
- notifier l’ANSSI
- en cas de vulnérabilité significative dans un produit
- OU en cas d’incident affectant leur SI et susceptible d’affecter significativement un produit
- ET fournir une analyse des causes et conséquences de la vulnérabilité ou de l’incident
- ET informer les utilisateurs du produit dans les meilleurs délais
Tous les éditeurs qui conçoivent et distribuent du logiciel en France sont concernés – oui, absolument tous.
D’ici là, nous conseillons aux éditeurs de logiciels :
- de rédiger un plan de réponse aux incidents si ce n’est pas déjà fait ;
- de mettre en place une politique de divulgation responsable (Responsible Disclosure) ;
- de mettre en place des moyens de détection des vulnérabilités, comme les tests de cybersécurité offensive proposés par Yogosha – à savoir le Pentest as a Service et le bug bounty ;
- de s’intéresser à la gestion des vulnérabilités, et notamment au système CVSS qui permet d’évaluer le risque en assignant un score aux vulnérabilités selon leur impact potentiel. A noter que toutes les vulnérabilités identifiées dans le cadre de nos tests sont automatiquement hiérarchisées par score CVSS sur notre plateforme Vulnerability Operations Center.
