Loi sur la cyber-résilience La fin du développement logiciel sans souci
La loi sur la cyber-résilience (également appelée "loi européenne sur la cyber-résilience" ou "loi sur la cyber-sécurité") fait partie du " nouveau cadre législatif " de l'UE avec une approche réglementaire basée sur les risques et fait partie de la "stratégie de cybersécurité" de l'UE pour 2020.
Selon la Commission européenne, la loi sur la cyber-résilience est motivée par la constatation du faible niveau actuel de cybersécurité et de la compréhension insuffisante des risques de cybersécurité sur le marché. De ce fait, des chaînes d'approvisionnement entières sont touchées et peuvent entraîner non seulement de graves perturbations des activités économiques et sociales, mais aussi des situations potentiellement mortelles.
Le Cyber Resilience Act vise donc à réduire les points faibles des produits numériques. En outre, les fabricants doivent garantir la cybersécurité pendant tout le cycle de vie du produit (mais au plus tard pendant une période de cinq ans après la mise sur le marché). Globalement, la transparence de la sécurité des produits logiciels et matériels doit être améliorée.
Ci-dessous, un aperçu de la loi sur la cyber-résilience :
Champ d'application personnel
Avec le Cyber Resilience Act, ce sont surtout les fabricants qui sont mis à contribution. Toutefois, des obligations sont également imposées aux importateurs et aux distributeurs, ce qui est par exemple important pour les produits en marque blanche.
Champ d'application matériel
Sur le plan matériel, différentes conditions sont déterminantes :
Produit contenant des éléments numériques
D'un point de vue matériel, le Cyber Resilience Act couvre les "produits contenant des éléments numériques". Ces "produits contenant des éléments numériques" sont définis de manière très large, à savoir comme suit :
"un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels, destinés à être commercialisés séparément".
Uniquement les produits "en réseau".
Une condition supplémentaire pour l'application du Cyber Resilience Act est que le produit soit "en réseau". Ceci est actuellement défini dans le Cyber Resilience Act comme suit :
"Le présent règlement s'applique aux produits contenant des éléments numériques dont l'utilisation prévue ou raisonnablement prévisible implique une connexion de données logique ou physique, directe ou indirecte, avec un appareil ou un réseau".
La compréhension généralement déduite de cette formulation est que seuls les produits "en réseau" doivent être couverts. Toutefois, le terme de "réseau" peut être quelque peu trompeur, car pour l'application de la loi sur la cyber-résilience, une connexion de données indirecte à un appareil ou à un réseau est également suffisante, de même que l'utilisation prévisible du produit. Les produits qui ne sont pas connectés à un réseau seront donc également couverts par le Cyber Resilience Act. Il suffira, par exemple, qu'un logiciel soit intégré dans une machine conformément à sa destination et que celle-ci communique ou "interagisse" avec d'autres appareils (par exemple dans une chaîne de production).
La question de l'étendue exacte de la réglementation de cette exigence supplémentaire de mise en réseau est certainement sujette à controverse. Toutefois, de nombreux produits devraient être couverts par le Cyber Resilience Act, même s'ils ne sont pas eux-mêmes compatibles avec la mise en réseau. Les logiciels autonomes devraient être régulièrement couverts. C'est ce que montrent par exemple les exemples de produits expressément cités dans le Cyber Resilience Act, à savoir entre autres : les navigateurs, les gestionnaires de mots de passe et les logiciels antivirus.
Exceptions pour SaaS, services et secteurs spécifiques
Les offres SaaS sont exclues du Cyber Resilience Act. Les services ne sont pas non plus couverts par le Cyber Resilience Act. Les solutions dites de "transmission de données à distance" ne sont pas couvertes par l'exception (et relèvent donc du Cyber Resilience Act). L'objectif est notamment d'éviter que le champ d'application du Cyber Resilience Act ne soit contourné en transformant des produits classiques avec des éléments numériques de telle sorte que certaines parties soient désormais conçues comme SaaS. Pour les offres SaaS, la directive NIS2 (directive UE 2022/2555) ou la loi transposant la directive NIS2 dans le droit national ("NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz" ou la BSIG ainsi adaptée) peut toutefois s'appliquer.
Sont également exclus du champ d'application certains produits auxquels s'appliquent des réglementations sectorielles spécifiques, notamment les dispositifs médicaux relevant du MDR (règlement 2017/745) ou du IVDR (règlement 2017/746), le règlement 2018/1139 dans le domaine de la sécurité aérienne et le règlement 2019/2144 dans le domaine des véhicules à moteur.
Il convient toutefois d'examiner attentivement les exceptions sectorielles spécifiques. Souvent, il existe d'autres produits que ceux couverts par les réglementations sectorielles spécifiques. Jusqu'à présent, c'était un résultat souhaitable, car cela permettait d'éviter les exigences réglementaires et d'économiser des efforts. Mais cela pourrait changer avec la loi sur la cyber-résilience. Exemple : jusqu'à présent, le seuil d'un dispositif médical selon le MDR n'était parfois délibérément pas franchi, de sorte qu'il n'existait qu'un simple "produit de bien-être" pour lequel les nombreuses exigences réglementaires du MDR ne devaient pas être respectées. Or, un tel "produit de bien-être" peut être "certifié" par le Cyber Resilience Act. De même, un produit accessoire qui n'était pas couvert par les réglementations sectorielles peut désormais être soumis au Cyber Resilience Act.
Classes de risque
Le Cyber Resilience Act fait partie du New Legislative Framework avec une approche basée sur les risques. En conséquence, on distingue quatre classes de risque pour les produits contenant des éléments numériques. Les produits de toutes les classes de risque doivent respecter des exigences dites de base , qui sont réglées plus en détail dans l'annexe I du Cyber Resilience Act. En fonction de la classe de risque exacte à laquelle appartient un produit contenant des éléments numériques, d'autres exigences doivent être respectées.
On distingue les quatre classes de risque suivantes:
"Produits contenant des éléments numériques" normaux / non critiques
"Produits critiques contenant des éléments numériques" de classe I
"Produits critiques contenant des éléments numériques" de la classe II
"Produits hautement critiques contenant des éléments numériques".
"Produits simples avec éléments numériques"
La classe de risque la plus basse est uneclasse "fourre-tout". Tous les produits contenant des éléments numériques qui n'entrent pas dans l'une des autres classes de risque doivent être affectés à cette classe de risque la plus basse. Selon les calculs de la Commission européenne, environ 90 % des produits relèveraient de cette classe de risque.
"Produits critiques contenant des éléments numériques de la classe I".
L'annexe de la loi sur la cyber-résilience définit plus précisément quels produits relèvent de la classe I des produits critiques. Sont notamment mentionnés : Les gestionnaires de mots de passe, les navigateurs autonomes et intégrés, les systèmes VPN, les logiciels d'accès à distance et de partage de données ainsi que la gestion des mises à jour et des correctifs.
"Produits critiques contenant des éléments numériques de classe II".
Les produits critiques de classe II sont également mentionnés dans l'annexe de la loi sur la cyber-résilience. Il s'agit notamment des systèmes d'exploitation pour serveurs, ordinateurs de bureau et appareils mobiles, des éléments de sécurité, des systèmes d'exécution de conteneurs qui prennent en charge l'exécution virtualisée de systèmes d'exploitation et d'environnements similaires, des infrastructures à clé publique et des émetteurs de certificats numériques, des cartes à puce et des appareils IIoT (Internet des objets).
"Produits hautement critiques contenant des éléments numériques".
La Commission européenne déterminera quels sont les produits hautement critiques contenant des éléments numériques par le biais d'actes juridiques délégués. Les critères déterminants sont notamment l'importance des produits pour la résistance de l'ensemble de la chaîne d'approvisionnement et l'utilisation d'installations essentielles au sens de la directive NIS2 (donc d'infrastructures critiques).
Procédure d'évaluation de la conformité
Le marquage CE ne peut être apposé qu'après la réussite de la procédure d'évaluation de la conformité, qui est réglementée plus en détail dans le Cyber Resilience Act et ses annexes.
Dans le cadre de la classe de risque la plus basse, les fabricants peuvent effectuer eux-mêmes la procédure d'évaluation de la conformité et établir ou signer eux-mêmes la déclaration de conformité UE figurant en annexe du Cyber Resilience Act.
Dans les cas des classes de risque moyen et élevé, les possibilités d'évaluation de la conformité sont limitées. La procédure dite d 'examen UE de type et "l'évaluation de la conformité sur la base d'une assurance qualité complète" sont alors disponibles. Dans ce cas, il peut notamment être nécessaire de faire appel à un organisme externe, à savoir un organisme notifié (Notified Body). Cet organisme notifié peut alors confirmer la conformité - ou la suspendre, la limiter ou la retirer, ce qui limiterait ou supprimerait la possibilité de commercialiser le produit.
Présomption de conformité selon le Cyber Security Act
Le Cyber Resilience Act s'inscrit dans une initiative législative de grande envergure. Outre le Cyber Resilience Act, il faut par exemple tenir compte du Cyber Security Act.
Sur la base du Cyber Security Act, qui est déjà en vigueur depuis 2019, il devient possible de délivrer ou d'obtenir des certificats de cybersécurité. Si un tel certificat de cybersécurité est disponible à l'égard d'un produit donné contenant des éléments numériques, une présomption de conformité s'applique conformément au Cyber Resilience Act. La procédure d'évaluation de la conformité ne doit alors plus être effectuée dans son intégralité, ce qui permet un gain de temps et d'efforts considérable.
Selon le Cyber Security Act, des " schémas " sont "adoptés". Ces schémas servent à leur tour de base pour les certifications de sécurité à effectuer par des entreprises spécialisées dans ce type de certification.
Jusqu'à présent, l'élaboration de trois schémas a été lancée :
European Union Common Criteria Scheme (EUCC)
European Union Cybersecurity Certification Scheme on Cloud Services (EUCS) (système de certification de cybersécurité de l'Union européenne pour les services en nuage).
Cybersécurité des réseaux 5G (EU5G).
Aucun de ces schémas n'est toutefois achevé ou adopté.
Obligation d'information et de mode d'emploi pour les utilisateurs
Neuf informations doivent obligatoirement accompagner tout produit contenant des éléments numériques. Parmi ces informations, on trouve des données "simples", comme le nom du fabricant et son adresse électronique.
Toutefois, il convient également d'indiquer toutes les circonstances connues ou prévisibles liées à l'utilisation prévue du produit contenant des éléments numériques ou à sa mauvaise utilisation raisonnablement prévisible, susceptibles d'entraîner des risques importants en matière de cybersécurité. Il conviendra de réfléchir très attentivement à la question de savoir quelles indications peuvent être fournies ici de manière judicieuse et sans risque supplémentaire.
SBOM / nomenclature de logiciels
La nouvelle obligation de savoir "si et, le cas échéant, où la nomenclature des logiciels peut être consultée" aura également une portée considérable. L'obligation d'établir une nomenclature de logiciels, c'est-à-dire la SBOM (Software Bill of Material), est donc implicitement incluse. Cette nomenclature logicielle est définie comme suit :
"nomenclature logicielle" un enregistrement formel des détails et des relations de la chaîne d'approvisionnement des composants inclus dans les éléments logiciels d'un produit contenant des éléments numériques ;
En fin de compte, tous les composants tiers doivent donc également être représentés. La raison en est compréhensible : Si une faille de sécurité est découverte dans un composant tiers (par exemple une bibliothèque logicielle courante du domaine open source, comme récemment en ce qui concerne la glibc), chaque entreprise doit pouvoir déterminer si cette bibliothèque logicielle est contenue dans son propre produit - et si possible chaque utilisateur également. Dans la pratique, l'établissement d'une telle liste et sa mise à jour sont toutefois liés à un travail considérable. Souvent, cela implique d'adapter les contrats avec les fournisseurs et de modifier les processus internes. Même pour les produits logiciels les plus simples, cette liste peut prendre une ampleur considérable.
Exception pour les logiciels open source ?
Ce n'est que récemment, en raison de négociations plus approfondies sur le Cyber Resilience Act, qu'une réglementation sur les logiciels open source (OSS) a été intégrée dans un document de compromis comme suit :
"This Regulation applies to free and open-source software only when made available on the market in the course of a commercial activity".
(Art. 2 n° 3a Compromise Draft)
Selon cette disposition, il est essentiel de savoir s'ily aune "activité commerciale" en ce qui concerne le logiciel libre. Dans les considérants, qui peuvent uniquement être utilisés pour interpréter le Cyber Resilience Act, mais qui ne sont pas juridiquement contraignants, on trouve les lignes directrices suivantes pour répondre à la question de savoir s'il y a une activité commerciale :
"Par exemple, un modèle de développement entièrement décentralisé, dans lequel aucune entité commerciale unique n 'exerce de contrôle sur ce qui est accepté dans la base de code du projet, devrait être considéré comme une indication que le produit a été développé dans un cadre non commercial.
D'autre part, lorsque le logiciel libre et open source est développé par une seule organisation ou par une communauté asymétrique, lorsqu'une seule organisation génère des revenus à partir d'utilisations connexes dans le cadre de relations commerciales, il convient de considérer qu'il s'agit d'une activité commerciale.
De même, lorsque les principaux contributeurs à des projets libres et open source sont des développeurs employés par des entités commerciales et lorsque ces développeurs ou l'employeur peuvent exercer un contrôle sur les modifications acceptées dans la base de code, le projet devrait généralement être considéré comme étant de nature commerciale".
Ces exceptions risquent d'être insuffisantes ou d'entraîner des dommages collatéraux importants dans le domaine de l'open source si les règles et les "lignes directrices" restent en l'état. Des questions de délimitation se posent par exemple lorsque des organisations à but non lucratif reçoivent des dons ou lorsque des entreprises commerciales emploient des collaborateurs pour programmer des logiciels open source au bénéfice général.
Exceptions pour les salons et à des fins de test
Le Cyber Resilience Act prévoit que les logiciels puissent continuer à être utilisés pour des foires, des expositions et des présentations, même sans évaluation complète de la conformité.
En outre, la mise à disposition non réglementée de logiciels à des fins de test doit rester possible si elle n'a lieu que pendant une période raisonnable.
Nouvelles obligations de notification
Le Cyber Resilience Act prévoit en outre des obligations de notification. En vertu de cette loi, le fabricant doit informer l'ENISA(agence de cybersécurité de l'UE) immédiatement, et en tout cas dans les 24 heures, après avoir pris connaissance de vulnérabilités activement exploitées.
En outre, un fabricant doit signaler immédiatement, et en tout cas dans les 24 heures, tout incident affectant la sécurité du produit.
En outre, le fabricant peut non seulement être tenu de notifier l'ENISA, mais également d'informer les différents utilisateurs du produit (c'est-à-dire les utilisateurs finaux). Outre les aspects liés à la manière de communiquer, cela peut représenter une charge de travail considérable, selon le produit concerné.
Obligation d'entretien à long terme
Contrairement à la législation allemande actuelle (avec des exceptions récentes dans le domaine des produits de consommation), il y a un changement important en ce qui concerne la garantie de l'absence de défaut - du moins dans la mesure où celle-ci est liée aux points faibles de la sécurité informatique.
En effet, en vertu de la loi sur la cyber-résilience, le fabricant est tenu de "traiter" efficacement les vulnérabilités pendant la durée de vie prévue du produit ou pendant une période de cinq ans à compter de la mise sur le marché du produit (la période la plus courte étant retenue). Cela signifie généralement la mise à disposition de mises à jour de sécurité.
Ce qui est remarquable dans cette réglementation, c'est que cette obligation incombe au fabricant et non au vendeur. Selon le type exact de produit concerné, cela peut toutefois conduire à l'introduction de dispositions contractuelles dans la chaîne d'approvisionnement afin d'informer des mises à jour et de pouvoir les diffuser.
Liens avec d'autres "lois" actuelles
Le Cyber Resilience Act doit être "lié" à différents autres règlements de l'UE actuellement à l'état de projet.
En ce qui concerne différentes exigences de base, il faut par exemple tenir compte en parallèle du prochain règlement de l'UE sur la sécurité générale des produits.
Dans la mesure où le produit est également soumis au règlement européen sur les machines, certaines présomptions de conformité s'appliquent également au Cyber Resilience Act en ce qui concerne la protection et la corruption ainsi que la sécurité et la fiabilité des systèmes de commande.
Dans la mesure où il existe un système d'IA à haut risque selon le prochain règlement sur l'IA et que la précision et la robustesse sont confirmées selon le règlement sur l'IA, cet aspect est également considéré comme conforme selon le Cyber Resilience Act. Il est en outre réjouissant de constater que le même organisme notifié (Notified Body), responsable de l'évaluation de la conformité selon le règlement sur l'IA, peut également effectuer des contrôles selon le Cyber Resilience Act. Cela permet de mettre en place une procédure de "guichet unique" pour l'évaluation de la conformité. La condition préalable est bien entendu la désignation correspondante de l'organisme notifié, de sorte que celui-ci puisse également procéder à l'évaluation de la conformité selon le Cyber Resilience Act.
De même, les systèmes EHR sont pris en référence selon le règlement de l'UE sur l'espace européen des données de santé (European Health Data Space - EHDS).
Documentation technique
Il ne faut pas sous-estimer le travail nécessaire à l'élaboration de la documentation technique.
Certains aspects peuvent en outre entraîner des difficultés particulières, voire l'impossibilité d'élaborer une documentation technique. Par exemple, en présence d'un système d'IA à haut risque ou d'un système de DSE, la documentation technique doit être établie en tant que "documentation technique unique". Il ne sera donc pas possible de faire référence à une documentation technique "modulaire" chez les fournisseurs. La réglementation devrait plutôt être comprise comme signifiant que la documentation technique des différents fournisseurs doit également être disponible de manière uniforme chez le fabricant, les détails à ce sujet n'étant pas encore réglés. Comme le montre déjà l'expérience dans le domaine du règlement de l'UE sur les dispositifs médicaux (MDR), la constitution d'une telle documentation technique peut entraîner des difficultés considérables. Il faut notamment tenir compte des intérêts relatifs aux secrets commerciaux et industriels des fournisseurs.
Obligation d'apposer un marquage CE
Tous les produits contenant des éléments numériques doivent être munis d'un marquage CE à partir de l'entrée en vigueur de la loi sur la cyber-résilience. En apposant le marquage CE et en signant au préalable la déclaration de conformité UE , le fabricant assume la responsabilité du produit.
Compte tenu de la définition très large d'un produit contenant des éléments numériques, les jours où un nouveau produit peut être mis sur le marché "comme ça" sont probablement comptés. C'est l'objectif déclaré du Cyber Resilience Act, qui vise à atteindre une "sécurité dès la conception".
Conséquences juridiques
Certaines infractions au Cyber Resilience Act sont passibles d'une amende. Une amende pouvant aller jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, selon le montant le plus élevé, peut être infligée.