Pascal Geenens, VP Cyber Threat Intelligence, Radware – Série d’entretiens

Pascal Geenens, VP Cyber Threat Intelligence, Radware, est un chercheur en sécurité informatique et un leader technologique avec plus de deux décennies d’expérience dans les technologies de l’information, la sécurité des réseaux et l’intelligence sur les menaces. Chez Radware, il contribue à diriger les recherches et la pensée de l’entreprise sur l’évolution du paysage des menaces cybernétiques, avec un accent particulier sur les attaques de déni de service distribuées, les logiciels malveillants pour l’Internet des objets, les menaces automatisées et l’utilisation croissante de l’intelligence artificielle par les attaquants et les défenseurs. Geenens développe et maintient des pièges à miel pour l’Internet des objets dans le cadre de l’équipe de recherche en sécurité de Radware et a mené des recherches approfondies sur des menaces telles que BrickerBot et Hajime. Avant de rejoindre Radware, il a travaillé en tant qu’ingénieur consultant chez Juniper Networks , conseillant les principaux fournisseurs de services cloud et de communications en Europe, au Moyen-Orient et en Afrique sur les stratégies de réseau défini par logiciel, la virtualisation des fonctions réseau et l’automatisation des centres de données.

Radware est une entreprise de sécurité informatique et de livraison d’applications cotée en bourse qui aide les entreprises à protéger les réseaux, les sites Web, les applications et les API dans des environnements physiques, cloud, hybrides et définis par logiciel. Son portefeuille comprend une protection contre les attaques de déni de service distribuées alimentée par l’IA, des pare-feu d’applications Web, une gestion des robots, une sécurité des API, des contrôleurs de livraison d’applications et des services de réponse d’urgence gérés. En combinant l’analyse comportementale, l’apprentissage automatique, l’intelligence sur les menaces à grande échelle et la mitigation automatisée, la technologie de Radware est conçue pour identifier les activités malveillantes en temps réel tout en préservant l’accès pour les utilisateurs légitimes et en maintenant la disponibilité et les performances des services numériques critiques.

Vous avez passé près de trois décennies dans la cybersécurité, de la prise en charge du noyau IBM AIX et de l’ingénierie des infrastructures à la découverte de botnets comme BrickerBot, JenX et Demonbot, et maintenant en tant que responsable de l’intelligence sur les menaces chez Radware. En regardant en arrière, quels sont les principaux changements que vous avez constatés dans la façon dont les attaquants innovent, et comment l’IA a-t-elle changé vos attentes quant à l’apparence des prochaines générations de menaces cybernétiques ?

Le paysage des menaces a subi un changement fondamental, passant d’attaquants solitaires qui étaient des enthousiastes techniques très qualifiés à des cybercriminels très organisés et sophistiqués. Dans le passé, un attaquant était généralement motivé par le défi technique lui-même. Aujourd’hui, la combinaison de l’accélération numérique et de l’IA générative a commercialisé l’ensemble de l’opération, alimentant une économie mature de Crime-as-a-Service (CaaS). Les acteurs malveillants ont essentiellement reproduit le modèle de Software-as-a-Service (SaaS) des entreprises, en vendant des outils avancés à quiconque. Cela permet à des novices complets de lancer des attaques sophistiquées à grande échelle. À mesure que notre empreinte numérique s’étend chaque année, la surface d’attaque disponible et les opportunités d’exploitation financière augmentent avec elle.

L’IA est à l’origine du prochain chapitre de cette évolution de deux manières distinctes.

Tout d’abord, elle démocratise la cybercriminalité. Elle donne un coup de pouce immédiat aux attaquants amateurs tout en aidant les syndicats majeurs à rationaliser leurs opérations, à polir leurs interfaces utilisateur et à commercialiser leurs services malveillants de manière beaucoup plus efficace.

Deuxièmement, et plus critique, l’émergence de l’IA agente combinée aux derniers modèles de frontière est en train d’automatiser le cycle de vie des vulnérabilités. Nous nous dirigeons vers une réalité opérationnelle dans laquelle les machines peuvent analyser les réseaux de manière autonome, découvrir les vulnérabilités et exploiter les failles presque entièrement d’elles-mêmes, travaillant 24 heures sur 24 et exécutant des actions à des vitesses bien supérieures à celles de tout défenseur humain.

L’IA réduit considérablement la barrière technique pour les attaquants. Quelles sont les capacités offensives de l’IA qui vous préoccupent le plus au cours des trois à cinq prochaines années, et lesquelles, selon vous, reçoivent actuellement plus d’attention qu’elles n’en méritent ?

Le domaine qui nécessite l’attention la plus immédiate est la découverte et l’exploitation des vulnérabilités assistées par l’IA. Dès qu’une faille est divulguée, une course commence. Les attaquants utilisent l’IA pour analyser instantanément la faille, cartographier les endroits où elle s’applique et générer des variations d’exploitation. Cela comprime complètement le délai d’exploitation qui était déjà trop rapide pour la plupart des processus de gestion des correctifs des entreprises.

Parallèlement, nous assistons à un changement majeur vers des systèmes d’IA locaux et continus. Plus précisément, l’émergence des « agents locaux avec une pulsation ». Un exemple parfait est OpenClaw et l’annonce récente de Microsoft (MSFT ) qu’ils intégreront OpenClaw dans la barre d’outils de chaque employé. Contrairement aux assistants basés sur le cloud standard, ces agents locaux s’exécutent en continu en arrière-plan, directement sur la machine d’un employé. Ils fonctionnent via des boucles continues et imitent les actions humaines, comme la saisie et la navigation via l’automatisation du navigateur. Cela rend pratiquement impossible pour les systèmes de sécurité des points de terminaison standard de faire la distinction entre l’employé et l’agent d’IA. Puisque les utilisateurs doivent inévitablement accorder à ces agents des autorisations de système étendues pour effectuer leur travail, les agents peuvent contourner les connecteurs de API sécurisés en utilisant simplement les navigateurs locaux pour cliquer sur des liens et des boutons. Si ces agents autonomes sont victimes d’une attaque d’injection de prompte directe ou indirecte, un acteur malveillant peut les manipuler pour exfiltrer, modifier ou détruire des données d’entreprise avec zéro empreinte traditionnelle.

Le risque surestimé est le potentiel pour des essaims d’IA autonomes et exploitant des failles zero-day qui peuvent pirater des entreprises complexes à grande échelle à partir de zéro. Cela peut arriver éventuellement, mais ce n’est pas le problème d’aujourd’hui. Le problème d’aujourd’hui est celui des attaquants experts humains dotés d’outils et d’automatisation améliorés et d’un nombre accru d’attaquants moins expérimentés qui peuvent faire plus qu’avant.

La fenêtre entre la divulgation d’une vulnérabilité et son exploitation active continue de se rétrécir. À quel point l’IA a-t-elle accéléré ce délai, et quels changements les équipes de sécurité des entreprises devraient-elles apporter pour rester en tête ?

C’est une course à deux niveaux : d’une part, il y a la course pour découvrir, corriger et divulguer de nouvelles vulnérabilités avant que les méchants ne le fassent, et d’autre part, la course pour corriger les déploiements de logiciels vulnérables avant que les méchants ne lancent une exploitation. L’IA est au cœur de ces deux courses.

Les défenseurs doivent gérer un nombre croissant de vulnérabilités et ont de moins en moins de temps pour réagir. Une fois qu’une vulnérabilité est publique, les attaquants passent rapidement par les bases. Qu’est-ce qui est affecté ? Est-ce accessible depuis Internet ? L’exploitation peut-elle être reproduite et adaptée pour fonctionner dans plusieurs environnements ? L’IA aide à chacune de ces étapes, en résumant la faille, en examinant le code de preuve de concept, en suggérant des modifications et en automatisant l’analyse, l’exploitation et le traitement des résultats.

Le patchage ne peut plus être la seule horloge que les équipes de sécurité regardent. Il est nécessaire, mais il est généralement plus lent que le calendrier de l’attaquant, surtout pour les applications et les API de production qui font face à Internet. Les équipes doivent savoir ce qui est exposé, ce qui est exploitable dans la pratique et quels services et ressources commerciales seront impactés lorsqu’ils seront touchés.

Pour fermer cette fenêtre d’exposition critique, les défenseurs doivent passer d’une mentalité réactive, axée sur le patchage, à un modèle de protection automatisé. Au lieu de s’appuyer sur des signatures génériques ou de forcer les équipes d’exploitation à déployer des mises à jour de logiciel non validées en production, les organisations devraient commencer à s’appuyer sur la découverte en temps réel et automatisée des points de terminaison des API et de la logique commerciale des applications en ligne, ainsi que sur une liste de matériel logiciel (SBOM) automatisée, combinée avec des renseignements sur les menaces et les vulnérabilités les plus récentes pour générer dynamiquement des correctifs virtuels adaptés. Le déploiement de ces protections sensibles au contexte sur les applications Web et les points de terminaison des API bloque les tentatives d’exploitation au niveau de la couche de runtime avant qu’elles ne puissent atteindre la logique d’application vulnérable. Ce type d’interception automatisée offre aux équipes de sécurité une fenêtre de remédiation, leur permettant de tester soigneusement et de déployer des mises à jour de logiciel en toute sécurité sur une échéance gérable sans exposer l’entreprise à un risque immédiat ou à une interruption.

Les organisations déployant rapidement des applications et des agents alimentés par l’IA qui s’appuient lourdement sur les API. Est-ce que les entreprises sous-estiment les risques de sécurité que cela crée, et quels sont les plus grands erreurs que vous voyez actuellement ?

Oui, de nombreuses entreprises sous-estiment encore les risques parce qu’elles traitent toujours les agents d’IA comme des applications à sécuriser et la sécurité de l’IA comme une question de confidentialité des données plutôt que comme une menace opérationnelle. Le problème que nous voyons le plus souvent est une méconnaissance fondamentale de l’agentivité. Pour qu’un agent d’IA local soit vraiment efficace et épargne du temps à un employé, l’utilisateur doit lui relayer toutes ses autorisations d’accès. Cela signifie que l’agent hérite effectivement de l’identité et de l’accès de confiance de l’employé aux applications d’entreprise, aux sessions de navigateur et aux fichiers locaux. Même si une organisation surveille activement et limite les connecteurs d’agent d’IA, ces agents locaux peuvent interagir avec les systèmes en imitant le comportement humain, comme l’automatisation du navigateur. Les systèmes de sécurité de l’entreprise deviennent complètement incapables de faire la distinction entre l’employé réel et l’agent automatisé.

Cette délégation de confiance devient extrêmement dangereuse en raison de la façon dont les modèles de langage (LLM) traitent fondamentalement les informations : les modèles d’IA ne distinguent pas entre les données et les instructions. Lorsqu’un agent est autorisé à accéder au système de manière étendue pour faire son travail, il devient incroyablement facile pour un acteur malveillant de manipuler l’agent par le biais d’une injection de prompte indirecte. Un attaquant peut simplement planter des instructions malveillantes à l’intérieur d’un e-mail, d’un PDF ou d’une page Web que l’agent est censé lire. Le modèle traite les données non fiables comme une commande, contournant complètement la conscience de l’utilisateur. Soudain, un outil simple conçu pour résumer des documents est manipulé pour exporter de manière autonome des informations sensibles, modifier des données d’entreprise ou installer des logiciels malveillants, le tout en se cachant derrière les informations d’identification légitimes de l’utilisateur.

Ayant passé des années à rechercher les logiciels malveillants pour l’Internet des objets et les botnets, comment voyez-vous l’IA transformer la prochaine génération de botnets ? Pourrions-nous éventuellement voir des botnets autonomes capables de s’adapter sans intervention humaine directe ?

Les maîtres de botnet ne sont jamais restés inactifs. Les opérateurs font pivoter les charges utiles, mettent en œuvre de nouvelles vulnérabilités, analysent en continu les appareils obsolètes et déplacent leur infrastructure de commande lorsque les défenseurs les rattrapent. Les agents d’IA peuvent accélérer sérieusement ces cycles, que ce soit pour le triage des vulnérabilités, la génération d’exploits ou la gestion de l’infrastructure.

Les botnets autonomes ne sont pas de la fiction. Brickerbot était l’un des premiers bots autonomes. Il restait silencieux et attendait que les appareils infectés par Mirai tentent de compromettre son appareil hôte, puis il contre-attaquait en exploitant les vulnérabilités pour acquérir une emprise sur l’appareil. Finalement, Brickerbot détruisait l’appareil infecté. Le bot agissait comme un système expert basé sur des règles, similaire aux premiers systèmes d’IA. Un autre botnet qui a marqué la communauté de sécurité il y a plus d’une décennie est Hajime. C’était l’un des premiers botnets pair à pair. En utilisant les tables de hachage distribuées de Torrent, Hajime pouvait être contrôlé et mis à jour de manière décentralisée, sans nécessiter d’infrastructure de commande et de contrôle centralisée, et par conséquent presque impossible à détruire.

Il y a plusieurs discussions dans la communauté de sécurité sur le potentiel d’un botnet agentic basé sur des cadres d’agents d’IA locaux comme OpenClaw. Ce ne sont pas les botnets de logiciels malveillants traditionnels basés sur du code, mais des botnets impulsés entièrement par la manipulation de contexte. Lorsque des agents locaux traitent des données externes, les attaquants n’ont pas besoin de trouver une faille de logiciel traditionnelle pour pirater ces machines ; ils n’ont besoin que de tromper le LLM sous-jacent. En faisant cela, les attaquants obtiennent un accès à l’exécution de terminal puissante, à l’automatisation du navigateur et potentiellement à une foule d’autres « compétences ».

La communauté discute spécifiquement de quelques éléments clés qui rendent un botnet OpenClaw largement répandu viable :

• Étant donné que OpenClaw ingère en continu des données externes (comme la surveillance des problèmes de GitHub, la lecture des messages entrants Slack/Telegram ou la synthèse de pages Web), les attaquants peuvent intégrer des instructions malveillantes dans les données accessibles au public. Si un agent local d’un utilisateur traite ces données, l’injection de prompt peut remplacer les instructions du système et commander à l’agent de se connecter à un serveur de commande et de contrôle (C2) contrôlé par l’attaquant.
• Les chercheurs en sécurité ont noté que les agents OpenClaw ont la capacité d’utiliser des canaux de communication pair à pair ou agent à agent chiffrés (comme les compétences construites par la communauté telles que ClaudeConnect). Les cybercriminels réalisent qu’ils peuvent exploiter ces canaux de communication pour permettre aux agents piratés de coordonner entre eux en silence, contournant complètement les pare-feu réseau traditionnels et la surveillance des points de terminaison.
• Les analyses de sécurité ont révélé que des dizaines de milliers d’utilisateurs naïfs mettaient en ligne des instances OpenClaw sur des serveurs cloud et exposaient accidentellement les interfaces de gestion HTTP directement à Internet. Cette vaste étendue d’environnements à privilèges élevés exposés donne aux acteurs malveillants une empreinte massive à cibler.
• Étant donné que OpenClaw s’appuie fortement sur des « compétences » téléchargées à partir de référentiels publics comme ClawHub, les attaquants téléchargent des compétences apparemment inoffensives (comme « Que ferait Elon ») qui contiennent des instructions cachées. Une fois installées, l’agent est silencieusement ordonné d’exécuter des commandes de shell en arrière-plan ou de déposer des logiciels malveillants, recrutant efficacement la machine hôte dans un botnet sans que l’utilisateur ne voie jamais d’alerte de fichier suspect.

Finalement, le consensus dans la communauté est que OpenClaw est une cible de premier plan pour le premier véritable botnet agentic. Au lieu d’un botnet composé de routeurs compromis ou d’appareils IoT exécutant des scripts DDoS, un botnet OpenClaw consisterait en des machines entièrement authentifiées et très capables que les acteurs malveillants pourraient commander pour voler des informations d’identification, modifier des données ou orchestrer des attaques de chaîne d’approvisionnement massives à une vitesse de machine.

En ce qui concerne les bots automatisés qui pivotent et s’adaptent de manière autonome en exploitant un LLM central comme leur cerveau, ce n’est certainement pas de la fiction, mais ce n’est pas non plus quelque chose que des maîtres de botnet expérimentés favoriseraient. Les botnets sont des actifs. L’automatisation qui se comporte mal peut exposer l’infrastructure, attirer l’attention trop tôt, exposer l’opérateur ou brûler excessivement les jetons. Les attaquants utiliseront l’automatisation là où cela les aide à accélérer, mais ils sont peu susceptibles de renoncer au contrôle des décisions qui pourraient brûler l’accès, exposer l’infrastructure ou nuire aux profits.

Je ne négligerais pas complètement le risque, cependant. À mesure que nous nous dirigeons vers l’IA de pointe et que de nouveaux appareils intelligents sont de plus en plus souvent équipés de petits modèles de langage (SLM) locaux, je peux voir des acteurs malveillants ciblant les fruits les plus bas et intégrant des fonctionnalités de bot assistées par prompt dans leurs botnets. Au moins, ils n’auront pas à payer pour une utilisation excessive de jetons lorsque le SLM local commence à boucler sur une prompte trop sophistiquée ou un contexte qui est devenu trop grand.

Les campagnes de hacktivisme et les attaques DDoS à grande échelle sont de plus en plus courantes. Ces groupes deviennent-ils plus sophistiqués, ou l’IA et les outils d’attaque facilement disponibles rendent-elles simplement les attaques avancées accessibles à un public beaucoup plus large ?

Les deux. Certains groupes de hacktivisme sont devenus réellement plus organisés. Certains groupes, comme l’emblématique NoName057(16), mènent des attaques DDoS quotidiennes depuis février 2022. Ils ont eu le temps d’améliorer leurs outils, de construire un public fidèle et d’apprendre à choisir des cibles qui attirent l’attention, à chronométrer leurs attaques autour d’événements politiques et à utiliser des revendications publiques pour exercer une pression. Pour les hacktivistes, le message est plus important que la perturbation elle-même.

En même temps, les outils sont devenus plus faciles à obtenir qu’ils ne l’étaient auparavant. Les services DDoS à louer, les botnets, les réseaux de proxy, les scripts divulgués et les didacticiels ont permis à quiconque ayant des compétences limitées de rejoindre une campagne et de se sentir partie prenante de quelque chose de plus grand. L’IA ajoute une assistance de codage, une recherche de cible, une traduction, un message de campagne et une automatisation de base à cela.

Les cibles ressentent l’impact de toute façon, que l’attaque provienne d’un groupe habile motivé par l’idéologie ou d’un loup solitaire embauché par un concurrent qui loue une infrastructure d’attaque DDoS. Un site Web fermé affecte les clients. Un service public indisponible est remarqué par les citoyens. Suffisamment de bruit, et les équipes de direction et de communication doivent répondre, quelle que soit la personne derrière le clavier.

Alors que les entreprises intègrent l’IA générative dans leurs opérations, quels nouveaux plans d’attaque émergent qui pourraient ne pas être pleinement appréciés par les dirigeants de la sécurité ?

La réponse est définie par ce que l’agent d’IA peut atteindre. Une fois qu’il a accès à des documents internes, du code, des pipelines CI/CD, des clés d’API ou des outils DevOps, la surface d’attaque s’étend rapidement. Pour être utile, un agent a besoin d’agentivité ; sinon, il n’est qu’un chatbot glorifié. La question devient alors ce que l’agent est autorisé à faire. Quelles informations confidentielles peut-il lire ? Peut-il modifier un ticket ou le compte bancaire d’un client dans le CRM ? Peut-il exécuter du code ? Peut-il appeler un service externe ? Peut-il exposer des données via l’appel d’outils ?

L’injection de prompte indirecte devient plus grave dans un tel environnement. Si un agent traite du contenu non fiable et agit ensuite, la prompte peut devenir un chemin dans le flux de travail. Cela diffère d’un chatbot qui répond à une question.

L’IA est maintenant utilisée à la fois par les attaquants et les défenseurs. Pensez-vous que l’IA défensive finira par suivre le rythme de l’IA offensive, ou les organisations feront-elles face à une bataille de plus en plus asymétrique au cours des prochaines années ?

L’IA crée un déséquilibre qui favorise l’attaquant. Ce n’est pas parce que les modèles d’IA défensive sont inférieurs. En fait, l’utilisation de l’IA dans la défense est très efficace pour filtrer le bruit quotidien et accélérer la réponse aux incidents. Le problème, cependant, est un écart structurel en termes de vitesse opérationnelle et de contraintes.

Historiquement, lorsqu’une vulnérabilité était découverte, les équipes de sécurité avaient une petite fenêtre de temps pour déployer un correctif avant que les acteurs malveillants ne l’exploitent. Aujourd’hui, l’IA agente a compressé cette fenêtre à quasi-zéro. Les outils automatisés peuvent trouver une faille et générer instantanément une exploitation ciblée. Un processus de gestion des correctifs traditionnel mené par l’homme ne peut simplement pas rivaliser avec un pipeline d’attaque automatisé en continu.

De plus, les deux côtés opèrent sous des règles entièrement différentes. Les attaquants ne sont confrontés à aucune contrainte en termes de conformité, d’éthique ou de temps d’arrêt opérationnel. Ils peuvent déployer des agents d’IA personnalisés pour lancer des campagnes à grande échelle sans restriction. Les défenseurs, en revanche, doivent opérer de manière déterministe. Un IA défensive ne peut pas isoler aveuglément une base de données de production critique ou révoquer les informations d’identification d’un dirigeant sur la base d’une anomalie à forte probabilité. Les défenseurs ont besoin d’une vérification pour protéger la continuité des activités, et la latence introduite par ces garde-fous nécessaires est exactement ce que les attaques automatisées exploitent.

Finalement, le leadership en matière de sécurité ne sera pas défini par qui possède l’IA « la plus intelligente », mais par qui comble ce fossé de vitesse architecturale. Les organisations qui traitent l’IA comme un outil de sécurité standard seront submergées par la vitesse des menaces modernes. Le succès nécessite de repenser l’infrastructure pour permettre à l’IA défensive d’isoler et de contenir les menaces de manière autonome.

De nombreuses équipes de sécurité continuent de s’appuyer sur des indicateurs de sécurité traditionnels et des méthodes de détection. À mesure que les attaques deviennent plus rapides et plus automatisées, quels indicateurs ou comportements les organisations devraient-elles privilégier à la place ?

La plupart des indicateurs de sécurité se concentrent encore fortement sur l’activité : les alertes déclenchées, les attaques bloquées ou les vulnérabilités découvertes. Même si ces chiffres sont utiles pour mesurer la réponse aux incidents, ils ne fournissent pas d’informations sur l’exposition réelle de l’organisation. Ils indiquent aux défenseurs ce qu’ils ont attrapé, mais ne montrent pas les angles morts qui restent ouverts jusqu’à ce qu’un attaquant les exploite.

À l’ère des menaces automatisées, s’appuyer sur des indicateurs de sécurité réactifs n’est plus viable. Une fois qu’une organisation est ciblée, la vitesse de l’attaque nécessite une gestion proactive. La gestion de la surface d’attaque en temps réel est maintenant impérative. Les défenseurs ont besoin d’une visibilité continue sur les risques opérationnels spécifiques : quels applications et API critiques sont exposées à Internet ? Quelles vulnérabilités existent-elles à l’intérieur ?

Une véritable résilience vient de connecter ce contexte de surface d’attaque à la détection comportementale et aux renseignements sur les menaces. En comprenant exactement ce qui est exposé et comment cela se comporte, les équipes de sécurité peuvent anticiper et bloquer des attaques inconnues.

Finalement, la vitesse opérationnelle reste un indicateur critique de succès, mais les défenseurs doivent mesurer la bonne fenêtre de temps : combien de temps mettons-nous pour identifier qu’une nouvelle vulnérabilité affecte un système exposé, et combien de temps mettons-nous pour mettre en place un contrôle de compensation pour le protéger ? Cette vitesse spécifique est la mesure la plus précise de savoir si un programme de sécurité peut résister à des attaques à grande vitesse.

En regardant cinq ans en avant, quel sera le défi de cybersécurité définissant l’ère de l’IA, et que les DSI et les équipes de sécurité devraient-ils commencer à faire aujourd’hui pour s’y préparer ?

En regardant cinq ans en avant, le défi de cybersécurité définissant l’ère de l’IA sera de gérer et de sécuriser les relations non humaines autonomes. À mesure que les organisations passent d’applications de chatbot autonomes à des systèmes d’agents multiples interconnectés qui possèdent l’agentivité pour exécuter des transactions financières, modifier le code source, modifier l’infrastructure cloud et interagir avec des systèmes tiers, les frontières de sécurité traditionnelles s’effondreront. Dans cinq ans, une entreprise ne gérera pas seulement des employés humains et des logiciels statiques ; elle supervisera des milliers d’agents d’IA autonomes qui interagissent les uns avec les autres, les données d’entreprise et les systèmes tiers.

La visibilité dans les systèmes agents à travers l’organisation sera impérative. Avant que les agents ne se multiplient, les DSI devraient établir un registre central qui définit clairement la propriété de chaque agent déployé, les modèles de données et les référentiels que l’agent est autorisé à lire, ainsi que les outils, les API et les commandes de système qu’il est autorisé à appeler. Les DSI devraient également exiger que tout déploiement de technologie agente utilise des protocoles de connectivité standardisés et vérifiables pour garantir que toutes les intégrations d’outils sont strictement consignées.

Dans cinq ans, la défense des API et des applications en ligne ne consistera plus à gérer les configurations, à bloquer les signatures connues et à corriger les vulnérabilités ; ce sera une guerre de logique contre logique automatisée. À mesure que les acteurs malveillants déployeront des pipelines d’attaque agents entièrement automatisés qui peuvent inverser l’ingénierie de la logique commerciale d’une application dans les secondes qui suivent sa découverte, les pare-feu d’applications Web (WAF) traditionnels deviendront obsolètes. La défense de ce paysage nécessitera un passage à des architectures autonomes et sensibles au contexte.

Les attaquants utiliseront les modèles de frontière pour automatiser complètement le cycle de découverte et d’exploitation des failles de logique des API (comme la autorisation de niveau d’objet cassée, ou BOLA). Au lieu de rechercher des bogues logiciels connus, les bots d’attaque automatisés cartographieront l’ensemble du schéma d’API d’une application, comprendront comment les données circulent et généreront dynamiquement des séquences de charge utile personnalisées pour manipuler la logique commerciale. Puisque ces attaques utilisent une syntaxe valide et des appels d’API légitimes, la détection de seuil et la détection de signature standard seront complètement aveugles à leur égard.

Pour contrer la découverte automatisée, les défenseurs doivent atteindre une visibilité en temps réel et continue sur leur propre architecture exposée. Les équipes de sécurité ne peuvent pas s’appuyer sur la documentation statique ou les catalogues d’API obsolètes. L’IA défensive doit analyser et cartographier chaque point de terminaison d’API actif, chaque relation de microservice et chaque flux de travail d’application en ligne à travers des environnements cloud hybrides. Cette visibilité automatisée doit être associée à un SBOM dynamique pour relier instantanément une nouvelle divulgation de vulnérabilité mondiale aux lignes de code spécifiques exposées à Internet.

Étant donné que les attaques automatisées se fondent dans le trafic des utilisateurs légitimes, la défense doit basculer entièrement vers l’analyse comportementale contextuelle. L’IA défensive doit profiler le comportement standard de chaque client d’API, de jeton et d’identité utilisateur. Elle doit surveiller l’intention et la séquence des appels d’API plutôt que seulement les entrées. Si un script d’attaque automatisé commence à assembler des appels d’API légitimes dans une séquence anormale pour extraire des données ou tester une faille de logique, le système doit reconnaître la déviation structurelle d’intention et intervenir instantanément.

La mesure la plus précise de la résilience sera la vitesse à laquelle une organisation peut compresser la fenêtre entre l’exposition d’une vulnérabilité et sa correction. Attendre que les équipes de développement écrivent, testent et déployent des mises à jour de code en production sera une stratégie fatale. La véritable protection reposera sur la mise en place de correctifs virtuels automatisés et sensibles au contexte au niveau de la couche de runtime. En alimentant les renseignements sur les menaces et les données de découverte d’API directement dans les moteurs d’IA défensive à la pointe, l’infrastructure générera automatiquement et déployera des correctifs virtuels adaptés pour intercepter et bloquer les tentatives d’exploitation avant qu’elles n’atteignent la logique d’application vulnérable.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Radware.