A l’occasion de sa conférence annuelle, Splunk propriété de Cisco a présenté des agents IA pour les équipes IT et de sécurité des entreprises. Elle bénéficieront de fonctions d’automatisation, d’une réponse proactive et une observabilité en temps réel.
Réunis à Boston pour l’évènement .con25, les clients et les partenaires de Splunk ont été attentifs aux annonces de la société rachetée par Cisco en mars 2024. Les deux entreprises poursuivent le travail d’intégration entre leur deux portefeuilles. Cette année, le cap est mis sur les agents IA qui s’invitent dans les solutions d’observabilité et sécurité. Ils visent à automatiser la réponse aux menaces, rationaliser les opérations IT et gérer les environnements complexes.
Une sécurité renforcée par les agents IA
Au cœur des annonces, il y a Enterprise Security Premier et Enterprise Security Essentials qui vont unifier les workflows de sécurité pour la détection, l’investigation et la réponse aux menaces (TDIR). Basés sur Enterprise Security 8.2, ces deux offres intègrent des agents d’IA capables d’orchestrer et d’automatiser des workflows complexes. « Nous avons combiné toutes les expériences de Splunk en une seule expérience produit unifiée », a expliqué Kamal Hathi, vice-président senior et directeur général de la division Splunk chez Cisco. Enterprise Security Essentials combine donc Enterprise Security 8.2, AI Assistant in Security et Detection Studio dans un paquet unique offrant une expérience unifiée. Quant à Enterprise Security Premier, il intègre en plus les fonctions SOAR (Security Orchestration, Automation, and Response) et UBEA (User and Entity Behavior Analytics).
Un agent sera chargé de l’analyse des comportements des utilisateurs et des machines (UEBA). (Crédit Photo: Splunk)
Sur la partie sécurité, Splunk a également mis à jour ses agents IA avec des fonctionnalités supplémentaires. Ainsi, un agent de triage évalue, hiérarchise et explique les alertes afin de simplifier la tâche des analystes et mettre en évidence les alertes les plus significatives. L’agent de neutralisation des malwares décrit les scripts malveillants, extrait les indicateurs de compromission, signale les tentatives d’évasion et regroupe les comportements récurrents. De son côté, AI Playbook Authoring traduit l’intention du langage naturel en playbooks SOAR fonctionnels et testés. L’agent Response Importer respecte les procédures opérationnelles standard définies par le centre des opérations de sécurité (SOC) et utilise LLM pour importer procédures dans les plans de réponse de sécurité des entreprises. Une librairie de détection améliorée par l’IA optimise les réponses à incident. De même, un générateur SPL (search processing language) personnaliser les détections dans la bibliothèque pour les aligner sur les environnements SOC. Enfin, WebEx Response Automation crée des salles de crises dans l’outil de visioconférence de Cisco à l’aide de playbooks SOAR lorsqu’un incident se produit. A noter que Cisco a également intégré Isovalent Runtime Security eBPF (extended Berkeley Packet Filter) dans Splunk afin d’offrir une visibilité sur l’ensemble des charges de travail et d’identifier les failles de sécurité potentielles et les anomalies de l’infrastructure. Le fournisseur a par ailleurs étendu la recherché fédérée de Splunk Cloud pour Amazon S3 et security analytics and loggings (SAL) donnant la capacité aux analystes d’effectuer des analyses de sécurité sur les journaux de pare-feu stockés dans SAL.
Des améliorations de l’observabilité grâce à l’IA
Cisco a aussi annoncé la mise à jour de Splunk Observability afin d’utiliser Cisco AgenticOps, qui déploie des agents IA pour automatiser la collecte de données télémétriques, détecter les problèmes, identifier les causes profondes et appliquer des correctifs. Ces mises à jour des agents IA aident les entreprises clientes à automatiser la détection des incidents, l’analyse des causes profondes et les correctifs de routine. « Nous veillons à ce que tous nos outils, tant dans AppDynamics que dans Observability Cloud, tirent réellement parti des atouts les uns des autres, c’est-à-dire qu’ils peuvent exploiter les données et les informations provenant à la fois de la télémétrie d’observabilité traditionnelle et de l’entreprise », a expliqué Kamal Hathi. « C’est une toute nouvelle dimension de l’observabilité qui permet de comprendre non seulement les performances d’une machine, d’une application, d’un réseau ou d’une infrastructure, mais aussi l’impact réel sur l’activité. Un dernier élément se situe autour de la notion d’observation et de compréhension de ce que fait l’IA elle-même. »
Splunk intègre les données métiers et les données machine afin de proposer aux entreprises de corréler les problèmes techniques avec leur impact métier et d’offrir une visibilité sur le comportement et les performances des systèmes et des agents IA. Parmi les fonctionnalités, on trouve AI-Directed Troubleshooting qui fournit un dépannage guidé par l’IA basé sur l’analyse des incidents et l’identification de leurs causes profondes. De son côté, Event IQ aide les équipes à configurer la corrélation des alertes automatisées. La fonction ITSI (IT service Intelligence) episode summarization livre des aperçus des alertes regroupées. Quant à AI agent monitoring, il est en charge de surveiller la qualité et le coût des LLM. Il est complété par l’agent en charge de la surveillance de la santé et la consommation de l’infrastructure. Cisco rassemble AppDynamics et Observability Cloud, tout en approfondissant l’intégration avec ThousandEyes afin que les équipes d’entreprise puissent mieux identifier l’impact du réseau sur les performances des applications et l’expérience des utilisateurs finaux.
La fonction Event IQ utilise l’IA pour créer des corrélations d’alertes qui réduisent le bruit. (Crédit Photo: Splunk)
« Cela fait des années que nous intégrons l’IA et nous sommes ravis d’annoncer l’ajout de fonctionnalités basées sur l’IA agentique à l’ensemble du portefeuille Splunk Observability afin d’aider les équipes à enquêter et à résoudre les problèmes plus rapidement », ont écrit Dayna Lord et Patrick Lin dans un blog. « Grâce à la corrélation des alertes basée sur l’IA, au résumé des épisodes et aux agents d’IA pour la détection, le dépannage et la remédiation, l’IA agentique permet aux équipes de comprendre, de dépanner et de résoudre plus rapidement les incidents ayant un impact sur l’activité. »
Microsoft a publié des correctifs de sécurité pour 81 failles dont deux sont de type zero day. La première touche Windows SMB, mais fait l’objet d’une polémique, et l’autre répare une faille datant de 2024. D’autres brèches à ne pas négliger concernent Hyper-V, NTLM et le pack HPC.
En ce mois de rentrée, Microsoft épargne les RSSI et administrateurs systèmes avec un Patch Tuesday plus léger que les précédents. La livraison de septembre comprend 81 correctifs contre 137 en août dernier. Dans le détail, 13 des failles corrigées sont considérées comme critiques. Satnam Narang, chercheur chez Tenable, souligne que, ce mois-ci, Microsoft a réparé davantage de vulnérabilités d’élévation de privilèges que de failles d’exécution de code à distance. Dans l’ensemble de ces correctifs, les équipes de sécurité devront se pencher en priorité sur deux vulnérabilités zero day.
Une controverse sur la faille touchant Windows SMB
La première – référencée comme CV-2025-5534 – concerne une faille d’élévation de privilèges dans Windows SMB (Server Message Block). Elle a déjà été diffusée publiquement. Dans certaines configurations, cette brèche pourrait exposer le serveur SMB aux attaques par relais, a déclaré Microsoft. Ce correctif semble avoir été publié pour aider les clients à auditer et évaluer leur environnement et à identifier les problèmes d’incompatibilité avant d’utiliser certaines fonctionnalités de renforcement des serveurs SMB, a déclaré Satnam Narang. Un avis partagé par Mike Walters, président d’Action1, « ce correctif est un exemple de correctifs de septembre qui nécessitent des activités supplémentaires après le déploiement ». Les entreprises doivent d’abord déployer les mises à jour pour activer l’audit, puis évaluer la compatibilité avant de prendre des mesures de renforcement des serveurs PME, notamment la signature et la mise en œuvre de la protection étendue pour l’authentification. Les RSSI devraient planifier une approche progressive du renforcement, incluant l’évaluation, les tests et la mise en œuvre, afin d’éviter toute interruption d’activité, a conseillé le dirigeant.
Pour autant d’autres spécialistes critiques l’usage abusif du classement CVE de la faille. Tyler Reguly, directeur associé de la R&D chez Fortra, a déclaré, « elle aurait dû être rejetée par les autorités CVE. Nous savons que les attaques par relais sont possibles contre les PME et que des mécanismes de renforcement existent pour y remédier ». Il ajoute que Microsoft explique cette CVE a été publiée « pour fournir des fonctionnalités d’audit et d’évaluation » et que dans ce cadre, « il s’agit d’une utilisation abusive du système CVE ». Pour lui, « les RSSI devraient demander à Microsoft si cette CVE présente réellement une vulnérabilité. Si un fournisseur se sert d’une CVE simplement pour ajouter une fonctionnalité, les RSSI du monde entier doivent s’y opposer ».
La seconde faille critique n’est pas récente. Elle a été divulguée en 2024 et cible Newtonsoft.Json incluse dans SQL Server. « La CVE-2024-21907 corrige une vulnérabilité de gestion de conditions exceptionnelles dans Newtonsoft.Json avant la version 13.0.1 », explique Microsoft. Il ajoute, « Les données trafiquées transmises à la méthode JsonConvert.DeserializeObject peuvent déclencher une exception StackOverflow entraînant un déni de service. Selon l’utilisation de la bibliothèque, un attaquant distant non authentifié peut provoquer le déni de service.»
Vulnérabilités dans Hyper-V et Windows NTLM
Les administrateurs Windows doivent également veiller à corriger rapidement deux vulnérabilités (CVE-2025-54098 et CVE-2025-55224) dans l’hyperviseur de type 1 Hyper-V. Un contrôle d’accès inapproprié dans celui-ci peut donner à un attaquant autorisé la capacité d’élever les privilèges localement, a déclaré la firme de Redmond. Selon Mike Walter, ces failles exigent une attention particulière de la part des RSSI gérant les datacenters des entreprises. « Ces failles de type « invité vers hôte » pourraient mettre en danger des hôtes de virtualisation entiers exécutant des charges de travail critiques » constate-t-il. Il ajoute « les responsables de la sécurité doivent collaborer étroitement avec celles des centres de données et de virtualisation pour appliquer rapidement ces correctifs dans les environnements de production. »
Le dirigeant a également attiré l’attention des équipes sécurité sur la vulnérabilité CVE-2025-54918 provoquant des élévation de privilèges sur NTLM de Windows, une suite de protocoles d’autorisation utilisateur. Avec un score CVSS de 8,8, la faille affecte l’infrastructure d’authentification gérée de manière centralisée et donne aux attaquants les moyens d’obtenir des privilèges au niveau du système sur les réseaux, a-t-il déclaré. Microsoft l’a classée comme « exploitation très probable », a-t-il souligné, indiquant une urgence plus élevée que d’autres vulnérabilités similaires moins susceptibles d’être exploitées. « Les équipes doivent corriger rapidement les contrôleurs de domaine et les serveurs d’authentification, ce qui pourrait accélérer les cycles de correctifs normaux pour ces systèmes critiques », a-t-il ajouté.
Le pack HPC touché
Parmi les autres failles corrigées, Tyle Reguly de Forttra signale une vulnérabilité critique dans le pack HPC (High Performance Compute) de Microsoft. La CVE-2025-55232 donne la capacité à des attaquants non autorisés d’exécuter du code sur le réseau. « Il s’agit donc d’une vulnérabilité CVSS 9.8 à laquelle il convient de prêter attention », a-t-il déclaré. Microsoft a fourni des mesures d’atténuation pour ceux qui ne peuvent pas effectuer la mise à jour immédiatement. C’est important, a ajouté le responsable car la mise à jour pour HPC Pack 2016 vise à migrer vers HPC Pack 2019 ; il n’existe pas de correctif pour HPC Pack 2016. « Heureusement, Microsoft a qualifié cette vulnérabilité d’exploitation de peu probable, avec une gravité importante », a-t-il précisé, « mais il convient d’y prêter attention si le pack HPC Pack est déployé dans votre environnement. »
Enfin, Satnam Narang de Tenable insiste sur la correction d’une vulnérabilité touchant NTFS et provoquant une exécution de code à distance. Selon l’expert, elle n’est pas à négliger, car NTFS est le principal système de fichiers utilisé par Windows.
Une attaque nommée GhostAction a visé GitHub Actions. Des pirates sont parvenus à détourner des identifiants et et voler 3 325 secrets provenant de centaines de référentiels npm et PyPI.
Dans une vaste attaque de type supply chain contre Github Actions, des pirates sont parvenus à dérober 3 325 secrets à 327 utilisateurs dans 817 référentiels. Les workflows qui ont été visés sont des processus automatisés définis dans un référentiel GitHub répondant à des événements spécifiques. « Les chercheurs en sécurité de GitGuardian ont été alertés en interne de la compromission potentielle d’un référentiel GitHub associé au projet FastUUID », ont déclaré Gaetan Ferry et Guillaume Valadon, chercheurs en sécurité chez l’éditeur, dans un article de blog. « Les investigations ont révélé qu’un fichier de workflow GitHub malveillant avait été injecté dans le projet ». L’utilisateur compromis a poussé des commits malveillants identiques vers d’autres référentiels publics et privés. Des identifiants PyPI, npm, DockerHub ont été volés ainsi que des jetons GitHub et bien d’autres encore. Ils ont été transmis via des requêtes HTTP POST à un point de terminaison contrôlé par l’acteur. La campagne a été détectée et contenue le 5 septembre.
Des jetons CI/CD interceptés
La campagne GhostAction concerne le projet Python FastUUID dans lequel un contributeur identifié par le pseudonyme « Grommash9 » a introduit une modification du workflow le 2 septembre. La modification contenait un code qui extrayait des jetons sensibles, tels que le PYPI_API_TOKEN, et les transmettait via des requêtes HTTP POST à un domaine contrôlé par l’attaquant. « Même si ce jeton aurait dû permettre à l’acteur de compromettre le paquet FastUUID sur PyPI, aucune preuve de publication de paquets malveillants n’a été trouvé pendant la période de compromission », ont déclaré les chercheurs, ajoutant que l’inaction de l’attaquant après la compromission initiale suggérait que FastUUID n’était pas la cible principale.
Dans un deuxième temps, les enquêteurs ont découvert des workflows malveillants similaires dans cinq référentiels publics au moins et une dizaine de référentiels privés. L’attaque était très adaptative, ciblant des secrets spécifiques à l’environnement, depuis des identifiants de registre de conteneurs jusqu’aux clés des fournisseurs de cloud. « Le modèle d’attaque est resté le même pour tous les projets. Le pirate a d’abord répertorié les secrets provenant de fichiers de workflows légitimes, puis a codé en dur ces noms secrets dans des workflows malveillants », ont ajouté les chercheurs. GhostAction a exfiltré des milliers de jetons sensibles qui auraient pu être utilisés pour altérer des paquets, accéder sans autorisation à des infrastructures ou compromettre davantage la chaîne d’approvisionnement.
Une menace maîtrisée en quelques jours
L’équipe de sécurité de GitGuardian a réagi rapidement après la détection, et le paquet FastUUID a été verrouillé en lecture seule par les administrateurs PyPI en quelques minutes. Le commit frauduleux a été annulé peu après. GitGuardian a averti les responsables des dépôts concernés, contactant avec succès 573 projets, tout en alertant les équipes de sécurité de GitHub, npm et PyPI afin qu’elles surveillent les abus. Même si aucun paquet malveillant n’avait encore été publié dans les registres officiels, GitGuardian a signalé que certains paquets étaient potentiellement toujours exposés à des risques. « D’après nos premières investigations, 9 paquets npm et 15 paquets PyPI risquent d’être compromis dans les prochaines heures ou les prochains jours », ont mis en garde les chercheurs. Ces derniers ont publié sur le blog une liste d’indicateurs de compromission, notamment des indicateurs réseau et GitHub Workflow. Pour une protection supplémentaire, ils ont insisté sur l’importance de revoir les workflows des référentiels, de modifier les identifiants exposés et d’adopter des contrôles plus stricts pour GitHub Actions afin d’éviter que des incidents similaires ne se reproduisent à l’avenir.
Les écosystèmes de paquets tels que npm et PyPI restent des cibles fréquentes en raison de leur popularité et de leur large portée au sein de la communauté des développeurs. Au-delà de la publication directe de paquets malveillants, comme la récente campagne de reconnaissance npm, les attaquants ont également utilisé des techniques telles que le typosquatting (qui exploite les fautes de frappe et d’orthographe) ou même l’exploitation de dépendances hallucinées par l’IA pour inciter les développeurs à installer du code compromis.
Autonomes, adaptatifs et interconnectés, les systèmes d’IA agentique sont à la fois un facteur de productivité et un multiplicateur de risques cyber. Pour sécuriser leur activité, les approches traditionnelles de sécurité pourraient ne pas suffire.
Les entreprises utiliseront sans aucun doute l’IA agentique pour un nombre croissant de workflows et de processus, notamment dans le développement logiciel, le support client, ou dans l’évolution de la robotisation des processus (RPA) et l’assistance aux employés. Sauf que ces déploiements annoncés soulèvent bien des questions pour les RSSI et leurs équipes : quels sont les risques de cybersécurité liés à l’IA agentique ? Quels efforts supplémentaires mettre en oeuvre pour concrétiser les ambitions de leur organisation en matière d’IA agentique ?Dans un rapport de 2024 analysant la façon dont les acteurs malveillants pourraient exploiter l’IA en 2025, Cisco Talos souligne que les systèmes et modèles d’IA capables d’agir de manière autonome pour atteindre leurs objectifs sans intervention humaine pourraient mettre en péril les organisations qui ne sont ni préparées ni équipées pour gérer les systèmes agentiques et leurs compromissions éventuelles.« À mesure que les systèmes agentiques s’intègrent de plus en plus à des services et des fournisseurs divers, les risques d’exploitation ou de vulnérabilité se multiplient, écrivent les auteurs du rapport. Les systèmes agentiques peuvent également être capables de mener des attaques en plusieurs étapes, de trouver des moyens créatifs d’accéder à des systèmes de données à accès restreints, d’enchaîner des actions apparemment anodines pour bâtir des séquences dangereuses ou d’apprendre à échapper à la détection des services de défense des réseaux et systèmes. »Nouvelle catégorie de risques cyberIl est clair que l’IA agentique constituera un défi majeur pour les équipes de cybersécurité et que les RSSI doivent prendre part au débat concernant cette technologie, à mesure que leurs organisations l’adoptent. C’est d’autant plus vrai que de nombreuses entreprises se sont lancées dans les déclinaisons de l’IA sans vraiment se soucier de renforcer leurs systèmes.Alors que les entreprises adoptent l’IA agentique pour améliorer leur efficacité, leur prise de décision et leur automatisation, « elles doivent également faire face à une nouvelle catégorie de risques cyber, explique Sean Joyce, responsable de la cybersécurité et de la confidentialité au sein du cabinet de conseil PwC. Contrairement aux modèles d’IA traditionnels qui répondent à des sollicitations directes, ces systèmes peuvent agir de manière autonome pour atteindre des objectifs généraux, prendre des décisions, interagir avec d’autres systèmes et adapter leur comportement au fil du temps. » Pour les RSSI, « comprendre et atténuer ces risques émergents est essentiel pour favoriser une adoption sûre et responsable de l’IA », souligne Sean Joyce.Voici quelques-uns des principaux enjeux et risques impliqués.1 Manque de visibilité et essor du shadow IALes RSSI n’aiment pas travailler dans le brouillard, et c’est l’un des risques liés à l’IA agentique. Elle peut être déployée de manière autonome par des équipes, voire des utilisateurs individuels, via diverses applications, sans supervision adéquate des services IT et cyber. Cela crée des « agents d’IA fantômes » qui peuvent fonctionner sans contrôles basiques, tels que l’authentification, ce qui rend difficile le suivi de leurs actions et de leur comportement. Cela peut entraîner des risques de sécurité importants, car des agents invisibles peuvent introduire des vulnérabilités.« Le manque de visibilité engendre plusieurs risques pour les organisations, notamment des risques de sécurité, des problèmes de gouvernance/conformité, des risques opérationnels et un manque de transparence, qui peut entraîner une perte de confiance des employés, des fournisseurs, etc., et freiner l’adoption de l’IA », explique Reena Richtermeyer, associée chez CM Law, qui représente des développeurs d’IA ainsi que de grandes entreprises et entités gouvernementales mettant en oeuvre l’IA.« Le principal problème que nous constatons est véritablement le manque de visibilité », souligne Wyatt Mayham, consultant en IA au sein du cabinet de conseil Northwest AI. L’IA agentique débute souvent en périphérie du réseau, lorsque des utilisateurs configurent ChatGPT et d’autres outils pour automatiser certaines tâches, explique-t-il. « Et ces agents ne sont ni approuvés, ni contrôlés par la DSI, ce qui signifie qu’ils ne sont ni enregistrés, ni versionnés, ni gouvernés », précise le consultant. Les RSSI sont habitués aux logiciels SaaS déployés sans approbation ; ils doivent désormais composer avec le Shadow IA« Les organisations ignorent souvent où ces systèmes sont implémentés, qui les utilise et leur degré d’autonomie, explique Pablo Riboldi, RSSI chez BairesDev, une société de développement logiciel nearshore. Il en résulte un problème majeur de shadow IT, car les équipes de sécurité peuvent ignorer les agents qui prennent des décisions en temps réel ou accèdent à des systèmes sensibles sans contrôle centralisé. »2 Davantage d’autonomie signifie davantage de risquesL’IA agentique permet de laisser la technologie prendre des décisions et agir sans supervision humaine. Ce qui se traduit aussi par des risques cyber. « Les systèmes d’IA agentique sont axés sur les objectifs, explique Sean Joyce. Lorsque ceux-ci sont mal définis ou ambigus, les agents peuvent agir de manière non conforme aux normes de sécurité ou d’éthique de l’entreprise. »Par exemple, si un agent reçoit l’ordre de réduire le « bruit » dans le centre des opérations de sécurité, il risque d’interpréter cela de manière trop littérale et de supprimer des alertes valides dans le but de rationaliser les opérations, laissant l’organisation aveugle lors d’une intrusion, souligne l’expert de PwC.Les systèmes d’IA agentique étant conçus pour agir de manière indépendante, sans gouvernance solide, cette autonomie peut rapidement devenir un handicap, ajoute Pablo Riboldi. « Un agent apparemment inoffensif recevant des instructions vagues ou mal définies peut outrepasser ses limites, lancer des workflows, altérer des données ou interagir avec des systèmes critiques de manière imprévue », énumère le RSSI.Dans un environnement d’IA agentique, « on rencontre beaucoup d’actions effectuées de façon autonome, sans supervision », explique Wyatt Mayham. « Contrairement à l’automatisation traditionnelle, les agents font des choix qui peuvent impliquer de cliquer sur des liens, d’envoyer des e-mails ou de déclencher des workflows. Tout cela repose sur un raisonnement probabiliste. Lorsque ces choix sont erronés, il est difficile d’en déterminer la cause. Nous avons constaté que certains de nos clients exposaient accidentellement des URL internes sensibles par méconnaissance de la signification des implications d’un ‘partage sécurisé’ ».3 Systèmes multi-agents : des partages indésirables de données Les systèmes multi-agents sont très prometteurs pour l’entreprise, mais l’interaction et le partage de données entre agents IA présentent des risques liés à la sécurité, à la confidentialité et peuvent déboucher sur des conséquences imprévues, explique Reena Richtermeyer de CM Law. « Ces risques découlent de la capacité de l’IA à accéder à de vastes volumes de données, de son autonomie et de la complexité à gouverner des systèmes d’IA multi-agents », explique-t-elle.Par exemple, les agents d’IA peuvent accéder à des informations sensibles, parfois soumises à des contrats ou à une réglementation stricte, et les traiter. Ce qui peut entraîner une utilisation ou une divulgation de ces informations et, potentiellement, engager la responsabilité de l’organisation, reprend l’avocate.« Dès qu’une configuration multi-agents est mise en place, un risque de coordination s’installe », renchérit Wyatt Mayham de Northwest AI. « Un agent pourrait étendre la portée d’une tâche d’une manière imprévue, qu’un autre agent n’a pas été formé à gérer. Sans sandboxing, cela peut entraîner un comportement imprévisible du système, surtout si les agents ingèrent de nouvelles données issues d’un fonctionnement en production.»Car les agents collaborent souvent avec d’autres agents pour effectuer des tâches, ce qui engendre des chaînes de communication et de prise de décision complexes, explique Sean Joyce de PwC. « Ces interactions peuvent propager des données sensibles de manière imprévue, créant des risques de conformité et de sécurité », précise-t-il. Par exemple, un agent du service client résume les informations de compte pour un agent interne chargé de l’analyse de la rétention client. Ce second agent stocke les données dans un emplacement non protégé pour une utilisation ultérieure, violant ainsi les politiques internes de gestion des données.4 Intégration de tiers : les risques de la supply chain logicielle de l’IALes agents peuvent également intégrer et partager des données avec les applications de partenaires via des API. Un défi supplémentaire pour les RSSI, car l’intégration avec des services et des fournisseurs multiples et variés peut augmenter les risques et introduire de nouvelles vulnérabilités.L’IA agentique s’appuie fortement sur les API et les intégrations externes, note Pablo Riboldi (BairesDev). « Plus un agent accède à des systèmes divers, plus son comportement devient complexe et imprévisible, ajoute-t-il. Ce scénario introduit des risques sur la supply chain logicielle, car une vulnérabilité dans un service tiers pourrait être exploitée ou déclenchée par inadvertance via des interactions agentiques sur différentes plateformes. »De nombreux agents lancés en phase pilote ou en expérimentation s’appuient sur des API fragiles ou non documentées, ou sur l’automatisation des navigateurs, explique Wyatt Mayham (Northwest AI). « Nous avons constaté des cas où des agents divulguent des jetons via des intégrations mal définies, ou exfiltrent des données via des chaînes de plugins non anticipées. Plus la stack de fournisseurs est fragmentée, plus la surface d’exposition à ce type de problème est grande », ajoute-t-il.« Chaque point d’intégration élargit la surface d’attaque et peut introduire des vulnérabilités dans la supply chain, abonde Sean Joyce (PwC). Par exemple, un agent d’IA s’intègre à une plateforme RH d’un fournisseur pour automatiser l’onboarding des salariés. Or, l’API de ce fournisseur présente une vulnérabilité connue, un attaquant peut alors l’exploiter pour s’offrir un accès aux systèmes RH internes par déplacement latéral. »De nombreux outils agentiques s’appuient sur des bibliothèques et des frameworks d’orchestration Open Source, qui peuvent receler des vulnérabilités inconnues des équipes de sécurité, ajoute encore Sean Joyce.5 Les attaques multi-étapes brouillent la frontière entre erreur et exploitLes systèmes agentiques recèlent également un potentiel pour mener des attaques multi-étapes et trouver de nouveaux moyens d’accéder à des systèmes de données à accès restreints en échappant à la détection des outils de sécurité.« À mesure que les systèmes agentiques gagnent en sophistication, ils peuvent développer ou apprendre par inadvertance des comportements sophistiqués qui imitent les attaques multi-étapes, explique Pablo Riboldi. Pire encore, ils peuvent involontairement découvrir des moyens de contourner les méthodes de détection traditionnelles, non pas parce qu’ils sont malveillants, mais parce que leur comportement, axé sur l’atteinte d’objectifs, encourage l’évasion. » Ce qui brouille la frontière entre erreur et exploit, explique le RSSI. Et complique la tâche des équipes de sécurité pour déterminer si un incident est issu d’une attaque, s’il s’agit d’un comportement émergent, ou les deux.Ce type de risque « est moins théorique qu’il n’y paraît », reconnaît Wyatt Mayham. Lors de tests en laboratoire, nous avons vu des agents solliciter des chaines d’outils de manière inattendue, non pas de manière malveillante, mais plutôt créative. Imaginez maintenant que cette même capacité de raisonnement soit exploitée pour sonder des systèmes, tester des terminaux et éviter les outils de détection basés sur des schémas prédéfinis. »Comme l’IA agentique peut apprendre des feedbacks qu’elle reçoit, elle pourrait modifier son comportement pour éviter de déclencher les systèmes de détection, intentionnellement ou non, souligne Sean Joyce. « Cela représente un sérieux défi pour les outils traditionnels de détection et de réponse aux incidents basés sur des règles », dit-il. Un agent pourrait déterminer que certaines actions déclenchent des alertes sur telle plateforme de détection des menaces sur les endpoints et ajuster sa méthode pour rester sous les radars, de la même manière qu’un logiciel malveillant s’adapte aux analyses antivirus.A nouveau paradigme, nouveaux modèles de défenseL’IA agentique est un modèle très attractif pour les entreprises, affirme Sean Joyce (PwC), mais aussi un défi en matière de cybersécurité. « Son autonomie, son adaptabilité et son interconnectivité en font à la fois un multiplicateur de productivité et un vecteur d’attaque potentiel, résume-t-il. Pour les RSSI, les modèles de sécurité traditionnels ne suffisent plus. »Selon lui, une stratégie de défense robuste de l’IA agentique doit inclure les fondamentaux suivants :- Observabilité et télémétrie en temps réel ;- Politiques de gouvernance rigoureuses ;- Pratiques de développement sécurisées by-design ;- Coordination entre les équipes de sécurité, la DSI, le département data et la conformité« En adoptant une approche de sécurité proactive et multicouche et en intégrant la gouvernance d’emblée, les organisations peuvent tirer parti des promesses de l’IA agentique tout en minimisant les risques qu’elle comporte », assure Sean Joyce.
Le fournisseur vient de livrer la version 4.0 de Prisma avec plusieurs évolutions dont une concernant les risques liés aux navigateurs.
La plateforme SASE (secure access service edge) Prisma de Palo Alto Networks passe en version 4.0 et apporte son lot d’évolutions. Parmi elles, on trouve une sécurité avancée des données au sein du navigateur. Selon le fournisseur, Prisma Browser couvre les menaces Web que les offres traditionnelles ne parviennent pas à détecter. Les applications et les données critiques résident dans le navigateur, et ils ne peuvent pas fournir les contrôles de sécurité nécessaires pour faire face au nombre croissant de cyberattaques. « La protection avancée de Prisma Browser inspecte les pages Web entièrement et détecte les menaces en temps réel », a expliqué Palo Alto Networks.
« La notion de périmètre traditionnel est obsolète, grâce à l’IA, les attaques plus rapides et plus sophistiquées des adversaires peuvent contourner les proxys et les pare-feux applicatifs (WAF). Les attaquants se cachent dans le trafic chiffré, assemblent des logiciels malveillants directement dans le navigateur et exploitent le DNS à grande échelle », a écrit Anupam Upadhyaya, vice-président senior de la gestion des produits pour toutes les plateformes SASE chez Palo Alto, dans un blog consacré à la sortie du produit.
Une classification des données basées sur l’IA
Il évoque une autre menace « les données sensibles circulent à travers d’innombrables canaux (structurés et non structurés), documents, codes sources et contenus générés par l’IA. La sécurité traditionnelle peine à suivre le rythme, tandis que les outils ponctuels ralentissent les utilisateurs et créent des solutions de contournement risquées ». Pour répondre à cette problématique, Prisma 4.0 propose des outils de classifications basés sur des modèles pré-entraînés pour lister automatiquement les informations sensibles dans tous les formats, y compris le contenu non structuré et les données en cours d’utilisation, ce qui réduit le nombre de faux positifs.
Enfin, « la fonctionnalité Private Application Security protège automatiquement ces applications essentielles et met à jour en continu les politiques de sécurité des applications », a affirmé Palo Alto Networks. Les entreprises peuvent ainsi de détecter les anomalies et de bloquer les botnets, les abus d’API et les exploits Day-0 sans avoir recours à des mises à jour manuelles constantes. A noter que les mises à jour du produit Prisma SASE 4.0 devraient être disponibles dans le courant de l’année.
Prévue pour la fin du mois, la dernière version de la célèbre base de données open source ajoute des capacités pour des transactions plus rapides. Mais PostgreSQL 18 ne dispose pas des fonctionnalités dédiées aux charges de travail hybride et aux agents IA.
L’arrivée prochaine de PostgreSQL 18 divise les experts quant à son contenu. En effet, la dernière version de la base de données open source introduit des fonctionnalités qui améliorent les performances avec des gains significatif pour les charges de traitement transactionnel en ligne (OLTP). Mais elle fait l’impasse sur deux thèmes très tendances : le support des charges de travail hybride mêlant transactionnel et analytique (OLAP), et les agents IA. PostgreSQL est devenue une base de données incontournable…
Il vous reste 93% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
L’approche zero trust commence à être adoptée comme principe de cybersécurité, mais sa mise en oeuvre reste complexe et longue. Beaucoup d’entreprises rencontrent des difficultés à en mesurer les bénéfices à court terme.
Selon un récent rapport d’Accenture, près de neuf responsables de la sécurité sur dix rencontrent des difficultés majeures dans la mise en œuvre de l’approche zero trust. La complexité inhérente à ce type de déploiement, la résistance de certaines directions métiers et le temps extrêmement long nécessaire pour obtenir un retour sur investissement tangible expliquent en grande partie la frustration des RSSI.
Changer de culture et clarifier le concept
Une part importante de la difficulté du zero trust vient de sa définition variable selon les entreprises. Comme le souligne Prashant Deo, responsable mondial cybersécurité chez Tata Consultancy Services : « Il s’agit d’une transformation stratégique, pas d’un simple déploiement tactique, et c’est pourquoi la méthoe trust reste un chantier complexe pour l’ensemble du secteur. » Karen Andersen, architecte identité chez World Wide Technology, complète : « Le terme est ambigu, certains pensent qu’il s’agit d’un produit, d’autres d’une stratégie. Il peut sembler être un buzzword, mais la stratégie derrière reste pertinente. » Chaque environnement est unique et exige une grande flexibilité : conformité, localisation géographique, secteur d’activité, partenaires et accès tiers varient fortement, tout comme les infrastructures on-premise, cloud, sites distants, IoT ou systèmes hérités.
Au-delà des aspects techniques, le zero trust impose un changement de culture majeur. « Pendant des décennies, la sécurité reposait sur la confiance implicite dans le périmètre réseau. Il exige l’inverse total : ne jamais faire confiance, toujours vérifier », rappelle Prashant Deo. « Faire évoluer l’ensemble d’une entreprise vers cette logique est un défi considérable. Pour Karen Andersen, il est même étonnant que seuls 88 % des responsables de la sécurité déclarent rencontrer des difficultés : « Je veux rencontrer les 12 % qui n’ont pas trouvé cela difficile », plaisante-t-elle.
Un parcours sans fin
Un déploiement complet du zero trust peut prendre plus d’une décennie, selon l’architecte « Quand je l’explique à la direction, je parle d’une feuille de route sur 10 à 12 ans pour construire une vraie base. On n’atteint jamais vraiment la fin du zero trust. » Saleh Hamdan Al-Bualy, ancien responsable sécurité du groupe The Four Seasons Hotels, insiste sur la complexité et l’absence d’incitations concrètes. « Il n’y a absolument aucun intérêt immédiat à le faire. Tant qu’on ne l’implémente pas entièrement, on ne retire aucun bénéfice », précise-t-il. Selon lui, le succès du zero trust passe par un soutien ferme de la direction, à l’instar de ce qui a été observé pour l’IA générative.
Will Townsend, VP et analyste principal chez Moor Insights & Strategy, souligne que la rémunération des RSSI ne favorise pas un déploiement enthousiaste. « La rétribution n’est pas alignée sur les objectifs zero trust. Les entreprises cotées vivent au rythme des trimestres, ce qui valorise surtout la productivité métier et la sécurisation du cloud. Difficile de mesurer un ROI immédiat sur l’hygiène sécurité. » Enfin, Prashant Deo ajoute que le manque de visibilité sur l’ensemble des flux de données et les menaces à l’échelle globale complique également l’adoption.
Invoquant un besoin croissant de gouvernance neutre et communautaire, la fondation Rust a annoncé un programme de soutien à des projets innovants avec son programme Innovation Lab. La bibliothèque de sécurité de la couche de transport Rustls est le premier à en bénéficier.
Soutenant le développement du langage de programmation open source Rust et de ses différents projets depuis sa création en 2021, la fondation Rust lance sa dernière initiative : Innovation Lab. Son but ? Apporter une aide à des projets open source pertinents. Annoncé le 3 septembre, ce parrainage du Rust Innovation Lab comprend un soutien au niveau gouvernance, juridique, réseautage, marketing et d’administration. La création de cette structure intervient à un moment charnière selon la fondation.
Le premier projet sponsorisé, Rustls, une bibliothèque TLS (Transport Layer Security) flexible, performante et sécurisée pour la mémoire explique l’organisme à but non lucratif. Cet outil répond à une demande croissante en matière de sécurisation au niveau de la couche transport et au niveau de la mémoire. Il est utilisé pour établir des connexions sécurisées dans l’écosystème Rust explique la fondation dont ce projet selon elle démontre la capacité du langage à offrir sécurité et performances dans l’un des domaines les plus sensibles de l’infrastructure logicielle moderne.
Un soutien institutionnel fort pour durer
Les projets menés dans cet Innovation Lab devraient gagner en visibilité dans l’écosystème Rust, et attirer davantage de contributeurs, de partenaires et de soutiens financiers. Un support institutionnel fiable permettra à ces projets de rester durables, sécurisés et indépendants des fournisseurs selon la fondation. L’adoption de ce langage de développement s’est accélérée tant dans l’industrie que dans l’open source, et de nombreux projets écrits en Rust sont devenus des éléments essentiels de l’infrastructure logicielle mondiale, a souligné l’organisme. Avec l’intégration croissante de Rust dans tous les domaines, des plateformes cloud aux systèmes embarqués, un besoin croissant s’est fait sentir pour une gouvernance neutre et dirigée par la communauté, assure t’elle.
Des pirates se sont servis de smart contracts basés sur Ethereum pour masquer l’URL de charges utiles d’un malware. La chaîne d’attaque avait été déclenchée par un dépôt GitHub malveillant.
Les chercheurs de ReversingLabs ont découvert une attaque mêlant dépôt sur GitHub, package npm et la blockchain Ethereum. Cette campagne « montre que les attaques contre les dépôts évoluent et que les développeurs ainsi que les entités de codage doivent être vigilants face aux tentatives d’implantation de code malveillant dans des applications légitimes, d’accès à des ressources de programmation et de vol de données et d’actifs numériques sensibles », rapporte les…
Il vous reste 89% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Afin de limiter la distribution de malwares sur les terminaux Android, un programme de vérification de l’identité des développeurs d’applications sera déployé à partir de septembre 2026. Il concerne ceux qui distribuent des apps en dehors de Google Play.
Pour renforcer la sécurité des applications Android, Google a décidé de mettre en place une méthode qui a fait ses preuves : vérifier l’identité des développeurs. Annoncé à la fin août, cette politique vise à mieux protéger les utilisateurs contre les acteurs malveillants qui répandent des arnaques et des logiciels malveillants via le téléchargement d’applications. A partir de septembre 2026, la firme américaine exigera que les applications soient enregistrées par un développeur vérifié afin de pouvoir être installées sur des terminaux Android certifiés
Google a comparé cette procédure au contrôle d’identité dans les aéroports, qui confirme l’identité d’un voyageur indépendamment du contrôle des bagages. Seule l’identité du développeur sera validée, mais aucun examen du contenu, ni de la provenance de l’application ne sera effectué. Le déploiement de ce programme d’authentification est prévu dans les pays particulièrement touchés par les arnaques répandues par le biais d’applications frauduleuses. En septembre, le Brésil, l’Indonésie, Singapour et la Thaïlande seront concernés. L’initiative sera imposé à l’échelle mondiale à partir de 2027.
Pour cela, le fournisseur met en place une console pour les développeurs Android afin de valider leur identité. Cela concerne ceux qui distribuent leurs apps uniquement en dehors de la boutique d’applications Google Play. Ce dernier dispose déjà de ce système depuis 2023 et « Google a constaté qu’il empêchait des acteurs malveillants de profiter de l’anonymat pour distribuer des malwares, voler des données sensibles et commettre des fraudes financières ».