Depuis des années, la cyber-résilience est définie par la technologie : mesures de sécurité, capacités de détection sophistiquées et stratégies de sauvegarde de plus en plus robustes, conçues pour prévenir les attaques ou permettre une reprise plus rapide. Ces investissements restent essentiels, mais ils ne suffisent plus. L’IA a profondément modifié la nature des cyberattaques, qui évoluent désormais à une vitesse qui met à rude épreuve même les organisations les plus expérimentées. Alors que le délai entre la compromission et la perturbation des activités ne cesse de se réduire, la résilience consiste de moins en moins à prévenir chaque attaque et de plus en plus à maintenir le fonctionnement de l’entreprise lorsque la prévention échoue inévitablement.

Cette évolution est au cœur du nouveau rapport d’IDC, intitulé « Resilience Operations : The Discipline that Makes Readiness Provable » (Opérations de résilience : la discipline qui rend la préparation vérifiable). Cette évolution est au cœur du nouveau rapport d’IDC, « Resilience Operations : la discipline qui rend la préparation vérifiable ». S’appuyant sur une enquête menée auprès de plus de 500 organisations nord-américaines, ce rapport affirme que la résilience est en train de devenir une discipline opérationnelle transversale qui relie les priorités métier à la cybersécurité, aux opérations informatiques (ITOps) et à la reprise après sinistre. Plus important encore, il met en évidence plusieurs lacunes qui suggèrent que de nombreuses organisations continuent de se préparer à un paysage de menaces qui n’existe plus. Voici les enseignements qui ressortent. 

La reprise doit s’articuler autour des résultats commerciaux, et non des aspects techniques.

Historiquement, la planification de la reprise après sinistre s’est concentrée sur la restauration des infrastructures dans les meilleurs délais, le succès étant évalué à l’aune des objectifs de délai de reprise, des taux d’achèvement des sauvegardes et de la disponibilité des applications. Bien que ces indicateurs restent pertinents, ils ne répondent pas nécessairement à la question qui préoccupe le plus les dirigeants : quand l’activité pourra-t-elle reprendre ? 

IDC estime que la résilience doit être axée sur les résultats commerciaux plutôt que sur des étapes techniques : il s’agit de rétablir les capacités qui permettent à l’entreprise de servir ses clients, de générer des revenus et de remplir ses obligations. Cela peut sembler n’être qu’une question de terminologie, mais cela modifie la manière dont les priorités en matière de reprise sont définies. La technologie devient alors un moyen d’atteindre un but, plutôt qu’une fin en soi. 

La plupart des organisations n’ont toujours pas défini ce qui compte le plus.

Près de 6 organisations sur 10 n’ont pas encore clairement défini leur « modèle économique minimal viable » (MVB) – c’est-à-dire l’ensemble minimal de fonctions, de systèmes, de processus et de données nécessaires pour poursuivre leurs activités après une perturbation. 

Sans une vision commune des éléments dont dépend réellement l’activité, chaque action menée pendant la phase de reprise devient une simple réaction. En définissant votre MVB avant qu’une crise ne survienne, vous favoriserez une prise de décision plus rapide, une meilleure coordination pendant la phase de reprise et, au final, une organisation plus résiliente. 

L’automatisation devient la ligne de démarcation entre la résilience et l’endettement lié à la reprise.

Alors que les attaquants automatisent de plus en plus les phases de reconnaissance, d’exploitation et de déplacement latéral, de nombreuses entreprises continuent de s’appuyer sur des processus de restauration manuels. Ce déséquilibre devient de plus en plus difficile à ignorer. L’IA raccourcit les délais d’attaque, mais les délais de restauration n’ont pas suivi le rythme. L’orchestration automatisée de la restauration, l’identification précise des points de restauration et la validation coordonnée deviennent des capacités essentielles pour assurer une restauration à la vitesse exigée par les attaques modernes. 

Ce n’est pas la technologie qui constitue le principal défi en matière de résilience, mais bien la cohésion organisationnelle.

Les équipes de sécurité se concentrent sur le confinement, les équipes chargées de l’infrastructure sur la remise en état, les dirigeants sur l’impact sur les clients et les équipes chargées de la conformité sur les obligations réglementaires. Aucune de ces priorités n’est en soi erronée, mais lorsqu’elles évoluent de manière indépendante, les organisations se retrouvent confrontées à une crise sans disposer d’un modèle opérationnel commun. 

C’est là qu’intervient le concept de « ResOps ». Plutôt que de considérer la résilience comme une responsabilité du service informatique, le rapport la présente comme une discipline qui rassemble délibérément les domaines de l’activité, de la sécurité, de l’infrastructure et de la planification de la reprise. Le message est clair : la résilience dépend moins des outils individuels que de la définition de priorités communes avant qu’un incident ne vous oblige à prendre des décisions difficiles. 

Le dépistage reste l’un des indicateurs les plus fiables de la résilience.

IDC a constaté que relativement peu d’organisations mènent fréquemment des exercices sur table ou des simulations en cyber-range, alors que des décennies de données montrent que ces répétitions améliorent systématiquement les performances lors d’incidents réels. 

Les exercices permettent de mettre en évidence les dépendances cachées, de révéler les lacunes en matière de communication et de permettre aux équipes de prendre des décisions sans en subir les conséquences réelles. Les organisations qui valident régulièrement leurs processus de reprise développent un niveau de confiance qui va au-delà de la simple planification. 

Les défis de demain en matière de résilience se dessinent déjà.

Ransomware continue de faire la une de l’actualité, mais les prochains défis en matière de résilience se profilent déjà à l’horizon : de l’IA agentique et des identités machines à la cryptographie post-quantique. 

Ces menaces nous rappellent que la planification de la résilience ne peut pas se concentrer exclusivement sur les infrastructures actuelles. La reprise implique de plus en plus des services « cloud », des applications « SaaS », des modèles d’IA, des identités machine, des fournisseurs tiers et des écosystèmes numériques distribués qui n’existaient pas il y a dix ans. 

La résilience devient mesurable.

Le modèle de maturité ResOps d’IDC est un outil précieux pour évaluer la situation actuelle de votre organisation. Plutôt que de considérer la résilience comme une qualité que les organisations possèdent ou non, ce cadre décrit une évolution allant d’opérations réactives et cloisonnées vers une résilience mature et adaptative, fondée sur la gouvernance, l’automatisation et l’amélioration continue. À mes yeux, cette évolution reconnaît une réalité importante : la résilience n’est jamais achevée. Il ne s’agit pas d’acheter une plateforme ou de mener à bien un projet. Les organisations deviennent résilientes en améliorant continuellement la manière dont la technologie, les personnes et les processus métier collaborent sous pression. Sous cet angle, la résilience s’apparente moins à une assurance qu’à l’excellence opérationnelle : une capacité qui peut être évaluée, renforcée et démontrée au fil du temps. 

Nous assistons actuellement à une évolution plus générale de la manière dont les organisations envisagent la résilience.

Les discussions sur la résilience ne portent plus uniquement sur la protection des infrastructures, mais s’étendent désormais à la protection de l’entreprise elle-même. Cela signifie que la planification de la reprise commence par les clients plutôt que par les serveurs, que la gouvernance revêt désormais autant d’importance que la technologie, et que la confiance repose davantage sur la démonstration des capacités que sur la simple documentation des intentions. ResOps n’est pas vraiment un nouveau cadre ; il s’agit plutôt d’une prise de conscience plus large du fait que la cyber-résilience est devenue une discipline opérationnelle. À mesure que les attaques gagnent en rapidité et en complexité, la résilience ne se mesurera plus à l’absence d’incidents, mais à la capacité d’une organisation à continuer de servir ses clients, de soutenir ses collaborateurs et de préserver la confiance malgré les perturbations. C’est finalement ce que ResOps est censé démontrer. Rajiv Kottomtharayil est directeur des produits chez Commvault. 

Points clés à retenir

• À l’ère de l’IA, la confiance ne disparaît pas : elle évolue.
• Les organisations doivent vérifier en permanence le fonctionnement de l’IA plutôt que de s’y fier aveuglément.
• L’adoption de l’IA devrait donner plus d’autonomie aux employés, et non les pousser vers une « IA fantôme ».
• Le modèle « zero trust » ne consiste pas à se méfier des gens. Il s’agit de vérifier en permanence les identités, les appareils et les actions.
• Pour une adoption responsable de l’IA, il faut que la technologie, la gouvernance et les personnes travaillent main dans la main.

Lorsque nous avons lancé « Ready. Or Not. », notre objectif était de créer une série permettant de mieux comprendre certains des grands débats actuels autour de l’IA. En réunissant l’humoriste Nathan Macintosh et des experts du secteur, nous abordons des thèmes aussi variés que l’IA agentique, la cyber-résilience ou encore la gestion des données, le tout avec une touche d’humour.

Si vous avez écouté notre premier épisode consacré aux opportunités et aux risques liés à l’IA agentique, je pense que celui-ci vous plaira également. Cette fois-ci, nous abordons un sujet qui est au cœur de tous les débats sur l’IA : la confiance.

Nathan s’entretient avec Diana Kelley, responsable de la sécurité des systèmes d’information chez Protect AI, pour discuter de ce que signifie faire confiance à la technologie à une époque où l’IA est capable de générer des contenus falsifiés convaincants, de prendre des décisions et même d’imiter des personnes. Des « deepfakes » et des « hallucinations » au modèle « zero trust » et à l’« IA fantôme », ils examinent comment les organisations peuvent adopter l’IA sans perdre confiance en leurs collaborateurs et leurs systèmes.

Regardez l’épisode dans son intégralité sur Readiverse. À l’issue de cet épisode, je me suis senti plus optimiste que je ne l’aurais imaginé. Non pas parce que l’IA est soudainement devenue plus fiable, mais parce que Diana nous montre que la confiance s’installe lorsque les organisations mettent en place les politiques, les garde-fous et les technologies adéquats. Voici quelques thèmes abordés au cours de cette conversation qui jettent un nouvel éclairage sur l’IA.

La confiance et la technologie peuvent coexister

Diana estime que la confiance est possible à l’ère de l’IA, mais qu’elle prendra une forme différente. Nous avons toujours construit la confiance à travers nos relations avec les autres. Aujourd’hui, nous apprenons à étendre cette confiance aux systèmes. Cela ne signifie pas pour autant qu’il faille faire aveuglément confiance à la technologie. Il s’agit plutôt de comprendre le fonctionnement de l’IA, d’en reconnaître les limites et de mettre en place les mesures de protection adéquates afin que les personnes et la technologie puissent collaborer en toute confiance.

« La confiance doit évoluer pour s’adapter à ce nouveau monde. » – Diana Kelley

Ce qui m’a particulièrement marqué, c’est l’idée que la confiance et la technologie ne sont pas nécessairement incompatibles. Avec une approche adaptée, elles peuvent se renforcer mutuellement.

Nous progressons dans notre compréhension de l’IA

Les deepfakes sont devenus l’un des risques liés à l’IA dont on parle le plus, et on comprend aisément pourquoi. L’IA est désormais capable de générer des voix, des images et des vidéos convaincantes qui nous amènent à nous interroger sur ce qui est réel. Mais Diana a souligné que si l’IA gagne en sophistication, les gens deviennent eux aussi plus avisés. Nous sommes davantage enclins à nous interroger sur un appel téléphonique inattendu, à examiner de plus près une publication sur les réseaux sociaux ou à nous interroger face à quelque chose qui ne nous semble pas tout à fait normal.

Les organisations deviennent elles aussi plus avisées. À mesure que l’IA perfectionne ses capacités d’usurpation d’identité, les entreprises investissent dans de nouveaux moyens permettant de vérifier en permanence les identités et de valider les informations. Ce que j’en retiens, c’est que la technologie continuera à s’améliorer, mais qu’il en sera de même pour notre capacité à la reconnaître et à y répondre de manière responsable.

« Est-ce que c’est un bon jour pour se lancer dans le deepfake ? » – Nathan Macintosh

Une IA responsable est bénéfique pour les entreprises

Diana a donné un exemple qui semblera sans doute familier à de nombreuses entreprises. Une employée qu’elle appelle « Karen, du service financier », commence à utiliser l’IA car cela lui permet d’accomplir une tâche en quelques minutes au lieu de plusieurs heures. Karen ne cherche pas à contourner la politique de l’entreprise : elle essaie simplement d’être plus productive.

Les collaborateurs utilisent l’IA parce qu’ils y voient une réelle valeur ajoutée, ce qui représente une opportunité pour les entreprises. Lorsqu’ils ont accès à des outils d’IA approuvés, accompagnés de politiques claires et de conseils pratiques, ils peuvent travailler plus efficacement tout en contribuant à la protection des données et des systèmes de l’entreprise.

Aperçu : une adoption plus intelligente de l’IA

L’objectif n’est pas d’empêcher les employés d’utiliser l’IA, mais de s’assurer qu’ils l’utilisent correctement. Diana explique comment les entreprises peuvent encourager l’adoption de l’IA sans créer de risques inutiles.

Le modèle « Zero Trust » est plus important que jamais

« Quand on comprend comment les choses fonctionnent, on peut alors commencer à comprendre comment les gérer. » – Diana Kelley

Le « zero trust » fait partie de ces concepts qu’il est beaucoup plus facile de comprendre à l’aide d’une analogie. Diana en propose une excellente. Elle le décrit comme le fait de se déplacer dans un bâtiment. Ce n’est pas parce que l’on vous a autorisé à franchir la porte d’entrée que toutes les autres portes s’ouvrent automatiquement pour vous. Chaque fois que vous accédez à une nouvelle pièce, un nouveau contrôle rapide est effectué pour confirmer que vous êtes bien autorisé à vous y trouver.

C’est essentiellement ainsi que fonctionne le « zero trust ». C’est en substance ainsi que fonctionne le modèle « zero trust ». Au lieu de considérer qu’une personne ou un appareil est digne de confiance après une simple connexion, les entreprises vérifient en permanence les identités, les appareils et les actions, à mesure que les technologies deviennent de plus en plus interconnectées. La plupart de ces vérifications s’effectuent discrètement en arrière-plan. L’un des aspects que j’ai particulièrement appréciés dans l’explication de Diana, c’est que le « zero trust » ne donne pas l’impression d’être un simple mot à la mode dans le domaine de la sécurité. Il apparaît plutôt comme une approche concrète de la confiance dans un monde où l’IA et les identités numériques font désormais partie intégrante du quotidien des entreprises.

La confiance, c’est avant tout une question de personnes

En fin de compte, ce n’est pas la technologie qui instaure la confiance, mais les personnes. Ce sont elles qui définissent les politiques, les processus et les limites éthiques qui régissent l’utilisation de l’IA, tandis que la technologie permet de vérifier que ces garde-fous fonctionnent comme prévu. C’est ce partenariat entre les personnes et la technologie qui rend possible une IA responsable.

La confiance dépasse le cadre de nos propres organisations. Les entreprises doivent pouvoir avoir confiance dans les partenaires avec lesquels elles travaillent, les systèmes auxquels elles se connectent et les technologies qu’elles adoptent. C’est pourquoi la transparence, les normes communes et la vérification continue deviennent tout aussi importantes que l’innovation elle-même. Plus l’IA s’intègre dans le quotidien des entreprises, plus la confiance devient la responsabilité de chacun.

Perspectives d’avenir

L’IA continuera d’évoluer, tout comme la manière dont nous interagissons avec elle. Les organisations qui réussiront ne seront pas celles qui font aveuglément confiance à l’IA ou qui l’évitent complètement. Ce seront celles qui mettront en place des politiques solides, adopteront les technologies adaptées et vérifieront en permanence les systèmes sur lesquels elles s’appuient.

La confiance n’est pas quelque chose que l’on perd à mesure que la technologie progresse. C’est quelque chose que l’on construit et que l’on fait évoluer de manière intentionnelle. C’est exactement le genre de discussion que nous espérons poursuivre à chaque épisode de Ready. Or Not. Regardez l’épisode dans son intégralité sur Readiverse.

FAQ

Q : Qu’est-ce que la confiance numérique ?

R : La confiance numérique, c’est la certitude que les personnes, les systèmes et les organisations sont bien ceux qu’ils prétendent être et qu’ils agissent de manière conforme aux attentes et sécurisée. Elle associe technologie, gouvernance et vérification pour aider les organisations à interagir en toute sécurité.

Q : Qu’est-ce que les « deepfakes » ?

R : Les « deepfakes » sont des images, des vidéos ou des enregistrements audio générés par l’intelligence artificielle et conçus pour imiter fidèlement des personnes réelles. Bien qu’ils aient des utilisations légitimes, ils peuvent également servir à usurper l’identité de personnes ou à commettre des fraudes.

Q : Qu’est-ce que le « zero trust » ?

R : Le « zero trust » est un modèle de sécurité fondé sur une vérification continue plutôt que sur une confiance automatique. Au lieu de considérer qu’un utilisateur ou un appareil est digne de confiance dès sa première connexion, les entreprises vérifient en permanence les identités et les actions.

Q : Qu’est-ce que l’IA « shadow » ?

R : Le terme « Shadow AI » désigne l’utilisation par les employés d’outils d’IA qui n’ont pas été approuvés ni régis par leur entreprise. Bien que souvent motivée par de bonnes intentions, cette pratique peut entraîner des risques en matière de sécurité, de confidentialité et de conformité.

Q : Pourquoi les entreprises ne devraient-elles pas simplement bloquer les outils d’IA ?

R : Les employés adoptent généralement l’IA car celle-ci les aide à travailler plus efficacement. Plutôt que d’interdire purement et simplement l’IA, les entreprises devraient mettre à disposition des outils approuvés, établir des politiques claires et sensibiliser leurs employés à une utilisation responsable.

Q : Quel est le principal enseignement à retenir de cet épisode ?

R : La confiance ne disparaît pas à cause de l’IA : elle évolue. Les organisations qui associent ressources humaines, politiques et technologies à un processus de vérification continue seront mieux à même d’adopter l’IA en toute confiance et de manière responsable.

Katherine Demacopoulos est directrice principale de la stratégie et des programmes de contenu mondiaux chez Commvault.

Notre directeur des produits, Rajiv Kottomtharayil, a récemment évoqué une évolution majeure qui se produit actuellement dans tous les secteurs. Les modèles d’IA de pointe réduisent le délai entre la découverte d’une vulnérabilité et son exploitation. Cette évolution incite les entreprises du monde entier à réexaminer leurs processus de gestion des vulnérabilités. C’est également ce que nous faisons chez Commvault. C’est pourquoi, à compter du 11 août, nous modifions la fréquence de nos communications relatives aux vulnérabilités. Ce qui change Nous plaçons la barre plus haut en matière de sécurité, de transparence et de confiance des clients. Le 11 août, puis chaque deuxième mardi du mois, nous lancerons les « Patch Tuesdays » : une publication mensuelle programmée au cours de laquelle nous diffuserons des avis de sécurité et des correctifs de vulnérabilités.  

Les « Patch Tuesdays » sont une pratique courante chez les grandes entreprises technologiques, car ils offrent aux clients un rythme de sécurité prévisible. Cela revêt d’autant plus d’importance que le rythme de découverte des vulnérabilités s’accélère. Bien entendu, si une vulnérabilité urgente doit être signalée en dehors de ce cycle, nous n’hésiterons pas à suivre nos processus bien établis.  

Où trouver des ressources à jour  

Chaque deuxième mardi du mois, vous trouverez de nouvelles informations concernant les CVE sur notre page « Avis de sécurité ». Vous pouvez également consulter les publications officielles sur le site CVE. Sur le Centre de sécurité Commvault, vous trouverez notre programme de gestion des vulnérabilités ainsi que d’autres réflexions de pointe sur la sécurité intégrée dès la conception.   

Pour consulter les certifications de conformité, les rapports d’audit et la documentation expliquant comment Commvault protège les données de ses clients, rendez-vous sur le Centre de confiance Commvault. Vous pouvez vous abonner aux mises à jour du Trust Center via le lien situé dans le coin supérieur droit de la page. Bill O’Connell est directeur de la sécurité chez Commvault. 

Depuis des décennies, les leaders du secteur technologique s’efforcent d’éliminer les silos. Des programmes de modernisation à part entière ont été mis en place dans le but de relier les applications, de regrouper les plateformes et d’offrir aux entreprises une vision plus complète de leurs données. Ces efforts ont apporté une valeur inestimable, mais ils ont également façonné notre façon d’envisager la résilience. Lorsqu’un problème survient, nous cherchons instinctivement à l’attribuer à une fragmentation technique. Or, nous avons constaté que le véritable défi réside ailleurs.

Les cloisonnements les plus importants qui nuisent aujourd’hui à la cyber-résilience ne se trouvent pas dans les bases de données ou les applications, mais dans les structures organisationnelles. Ils existent entre les équipes chargées de la sécurité et celles chargées de l’infrastructure, entre le service informatique et les métiers, ainsi qu’entre les personnes chargées de réagir à une attaque et celles chargées d’assurer la continuité des activités de l’organisation.

La dernière étude d’IDC consacrée au ResOps, intitulée «Resilience Operations : The Discipline that Makes Readiness Provable» (Opérations de résilience : la discipline qui permet de démontrer l’état de préparation), suggère que ces frontières organisationnelles sont devenues l’un des principaux obstacles à une reprise efficace. Cette observation tombe à point nommé, car les cyberattaques ont évolué d’une manière qui rend ces frontières de plus en plus difficiles à maintenir.

Les attaques modernes ne respectent pas l’organigramme de votre entreprise

Une cyberattaque moderne touche rarement un seul domaine technologique. Un incident de type « ransomware » peut commencer par la compromission d’identités, se propager à travers l’infrastructure d’ cloud , chiffrer des charges de travail critiques, perturber les applications destinées aux clients, affecter des services tiers et déclencher des obligations de déclaration réglementaires – le tout en l’espace de quelques heures. Chaque étape mobilise des équipes, des outils et des priorités différents. Pourtant, de nombreuses organisations continuent de se préparer à la reprise comme si ces responsabilités pouvaient être gérées séparément.

Les équipes de sécurité se concentrent naturellement sur le confinement des menaces et la préservation des preuves. Les équipes chargées de l’infrastructure donnent la priorité à la restauration des systèmes et à la réduction des temps d’arrêt. Les dirigeants se concentrent sur les clients, le chiffre d’affaires et la continuité opérationnelle. Les équipes de communication se préoccupent de la réputation, tandis que les équipes juridiques et de conformité se concentrent sur les obligations réglementaires. Chacun de ces points de vue est tout à fait raisonnable. Le problème survient lorsque ces priorités n’ont jamais été conciliées avant qu’un incident ne se produise.

En pleine crise, la reprise nécessite de prendre des décisions sous pression. Quelles applications doivent être rétablies en priorité ? Quelles données peuvent être restaurées en toute sécurité ? Quel niveau de Risk est acceptable avant la reprise des services aux clients ? Qui a le pouvoir de prendre ces décisions ? En l’absence d’alignement, les organisations constatent souvent que les retards les plus importants ne sont pas dus à la technologie, mais à l’incertitude – celle-là même qui pourrait être atténuée par une meilleure préparation.

La résilience commence par une définition commune de ce qui compte vraiment

Ce rapport met l’accent sur la mise en place d’un modèle d’entreprise minimal viable (MVB). À première vue, cela ressemble à un énième exercice de planification de la reprise, mais sa véritable valeur réside dans les discussions qu’il oblige les organisations à mener.

Pour définir un MVB, les dirigeants d’entreprise, les équipes de sécurité, les spécialistes des infrastructures et les responsables d’applications doivent s’accorder sur une question d’une simplicité trompeuse : qu’est-ce qui doit absolument continuer à fonctionner si tout le reste s’arrête ?

Cette réflexion modifie la nature même de la planification de la résilience. Les priorités en matière de reprise ne sont plus déterminées par le responsable d’application qui s’exprime de la manière la plus convaincante lors d’un incident. Elles sont désormais définies à l’avance, fondées sur les résultats opérationnels et étayées par des dépendances techniques compréhensibles par tous.

Mais surtout, le MVB crée un langage commun. Les dirigeants d’entreprise commencent à parler de capacités critiques plutôt que de systèmes individuels. Les équipes techniques commencent à mettre en correspondance l’infrastructure avec les résultats attendus par les clients plutôt qu’avec des architectures techniques. Les équipes de sécurité identifient plus clairement les actifs qui méritent les niveaux de protection les plus élevés pendant la Recovery. C’est précisément cette vision commune qui fait défaut à de nombreuses organisations.

La technologie peut automatiser la récupération, mais elle ne peut pas créer d’alignement

Le rapport ne soutient pas que les organisations aient besoin d’une énième plateforme. Il affirme qu’elles ont besoin d’une méthode de travail qui aligne les personnes, les processus et la technologie autour d’un objectif opérationnel unique. C’est là que ResOps – une discipline transversale – fait ses preuves.

La technologie peut aider à automatiser la Recovery, mais elle ne peut pas résoudre les désaccords concernant les priorités métier. Elle ne peut pas décider quels services clients sont les plus importants. Et elle ne peut pas se substituer à la gouvernance nécessaire pour coordonner plusieurs équipes lors d’un incident à forte pression. Ce sont là des défis en matière de direction, et la meilleure façon d’y faire face est de consacrer du temps à répondre ensemble aux questions difficiles, bien avant qu’une attaque ne vous oblige à agir.

Les organisations les plus performantes ne suppriment pas les cloisonnements : elles les relient entre eux.

Les cyberattaques continueront d’évoluer. L’IA continuera de réduire les délais d’exécution des attaques. Les nouvelles technologies introduiront de nouvelles dépendances, et de nouvelles menaces émergeront parallèlement. Rien de tout cela ne change l’exigence fondamentale en matière de résilience. Les organisations ne se relèvent pas parce que certaines équipes, prises isolément, réalisent des performances exceptionnelles, mais parce que ces équipes savent déjà travailler ensemble.

C’est peut-être là, en fin de compte, la conclusion la plus importante qui ressort de l’étude menée par IDC. La résilience n’est pas simplement le fruit d’une technologie plus performante ou de contrôles de sécurité plus sophistiqués. Elle résulte de priorités communes, d’une gouvernance claire et d’un modèle opérationnel éprouvé qui rassemble les bonnes personnes avant même qu’un incident ne se produise. Vidya Shankaran est directrice technique sur le terrain chez Commvault.

Points clés à retenir

• Un CVE est un identifiant unique au monde attribué à une vulnérabilité logicielle rendue publique, qui permet aux éditeurs, aux chercheurs et aux responsables de la sécurité de s’y référer de manière cohérente.
• L’approche adoptée par une organisation en matière de divulgation des vulnérabilités – notamment la mise en place de correctifs coordonnés, la collaboration avec les chercheurs et la tenue d’un inventaire précis des logiciels – constitue un indicateur fiable de sa maturité globale en matière de sécurité.
• Commvault assure la protection de ses clients grâce à un programme CVE caractérisé par la transparence, la régularité et la clarté. La manière dont les vulnérabilités CVE sont divulguées en dit long sur la maturité d’un programme de sécurité et d’ingénierie.

Pourquoi est-ce important ?

De nombreuses failles qui parviennent jusqu’au conseil d’administration trouvent leur origine dans des vulnérabilités logicielles. Le mécanisme utilisé par l’ensemble du secteur pour nommer et décrire ces vulnérabilités est le CVE(Common Vulnerabilities and Exposures). La manière dont un fournisseur, ou votre propre entreprise, gère les CVE est l’un des indicateurs les plus évidents de la maturité en matière de sécurité.

Une entreprise qui communique ses vulnérabilités et reconnaît équitablement le travail des chercheurs est généralement une entreprise qui prend au sérieux l’ingénierie sous-jacente. Cet article explique comment un CVE est créé, qui gère le système et ce qui distingue une divulgation exemplaire d’une divulgation médiocre.

Au-delà du CVE : pourquoi la philosophie de la divulgation est importante

La publication d’un CVE est un minimum indispensable. Les éléments qui font la différence sont les suivants : la transparence concernant la vulnérabilité et le correctif, la mise en place régulière d’analyses et d’applications de correctifs, ainsi qu’une communication claire. Commvault considère la divulgation comme une discipline d’ingénierie et de sécurité plutôt que comme une simple formalité de conformité : établir un rythme régulier pour la révision du code et la correction des failles, communiquer les mesures correctives dans un langage simple et clair, et protéger nos clients. C’est cette cohérence, plus que n’importe quel score isolé, qui témoigne de la maturité en matière de sécurité dans la divulgation des CVE.

Qu’est-ce qu’une vulnérabilité CVE, au juste ?

Un CVE n’est ni un correctif, ni un score, ni un logiciel malveillant. Il s’agit d’une entrée de dictionnaire qui attribue à une vulnérabilité spécifique et connue du public un nom permanent et unique, afin que chacun puisse s’y référer. L’identifiant lui-même respecte un format simple et stable : les lettres « CVE », l’année d’attribution de l’identifiant et un numéro d’ordre, par exemple « CVE-2021-44228 ».

L’ampleur du programme est considérable et ne cesse de croître : 48 000 CVE ont été publiés en 2025, soit environ 132 par jour, ce qui représente une hausse de plus de 260 % depuis 2020.

Anatomie d’un enregistrement unique

Les publications CVE doivent respecter un ensemble d’éléments standardisés. Leur lecture est aisée dès lors que l’on connaît la fonction de chaque partie :

• Identifiant : le numéro unique CVE-AAAA-NNNNN
• Description: explication concise de la vulnérabilité : en quoi elle consiste et comment un acteur malveillant pourrait l’exploiter.
• Produits et versions concernés: quels logiciels, matériels ou micrologiciels (et quelles versions) sont affectés, et quelles versions intègrent le correctif.
• Niveau de gravité : la catégorie de gravité sous-jacente.
• Références, liens vers l’avis du fournisseur, le correctif et les documents techniques.

Les acteurs secondaires : CVSS, CWE, EPSS et KEV

Quatre systèmes complémentaires permettent de faire d’un CVE une priorité pour l’entreprise. Il est facile de les confondre, il est donc important de bien distinguer chacun d’entre eux :

• Le CVSS (Common Vulnerability Scoring System) répond à la question « Quelle est la gravité de cette faille ? ». Le CVSS correspond à la note de gravité (sur une échelle de 1 à 10, 10 étant la plus grave) attribuée à la faille, et non à une évaluation de votre exposition spécifique.
• L’EPSS (Exploit Prediction Scoring System) répond à la question suivante : « Quelle est la probabilité que cette vulnérabilité soit exploitée prochainement ? » L’EPSS génère un score de probabilité, compris entre 0 et 100 %, qui estime la probabilité qu’une vulnérabilité soit exploitée au cours des 30 prochains jours.
• Le CWE (Common Weakness Enumeration) répond à la question « Quel type d’erreur en est à l’origine ? ». Le CWE classe la faille de codage sous-jacente.
• Le KEV (Known Exploited Vulnerabilities, ou « vulnérabilités connues exploitées ») répond à la question suivante : « Cette vulnérabilité est-elle actuellement exploitée contre des utilisateurs ? » Le catalogue KEV est une liste triée sur le volet de CVE dont l’exploitation dans le monde réel a été confirmée.

Un score CVSS élevé indique le degré de gravité d’une vulnérabilité, un score EPSS élevé indique la rapidité avec laquelle elle est susceptible d’être exploitée, et sa présence dans le catalogue KEV confirme qu’elle fait déjà l’objet d’une exploitation. Les meilleurs programmes de gestion des vulnérabilités prennent en compte ces trois critères.

FAQ

Q : Qu’est-ce qu’un CVE, et pourquoi est-ce important ? R : Un identifiant CVE (Common Vulnerability and Exposure) est un identifiant normalisé attribué à une vulnérabilité logicielle rendue publique. Il permet à tous – des éditeurs et chercheurs aux autorités de régulation et aux clients – de faire référence à la même vulnérabilité sans ambiguïté.

Q : Quelles informations un enregistrement CVE bien structuré doit-il contenir ?
R : Un enregistrement CVE complet doit comporter un identifiant unique, une description de la vulnérabilité, les produits et versions concernés, le niveau de gravité, ainsi que des références aux avis de sécurité ou aux correctifs des éditeurs. Ces éléments permettent aux organisations de comprendre leur exposition au risque et d’y répondre efficacement.

Q : En quoi le CVSS, le CWE, l’EPSS et le KEV diffèrent-ils d’un CVE ? R : Un CVE identifie une vulnérabilité spécifique, tandis que le CVSS en mesure la gravité, l’EPSS estime la probabilité d’une exploitation à court terme, le CWE classe la faille de codage sous-jacente et le KEV identifie les vulnérabilités activement exploitées dans le monde réel. Ensemble, ces référentiels contribuent à fournir le contexte nécessaire pour hiérarchiser les mesures correctives.

Q : Quels sont les critères pris en compte par Commvault dans ses propres pratiques de communication d’informations ? R : Commvault applique à ses propres communications les mêmes critères qu’elle attend des autres : transparence, régularité et clarté. C’est ainsi que Commvault protège ses clients.

Q : Quels sont les éléments que les dirigeants d’entreprise doivent prendre en compte lorsqu’ils évaluent les pratiques des fournisseurs en matière de gestion des vulnérabilités ? R : Les dirigeants doivent s’assurer que les fournisseurs disposent de calendriers de divulgation coordonnés, de registres CVE complets et précis, de consignes de correction claires, de programmes de reporting solides, ainsi que de la capacité à déterminer rapidement si leurs produits sont affectés par des vulnérabilités récemment divulguées. Ces caractéristiques témoignent d’une culture de sécurité forte et renforcent la résilience de l’organisation. Werner Nel est responsable principal de l’expérience produit chez Commvault.

Points clés à retenir

• « JadePuffer » est le nom que les chercheurs en sécurité de Sysdig ont donné à ce qu’ils ont identifié comme la première opération de type « ransomware » documentée, menée de bout en bout par un agent IA autonome, et non par un humain utilisant une boîte à outils.
• Les techniques utilisées n’étaient pas nouvelles. Ce qui a changé, c’est la rapidité d’exécution : l’agent a enchaîné les phases de reconnaissance, le vol d’identifiants, le déplacement latéral et le chiffrement destructeur, parvenant à corriger une tentative de connexion infructueuse en 31 secondes.
• L’agent a généré sa propre clé de chiffrement, qu’il n’a ensuite ni stockée ni transmise. Le paiement de la rançon n’aurait pas permis de récupérer les données.
• Les dommages réels ont visé l’état de configuration et les systèmes du plan de contrôle, et pas seulement les fichiers, ce qui correspond précisément à la couche que la plupart des plans de reprise ne couvrent pas.
• Se remettre d’une attaque de ce type implique de démontrer que l’entreprise est en mesure de reprendre ses activités en toute sécurité, et pas seulement de restaurer une sauvegarde.

Que s’est-il passé ?

Au milieu de l’année 2026, des chercheurs en sécurité de Sysdig ont mis en évidence une campagne de chantage qu’ils estiment être la première du genre : une opération de « ransomware » menée de bout en bout par un agent basé sur un grand modèle linguistique, avec une intervention humaine minimale au clavier. Ils l’ont baptisée « JadePuffer ».

Le point d’entrée était bien connu. L’attaquant a exploité la vulnérabilité CVE-2025-3248, une faille permettant l’exécution de code à distance sans authentification dans Langflow, un framework open source destiné à la création de workflows d’agents d’IA, dont la version était antérieure à la 1.3.0. À partir de là, l’agent a procédé à l’énumération de l’hôte, a recherché des identifiants auprès de fournisseurs d’ cloud , de fournisseurs de modèles d’IA et de bases de données, puis a discrètement copié la base de données interne de l’ platform.

Ce qui s’est passé ensuite mérite particulièrement notre attention. L’agent a analysé le réseau interne, a trouvé un magasin d’objets exposé et a extrait les fichiers d’état et de configuration de Terraform. Il a mis en place une tâche planifiée pour communiquer avec son serveur de commande toutes les 30 minutes. Il s’est ensuite tourné vers un système de production distinct exécutant MySQL et Alibaba Nacos, une plateforme de configuration et de découverte de services couramment utilisée dans les architectures de microservices.

Une fois à l’intérieur, l’agent a tenté de créer un compte administrateur dans Nacos. L’opération a échoué. Trente et une secondes plus tard, il avait identifié la cause de l’échec et réussi à atteindre son objectif en adoptant une approche différente. Il a ensuite utilisé les fonctions de gestion de fichiers de MySQL pour vérifier s’il pouvait aller plus loin, avant de chiffrer plus de 1 300 enregistrements de configuration, de supprimer les tables d’origine et de laisser une demande de rançon.

La clé de chiffrement a été générée à la volée, affichée une seule fois, et n’a jamais été stockée à un endroit où l’attaquant aurait pu la récupérer. Que cela ait été intentionnel ou non, le résultat pour la victime est le même : il n’y avait aucun moyen de revenir en arrière via l’attaquant ou une clé de déchiffrement, que la rançon ait été payée ou non. La restauration dépendrait de sauvegardes intactes, d’une reconstruction du système ou de points de restauration validés.

Pourquoi les chercheurs qualifient-ils cela d’« agentique » ?

Aucune des techniques décrites ici n’est nouvelle. Exploiter une vulnérabilité CVE non corrigée, collecter des identifiants, rechercher des possibilités de déplacement latéral, chiffrer des données à des fins d’extorsion : les équipes de sécurité ont déjà rencontré chacune de ces techniques. Ce qui a conduit Sysdig à classer cet opérateur comme un « agent » plutôt que comme un attaquant classique, c’est la manière dont ces différentes étapes s’articulent entre elles.

L’agent ne suivait pas un scénario prédéfini. Il analysait les résultats et s’adaptait en conséquence. Lorsqu’il s’attendait à recevoir une réponse au format JSON et qu’il obtenait du XML à la place, il modifiait son approche et poursuivait son exécution. Lorsque sa première tentative de création d’un compte administrateur a échoué, il a identifié la cause précise de l’échec et a essayé une autre approche, le tout en moins d’une minute.

Les chercheurs ont également découvert des commentaires intégrés dans les charges utiles, expliquant les cibles et les étapes suivantes dans un langage simple, un schéma qui correspond davantage au raisonnement d’un modèle de langage de grande envergure (LLM) effectuant une tâche qu’à celui d’un humain copiant-collant un kit d’exploitation connu. Les informations rendues publiques n’ont pas permis de confirmer quel modèle ou quelle « platform » était à l’origine de l’attaque. Ce qui est confirmé, c’est son comportement : une entité a raisonné, agi, s’est heurtée à un obstacle et a corrigé sa trajectoire plus rapidement que ne le permet la plupart des interventions humaines en cas d’incident.

Le problème de la récupération que trop de frameworks négligent encore

La plupart des guides de gestion des incidents liés à l’ransomware e reposent sur une hypothèse précise : vos fichiers ont été chiffrés, et la question est de savoir si vous pouvez restaurer une sauvegarde intacte ou si vous devez négocier une clé de déchiffrement.

JadePuffer remet en cause cette hypothèse de deux manières. Premièrement, il n’y avait aucune clé de déchiffrement à négocier. Deuxièmement, les dégâts ne se limitaient pas aux données. Ils concernaient également la couche de configuration et de plan de contrôle sous-jacente aux données : la plateforme de découverte de services, les secrets qu’elle contenait, l’état Terraform décrivant l’architecture de l’infrastructure, ainsi que les identifiants dispersés sur tous les systèmes que l’agent a touchés en chemin.

C’est un problème de restauration plus complexe que la simple « restauration de la base de données ». Une restauration « propre » des fichiers dans un environnement où les identifiants ont été renouvelés mais n’ont pas été vérifiés, où les dérives de configuration n’ont pas été examinées et où la couche d’identité n’a fait l’objet d’aucun nouvel audit ne constitue pas vraiment une restauration « propre ». Il s’agit simplement d’une nouvelle copie des données stockée dans un système qui ne peut toujours pas être considéré comme fiable.

Ce que cela implique pour votre stratégie de résilience

JadePuffer offre un aperçu de la question à laquelle tout plan de reprise devra tôt ou tard répondre : est-il possible de reprendre ses activités lorsqu’un attaquant a compromis non seulement vos données, mais aussi les systèmes d’identité, de configuration et de plan de contrôle dont ces données dépendent ?

Quelques pistes pour commencer :

Considérez les systèmes de configuration et de plan de contrôle comme essentiels à la Recovery, et pas seulement les applications. Les plateformes de découverte de services, les référentiels de secrets et l’état de l’infrastructure en tant que code sont aussi critiques pour l’entreprise que les bases de données qu’ils configurent. S’ils ne figurent pas encore dans votre plan de Recovery, c’est la première lacune à combler.

Intégrez la gestion des identifiants dès la phase de restauration, et non après. La restauration d’une charge de travail qui réintroduit des identifiants compromis ne met pas fin à l’incident ; elle remet le compteur à zéro. C’est cette même approche que Commvault applique aujourd’hui à l’infrastructure d’identité : une évaluation des vulnérabilités pour détecter les failles avant qu’un attaquant ne le fasse, un audit en temps réel pour repérer les modifications au fur et à mesure qu’elles se produisent, et une restauration en arrière pour annuler les modifications non autorisées sans avoir à tout reconstruire à partir de zéro.

Validez avant la restauration, pas après. Un point de restauration n’est utile que si vous êtes certain qu’il est « propre ». C’est le principe sur lequel repose Commvault® Cleanroom™: tester et valider les données dans un environnement isolé avant qu’elles ne rejoignent à nouveau l’environnement de production, plutôt que de s’en rendre compte après une réinfection.

Préparez-vous à une compromission du plan de contrôle, et pas seulement à un simple cas de chiffrement de fichiers. Une feuille de route de reprise conçue uniquement pour le scénario « fichiers chiffrés, restauration à partir d’une sauvegarde » ne tiendra pas la route face à un incident de ce type. La question la plus pertinente, et celle qui est au cœur des ResOps (opérations de résilience) en tant que discipline opérationnelle, est de savoir ce qu’il faut pour atteindre un niveau minimal de fonctionnement viable lorsque ce sont les systèmes sous-jacents à vos applications qui ont été touchés.

Rien de tout cela n’implique de considérer l’IA agentique comme une menace sans précédent qui nécessiterait de repartir de zéro. Il s’agit plutôt d’étendre la même approche axée sur la résilience, qui s’applique déjà à l’identité et aux données, jusqu’à la couche de configuration et de contrôle que les attaques agentiques ciblent désormais directement. Découvrez comment Commvault aborde la résilience des identités et la validation de la restauration propre.

FAQ

Q : Qu’est-ce que JadePuffer ? R : « JadePuffer » est le nom donné par Sysdig à ce qu’elle a identifié comme la première campagne d’ ransomware s documentée, menée de bout en bout par un agent IA autonome, plutôt que par un attaquant humain utilisant manuellement une boîte à outils.

Q : Les pirates ont-ils utilisé un modèle d’IA spécifique, comme ChatGPT ou Claude ? R : Les informations rendues publiques n’ont pas permis de confirmer quel modèle ou quelle « platform » a été utilisé(e). L’agent a recherché des clés API provenant de plusieurs fournisseurs d’IA, ce qui témoigne d’un intérêt pour ce type d’accès, mais ne permet pas d’identifier ce qui a servi de base à l’attaque elle-même. Q : Comment l’attaque a-t-elle commencé ?

R : La vulnérabilité CVE-2025-3248, qui permet l’exécution de code à distance sans authentification dans Langflow, un framework open source d’agents d’IA, affecte les versions antérieures à la version 1.3.0. Q : La victime aurait-elle pu payer la rançon pour récupérer ses données ? R : Non. La clé de chiffrement a été générée à la volée et n’a jamais été stockée ni transmise ; il n’y avait donc aucune clé à récupérer, quel que soit le montant du paiement.

Q : En quoi cela diffère-t-il d’un « ransomware » classique ? R : Les techniques utilisées n’étaient pas nouvelles. Ce qui a retenu l’attention, c’est la rapidité et la capacité d’adaptation : l’agent a détecté une tentative de connexion infructueuse et l’a corrigée en 31 secondes, un rythme plus proche de celui d’une machine que du comportement habituel d’un attaquant agissant à un rythme humain. Q : Quels enseignements les équipes chargées de la sécurité et de la reprise après sinistre doivent-elles en tirer ?

R : Cette planification de la reprise doit aller au-delà des données applicatives pour englober les référentiels de configuration, les plateformes de découverte de services, les secrets et les systèmes d’identité, c’est-à-dire la couche que JadePuffer a précisément ciblée pour causer un maximum de dégâts. Chris Bevil est responsable principal du marketing de portefeuille chez Commvault.

Points clés à retenir

• Des modèles d’IA avancés ont réussi à s’échapper d’un environnement d’évaluation restreint en exploitant des vulnérabilités jusque-là inconnues.
• OpenAI affirme que les modèles poursuivaient un objectif qui leur avait été assigné, sans agir avec une intention malveillante, mais qu’ils ont néanmoins provoqué un véritable incident de sécurité.
• Les mesures de contrôle traditionnelles, telles que le sandboxing et la segmentation, s’avèrent insuffisantes si l’IA parvient à trouver des voies inattendues pour les contourner.
• La cyber-résilience prend autant d’importance que la prévention.

Tout a commencé par une évaluation interne des capacités avancées de l’IA en matière de cybersécurité. Alors qu’ils tentaient de résoudre un test de performance aux critères très précis, les modèles d’OpenAI ont découvert une vulnérabilité « zero-day », ont contourné les restrictions prévues de leur environnement de test, ont élevé leurs privilèges, ont accédé à Internet et ont compromis l’infrastructure de Hugging Face. Ils considéraient les contraintes techniques qui les entouraient comme des problèmes à résoudre.

Il ne s’agissait pas d’une cyberattaque classique

C’est Hugging Face qui a été le premier à signaler qu’un cadre d’agent IA autonome avait compromis une partie de son infrastructure de production. Un ensemble de données malveillant a exploité deux voies d’exécution de code dans son pipeline de traitement des données, a obtenu un accès au niveau des nœuds, a récupéré des identifiants et s’est propagé latéralement à travers les clusters internes.

Les modèles concernés, notamment GPT-5.6 Sol et un modèle en préversion plus performant, fonctionnaient avec des restrictions de sécurité réduites et sans les classificateurs habituels utilisés en production. Ils sont allés bien au-delà de la mission qui leur était confiée, en exploitant une vulnérabilité de proxy pour accéder à Internet, puis en utilisant des identifiants volés et des vulnérabilités « zero-day » afin de trouver un moyen d’exécuter du code à distance sur les serveurs de Hugging Face.

Il n’était pas nécessaire qu’il y ait intention malveillante

Rien n’indique publiquement que les modèles aient développé une intention criminelle ou aient choisi de nuire à Hugging Face. Ils n’en avaient pas besoin. Donnez à un système performant un objectif, des outils, du temps et du retour d’information, et il contournera les obstacles. La discussion a désormais dépassé le stade des invites et des réponses erronées. Il s’agit de systèmes capables d’enquêter, de tester des hypothèses, de découvrir des vulnérabilités jusque-là inconnues, d’utiliser des identifiants volés, d’élever leurs privilèges et de continuer à fonctionner lorsque la première approche échoue.

Un bac à sable n’est pas un champ de force

Nous qualifions les environnements d’isolés, segmentés et en « sandbox », comme si cette étiquette suffisait à garantir la sécurité. Ce n’est pas le cas. Dans ce cas précis, l’accès direct à Internet était bloqué, mais un proxy accessible via un progiciel ne l’était pas, et les modèles ont exploité sa vulnérabilité pour s’échapper. Les politiques et les comportements attendus ne suffisent pas. C’est l’environnement technique lui-même qui doit faire respecter les limites.

Pourquoi il s’agit d’une histoire de résilience

L’activité s’est propagée depuis un environnement d’évaluation, en passant par l’infrastructure de recherche d’OpenAI, vers Internet, puis dans l’environnement de production de Hugging Face. Il s’agit là d’un rayon d’impact qui s’étend rapidement. Lorsque l’IA peut explorer et agir à la vitesse d’une machine, le délai entre l’accès initial et une compromission à plus grande échelle risque de continuer à se réduire.

Hugging Face ne s’est pas contenté de bloquer la voie d’accès initiale et de déclarer l’incident clos. L’entreprise a corrigé les failles permettant l’exécution de code, réinstallé les nœuds compromis, renouvelé les identifiants et les jetons, et renforcé les contrôles du cluster. L’objectif n’est pas simplement de rétablir le fonctionnement du système, mais aussi de restaurer la confiance.

La question n’est plus seulement : « Nos systèmes d’IA sont-ils sûrs ? » Elle est désormais la suivante : « Lorsqu’un système d’IA puissant découvre une voie dont nous ignorions l’existence, sommes-nous capables de limiter l’ampleur des répercussions, de poursuivre les opérations essentielles, de reconstruire ce en quoi nous n’avons plus confiance et de prouver qu’il est sûr d’aller de l’avant ? » Chris Bevil est responsable principal du marketing de portefeuille chez Commvault.

La sécurité ne s’arrête pas aux limites des systèmes propres à une organisation. Les entreprises modernes connectent un réseau toujours plus vaste d’applications tierces à leurs plateformes centrales afin de soutenir leurs activités de vente, de service et de collaboration. Chacune de ces connexions apporte une valeur ajoutée. Chacune d’entre elles introduit également une vulnérabilité que l’organisation ne maîtrise pas entièrement.

Ce risque n’est pas hypothétique. En juin 2026, un acteur malveillant a compromis des jetons OAuth liés à Klue, une « platform » de veille concurrentielle utilisée pour synchroniser les données commerciales et marketing avec Salesforce. L’attaquant a utilisé ces jetons pour accéder aux environnements Salesforce des nombreuses organisations ayant autorisé cette intégration, dont Commvault.

Dès que nous avons été informés d’un impact potentiel, notre équipe de sécurité a déclenché notre procédure de gestion des incidents afin de déterminer ce qui s’était passé, de limiter l’exposition au risque et d’évaluer si les informations des clients ou les services Commvault avaient été affectés. Notre enquête a révélé que cette activité se limitait à certaines informations relatives aux relations commerciales et aux ventes stockées dans notre environnement Salesforce. L’enquête n’a révélé aucun élément indiquant que les données de sauvegarde des clients, les données sur les produits, les métadonnées sur les produits, les journaux d’exploitation ou les services Commvault aient été affectés.

Agir rapidement quand il le faut

Notre intervention s’est déroulée conformément aux procédures établies en matière de gestion des incidents de sécurité, conçues pour limiter rapidement les risques tout en permettant la conduite d’une enquête approfondie. Dès que nous avons été informés de l’incident, nous avons désactivé l’intégration Klue, révoqué les droits d’accès associés et collaboré avec les parties concernées afin de mener une évaluation complète des faits. Tout au long de l’enquête, nos équipes se sont employées à déterminer quelles informations avaient été consultées, à vérifier l’intégrité de notre environnement et à s’assurer que l’incident restait confiné à la zone que nous avions déjà maîtrisée.

Une tendance à noter

Cet incident illustre parfaitement une tendance que les équipes de sécurité observent depuis plusieurs années : les pirates ciblent désormais les applications tierces connectées aux systèmes métier clés plutôt que de s’attaquer directement à ces derniers. Une seule intégration compromise peut offrir un accès privilégié aux environnements de nombreuses organisations en aval simultanément, souvent en rencontrant moins de résistance qu’une attaque directe contre l’une d’entre elles.

Cela modifie la nature même des mesures de défense qu’une organisation doit mettre en place. Des contrôles internes rigoureux restent nécessaires, mais ils ne suffisent plus à eux seuls. Ils doivent être associés à une surveillance active de chaque application à laquelle l’organisation se connecte, ainsi qu’à une capacité de réaction qui soit prête avant qu’un incident ne se produise, et non mise en place pendant celui-ci.

Renforcer la résilience au-delà de notre propre environnement

Chez Commvault, notre programme de sécurité comprend une évaluation continue des applications tierces connectées à notre environnement. Nous examinons régulièrement ces applications, évaluons les droits d’accès dont chacune dispose, surveillons l’apparition de nouveaux risques et réévaluons ces intégrations à mesure que les besoins de l’entreprise et le paysage des menaces évoluent. Lorsque les circonstances l’exigent, nous prenons des mesures pour réduire notre exposition et renforcer notre posture de sécurité, notamment en désactivant les intégrations qui ne répondent plus à nos normes.

Notre engagement en faveur de la transparence

La confiance se construit grâce à la transparence et à la responsabilité. Lorsqu’un événement touche nos parties prenantes, nous estimons qu’il est important de communiquer les informations dont nous disposons, d’expliquer comment nous avons réagi et de partager les conclusions de notre enquête, même lorsque cet événement trouve son origine en dehors de nos propres systèmes. Nous continuerons à évaluer nos mesures de sécurité, à affiner nos processus de gestion des incidents et à renforcer notre approche en matière de risques liés aux tiers, dans le cadre de notre engagement global à protéger nos clients et nos partenaires.

Pour obtenir les informations officielles concernant cet incident, notamment l’étendue de l’enquête et les conseils destinés aux clients, veuillez consulter les mises à jour de notre Centre de confiance. Will Galway est responsable adjoint de la sécurité des systèmes d’information chez Commvault.

Pendant des années, la cryptographie post-quantique (PQC) est restée classée dans la catégorie « importante, mais pas urgente ».

Les responsables de la sécurité savaient qu’elle allait arriver. Les chercheurs en parlaient. Les organismes de normalisation y travaillaient. La plupart des organisations reconnaissaient qu’il faudrait, à terme, s’y intéresser. Mais je dirais que c’est maintenant qu’il faut commencer à s’y préparer.

Dans cet épisode de STRIVE, j’ai rencontré Michael Fasulo, directeur senior du marketing de portefeuille, pour discuter des raisons pour lesquelles le débat autour de la PQC évolue si rapidement – et pourquoi les organisations qui attendent d’avoir des certitudes pourraient bien se retrouver à court de temps. Regardez l’épisode dans son intégralité.

Points clés à retenir

• Les attaques de type « Harvest Now, Decrypt Later » (collecter maintenant, décrypter plus tard) signifient que les données sensibles sont déjà exposées à des risques, même si les capacités quantiques ne sont pas encore stables ni commercialement viables.
• La plupart des organisations n’ont pas une vue d’ensemble complète de leur inventaire cryptographique, ce qui fait de l’inventaire le premier obstacle majeur.
• La PQC est autant un défi technologique à relever qu’une question de hiérarchisation des risques.
• Les organisations qui commencent à se préparer dès maintenant disposeront de plus d’options pour ajuster leurs priorités que celles qui seront contraintes de réagir plus tard.

Le problème ne réside pas dans la technologie

La plupart des discussions sur la cryptographie post-quantique partent de la technologie.

• À quel rythme l’informatique quantique progresse-t-elle ?
• Quand les systèmes quantiques pertinents pour la cryptographie deviendront-ils opérationnels ?
• Quels algorithmes ont des chances de survivre à long terme ?

Ce sont là des questions importantes. Mais ce ne sont pas celles que je poserais en priorité. Michael a rédigé un article de blog l’année dernière sur la cryptographie post-quantique (PQC) et nous avons discuté aujourd’hui des nombreux changements intervenus depuis.

Au cours des dernières années, les estimations ont systématiquement évolué dans un seul sens : ce qui semblait autrefois lointain semble désormais de plus en plus proche. Parallèlement, les normes évoluent ; les attentes réglementaires s’intensifient, et les organisations commencent à prendre conscience de l’ampleur de la dette cryptographique qu’elles ont accumulée au fil des décennies.

La date exacte du « Q-Day » reste peut-être incertaine. Mais la direction prise ne l’est pas.

Le risque est bien réel et immédiat

L’une des raisons pour lesquelles ce débat est devenu plus urgent tient à l’attention croissante portée aux attaques de type « Harvest Now, Decrypt Later » (récolter maintenant, décrypter plus tard). Le concept est simple : un adversaire accède aujourd’hui à des informations chiffrées, les stocke et attend que des capacités futures lui permettent de les rendre lisibles.

Ce qu’il faut retenir ici, c’est que le risque ne commence pas avec l’avènement de l’informatique quantique. Il commence dès que des données, même chiffrées, sont exfiltrées et stockées.

Pour les organisations qui protègent la propriété intellectuelle, les dossiers médicaux, les informations gouvernementales ou d’autres données sensibles conservées à long terme, cette distinction change tout.

Les organisations doivent savoir si les données conservées aujourd’hui auront encore de l’importance lorsque cet avenir se concrétisera.

Pour beaucoup, en particulier dans les secteurs fortement réglementés et les infrastructures critiques, la réponse est oui.

Aperçu : Pourquoi l’agilité cryptographique est-elle importante ?

Intégrer la vidéo ici : https://www.youtube.com/watch?v=A3YWU5rlmGA

Dans cet extrait, Michael explique pourquoi la cryptographie post-quantique (PQC) n’est pas une solution ponctuelle ni un simple changement. Le véritable objectif est l’agilité cryptographique : développer la flexibilité nécessaire pour adapter les algorithmes cryptographiques à mesure que les normes et les menaces évoluent. Car en cybersécurité, le défi ne consiste pas seulement à se préparer à ce qui va suivre. Il s’agit d’être prêt pour ce qui viendra après.

La découverte est le véritable projet

Une idée fausse concernant la PQC est qu’il s’agit avant tout d’une mise à niveau du chiffrement. En réalité, la plupart des organisations n’ont pas encore atteint le stade où le remplacement constitue la principale préoccupation.

Elles en sont encore à essayer de cerner l’ampleur du problème. La cryptographie est omniprésente.

• Applications
• Certificats
• Services cloud
• API
• Signature de code
• Plateformes tierces

De nombreuses organisations rencontrent des difficultés pour établir l’inventaire cryptographique ou en définir la portée. Cela fait de l’inventaire l’une des étapes les plus importantes – et souvent sous-estimées – de ce parcours.

Et pour de nombreuses entreprises, il s’agit d’une tâche bien plus vaste que prévu.

Le défi de la chaîne d’approvisionnement

Une autre raison pour laquelle la cryptographie post-quantique (PQC) est devenue une priorité est qu’aucune organisation ne pourra mener à bien cette transition seule. Les entreprises modernes dépendent de fournisseurs, de prestataires de services cloud, de partenaires logiciels et d’innombrables tiers, qui utilisent tous la cryptographie.

Cela signifie que la Readiness à l’ère quantique va au-delà des systèmes internes. Il s’agit désormais d’une question de Readiness de l’écosystème.

• Les fournisseurs se préparent-ils ?
• Les fournisseurs clés prévoient-ils des migrations ?
• Les plateformes tierces sont-elles conformes aux nouvelles normes ?

Ces questions feront de plus en plus partie des échanges sur les risques, des discussions relatives aux achats et de la planification technologique à long terme. Car la cryptographie ne s’arrête pas aux frontières de l’organisation. Le risque non plus.

Pourquoi cette discussion est importante

Le principal enseignement à tirer de cette discussion est que la cryptographie post-quantique n’est plus un défi technologique futur.

C’est désormais un sujet d’actualité en matière de résilience.

Les organisations n’ont pas à céder à la panique et n’ont pas besoin de remanier tous leurs systèmes du jour au lendemain. Mais elles doivent s’y atteler dès maintenant, afin de tirer le meilleur parti du temps dont elles disposent pour se préparer.

Les organisations qui réussiront cette transition ne seront pas nécessairement celles qui disposent de la cryptographie la plus sophistiquée. Ce seront celles qui ont commencé à se familiariser avec le sujet avant même que la certitude ne s’impose.

Et c’est souvent ainsi que fonctionne la résilience.

Regardez l’épisode dans son intégralité

Michael et moi abordons bien d’autres sujets dans cet épisode que je n’ai pas mentionnés ci-dessus. Ne manquez pas de le regarder dès maintenant pour découvrir :

• Les principaux défis auxquels les organisations sont confrontées lorsqu’elles se lancent dans l’aventure de la cryptographie post-quanta (PQC).
• Ce que les dirigeants devraient privilégier dès aujourd’hui, y compris certaines bonnes pratiques.
• La compréhension des algorithmes MLKEM et de l’agilité cryptographique.
• Les considérations relatives à l’infrastructure pour la PQC.
• Comment Commvault se prépare à cet avenir.

FAQ

Q : Qu’est-ce que la cryptographie post-quantique (PQC) ?
R : La PQC désigne des algorithmes cryptographiques conçus pour garantir la sécurité face aux attaques des futurs ordinateurs quantiques.

Q : Qu’est-ce que le principe « Harvest Now, Decrypt Later » ?
R : Il s’agit d’une stratégie selon laquelle les attaquants collectent aujourd’hui des données chiffrées dans l’intention de les déchiffrer plus tard, lorsque des capacités de calcul plus avancées seront disponibles.

Q : Pourquoi les entreprises se concentrent-elles dès maintenant sur la PQC ?
R : Parce que la préparation prend des années, et que les données sensibles collectées aujourd’hui pourraient encore avoir de la valeur lorsque les menaces quantiques deviendront une réalité.

Q : Quel est le plus grand défi auquel les entreprises sont confrontées ?
R : L’inventaire. La plupart des entreprises ne disposent pas d’une visibilité complète sur les endroits où la cryptographie est utilisée au sein de leurs environnements.

Q : Les entreprises doivent-elles remplacer immédiatement l’ensemble de leurs systèmes de cryptographie ? R : Non. La plupart des experts recommandent de commencer par dresser un inventaire, recenser les éléments concernés et établir des priorités avant de planifier des migrations à plus grande échelle. Q : Que doivent faire en premier lieu les dirigeants ? R : Identifier les données sensibles à longue durée de vie, comprendre les dépendances cryptographiques et commencer à élaborer une feuille de route pour la transition future. Vidya Shankaran est directrice technique sur le terrain chez Commvault.