Editeurs de logiciels en mode SaaS Vs. Exigences réglementaires cybersécurité

Editeurs de logiciels en mode SaaS Vs. Exigences réglementaires cybersécurité

Les éditeurs de logiciels en mode SaaS (Software as a Service) sont soumis à des exigences réglementaires de plus en plus nombreuses en matière de cybersécurité (RGPD, DSP2 ….)

Cet article présente les actualités les plus récentes de ces derniers mois : Loi de Programmation Militaire 2024-2030, NIS 2 et DORA.

Applicable depuis le 1er juin 2024, un décret (du 10 mai 2024) précise des exigences issues de la Loi de Programmation Militaire 2024-2030

Code de la Défense : lien
Décret : lien

Notification à l’ANSSI
Quand l’éditeur de logiciel (Saas ou On Premise, gratuit ou payant) détecte une vulnérabilité significative ou un incident de sécurité significatif affectant son produit, il se doit de le notifier à l’ANSSI. La notification doit inclure :

  • Une analyse des causes et des conséquences
  • Les informations nécessaires pour comprendre le problème

Information des utilisateurs
L’éditeur de logiciel doit informer ses utilisateurs des vulnérabilités et incidents dans un délai fixé par l’ANSSI, en fonction de l’urgence et des risques. Ce délai ne peut être inférieur à dix jours ouvrables, sauf en cas de risque pour la défense et la sécurité nationale.

Critères d’appréciation du caractère significatif
Pour décider si une vulnérabilité ou un incident est significatif, l’éditeur de logiciel doit regarder :

  • Le nombre d’utilisateurs concernés par la vulnérabilité ou l’incident affectant le produit ;
  • Le nombre de produits intégrant le produit affecté ;
  • L’impact technique, potentiel ou actuel, de la vulnérabilité ou de l’incident sur le fonctionnement attendu du produit. Selon les fonctionnalités du produit, cet impact est évalué au regard de critères de sécurité tels que la disponibilité, l’intégrité, la confidentialité ou la traçabilité ;
  • Le type de produit au regard de ses usages et de l’environnement dans lequel il est déployé ;
  • L’exploitation imminente ou avérée de la vulnérabilité ;
  • L’existence d’une preuve technique d’exploitabilité ou d’un code d’exploitation

Directive NIS 2

De notre analyse, l’éditeur de logiciel en SaaS est identifié dans les sous-secteurs « hautement critiques » car compris dans « les services d’informatique en nuage ».

En effet, le considérant 33 de la directive NIS 2 explicite ce qu’englobe un service d’informatique en nuage :

« Les modèles de services liés à l’informatique en nuage comprennent, entre autres, les infrastructures services (IaaS), les plateformes services (PaaS), les logiciels services (SaaS) et les réseaux services (NaaS). Les modèles de déploiement de l’informatique en nuage devraient inclure les modèles privés, communautaires, publics et hybrides en nuage. »

Source : https://eur-lex.europa.eu/legal-content/FR/TXT/PDF/?uri=CELEX:32022L2555

Donc l’éditeur de logiciel en SaaS en fonction de son CA et du nombre d’employés sera catégorisé « Entité Essentielle » (161 mesures de sécurité applicables) ou « Entité Importante » (91 mesures applicables).

Même si cette analyse peut être discutée (cela nous est déjà arrivé chez Ad Confirma avec des clients 😉), il ne faut pas oublier que certains clients des éditeurs de logiciels en SaaS seront eux éligibles à la Directive et devront s’assurer que leur prestataires et fournisseurs respectent bien les mesures de sécurité de la NIS 2. Il ne faut donc pas attendre pour se mettre en ordre de bataille et évaluer les écarts par rapport à ces mesures pour construire sa feuille de route.

>>> Cliquez ICI pour découvrir notre méthodologie d’accompagnement à la mise en conformité à la directive NIS 2

De plus, et c’est tout récent, le Règlement d’exécution 2024/2690 (voir article) du 17 octobre 2024 établissant des exigences techniques et organisationnelles relatives à l’application de la directive (UE) 2022/2555 (NIS2) pour des sous-secteurs particuliers :

  • Les fournisseurs de services DNS,
  • Les registres des noms de domaine de premier niveau,
  • Les fournisseurs de services d’informatique en nuage,
  • Les fournisseurs de services de centres de données,
  • Les fournisseurs de réseaux de diffusion de contenu,
  • Les fournisseurs de services gérés,
  • Les fournisseurs de services de sécurité gérés,
  • Les fournisseurs de places de marché en ligne, de moteurs de recherche en ligne et de plateformes de services de réseaux sociaux,
  • Les prestataires de services de confiance.

Ce texte précise un ensemble de mesures de sécurité techniques et organisationnelles applicables sans transposition depuis le 7 novembre 2024 !!

Règlement DORA

Le DORA ou Règlement sur la Résilience Opérationnelle Numérique, est un cadre réglementaire de l’Union européenne visant à renforcer la résilience des entités financières face aux risques numériques, y compris les cyberattaques et les défaillances technologiques.

Bien que le règlement cible principalement les institutions financières, il impose également des exigences aux tiers critiques. Les éditeurs de logiciels qui fournissent des solutions à des entités financières, en particulier en mode SaaS, cloud ou services externalisés, sont concernés par DORA s’ils :

  • Fournissent des logiciels critiques pour les activités des institutions financières.
  • Offrent des services liés aux TIC (technologies de l’information et de la communication), y compris l’hébergement, la maintenance, ou la gestion des données.

Notre article de la semaine dernière présentait de façon synthétique les exigences de sécurité du Règlement DORA (voir article) ; ce que l’on peut retenir pour les éditeurs de logiciels concernés :

  • Une obligation de notification pour tout incident ayant un impact significatif sur les services financiers doit être signalé rapidement aux institutions clientes et, si applicable, aux autorités compétentes via ces institutions.
  • Des tests de résilience encore plus approfondi incluant des simulations de scénarios d’attaque dont les résultats devront être partagés avec leurs clients financiers pour démontrer la robustesse des systèmes.
  • Une obligation de contractualisation avec les entités financières renforcée en incluant des clauses d’audit, de respect des exigences DORA, de définitions des responsabilités en cas d’incident ou de panne, de définition de SLA précisant les niveaux de service, les délais de résolution d’incidents, et les pénalités pour non-respect.
  • Des obligations de rapport et transparence sur la gestion des risques et la résilience des services TIC et des informations sur leurs mécanismes de sécurité et leur réponse aux incidents.

Conclusion

Pour les éditeurs de logiciels, l’année 2024 est riche en réglementation à prendre en compte et à respecter. Néanmoins, toutes ces exigences se recoupent et permettent une conformité multi-réglementaire via la construction d’un plan d’action tronc commun.

Pour arriver à mettre en œuvre ces mesures de sécurité et surtout les faire « vivre » dans le temps afin de démontrer sa conformité à ses clients ou aux autorités de contrôle, chez Ad Confirma, nous sommes convaincus qu’il faut mettre en place un Système de Management de la Sécurité de l’Information (SMSI) basé sur l’ISO 27001 et incluant les référentiels complémentaires applicables.

Cela nous semble être la seule solution pour arriver à adresser l’ensemble des exigences de façon pertinente, opérationnelle et pragmatique dans la durée.

Si vous êtes éditeurs de logiciels et que vous vous intéressez à ces réglementations, ou que vous avez des questions, n’hésitez à prendre rdv avec un consultant expert Ad Confirma.

Publications similaires