Avec l’IA, l’attaque se démocratise et la défense doit désormais réagir en quelques minutes. Stephan Hadinger, directeur technique d’AWS France, plaide pour une sécurité pensée pour réagir. Pierre Codis, directeur général de la filiale française de Keyfactor, rappelle qu’avant de réagir vite, encore faut-il savoir qui agit dans son système.
Moins de treize minutes. 94 actions enchaînées, sans aucune erreur. C’est la cyberattaque que cite Stephan Hadinger pour mesurer ce qui a changé. « L’IA change fondamentalement l’économie de l’attaque et de la défense. Elle réduit le niveau de compétences requis, le temps, le coût. Et tristement, elle démocratise la capacité d’attaque », constate le directeur technique d’AWS France. Ce qui frappe, c’est moins la vitesse brute que la souplesse : une attaque “protéiforme”, qui observe la réaction du site ou de l’application visés et s’adapte en quelques minutes. Les agents savent aussi assembler “une dizaine, une vingtaine” de vulnérabilités mineures, sans gravité prises une à une, pour construire une attaque bien réelle.
L’attaquant n’a pas de comité de validation
Face à cela, la défense joue avec un handicap. L’attaquant agit dans l’illégalité, sans procédure à respecter ni validation à obtenir. L’entreprise, elle, passe par des processus bien plus lourds. On ne se bat pas avec les mêmes armes ? “D’une certaine manière, oui”, admet Stephan Hadinger. Sa réponse tient en une conviction : “La vraie clé, ce n’est pas tant la découverte de la vulnérabilité que le temps de réaction”.
Et en quelques principes. D’abord, parer au plus pressé. Face à une faille comme celle qui a touché PHP la semaine dernière, des règles de filtrage constituent “une première défense, beaucoup plus rapide à mettre en place, parce qu’il n’y a pas besoin de refaire de la recette applicative”. Couper un service ou le basculer en maintenance le temps de corriger fait aussi partie des réponses “tout à fait légitimes”. Sans dispenser, insiste-t-il, de mettre à jour. Ensuite, ne pas se laisser submerger par “l’abondance” de vulnérabilités découvertes, mais les traiter au fil de l’eau. Puis sortir les tests d’intrusion de leur statut de “luxe”. Longtemps coûteux et dépendants d’experts rares, ils étaient réservés aux applications les plus sensibles. Certains responsables sécurité, raconte-t-il, n’avaient le budget que pour cinq tests par an. L’IA permet désormais d’en faire sur l’intégralité du code, et pour un coût bien moindre, ce qui compte quand “les budgets ne sont pas extensibles à l’infini”. Enfin, s’appuyer sur les modèles de langage pour l’investigation : ils sont “extrêmement bons” pour analyser les journaux et faire de la corrélation, à une vitesse qui permet aux équipes d’avoir une vision à 360 degrés de ce qui se passe dans les minutes qui suivent une alerte. Selon lui, une investigation qui prenait six heures peut se boucler en sept minutes.
Le discours est optimiste, et assumé comme tel. Il laisse pourtant une question en suspens : une fois toutes ces failles mises au jour, qui, dans l’entreprise, les corrige ?
Savoir qui agit avant d’agir vite
C’est précisément là que Pierre Codis déplace le débat. Pour lui, la question n’est pas seulement la vitesse de réaction, mais l’identité de ceux qui agissent dans le système. Et ceux-là ne sont plus seulement humains. Applications, conteneurs, API, services automatisés, agents IA : ces entités communiquent entre elles et accèdent parfois à des données sensibles, le plus souvent sans intervention humaine. Elles s’authentifient avec des clés API, des comptes de service ou des jetons d’accès, qui permettent de vérifier qu’un identifiant est valide, mais pas nécessairement que celui qui l’utilise est autorisé à le faire. Lorsqu’un identifiant est volé, copié ou partagé, “le système sollicité peut alors avoir des difficultés à distinguer une application autorisée d’un acteur malveillant utilisant les mêmes identifiants”. Pour réagir vite, encore faut-il savoir qui l’on a en face.
Et ces identifiants, les entreprises peinent à les suivre. Présents dans les applications, les plateformes, les outils de développement et les processus de déploiement, ils deviennent difficiles à inventorier et à contrôler. “Certains restent actifs plus longtemps que nécessaire, d’autres ne sont pas renouvelés suffisamment régulièrement”, constate Pierre Codis. Le diagnostic n’a rien de spectaculaire, et c’est bien ce qui le rend gênant.
Là encore, les réponses techniques existent. Identités vérifiables par cryptographie, à durée de validité limitée et renouvelées automatiquement, infrastructures à clés publiques, standards ouverts comme SPIFFE pour identifier les charges de travail quel que soit leur environnement d’exécution. Pour Pierre Codis, il s’agit moins de multiplier les mécanismes que de bâtir une infrastructure de confiance commune. “La confiance ne peut plus dépendre de l’endroit où se trouve une application. Elle doit reposer sur ce qu’elle est, ce qu’elle peut prouver et ce qu’elle est autorisée à faire”, résume-t-il.
Identifier un agent ne signifie pas lui donner carte blanche
Avec l’IA agentique, l’enjeu change d’échelle. Ces agents interrogent des bases de données, utilisent des API, déclenchent des opérations, échangent avec d’autres agents, parfois sans intervention humaine. Pierre Codis plaide pour que chacun dispose d’une identité fiable et vérifiable, mais prévient : “Identifier un agent ne signifie pas lui donner carte blanche”. Ses actions doivent rester encadrées par des autorisations précises, sans déborder de son périmètre. Le sujet n’a rien de théorique. En fin d’entretien, Stephan Hadinger le désigne lui-même comme une question « très centrale » chez les clients d’AWS.
Sur le fond, les deux dirigeants se rejoignent davantage qu’il n’y paraît. Pour Pierre Codis, la sécurisation des identités non humaines “n’est plus seulement une question technique réservée aux équipes informatiques”. C’est une priorité stratégique, qui suppose une gouvernance où « la confiance ne doit pas être accordée une fois pour toutes ». Stephan Hadinger pointe le même verrou, côté budget : « Tant qu’on n’a pas de problème de sécurité, c’est compliqué de mettre des budgets. Et quand on en a un, c’est trop tard. » On cherche l’extincteur une fois l’incendie déclaré.
Le directeur technique d’AWS France refuse pourtant le fatalisme. “Être cyberattaqué, c’est une certitude”. Être piraté ne l’est pas. Une attaque reste une affaire d’économie : rendre la défense assez rapide et assez peu coûteuse pour que l’attaquant finisse par renoncer, faute d’intérêt. Les outils pour y parvenir sont là, de l’analyse automatisée des journaux à l’identité machine renouvelée automatiquement. Reste à les activer, à les gouverner, à décider qui a droit à quoi. Ce travail-là, aucune IA ne le fera à la place de l’entreprise.
