La loi européenne sur la cyber-résilience mettra les responsables informatiques à l’épreuve

Contrairement à la plupart des réglementations en matière de cybersécurité, la loi européenne sur la cyber-résilience concerne la sécurité des produits plutôt que les processus ou la certification, étendant le marquage CE du côté physique des produits aux logiciels, micrologiciels, services backend et tout ce qui dispose d’une connexion réseau. Il code les meilleures pratiques existantes, impose des cycles de vie minimum de support produit et pourrait signifier développer des relations plus solides avec les projets open source sur lesquels s’appuie votre organisation. Et cela est assorti d’une date limite : d’ici le 11 septembre de cette année, vous devez mettre en place des processus de signalement des vulnérabilités et des incidents.

Même pour les organisations qui utilisent déjà des factures de matériel logiciel (SBOM), suivre les nouvelles obligations de l’ARC de signaler une vulnérabilité activement exploitée dans un produit dans les 24 heures et devoir fournir un rapport complet dans les trois jours peut s’avérer difficile à respecter.

Bien que presque tout le monde dans le récent rapport sur la gestion des artefacts de Cloudsmith, une alternative SaaS, génère des SBOM, seul un quart le fait automatiquement plutôt que manuellement ou à la demande. Plus de la moitié ont déclaré qu’un rapport complet nécessiterait beaucoup de temps et d’efforts, tandis que moins d’un tiers étaient très confiants de pouvoir réussir le type de vérification inattendue de la chaîne d’approvisionnement en logiciels qu’exigeront les vérifications ponctuelles de l’ARC.

« De nombreuses organisations n’appliquaient pas les meilleures pratiques en matière de chaîne d’approvisionnement logicielle », déclare Alison Sickelka, vice-présidente des produits chez Cloudsmith. « Et cela se reflète dans le fait que les gens doivent se démener pour comprendre comment ils vont générer des SBOM, faire des rapports et mettre tout cela en place à temps. » Parfois considérées comme un fardeau ralentissant le développement logiciel, les SBOM et l’auditabilité sont désormais des nécessités, ajoute-t-elle.

Cependant, pour de nombreux DSI, l’ARC n’est même pas sur leur radar. « Ils peuvent penser qu’il s’agit presque d’un exercice de cases à cocher », explique Oli Venn, responsable de l’ingénierie chez le fournisseur de sécurité WatchGuard, plutôt que d’une réglementation générale avec des exigences de reporting agressives couvrant l’ensemble du cycle de vie du produit, depuis la planification et la conception jusqu’au support et à la maintenance.

« Si vous êtes un fournisseur quelconque, ou si vous fabriquez ou fournissez un système numérique, qu’il s’agisse de thermostats intelligents, de machines à café ou de tout autre objet pouvant être connecté à Internet ou à un réseau, cela relève de la réglementation », ajoute-t-il. « Si des développeurs et des consommateurs l’utilisent d’une manière ou d’une autre, alors vous tombez sous le coup de l’ARC. »

Sphères d’influence

L’ARC s’applique aux logiciels et appareils tels que les téléphones mobiles, les systèmes d’exploitation intégrés, les bases de données, les jeux, les équipements réseau, les appareils IoT et même les billets livrés via une application. Cependant, cela ne s’applique pas à l’open source non commercial, mais les fondations open source ont certaines obligations. Et si votre produit comprend des éléments open source, vous êtes responsable de vous assurer qu’ils sont conformes. Le SaaS pur n’est pas couvert, mais les logiciels clients, les appareils ou les appareils qui utilisent le SaaS comme backend le sont.

« Le CRA inclut des composants back-end, ce que nous appelons des solutions de traitement de données à distance, si votre produit comporte un côté serveur », explique Daniel Ehrenberg, ingénieur en normes au sein du comité Cyber ​​EUSR de l’ETSI.

Les produits déjà en vente dans l’UE ne sont pas tenus de se conformer pleinement à la CRA, à moins qu’ils ne soient mis à jour de manière significative, même si les entreprises doivent toujours signaler les incidents et les vulnérabilités. Pourtant, la loi reconnaît qu’il n’est peut-être pas possible d’y remédier. Autrement, les seuls produits exemptés sont ceux déjà couverts par des réglementations plus strictes dans des secteurs comme l’automobile et le médical.

Sécurité des produits

L’ARC affirme que les produits numériques doivent être sécurisés dès leur conception et par défaut, et ne peuvent pas être livrés avec des vulnérabilités connues telles que des mots de passe par défaut évidents qui peuvent être exploités. Ils doivent également pouvoir être mis à jour si de telles vulnérabilités sont découvertes ultérieurement, et minimiser leur impact en limitant la surface d’attaque et en protégeant la confidentialité et l’intégrité grâce au cryptage et à une collecte de données réduite. Cela équivaut à l’obligation pour les logiciels commerciaux de bien les gérer, explique Ehrenberg, avec un processus efficace pour recueillir les rapports de bogues.

« On espérait beaucoup que cela n’arriverait pas, mais ce serait un signal d’alarme pour prendre en compte toutes les exigences, en commençant par une évaluation des risques », dit-il. «Lorsque vous mettez un produit sur le marché, vous devez procéder à une évaluation des risques de cybersécurité et effectuer un audit continu pour connaître vos dépendances actives afin de pouvoir évaluer si vous avez besoin de les mettre à jour.»

Cela inclut les composants des fournisseurs. « Assurez-vous qu’ils restent conformes et signalent toute vulnérabilité en matière de sécurité », explique Venn. Les exigences du SBOM sont raisonnables plutôt que coûteuses, ajoute Nigel Douglas, responsable des relations avec les développeurs chez Cloudsmith. « Avez-vous une visibilité sur les noms et identifiants des packages afin de savoir si la version de votre chaîne d’approvisionnement logicielle et la base de code que les utilisateurs consomment et paient contiennent du code potentiellement malveillant qui va les affecter », dit-il. « L’essentiel est de pouvoir prouver que l’on peut réagir rapidement à un incident. »

Pour l’open source, cela signifie également évaluer les projets sur lesquels vous comptez. « L’ARC exige de connaître et de comprendre l’état de santé des projets et de prendre des décisions éclairées et intelligentes concernant les projets open source que vous utilisez », note Kat Cosgrove, membre du comité directeur de Kubernetes. Les organisations qui découvrent et corrigent les vulnérabilités des projets open source devront y contribuer en amont, souligne Venn. « Ils ne peuvent plus se contenter d’être de simples consommateurs de ces technologies », dit-il. « S’ils veulent l’utiliser, ils doivent faire partie de la communauté. »

Pas comme les autres

Contrairement aux réglementations traditionnelles en matière de cybersécurité, l’ARC ne se concentre pas sur les pratiques de développement de logiciels et les certifications, qui, selon Ehrenberg, pourraient ne pas correspondre aux nouvelles exigences, mais sur le produit vendu. « Avez-vous réalisé un produit qui minimise la quantité de données traitées afin de réduire les risques liés aux données si elles ne sont pas correctement gérées ? demande-t-il. « Protégez-vous les données car elles sont en danger et en transit ? »

Les DSI doivent considérer les produits que leur organisation vend de manière descendante, en examinant comment ils répondent aux exigences de sécurité plutôt que si la façon dont ils sont construits répond à toutes les cases. « C’est un changement de responsabilité », ajoute-t-il. « Vous êtes responsable du produit final, pas seulement de vous assurer que les étapes ont été correctes. »

Les exigences exigent également une assistance produit, des mises à jour et des cycles de vie, dans la plupart des cas pour un minimum de cinq ans de mises à jour de sécurité gratuites, qui feront toutes l’objet d’une déclaration de conformité que les produits numériques nécessiteront à partir de décembre 2027. La déclaration et la documentation devront rester disponibles pendant 10 ans après la mise en vente du produit, mais le SBOM n’a pas besoin d’être public, il suffit d’être disponible pour les autorités de surveillance du marché lorsqu’elles en font la demande.

Les normes en pratique

Différentes classes de produits font l’objet de différents niveaux d’examen. La plupart des produits numériques sont réglementés par défaut dans le cadre de normes horizontales en matière de cybersécurité et de gestion des vulnérabilités, déjà disponibles sous forme de projet auprès des organismes de normalisation européens.

Mais des produits importants tels que les systèmes de gestion des identités, les navigateurs Web, les gestionnaires de mots de passe, les VPN et les routeurs d’accès Internet, ainsi que les produits critiques tels que les hyperviseurs, l’infrastructure PKI, les modules de sécurité matériels et les pare-feu industriels, nécessiteront des évaluations de conformité plus strictes.

Ceux-ci sont couverts par des normes verticales en cours d’élaboration pour analyser des risques spécifiques, qui répertorient les mesures d’atténuation potentielles telles que l’écriture d’un navigateur Web dans un langage sécurisé pour la mémoire. « L’ARC ne vous oblige pas à passer à des langages sécurisés en mémoire, ni à abandonner COBOL ou quelque chose du genre », explique Ehrenberg.

Délais et amendes

En tant que règlement plutôt que directive, l’ARC s’applique sans que les pays européens individuels n’adoptent de nouvelles lois, et les mécanismes permettant son administration sont mis en place cet été. « Les autorités de surveillance du marché se mettent en ligne avec leur capacité d’examiner et d’approuver les choses, puis les différents organismes d’évaluation de la conformité se mettent en ligne », explique Ehrenberg. L’Agence de l’Union européenne pour la cybersécurité (ENISA) gérera la plateforme unique de signalement des vulnérabilités et des incidents activement exploités.

Même si l’ARC s’appliquera pleinement à partir du 11 décembre 2027, son application interviendra progressivement et dépendra de la capacité technique des autorités de surveillance du marché, explique Ehrenberg. Ils peuvent exiger la mise en conformité des produits, restreindre leur vente, voire leur retrait, voire leur rappel, ainsi que prononcer des amendes pouvant aller jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires.

« Il y aura probablement des batailles judiciaires à l’avenir pour interpréter cela », dit Ehrenberg, car certains aspects ont déjà été critiqués pour être trop vagues et faibles. Mais les organisations qui s’appuient sur une application limitée ratent une occasion d’améliorer leurs produits et leur propre sécurité.

Une sécurité tout simplement meilleure

Avec l’augmentation des attaques sur la chaîne d’approvisionnement, les mandats de l’ARC offriront de réels avantages en matière de sécurité en obligeant les entreprises à suivre leur utilisation de l’open source et à informer rapidement les utilisateurs finaux des problèmes, déclare Neil Levine, vice-président directeur des produits chez le fournisseur de cybersécurité Anchore. Il suggère d’adopter les SBOM d’ici septembre pour vous aider à vous conformer aux exigences de déclaration, plutôt que d’attendre la date limite de 2027.

Les DSI avertis peuvent également profiter de cette opportunité pour obtenir les ressources nécessaires pour apporter des améliorations. « La plupart des DSI voudraient faire ces choses de toute façon, mais ils n’ont tout simplement pas la bande passante », explique Venn. « C’est donc probablement un outil qui leur permet de s’adresser au conseil d’administration et de dire qu’ils ont besoin de budget et de temps. »