Le code généré par l’IA se généralise, y compris dans les endroits où son utilisation est officiellement interdite, introduisant au passage de nouveaux risques. Voici ce que les RSSI peuvent faire pour s’assurer qu’il ne compromet pas la sécurité de l’organisation.
En 2023, l’équipe de la start-up spécialisée dans l’extraction de données Reworkd était soumise à des délais serrés. Les investisseurs entendaient monétiser la plateforme et, pour ce faire, l’équipe devait au préalable migrer de Next.js à Python/FastAPI. Pour accélérer les choses, elle a alors décidé de confier une partie du travail à ChatGPT. Le code généré par l’IA semblait fonctionner, a donc été implémenté directement dans l’environnement de production.Le lendemain matin, une mauvaise surprise attendait l’équipe de Reworkd : « plus de 40 notifications Gmail de plaintes d’utilisateurs, écrit le cofondateur de la start-up Ashim Shrestha dans un post de blog. Tout semblait avoir pris feu pendant la nuit. Aucun de ces utilisateurs ne pouvait s’abonner. »Un bogue sur la ligne 56, générée par l’IA, a provoqué une collision d’identifiant unique au cours du processus d’abonnement, et il a fallu cinq jours pour identifier le problème et le résoudre. Ce bogue, cette « simple erreur de ChatGPT nous a coûté plus de 10 000 dollars », souligne Ashim Shrestha.Bibliothèques hallucinéesSi Reworkd a révélé ouvertement son erreur, de nombreux incidents similaires passent sous les radars. Les RSSI en prennent souvent connaissance dans une réunion à huis clos. Les institutions financières, les systèmes de santé et les plateformes de commerce électronique ont tous rencontré des problèmes de sécurité, car les outils de complétion de code à base d’IA peuvent introduire des vulnérabilités, perturber les opérations ou compromettre l’intégrité des données. De nombreux risques sont associés au code généré par l’IA, des noms de bibliothèques résultant d’hallucinations à l’introduction de dépendances tierces non suivies et non vérifiées. « Nous sommes confrontés aux conditions idéales de déclenchement d’une crise : une dépendance croissante au code généré par l’IA, une croissance rapide des bibliothèques Open Source et la complexité inhérente de ces systèmes, souligne Jens Wessling, directeur technique de l’éditeur Veracode. Il est tout à fait naturel que les risques de sécurité augmentent. »De plus, les outils de complétion de code tels que ChatGPT, GitHub Copilot ou Amazon CodeWhisperer sont fréquemment utilisés en cachette. Une enquête menée par Snyk montre qu’environ 80 % des développeurs font fi des politiques de sécurité de leur organisation, pour intégrer du code généré par l’IA. Cette pratique crée des angles morts au sein des entreprises, ces dernières peinant à atténuer les risques ainsi créés et les problèmes juridiques qui en résultent.A mesure que l’adoption des outils de codage automatisé progresse fortement, la discussion sur les risques qu’ils posent est devenue une priorité absolue pour de nombreux RSSI et responsables de la cybersécurité. Si ces outils sont peuvent accélérer le développement, ils posent également divers problèmes de sécurité, dont certains sont difficiles à détecter.S’assurer que les packages logiciels sont identifiés« Le code généré par l’IA se confond souvent avec le code développé par l’homme, ce qui rend difficile l’identification des risques de sécurité », explique Jens Wessling. Parfois, le code généré automatiquement peut inclure des bibliothèques tierces ou des dépendances masquées, c’est-à-dire des dépendances qui ne sont pas explicitement déclarées. Ces packages logiciels passant sous le radar peuvent échapper aux analyses de code. Or, ils renferment potentiellement des vulnérabilités, sans oublier le nécessaire suivi des patchs de sécurité de ces composants.L’une des solutions consiste à utiliser des outils d’analyse de la composition des logiciels (SCA, Software composition analysis) et de sécurité de la supply chain logicielle, qui permettent d’identifier les bibliothèques utilisées, les vulnérabilités et les éventuels problèmes juridiques et de conformité que ces exploitations peuvent entraîner. « Un SCA bien réglé proposant une analyse en profondeur peut être une solution », dit Grant Ongers, CSO et cofondateur de Secure Delivery. Une solution cependant imparfaite. « Le plus gros problème, c’est que les SCA tendent à inclure des vulnérabilités dans des fonctions de bibliothèques qui ne sont jamais appelées », ajoute-t-il.Le rapport 2024 Dependency Management Report d’Endor Labs souligne que 56 % des vulnérabilités signalées dans les bibliothèques se trouvent dans des dépendances ‘fantômes’ pour les organisations. « Les outils doivent pouvoir donner aux équipes de sécurité une visibilité sur tous les composants logiciels utilisés à des fins de conformité et de gestion des risques », indique Darren Meyer, ingénieur de recherche chez Endor Labs.C’est pourquoi il est important que les organisations disposent d’un inventaire précis de leurs composants logiciels. « Sans cet inventaire, il est impossible d’identifier, et encore moins de gérer, les risques liés aux bibliothèques d’IA ou à toute autre bibliothèque tierce, reprend Darren Meyer. Si vous n’avez pas de moyen d’identifier les bibliothèques d’IA – intégrant des logiciels écrits, publiés et/ou consommés par votre organisation -, alors vous faites potentiellement face à un risque de conformité. »Surveiller les modèles ML communautairesLes organisations s’exposent également à des risques lorsque les développeurs téléchargent des modèles d’apprentissage machine (Machine Learning) ou des jeux de données à partir de plateformes communautaires comme Hugging Face. « Malgré les contrôles de sécurité effectués en entrée et en sortie, il peut arriver que le modèle contienne une porte dérobée qui devient active une fois le modèle intégré », explique Alex Ștefănescu, développeur de logiciels libres au sein de l’Organized Crime and Corruption Reporting Project (OCCRP). « Ce qui peut déboucher sur une fuite de données de l’entreprise exploitant ces modèles malveillants. » Début 2024, la plateforme Hugging Face hébergeait au moins 100 modèles ML malveillants, dont certains étaient capables d’exécuter du code sur les machines des victimes, selon un rapport de JFrog.En ce qui concerne les outils de complétion de code comme GitHub Copilot, Alex Ștefănescu s’inquiète des hallucinations. « Un LLM générera toujours la suite la plus statistiquement probable d’un prompt donné, il n’y a donc aucune garantie réelle qu’il générera un vrai paquet issu de PyPI (le dépôt officiel des codes Python, NDLR) par exemple, après le mot ‘import’. Certains attaquants en sont conscients et enregistrent des noms de paquets sur des plateformes telles que npm (gestionnaire de paquets pour Node.js, NDLR) et PyPI, en remplissant certaines fonctionnalités suggérées par les outils de complétion de code afin de donner l’impression que ces paquets sont légitimes. » Importés dans des applications exploitées en production, ces paquets peuvent évidemment causer de sérieux dommages.Pour faire face à ces risques, les RSSI peuvent établir des protocoles de téléchargement et d’intégration de modèles de ML ou de jeux de données à partir de plateformes externes telles que Hugging Face. Il s’agit notamment de mettre en oeuvre des outils d’analyse automatisée afin de détecter les codes malveillants ou les portes dérobées, de bâtir une politique n’autorisant que les modèles provenant d’éditeurs vérifiés, ou d’effectuer des tests internes dans des environnements isolés.Fuite d’information via les assistants de développementPrès de la moitié des organisations sont préoccupées par les systèmes d’IA qui apprennent et reproduisent des schémas intégrant des informations sensibles, selon l’enquête Voice of Practitioners 2024 de GitGuardian. « C’est particulièrement inquiétant car ces outils suggèrent du code basé sur des modèles entraînés sur des données pouvant, par inadvertance, inclure des informations d’identification codées en dur, par exemple », explique Thomas Segura, auteur de l’enquête chez GitGuardian.Bien qu’il n’y ait pas de solution miracle, les entreprises peuvent prendre quelques mesures pour réduire ce risque. « L’utilisation de systèmes d’IA auto-hébergés, qui ne renvoient pas de données, est une solution efficace », souligne Grant Ongers (Secure Delivery).Les développeurs, mais aussi les équipes data, marketing, etc.Les outils basés sur l’IA ne sont pas uniquement exploités par des équipes composées d’ingénieurs logiciels. « Nous constatons qu’un grand nombre d’outils sont adoptés par les analystes de données, les équipes marketing, les chercheurs, etc. », explique Darren Meyer (Endor Labs).Ces équipes ne développent pas leurs propres logiciels, mais écrivent de plus en plus d’outils assez simples qui exploitent des bibliothèques et des modèles d’IA, de sorte qu’elles ne sont souvent pas conscientes des risques encourus. « Cette combinaison de l’ingénierie de l’ombre et d’une sensibilisation à la sécurité applicative inférieure à la moyenne peut constituer un terrain propice à l’explosion des risques », ajoute Darren Meyer.Pour s’assurer que ces équipes travaillent en toute sécurité, les RSSI doivent nouer des relations avec elles dès le début du processus. Autre piste : la mise en place de programmes de formation adaptés à ces équipes afin de les sensibiliser aux risques potentiels qu’embarquent les outils à base d’IA et les bibliothèques logicielles. « Plutôt que de payer des abonnements à des outils de complétion de code, le secteur devrait investir dans le développement des connaissances de son personnel », tranche Alex Ștefănescu (OCCRP).Des budgets pour la sécurité applicative« Les budgets de sécurité n’augmentent généralement pas au même rythme que le développement de logiciels, et l’adoption de l’IA ne fait que creuser ce fossé », reprend Darren Meyer. La sécurité applicative est donc sous-financée dans la plupart des organisations, alors que l’adoption de l’IA et le développement assisté accélèrent le rythme de création de logiciels. « Un portefeuille d’outils de sécurité de haute qualité aidant à combler ce fossé n’est plus optionnel, pense Darren Meyer. Et si les outils sont essentiels, il en va de même pour le personnel AppSec et ProdSec à même de collaborer efficacement avec les développeurs – y compris les profils atypiques – et comprendre les implications techniques, celles en matière de conformité et de sécurité de l’IA. »Lorsqu’il s’agit d’obtenir des ressources suffisantes pour protéger les systèmes à base d’IA, certains interlocuteurs au sein des organisations peuvent hésiter, considérant qu’il s’agit d’une dépense facultative plutôt que d’un investissement essentiel. « L’adoption de l’IA est un sujet qui divise de nombreuses organisations, certains dirigeants et équipes y étant tout à fait favorables, tandis que d’autres y sont fermement opposés, explique Darren Meyer. « Cette tension peut représenter un défi pour les RSSI et responsables de la sécurité des informations métier. »Les RSSI qui sont conscients des avantages et inconvénients de cet équilibre peuvent essayer de mettre en place des contrôles pour gérer les risques de manière efficace, mais cela peut donner l’impression qu’ils veulent l’innovation s’ils n’expliquent pas correctement leur démarche.L’IA modifiant les pratiques d’écriture de code, l’industrie navigue sur une ligne de crête entre adoption d’une technologie riche en promesses et atténuation des risques qu’elle peut poser. Selon Grant Ongers, le plus important, est d’éviter les deux extrêmes : « soit une dépendance excessive à l’égard d’une IA imparfaite, soit l’ignorance totale de l’IA ».La bibliothèque de Babel est alimentée par l’IAAvec plus de cinq millions de bibliothèques Open Source disponibles aujourd’hui et environ un demi-milliard d’autres, selon des estimations, qui seront publiées au cours de la prochaine décennie, dont beaucoup seront alimentées par l’IA, les organisations sont confrontées à un défi sans précédent dans la gestion des risques de sécurité associés à leurs écosystèmes logiciels.« La communauté entre dans un territoire inconnu, et je pense que les risques doivent être abordés au niveau de l’industrie dans son ensemble pour garantir la sûreté, la sécurité et la qualité des logiciels qui alimentent notre environnement », fait valoir Jens Wessling, directeur technique de l’éditeur Veracode.La manière dont ces questions seront abordées est également importante. À l’heure actuelle, il y a une explosion de fournisseurs de sécurité qui prétendent sécuriser l’IA. Pour des résultats plus ou moins probants. En conséquence, « les organisations peuvent se retrouver sans la visibilité nécessaire pour prendre des décisions éclairées en matière de gestion des risques, et sans les capacités pour agir en fonction de ces décisions », explique Darren Meyer, ingénieur de recherche chez Endor Labs. « Les RSSI ne veulent pas se retrouver dans la situation où ils doivent développer de nouvelles capacités alors qu’une faille a fait la une des journaux – ou pire, lorsque c’est leur organisation qui a été victime de cette faille. »
Le règlement de l’UE visant à renforcer la résilience des organisations financières aux cyberattaques s’appliquera à partir du 17 janvier 2025. Il incombe aux RSSI de s’assurer que leurs organisations sont en conformité avec le nouveau règlement.
Le secteur financier figure parmi les cibles préférées des cybercriminels. Selon le Fonds monétaire international, près d’un cinquième des cyberattaques récentes visaient des entreprises financières, les banques étant les plus ciblées. Pour aider les institutions financières à résister à ces menaces, l’UE a introduit la loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act ou Dora), qui s’appliquera à partir du 17 janvier 2025.Dora vise à renforcer la sécurité des entités financières, traditionnelles ou non, notamment les banques, les entreprises d’investissement, les établissements de crédit, les cabinets d’audit, les agences de notation, ainsi que les fournisseurs de services de crypto-actifs et les plateformes de financement participatif (crowdfunding). Par extension, le règlement s’applique aux fournisseurs de services tiers qui travaillent avec ces entités financières, comme les opérateurs de datacenters et les fournisseurs de cloud.Explorons DoraEn termes simples, cette réglementation a deux objectifs : offrir un cadre complet pour la gestion des risques dans le secteur financier et harmoniser les réglementations en matière de gestion des risques dans l’ensemble de l’UE, car les règles applicables aux organisations financières varient d’un pays à l’autre. L’harmonisation est l’une des plus grandes réussites de Dora, qui « va simplifier les choses pour tout le monde à long terme », estime Joel Brandon, responsable des ventes pour la région EMEA chez ProcessUnity, éditeur spécialiste de la gestion des risques et de la conformité.La législation donne aux entités financières la possibilité de se mettre l’accent sur le renforcement de leur résilience face aux cyber-menaces, ajoute-t-il. Elle encouragera les organisations à améliorer leur posture de sécurité globale et à favoriser la collaboration. « Ce que nous apprécions vraiment dans Dora, c’est l’opportunité qu’elle offre aux entités concernées de se concentrer sur les perturbations des TIC et l’impact qu’elles pourraient avoir non seulement sur leurs propres activités, mais aussi sur l’écosystème plus large dans lequel elles opèrent », analyse Joel Brandon.Toutefois, se conformer au texte d’ici à janvier 2025 est tout sauf une sinécure, et le calendrier apparaît difficile à respecter pour de nombreux RSSI. Si beaucoup ont fait des efforts pour se préparer, il reste encore beaucoup de travail à accomplir. Une petite enquête de McKinsey, réalisée en mars 2024, a révélé que cinq des 16 cadres et responsables de programmes interrogés doutaient de pouvoir respecter le délai fixé par Dora, et que seuls cinq d’entre eux étaient confiants dans leur capacité à se conformer au règlement dans les temps.Des exigences dans 4 domainesEn plus d’intensifier leurs efforts, les entités financières doivent donc définir leurs priorités. « De nombreuses entreprises ne réalisent pas à quel point la conformité à Dora peut être complexe, d’autant plus que le texte implique la collaboration d’un grand nombre de parties différentes de l’organisation, reprend Joel Brandon. Nous constatons que nos clients sous-estiment souvent les ressources et le temps nécessaires, notamment pour la gestion des risques liés aux tiers et la mise en place de systèmes efficaces de signalement des incidents. »Le texte sur la résilience opérationnelle numérique fixe des exigences dans quatre domaines clés : la gestion des risques, la réponse aux incidents, les tests de résilience opérationnelle et la gestion des risques liés aux tiers. En outre, il encourage les entités financières à partager les informations relatives aux cybermenaces, même si cet aspect n’a pas de caractère obligatoire.La première des exigences, la gestion des risques et la gouvernance, fait reposer la responsabilité sur les épaules de l’organe de direction. Il stipule que les membres du conseil d’administration, les dirigeants exécutifs et les cadres supérieurs doivent définir des stratégies solides de gestion des risques et s’assurer de leur mise en oeuvre. En outre, Dora exige que tous les décideurs se tiennent au courant des derniers risques cyber. En cas de non-respect de ces obligations, les membres du conseil d’administration et les dirigeants peuvent être tenus personnellement responsables.Répertorier et classifier les incidentsDans ce contexte, le rôle des RSSI, qui consiste à fournir aux parties prenantes des informations sur les tendances en matière de sécurité, devient de plus en plus important. Ils doivent offrir des informations claires à des publics non techniques et s’assurer que tout le monde comprend les risques encourus. A la fois un défi, mais aussi une opportunité de faire prendre conscience de l’importance de leur rôle dans l’organisation. « Une fois que les membres du conseil d’administration et les autres dirigeants seront tenus pour responsables, ils prendront la sécurité plus au sérieux », explique Sagie Dulce, vice-président de la recherche chez Zero Networks, spécialiste de la protection des réseaux.La règlementation exige également que les entités financières « identifient, suivent, enregistrent, catégorisent et classent les incidents liés aux TIC en fonction de leur priorité et de leur gravité et en fonction de la criticité des services touchés », peut-on lire dans le document. L’impact d’un incident est déterminé sur la base de plusieurs critères, dont le nombre et l’importance des clients affectés, la durée de l’incident, son étendue géographique, les pertes potentielles de données, la criticité des services affectés et, enfin, les coûts et pertes directs et indirects.Trois natures de notifications d’incidentsLorsque des incidents critiques se produisent, les organisations doivent, par ailleurs, en informer les autorités compétentes. Trois notifications sont prévues : une initiale qui reconnaît l’incident, un rapport intermédiaire suivi de notifications mises à jour chaque fois que de nouvelles informations sont disponibles pour expliquer comment l’incident est géré, et un rapport final qui examine la cause de l’incident, son impact réel et les mesures d’atténuation prises par l’organisation.Un autre aspect essentiel du texte réside dans l’obligation de tester régulièrement les systèmes. Les évaluations de vulnérabilité et les tests basés sur des scénarios d’incidents doivent être effectués une fois par an, tandis que les tests de pénétration basés sur des menaces peuvent, eux, être réalisés tous les trois ans.Dora s’attaque aux risques liés aux tiersMais ce qui est remarquable dans ce texte, c’est qu’il ne s’applique pas seulement aux entités financières, mais également aux fournisseurs de services tiers. Or, selon l’enquête de McKinsey, la gestion des risques liés aux tiers est l’un des domaines dans lesquels les organisations financières éprouvent le plus de difficultés. Plus de la moitié des cadres et des responsables de programmes interrogés dans le cadre de cette étude ont déclaré qu’il s’agissait de l’un des éléments de Dora les plus complexes à mettre en oeuvre. Le RSSI joue un rôle clé à cet égard, car il aide les employés à évaluer les cybermenaces de la supply chain IT et veille à ce qu’ils comprennent les conséquences d’un engagement avec tel partenaire sur la sécurité de l’information.Les entités financières qui n’ont pas de programme dédié aux risques liés aux tiers devront en mettre un en place. « Nous allons assister à une surveillance beaucoup plus stricte et à moins de vérifications préalables basées sur une liste d’exigences à cocher. Et cette attention s’étendra tout au long du cycle de vie d’un contrat, dit Joel Brandon. Nous nous attendons à ce que l’accent soit mis davantage sur les clauses de sécurité, les droits d’audit, les mécanismes de reporting, ainsi que sur des clauses de résiliation strictes, permettant aux organisations de mettre fin plus facilement à des relations contractuelles en cas d’incidents. »Priorités absolues à l’approche de janvier 2025Dora commençant à s’appliquer dans six mois seulement, les organisations qui opèrent dans le secteur financier doivent accélérer leurs efforts, et les RSSI doivent s’assurer qu’ils mettent en oeuvre toutes les politiques de sécurité requises par la loi. « Six mois, c’est un délai très court », observe Wayne Scott, responsable des solutions de conformité réglementaire chez Escode, une entité du groupe NCC spécialisée dans la sécurisation des codes source. Dans l’idéal, les entités réglementées devraient avoir déjà effectué un grand nombre de tests de scénario d’incidents, avec un pourcentage élevé de tests réussis ».Les RSSI travaillant pour des petites ou moyennes entreprises, qui n’ont pas suffisamment investi dans la cybersécurité, seront confrontés à de nombreux défis. Selon Wayne Scott, un bon point de départ consiste à effectuer une analyse d’écarts afin de déterminer dans quels domaines les contrôles existants répondent aux exigences de Dora et dans quels domaines il faut investir. L’échéance approchant à grands pas, il n’est pas réaliste de viser une conformité à toutes les obligations dans les délais impartis ; mieux vaut commencer par se concentrer sur les plus critiques.Bien entendu, à ce stade, la cartographie de l’environnement est cruciale. Les organisations doivent « s’assurer qu’elles peuvent répondre aux questions fondamentales, comme savoir qui a accès à quoi, que l’on parle des collaborateurs en interne ou des tiers, dit Sagie Dulce. Elles doivent effectuer des tests de pénétration complets et disposer d’une certaine forme de journalisation et de surveillance. »Rapatrier ou externaliser en cas de panneLes RSSI doivent également se pencher sur les systèmes existants qui pourraient avoir besoin d’être mis à niveau pour répondre aux exigences du texte. Cette mise à niveau peut s’avérer difficile et coûteuse à ce stade, mais elle permettra théoriquement à l’organisation d’être plus sûre à long terme.Les entités financières doivent également affiner leurs plans de sortie de crise. Selon Dora, les plans de sortie doivent être complets, « suffisamment testés et révisés périodiquement ». « Ces plans doivent être testés de succès, ils doivent montrer clairement que l’entité réglementée peut rapatrier la gestion d’un service défaillant en interne [si ce service est externalisé, NDLR] ou, à l’inverse, en confier la gestion à un tiers, ajoute Wayne Scott. Il faut également établir clairement si des solutions de dépôt de code entièrement testées ont été mises en place. »Dora ne cite pas directement le dépôt de code auprès d’un tiers neutre (les solutions dites escrow) comme une composante des plans de sortie de crise. « Dora est agnostique sur le plan technologique et ne peut citer aucune solution, reconnaît Wayne Scott. Mais il y a une raison évidente pour laquelle des organismes comme la PRA, l’OCC, la RBI et le MAS citent tous le séquestre de code : cette solution fonctionne. »Conformité et technique avancent de concertQuelles que soient les priorités fixées par une organisation, une équipe pluridisciplinaire au sein de laquelle le personnel technique joue un rôle central, doit être mise en place et les RSSI devraient plaider en ce sens. Car, ainsi, les mesures de conformité et de sécurité ont une bonne chance d’avancer de concert. Selon Beltug, la plus grande association belge de DSI et de responsables des technologies, se concentrer uniquement sur une approche descendante de la conformité, sans impliquer le personnel technique, pourrait créer des problèmes à terme.Selon Joel Brandon, une fois que l’on aura « bien compris le champ d’application de Dora, il sera plus facile de constituer une équipe interne composée des services concernés, tels que la sécurité informatique, la conformité, les approvisionnements et le service juridique ».Les erreurs à éviterLes RSSI doivent également être attentifs aux pièges les plus courants. La plus grosse erreur qu’ils pourraient commettre est peut-être « d’aller trop lentement, de rendre les choses plus compliquées qu’elles ne le sont et de ne pas prendre de conseils extérieurs », selon Rois Ni Thuama, expert en cyber-gouvernance et en conformité aux risques. Joel Brandon, de ProcessUnity, ne dit pas autre chose : « l’erreur principale est de s’attaquer aux sujets trop tard ou de délibérer trop longtemps sur les mesures à prendre ».Les RSSI doivent également être conscients des chevauchements entre Dora et d’autres exigences. Une erreur fréquente consiste à penser que le texte sur la résilience couvre entièrement la directive NIS2, ce qui est faux. « La directive NIS2 est prioritaire dans les domaines où Dora ne contient pas d’exigences spécifiques », indique ainsi Beltug. Les États membres de l’UE doivent adopter la directive NIS2 avant le 17 octobre de cette année.Les organisations financières ont également tendance à sous-estimer certains risques : la défaillance des fournisseurs, la détérioration des services et le risque de concentration. Wayne Scott estime que les accords de licence devraient être modifiés pour inclure des exigences relatives aux plans de sortie en urgence d’un fournisseur. Toutefois, cela pourrait s’avérer difficile à réaliser étant donné l’échéance qui approche. « Les négociations contractuelles prennent du temps, conclure ces négociations dans le timing prévu risque d’être difficile », reconnaît-il.L’impact mondial de DoraLe Digital Operational Resilience Act devrait être un texte marquant tant au sein de l’Union européenne qu’à l’échelle mondiale. Si elle s’avère efficace, la réglementation pourrait être reproduite dans d’autres parties du monde, ce qui permettrait aux banques et aux autres entreprises financières d’être mieux préparées aux incidents liés à la technologie.« Les régulateurs américains ont clairement indiqué leur penchant pour Dora et ont fortement laissé entendre que les États-Unis peuvent s’attendre à des discussions réglementaires similaires dans un avenir assez proche », dit ainsi Wayne Scott. Joel Brandon juge que Dora pourrait, en fin de compte, rendre le secteur financier mondial plus sûr, en empêchant les entités financières de perdre de l’argent à la suite d’incidents liés à la technologie. « Il s’agit de mettre en place un ensemble de règles unifiées pour tous les pays, ce qui devrait permettre de mieux gérer les risques liés aux services technologiques externes », résume-t-ilEt Dora pourrait même avoir un impact sur d’autres secteurs. « Ces changements réglementaires devraient s’étendre en dehors des services financiers, principalement aux secteurs de l’énergie et des communications », pense Wayne Scott. Au fur et à mesure que les effets d’entraînement de Dora deviennent plus évidents, il pourrait être utile pour d’autres secteurs de se préparer à des changements réglementaires similaires. Comme le dit Rois Ni Thuama, « Dora n’est que le début de changements indispensables ».
Alors que les ransomwares prolifèrent, les entreprises doivent prendre conscience que la résilience va bien au-delà de la conformité pour prendre en compte tous les aspects d’une activité, de la continuité opérationnelle à la sécurité de la supply chain logicielle.
En mai 2021, lorsque le gestionnaire d’oléoduc Colonial Pipeline a été pris pour cible par les pirates informatiques de DarkSide, son Pdg Joseph Blount a pris la décision très controversée de payer la rançon de 4,4 millions de dollars réclamée par les criminels. L’attaque a mis en péril une infrastructure critique pour les États-Unis, ce qui a donné lieu à des briefings quotidiens avec le président Joe Biden, et Joseph Blount a justifié le paiement de la rançon comme étant nécessaire pour le pays, décrivant cette décision comme l’une des plus difficiles de sa carrière.« Nous nous sommes retrouvés dans une situation pénible et avons dû faire des choix difficiles auxquels aucune entreprise ne souhaite être confrontée », a ainsi expliqué le dirigeant devant la commission de la sécurité intérieure et des affaires gouvernementales du Sénat américain. Les paiements liés aux ransomwares atteignant le chiffre record de 1,1 Md$ en 2023, ces choix difficiles sont devenus finalement assez fréquents pour les dirigeants d’entreprise.Dépasser l’exercice à valider auprès des régulateursDe plus en plus de RSSI et de Pdg comprennent désormais que la question n’est pas de savoir si une attaque va se produire, mais plutôt quand elle va se produire. « Le plus grand changement pour moi est que j’accepte désormais totalement que cela puisse arriver, dit ainsi le Pdg d’une entreprise européenne réalisant 4 Md$ de chiffre d’affaires dans un rapport publié par la société de cybersécurité Istari et l’Université d’Oxford. Croyez-moi, il y a une différence fondamentale d’approche entre les organisations qui acceptent cette perspective et celles qui pensent qu’elles peuvent la repousser. »Cet état d’esprit – accepter le caractère inévitable d’une violation de données – pourrait aider les entreprises à devenir plus résilientes qu’elles ne le sont aujourd’hui. Trop souvent, les entreprises considèrent la résilience comme un exercice à cocher vis-à-vis des régulateurs, et n’équipent pas leurs RSSI de tout ce dont ils ont besoin pour véritablement rebondir après une attaque.Restaurer rapidement… ou en deux semaines ?Comme l’explique Mehran Farimani, Pdg de la société spécialisée dans la gestion des vulnérabilités RapidFort, la capacité à résister et à se remettre d’un incident de cybersécurité exige un changement de mentalité qui va au-delà de la conformité. « Oui, vous avez toujours coché la case indiquant que vous avez sauvegardé tous vos logiciels et données critiques, mais pouvez-vous restaurer rapidement en réponse à un événement indésirable, ou cela vous prendra-t-il deux semaines ? Vous assurez-vous en permanence que tous ces systèmes sont en bon état ? » explique le dirigeant.Selon un rapport de la société de cybersécurité Barracuda sur la résilience, publié en avril, lorsqu’on leur demande d’évaluer leur confiance dans la gestion des risques cyber sur une échelle de 1 à 10, la plupart des responsables de la sécurité informatique se montrent pessimistes. Les entreprises de services financiers semblent être les mieux préparées, 55 % d’entre elles estimant leur dispositif de sécurité très efficace. En comparaison, seuls 32 % des entreprises opérant dans les secteurs de l’industrie et du manufacturing se sont montrées optimistes, contre 39 % dans le secteur de la vente au détail. D’une manière générale, les petites entreprises se montrent moins confiantes dans leur capacité à résister aux cybermenaces que les grands groupes.Avec la montée de l’instabilité géopolitique, les inégalités croissantes de richesses et les risques amenés par l’IA, les RSSI doivent non seulement renforcer les cyberdéfenses de leur organisation, mais aussi les aider à se préparer aux pires scénarios, afin de s’assurer qu’elles peuvent rebondir rapidement en cas d’événement cyber non anticipé.La cyberrésilience sur le devant de la scèneLe concept de cyberrésilience a évolué pour devenir aujourd’hui une composante de la stratégie globale de l’entreprise. En fait, comme l’explique Kory Daniels, RSSI de la société spécialisée en détection et réponse aux incidents Trustwave, « les conseils d’administration ont commencé à poser la question : est-il important de nommer un responsable de la résilience ? »À la lumière des récentes cyberattaques, comme celle dont Colonial Pipeline a été victime, l’accent porté à la composante disponibilité du tryptique confidentialité, intégrité et disponibilité a augmenté. En effet, les perturbations n’affectent pas seulement la continuité opérationnelle, mais aussi la confiance des clients et la perception globale d’une entreprise par le marché.Selon Kory Daniels, il est essentiel d’adopter une « approche holistique » de la cyberrésilience, en tenant compte de tous les aspects de l’entreprise et de toutes les équipes, depuis les employés et les partenaires jusqu’au conseil d’administration. Souvent, les organisations disposent de davantage de capacités qu’elles ne le pensent, mais ces ressources peuvent être dispersées dans différents services. Et chaque entité responsable de la cyberrésilience peut n’avoir qu’une visibilité partielle des capacités existantes au sein de l’organisation. « Les opérations réseau et sécurité disposent d’une incroyable richesse de données dont les autres bénéficieraient », reprend le RSSI de Trustwave.S’étendre aux fournisseurs et partenairesDe nombreuses entreprises intègrent la cyberrésilience dans leurs processus de gestion des risques. Elles ont commencé à prendre des mesures proactives pour identifier les vulnérabilités, évaluer les risques et mettre en oeuvre les contrôles appropriés. « Cela inclut l’évaluation de l’exposition aux menaces, la validation régulière du niveau de cette exposition, par exemple via des tests de pénétration, et la surveillance continue pour détecter et répondre aux menaces en temps réel », explique Angela Zhao, analyste en chef au sein du cabinet Gartner.Ces mesures proactives dépassent souvent les frontières immédiates de l’organisation pour s’étendre aux fournisseurs et aux partenaires, ajoute Cameron Dicker, directeur de la résilience globale des entreprises au FS-ISAC, une association centrée sur la gestion des risques cyber pour la sphère financière. « Les entreprises devraient procéder à une analyse approfondie de leurs fournisseurs de services et de leurs chaînes d’approvisionnement en logiciels, identifier les risques de sécurité et élaborer des plans de réponse aux incidents en conséquence », dit-il.Supply chain logicielle : un terme central de l’équationMalheureusement, comme le souligne Kory Daniels de Trustwave, l’analyse de supply chain logicielle reste un aspect peu discuté de la cyberrésilience. « Les organisations devraient effectuer des tests de pénétration et des évaluations de risques approfondies de leur chaîne d’approvisionnement, mettre en oeuvre des exigences de cybersécurité pour les fournisseurs concernés et établir des plans d’urgence pour atténuer l’impact des perturbations que pourrait engendre cette supply chain sur leurs opérations », observe-t-il.Lorsqu’ils recherchent un fournisseur potentiel, en particulier un fournisseur qui se connectera au réseau privé de l’entreprise, les responsables de la sécurité doivent s’assurer que les contrats ou les accords-cadres de services comportent des clauses très spécifiques en ce qui concerne la résilience globale, à la fois cyber et métiers, souligne Bobby Williams, responsable de l’équipe de continuité des activités chez GuidePoint Security, une société de conseils en cybersécurité.« Un fournisseur doit être contractuellement responsable de la définition des programmes de continuité des activités, de reprise après sinistre et de sécurité de l’information, ajoute Bobby Williams. Un programme de test précis servant à démontrer la résilience du fournisseur doit figurer au contrat, et les résultats de ces tests doivent être mis à la disposition de l’entreprise pour qu’elle puisse les examiner. »Le mirroring n’est pas une sauvegardeSi le fournisseur propose des services logiciels ou des applications, le contrat doit spécifier des objectifs de temps de reprise (RTO) et de point de reprise (RPO). « Le fournisseur doit être en mesure de démontrer le RTO et le RPO au moyen de tests, souligne Bobby Williams. Le fournisseur doit également être contractuellement tenu de démontrer comment il sauvegarde les données de son client et fournir un calendrier de conservation des données. » Et de préciser que le mirroring des données ne doit jamais être accepté comme un substitut à la sauvegarde des données du client.Les risques associés à la supply chain logicielle ne doivent donc pas être pris à la légère. D’autant qu’ils sont désormais identifiés par des cybercriminels comme un moyen d’atteindre des cibles de plus grande valeur. « Il y a eu récemment plusieurs cas de cyberattaques contre les éditeurs de logiciels, note Aaron Shaha, RSSI chez la société de cybersécurité CyberMaxx. C’est un domaine qui continue de nécessiter une surveillance active. »L’IA, une complexité supplémentaireLa montée en puissance de l’IA générative, en tant qu’outil pour les pirates informatiques, complique encore les stratégies de résilience des organisations. En effet, l’IA générative donne à des individus même peu qualifiés les moyens d’exécuter des cyberattaques complexes. Par conséquent, la fréquence et la gravité des attaques pourraient augmenter, obligeant alors les entreprises à redoubler d’efforts.En revanche, les outils d’IA générative ne sont pas très efficaces à des fins défensives. Même si la technologie peut endosser un rôle d’assistant pour les équipes cyber. La détection et l’analyse des menaces, la détection des anomalies, la surveillance des comportements et les systèmes de réponse automatisés sont quelques-uns des domaines dans lesquels l’intelligence artificielle a montré son potentiel. L’IA est également utilisée dans la gestion des risques et l’examen du code. « Les algorithmes d’IA peuvent rapidement analyser de grandes quantités de données, identifier des modèles et détecter des menaces ou des vulnérabilités potentielles qui pourraient passer inaperçues aux yeux des opérateurs humains », analyse Valerie Abend, responsable de la stratégie chez Accenture Security. L’utilisation de l’IA dans l’élaboration et le maintien des programmes de cyberrésilience présente également quelques bénéfices.Pour l’instant toutefois, dans la cyber, l’IA reste une aide plutôt qu’un substitut à la surveillance humaine. « Si l’IA peut contribuer à certains aspects instrumentaux, sa contribution à la gestion des risques reste limitée à ce stade », souligne Anastasiia Voitova, responsable de l’ingénierie chez Cossack Labs (spécialisé dans la protection des données sensibles). « C’est un outil pour les professionnels de la sécurité, pas un professionnel de la sécurité en soi. »Une analyse que rejoint Mehran Farimani de RapidFort, ajoutant que les outils d’IA peuvent certainement aider à formuler et à communiquer des plans de résilience, mais sont loin d’être suffisamment fiables pour être mis en pilote automatique et protéger un système de façon autonome. Le rôle de l’IA dans la résilience devrait toutefois s’étendre dans les années à venir, car les outils alimentés par l’IA deviendront plus performants dans la détection et la réponse aux menaces en temps réel. En outre, l’IA sera probablement utilisée pour améliorer l’authentification des utilisateurs et les mécanismes de contrôle d’accès, ainsi que la résilience globale des systèmes critiques, selon Valerie Abend.Comment les réglementations compliquent la cyberrésilienceL’évolution du paysage réglementaire à travers le monde complique également la tâche des responsables de la sécurité, qui doivent se tenir au courant de toutes les contraintes auxquelles ils doivent se conformer. Même si le respect de ces exigences peut contribuer à atténuer les risques et à préserver la réputation de l’organisation.Pour Trevin Edgeworth, directeur de l’équipe Red team (tests de pénétration) chez Bishop Fox, « les réglementations peuvent notamment aider les organisations à se concentrer davantage sur les efforts de gestion des risques et les rendre plus responsables de leurs stratégies de résilience ». Le respect de ces règles contribuera à accroître la transparence sur les attaques subies et sur les pratiques de sécurité, ajoute-t-il.Les réglementations liées au Digital Operational Resilience Act (Dora), dans l’Union européenne, et celles émises par la Security and Exchange Commission (SEC), aux États-Unis, modifient la façon dont les entreprises abordent la résilience cyber. Dora, qui entrera en vigueur le 17 janvier 2025, vise à renforcer la sécurité des entités financières telles que les banques, les compagnies d’assurance et les sociétés d’investissement. Les entités financières et les fournisseurs de services de technologies et de communication situés en dehors de l’UE doivent également se conformer à Dora s’ils fournissent des services critiques à des institutions financières basées dans l’Union.Ne pas se contenter de cocher des cases« Compte tenu de cette nouvelle réglementation et des préoccupations concernant les cyberattaques, les sociétés de conseil consacrent moins de temps à la planification de la résilience tous risques confondus et plus de temps à la résilience informatique – en particulier aux questions de connexion entre les processus d’entreprise et les applications et infrastructures supportant ces processus », souligne Tamara Nolan, responsable de la cyberrésilience et de la résilience opérationnelle chez MorganFranklin Consulting.Et de conseiller aux entreprises de ne pas se contenter de cocher les cases exigées par les réglementations telles que Dora, mais de s’efforcer de couvrir tous les aspects de la résilience, car « la réglementation suppose que les éléments fondamentaux de la résilience opérationnelle sont déjà en place avant d’essayer de répondre aux exigences propres».Les entreprises opérant sur le marché américain doivent également se conformer à l’évolution de la réglementation. Car, en juillet 2023, la Securities and Exchange Commission (SEC) a introduit de nouvelles exigences en matière de rapports pour les entreprises cotées en bourse. Ces règles prévoient une divulgation des incidents de cybersécurité importants et exigent des entreprises qu’elles fournissent chaque année des informations concernant leur gestion des risques de cybersécurité, leur stratégie et leur gouvernance.Pour répondre à ces exigences, la plupart des entreprises cotées prennent des mesures pour s’assurer qu’elles disposent de systèmes permettant d’évaluer les incidents et d’y répondre. « Malheureusement, dans de nombreux cas, ces processus sont établis en dehors du cadre de résilience opérationnelle et ne sont donc pas intégrés au programme de gestion de crise de l’entreprise », souligne Tamara Nolan, qui recommande aux organisations de s’engager de manière proactive dans les cadres juridiques et réglementaires et de les intégrer dans leurs stratégies de cyberrésilience. Cette approche peut contribuer à minimiser les sanctions et à renforcer leur position globale en matière de cyberrésilience.Contagion des réglementationsSelon Angela Zhao (Gartner), Dora et les réglementations émises par la SEC ont tendance à avoir des répercussions dans le monde entier. « Les changements de réglementation dans une juridiction ont souvent des implications transfrontalières, car les entreprises multinationales opérant à l’échelle du globe doivent se conformer à de multiples cadres réglementaires, souligne-t-elle. Les entreprises doivent donc harmoniser leurs stratégies de cyberrésilience sur les différents marchés, afin de garantir des pratiques de sécurité cohérentes et la conformité aux diverses réglementations. »Les réglementations ont également joué un rôle clé dans la sensibilisation à l’importance de la cyberrésilience. Elles encouragent les entreprises à évaluer leur niveau de sécurité et renforcent l’attention des conseils d’administration sur ces sujets, selon Valerie Abend d’Accenture Security. « Nous assistons à une prise de conscience grandissante des Pdg, des cadres dirigeants et des conseils d’administration concernant ces risques, non seulement en raison des réglementations, mais aussi en raison d’une véritable préoccupation business », ajoute-t-elle.Les réglementations sont utiles, mais la conformité à elle seule n’est pas nécessairement synonyme de résilience. Les organisations pourraient « courir le risque de tomber dans un faux sentiment de sécurité en pensant que leur conformité équivaut à une forte sécurité renforcée », rappelle Trevin Edgeworth de Bishop Fox.En complément :- Cyberrésilience : comment Veolia et la Dinum anticipent les crises- L’IA s’infiltre progressivement parmi les risques les plus redoutés des entreprises- Le baromètre Cesin pointe une amélioration de la cyberrésilience des entreprisesLe facteur humain au coeur de la résilienceSi de nombreuses organisations investissent dans des solutions techniques pour renforcer leur résilience cyber, elles négligent parfois l’importance de disposer des bonnes compétences et d’encourager une culture de sensibilisation à la sécurité parmi les salariés. « L’incapacité à trouver rapidement des compétences cyber à un prix abordable crée des vulnérabilités au sein de l’industrie », souligne Aaron Shaha, RSSI chez la société de cybersécurité CyberMaxx. Les RSSI doivent donc élaborer des stratégies de recrutement solides et diversifiées pour s’assurer que les besoins en compétences sont bien satisfaits.En outre, ils devraient également investir dans des programmes de formation qui vont au-delà de la sensibilisation de base aux courriels d’hameçonnage et à la sécurité des mots de passe, note Kory Daniels de Trustwave. La formation devrait plutôt « englober une compréhension plus approfondie des cybermenaces, de l’importance de la protection des données et du rôle de chacun dans le maintien de la résilience cyber », ajoute-t-il.Les exercices et les simulations de crise sont également utiles. « Les entreprises doivent s’assurer que leurs exercices reposent sur une variété de scénarios afin de garantir que les plans de réponse aux incidents peuvent faire face à des événements inattendus, résume Bobby Williams de GuidePoint. Ces événements de type ‘cygne noir’ peuvent être gérés avec davantage de confiance si le processus de planification est resté pertinent et actualisé. »Ces exercices doivent être menés régulièrement et placer les équipes dans des situations difficiles. « Ce n’est qu’en menant des exercices stimulants qui repoussent les limites des équipes, des politiques et procédures en place qu’une organisation saura où sont ses limites et quels sont ses axes d’amélioration, souligne Cameron Dicker de FS-ISAC. Un incident cyber ne devrait jamais être la première fois que vous testez votre plan d’intervention. »