L’objectif de cet article est d’effectuer un panorama des solutions existantes pour déterminer celles qui pourraient s’intégrer aux pratiques d’un pentester professionnel/auditeur cybersécurité. L’analyse porte à la fois sur leur efficacité dans des environnements réalistes, leur coût, leur degré d’autonomie, leur couverture fonctionnelle et les enjeux de confidentialité associés à la manipulation de données sensibles.

En effet, aujourd’hui, il n’y a plus de doute sur l’intérêt de l’utilisation de l’IA pour la réalisation de tests d’intrusion. La publication des derniers modèles frontières tels que Fable 5.1 ou GPT Astra 6 confirme une tendance de fond : les capacités cyber-offensives des grands modèles de langage (LLM) progressent rapidement. L’incident de sécurité survenu lors d’une évaluation interne d’OpenAI sur le benchmark ExploitGym en fournit une illustration frappante.^[1] Une combinaison de modèles avec une configuration de refus cyber réduite dont GPT-5.6 Sol et un modèle supérieur en préversion, a contourné l’isolation réseau de l’environnement d’évaluation. Pour cela, ils ont exploité une vulnérabilité zero-day dans le proxy de registres de paquets, puis se sont propagés dans l’infrastructure d’OpenAI. Après avoir obtenu un accès à Internet, les modèles ont enchaîné plusieurs vecteurs d’attaque sur l’infrastructure de production de l’entreprise Hugging Face afin d’accéder aux solutions du benchmark ExploitGym directement depuis la base de données.

Depuis les premiers travaux autour de PentestGPT, présentés à USENIX Security, l’offre du marché et la recherche académique ont fortement évolué. Ces travaux ont montré que les LLM pouvaient apporter une réelle valeur aux tests d’intrusion, d’abord comme assistants capables de structurer le raisonnement d’un opérateur, puis comme moteurs de systèmes plus autonomes.
Le potentiel de l’IA générative devient plus important lorsque le modèle est intégré à une solution agentique capable de planifier des actions, d’appeler des outils, d’analyser leurs résultats et d’adapter sa stratégie. Les publications décrivant des architectures multi-agents se multiplient^[2][3][4], tout comme les projets open source. En parallèle, des acteurs commerciaux s’installent sur le marché et attirent des financements significatifs, à l’image de Horizon3, qui a annoncé 250 millions de dollars de financement en août 2026.^[5]

Quels types de solutions existent sur le marché ?

Le périmètre retenu couvre les solutions agentiques utilisant un ou plusieurs modèles d’intelligence artificielle générative afin d’assister ou de réaliser un test d’intrusion. Il exclut donc :

• Les modèles LLM considérés isolément comme Fable 5, GPT 5.6, ou DeepSeek V4 Pro
• Les solutions qui sélectionnent leurs actions au moyen de modèles décisionnels non génératifs (e.g. DeepExploit)
• Les solutions qui automatisent les tests d’intrusion en utilisant des méthodes déterministes (e.g. AutoPentestX)

Parmi l’ensemble des solutions documentées en ligne, une grande partie sont des solutions open-source disponibles sur GitHub. Certains de ces projets sont avant tout des prototypes académiques destinés à faire progresser l’état de l’art. À l’autre extrémité du spectre, un nombre croissant d’éditeurs proposent des plateformes promettant d’effectuer des tests d’intrusion à la demande ou en continu, généralement plus intégrées mais aussi plus opaques sur leur architecture.

Architecture

Plusieurs architectures co-existent sur le marché mais l’architecture globale d’une solution agentique peut être décrite par le schéma ci-dessous (voir cet article pour plus de détails) :

Le tableau ci-après recense les principales familles d’architectures identifiées, sans détailler leurs mécanismes de fonctionnement, dans un souci de concision et de lisibilité :

Ces catégories ne sont pas mutuellement exclusives. Une même solution peut, par exemple, associer un orchestrateur, plusieurs agents spécialisés et des outils exposés via MCP.

Autonomie

Le niveau d’autonomie doit être distingué des capacités techniques. Une solution peut être très performante sur une tâche précise tout en nécessitant de nombreuses interventions humaines. Le panorama utilise l’échelle suivante : 

• Assistant piloté par l’humain : la solution est un assistant possédant une expertise en cybersécurité avec qui l’humain peut discuter et demander des conseils, il n’y a pas d’exécution directe des outils et d’interaction avec la cible (e.g. PentestGPT v0)
• Semi-autonome : la solution est en partie autonome sur certaines tâches mais nécessite une configuration par l’humain relativement complexe en amont et/ou demande régulièrement des interventions humaines pour continuer le test d’intrusion (e.g. hackingBuddyGPT)
• Automatisé avec intervention humaine : la solution réalise une grande majorité du test d’intrusion de manière autonome mais garde l’humain dans la boucle pour les actions les plus critiques ou pour la confirmation (e.g. Decepticon)
• Complètement automatisé de bout en bout : la solution réalise l’entièreté du test d’intrusion avec une intervention humaine minimale voire inexistante (e.g. Strix)

Capacités couvertes

Les tests d’intrusion recouvrent une large gamme de catégories différentes qui ne sont pas représentées de manière homogène sur le marché.

En effet, l’offre est aujourd’hui la plus mature pour le secteur des applications web, des API, de la revue de code (SAST) et dans une moindre mesure pour les tests d’intrusion d’infrastructure interne. En revanche, beaucoup moins de solutions se positionnent spécifiquement sur les tests d’intrusion en milieu industriel, les audits produits et la rétro-ingénierie avancée. Les revendications liées au Red Teaming doivent être analysées avec prudence. Un exercice de Red Team ne consiste pas seulement à trouver des vulnérabilités : il impose une maîtrise fine de la furtivité, des règles d’engagement et du risque opérationnel. Ces contraintes sont plus difficiles à déléguer à un agent autonome qu’une recherche exhaustive de vulnérabilités sur une application isolée. 

Par ailleurs, beaucoup de solutions open-source et académiques sont conçues et évaluées sur des environnements simplifiés de type Capture The Flag (CTF). Bien que la résolution de ces tâches témoigne de bonnes capacités cyber-offensives, les CTF émulent souvent un environnement très simplifié avec un processus d’exploitation en entonnoir bien différent de la grande complexité des environnements réels.

Néanmoins, certaines solutions ont démontré leur potentiel en trouvant des vulnérabilités dans des projets en production. AISLE revendique 380 CVE attribuées^[6], dont 98 CVE confirmées par BugFlation^[7]. L’agent autonome XBOW s’est classé à la première place du classement HackerOne en l’espace de quelques mois et l’éditeur affirme avoir trouvé plus de 14 000 zero-days^[8] dans les applications de ses clients. Parmi les solutions open-source, on peut citer MAPTA et VulnHuntr qui ont respectivement trouvé 19 vulnérabilités^[9] et 10 zero-days^[10] (dont 6 enregistrées comme CVE) dans des projets open-source populaires.

Critères de comparaison

Pour établir une comparaison cohérente, les critères suivants ont été retenus :

• Le type, pour distinguer les solutions entièrement open-source, les solutions commerciales et les offres hybrides dont le code est open-source mais qui proposent une plateforme plus puissante pour le déployer
• L’architecture
• Le degré d’autonomie, pour déterminer selon les besoins un juste milieu entre le chatbot assistant et le test d’intrusion entièrement automatisé de bout en bout
• Les catégories de test couvertes :
  • Applications web, API et applications mobiles
  • Revue de code et revue de configuration
  • Infrastructure et réseau
  • Cloud et conteneurs
  • Pentest industriel, audit produit et rétro-ingénierie
  • Red Team et ingénierie sociale
• Les modèles supportés
• Les coûts, à la demande ou par mois pour les solutions commerciales et en consommation de tokens pour les solutions open-source
• La popularité, au travers du nombre d’étoiles sur les dépôts GitHub

La question des modèles supportés par les solutions agentiques est particulièrement pertinente car certaines solutions ne fonctionnent qu’avec des modèles particuliers (typiquement ceux d’OpenAI et d’Anthropic) ou ne donnent des résultats satisfaisants qu’avec les modèles frontières propriétaires.

Étant donné le prix conséquent des tokens pour les modèles frontières, il est pertinent de se demander si ces solutions peuvent s’interfacer sur des modèles locaux ou des modèles moins performants mais moins coûteux, tels que DeepSeek ou Kimi, et fonctionner de manière équivalente.

Pour donner un ordre de grandeur, une exécution consommant 4 millions de tokens en entrée et 1 million en sortie coûterait environ 90 dollars avec Claude Fable 5, 45 dollars avec Claude Opus 4.7 et moins de 3 dollars avec DeepSeek V4 Pro, sur la base des tarifs publics observés en juillet 2026. Cette comparaison reste indicative car le coût réel peut varier en fonction de la mise en cache, des appels d’outils, des nouvelles tentatives et des différences de tokenisation.

Que peuvent concrètement faire ces solutions ?

Forces

Dans le cas général, les solutions agentiques sont très efficaces sur les vulnérabilités répandues et bien documentées (injection SQL, XSS, CVE) mais moins pertinentes pour identifier des zero-days ou exploiter les vulnérabilités plus spécifiques nécessitant la compréhension d’une logique métier complexe.

Leur intérêt immédiat réside donc moins dans le remplacement de l’auditeur que dans l’augmentation de sa capacité de travail. Utilisées sous supervision, ces solutions peuvent :

• Accélérer la reconnaissance, l’énumération et la cartographie de la surface d’attaque 
• Explorer davantage de pistes et générer plus de variantes de payloads que ne le ferait un opérateur dans le même temps
• Documenter les étapes suivies et préparer une première version des constats et des recommandations
• Automatiser une partie des re-tests afin de vérifier la reproductibilité d’une vulnérabilité et l’efficacité d’un correctif
• Réserver le temps de l’auditeur aux décisions complexes, à la compréhension métier et aux scénarios d’exploitation à forte valeur. 

Points d’attention

Néanmoins, toutes les solutions ne sont pas nécessairement encore prêtes à être intégrées telles quelles dans des missions d’audit et de tests d’intrusion.

Les hallucinations restent un risque, notamment lorsque l’agent déduit une vulnérabilité à partir d’un retour partiel ou interprète incorrectement la sortie d’un outil. Les mécanismes de validation réduisent les faux positifs, mais ne les éliminent pas. 

La maîtrise du périmètre constitue un second enjeu. Un agent peut multiplier les requêtes, suivre une redirection vers un domaine tiers, utiliser un identifiant non prévu ou déclencher une action perturbatrice. Les garde-fous doivent donc être techniques et non uniquement formulés dans le prompt.

Certaines vulnérabilités nécessitent également de l’intuition, une compréhension fine du métier ainsi que du périmètre et une capacité à évaluer l’impact au-delà de la preuve de concept. Ces dimensions restent difficiles à automatiser et justifient le maintien d’un opérateur expérimenté dans la réalisation du test d’intrusion. 

Enfin, la confidentialité et la souveraineté des données sont centrales. Un test d’intrusion peut exposer du code source, des détails d’architecture, des identifiants, des données de test et des vulnérabilités non corrigées. Avant l’utilisation d’un modèle distant, il faut donc examiner les conditions de conservation, l’usage éventuel des données pour l’entraînement, la localisation du traitement, les sous-traitants et les possibilités de déploiement local ou dans un environnement maîtrisé. 

Panorama

Le marché des solutions agentiques appliquées aux tests d’intrusion évolue à un rythme particulièrement soutenu. Les projets se multiplient, les architectures changent rapidement et de nouveaux acteurs apparaissent régulièrement. Le radar ci-dessus présente une répartition des capacités couvertes sur un ensemble de 69 solutions mais tout panorama est une photographie datée, qu’il est nécessaire d’actualiser fréquemment.

Applications web, API et mobile

Cette catégorie regroupe les solutions conçues pour tester des applications web, des API et, plus rarement, des applications mobiles. Elle représente la part la plus importante du marché étudié avec une couverture par 81% des solutions de ce panorama. Certaines solutions adoptent une approche en boîte noire à partir d’une URL, tandis que d’autres acceptent des comptes de test, de la documentation d’API ou un accès complet au code source. 

Les solutions les plus convaincantes ne se limitent pas à lancer des scanners : elles construisent un modèle de l’application, gèrent l’authentification, suivent les états de session, vérifient l’exploitabilité et conservent les preuves nécessaires au rapport.

Parmi les solutions les plus prometteuses on peut citer Decepticon, Strix, Shannon, RedAmon, Transilience AI, DarkMoon, Pentest Swarm AI, Aikido et XBOW.

Infrastructure et réseau

Cette catégorie couvre les tests d’intrusion internes et externes, la cartographie réseau, l’élévation de privilèges et l’Active Directory. Ce domaine est moins mature que celui des applications web mais reste couvert par 52% des solutions étudiées. Plusieurs solutions reposent encore largement sur l’orchestration d’outils existants, comme Nmap, BloodHound ou Metasploit, sans toujours démontrer une réelle capacité à prioriser les chemins d’attaque dans un environnement complexe. 

Parmi les solutions intéressantes de cette catégorie, on trouve Pentera, Cracken, PentAGI, NeuroSploit et CyberStrike AI.

Analyse de code et revue de configuration

Cette catégorie regroupe les outils d’analyse de code, de revue de configuration et de recherche de vulnérabilités à partir d’un dépôt. Elle recouvre des usages proches du SAST, l’analyse des dépendances, la recherche de secrets, l’étude des configurations d’infrastructure as code et certains contrôles de supply chain.

36% des solutions étudiées couvrent cette catégorie avec notamment AISLE, Claude Security, Shannon, RepoAudit, Metis, Raptor et Clearwing.

Cloud et conteneurs

La plupart des solutions de cette catégorie qui regroupe 30% des outils étudiés permettent surtout de découvrir les points de terminaison basés sur le cloud et de détecter les mauvaises configurations des systèmes cloud et des conteneurs associés. L’exploitation concrète de vulnérabilités d’échappement de conteneurs Kubernetes, par exemple, reste assez rare.

Aikido, Hadrian, Claude Bug Bounty, PentestAgent et RedAmon font partie des solutions les plus intéressantes de cette catégorie.

Red Team et ingénierie sociale

De nombreux outils se présentent comme des solutions de Red Team, mais cette étiquette recouvre des réalités très différentes. Seulement 13% des solutions du panorama présentent des fonctionnalités caractéristiques d’une équipe Red Team : recherche d’un chemin de compromission pertinent par rapport à un objectif avec un haut niveau de contrôle, de furtivité et d’adaptation. Une solution qui énumère massivement des services ou exécute des charges utiles facilement identifiables par les solutions de sécurité peut être utile en tests d’intrusion tout en étant inadaptée à une opération de Red Team.

Certains outils proposent également des fonctions d’OSINT ou d’ingénierie sociale.

Parmi les solutions les plus prometteuses, on retrouve Decepticon, RedAmon, Drakben, Cracken et Pentera.

Pentest industriel, audit produit et rétro-ingénierie

Peu de solutions (7% des solutions étudiées) revendiquent explicitement des capacités robustes sur les tests d’intrusion en milieu industriel, en audit de produits ou en rétro-ingénierie. Certains agents intègrent des outils de désassemblage ou de décompilation, mais ces fonctions sont souvent présentées comme des briques supplémentaires pour les CTF plutôt que comme une capacité complète d’audit.

Les solutions les plus pertinentes de cette catégorie sont Decepticon, DeepZero, Clearwing et plus particulièrement CAI qui documente des cas d’usage dans des milieux industriels.^[11]

Conclusion

La multiplication des projets, leurs mises à jour fréquentes et l’arrivée régulière de nouveaux acteurs contribuent à faire évoluer rapidement ce panorama. Cette analyse se heurte également à un manque de données comparables : les capacités revendiquées par les éditeurs et les développeurs ne sont pas toujours démontrées dans des conditions réalistes, notamment pour les solutions commerciales, par nature plus opaques sur leurs résultats.

Une tendance de fond se dégage néanmoins : à court terme, ces solutions ne remplaceront pas les auditeurs professionnels. Elles peuvent en revanche augmenter significativement leurs capacités, en automatisant les tâches répétitives, en améliorant l’exhaustivité des recherches et en accélérant certaines phases du test, de la reconnaissance au re-test des vulnérabilités. Cette évolution pourrait également abaisser la barrière d’entrée de certaines opérations offensives. Des profils moins expérimentés (script kiddies) pourront s’appuyer sur des agents pour orchestrer des outils et produire des charges utiles auparavant réservées à des opérateurs plus qualifiés.

À ce stade, les solutions les plus performantes restent par ailleurs coûteuses, notamment lorsqu’elles reposent intensivement sur des modèles propriétaires de pointe. Leur adoption devra donc être évaluée au regard du gain de productivité obtenu, mais aussi des contraintes de confidentialité, de souveraineté et de maîtrise opérationnelle propres à chaque mission.

La sécurisation des agents eux-mêmes constitue enfin un chantier encore peu mature : manipulation du contexte, détournement des outils, exposition de secrets ou non-respect du périmètre peuvent transformer un accélérateur opérationnel en nouvelle surface d’attaque.

L’enjeu n’est donc plus de déterminer si l’IA agentique modifiera les tests d’intrusion, mais à quelle vitesse et selon quelles modalités. La prochaine étape consistera à confronter une sélection de ces solutions à des scénarios représentatifs de missions d’audit de sécurité, afin de mesurer leurs capacités effectives, leurs coûts, leurs limites et les conditions nécessaires à leur intégration dans les pratiques des auditeurs cybersécurité.

^[1] https://openai.com/fr-FR/index/hugging-face-model-evaluation-security-incident/

^[2] https://arxiv.org/abs/2408.11650

^[3] https://arxiv.org/abs/2510.05605

^[4] https://arxiv.org/abs/2509.13021

^[5] https://horizon3.ai/news/press-release/horizon3-raises-250m-series-e-at-2b-valuation-to-lead-the-ai-vs-ai-cybersecurity-era/

^[6] https://aisle.com/cve-discoveries

^[7] https://bugflation.com/systems/aisle/

^[8] https://xbow.com/news/xbow-named-winner-in-fast-companys-2026-world-changing-ideas-awards

^[9] https://arxiv.org/pdf/2508.20816

^[10] https://github.com/protectai/vulnhuntr

^[11] https://aliasrobotics.com/case-studies/case-study-cai-mqtt-broker.php 

Cet article ​​Panorama des solutions agentiques pour les tests d’intrusion​  est apparu en premier sur RiskInsight.

Mais depuis quelques temps, certains comités exécutifs ne sont plus aussi généreux et exigent davantage d’efforts de la part de la filière SSI. On le sait : prouver l’efficacité des moyens engagés n’est pas aisé, et certains RSSI se retrouvent à batailler pour ne serait-ce que maintenir leur budget annuel. La situation post-COVID risque de ne rien arranger, et mon petit doigt me dit qu’il n’y a aucune raison pour que la cyber échappe aux impératifs d’économies à venir.

Sur le terrain, les trois leviers suivants peuvent présenter des opportunités pour optimiser les coûts d’une filière SSI : 1. La revue de l’Operating Model, 2. la massification des contrats, 3. l’automatisation et le recours à l’offshore.

1/ La revue de l’Operating Model

Pour optimiser un Operating Model SSI, il faut rapidement se poser la question des redondances. Le constat est souvent le même d’une entreprise à l’autre : la filière SSI a grandi très rapidement, et différentes équipes ont des missions très proches voire redondantes. Beaucoup de prestataires peuvent en témoigner : il est assez classique d’être sollicité plusieurs fois pour la même étude au sein d’un Grand Compte, dans plusieurs entités différentes. Même si quelques entreprises envisagent de traiter ce sujet par une centralisation complète de l’équipe sécurité (quelques exemples récents dans l’industrie), la clé est plutôt de regrouper a minima l’expertise cyber en central et de structurer des offres de service consommables par tous : pentests, SOC, redteam, rédaction de politiques, awareness…

Attention, cela peut représenter un changement de posture fort pour de nombreuses équipes RSSI, qui passent ainsi d’un rôle de prescripteur à un rôle d’offreur de service avec toutes ses facettes (SLA, mesure de la qualité, voire pénalités). Mais c’est une excellente manière de supprimer les redondances, optimiser les coûts et clarifier au passage les responsabilités !

2/ La massification des contrats

Les contrats d’achat représentent souvent plus de la moitié des dépenses de la filière SSI et peuvent évidemment présenter d’excellentes pistes d’optimisation. De nombreuses entreprises ont multiplié le déploiement tactique de solutions de sécurité et il n’est pas rare de se retrouver en production avec 4 types d’IPS, 3 EDR et 3 SIEM… Une solution simple pour reprendre le contrôle et optimiser les coûts est de revenir au bon vieux catalogue de solutions avec prix négociés en central : maximum 2 produits référencés par techno et obligation pour toutes les entités de taper dans le catalogue ! Les résultats peuvent être spectaculaires en jouant sur les effets de volume.

Même approche pour les prestations : il s’agit d’éviter l’éparpillement des contrats et de faire jouer la concurrence. Sur le terrain, on constate typiquement une tendance à la massification des contrats ne nécessitant pas d’expertise cyber pointue : gestion de projets, PMO, conduite du changement… D’expérience il est assez simple d’aller chercher 10%-15% sur les taux journaliers, le panel des sociétés étant beaucoup plus important pour ce type de tâche ! Mais attention à ne pas perdre en valeur : il ne s’agit pas de baisser la garde sur l’expertise ou la stratégie cyber.

3/ L’automatisation et le recours à l’offshore

L’automatisation peut également être une piste d’optimisation à explorer à moyen terme. D’autant plus que le mouvement est déjà en marche : solutions SOAR pour le traitement des incidents, apprentissage automatique pour la détection d’anomalies, déploiement de mesures dans le Cloud… de nombreuses activités de la cybersécurité cherchent actuellement à gagner en rapidité en tirant partie de l’automatisation des tâches répétitives. Les résultats ne sont évidemment pas immédiats, mais la conjoncture actuelle risque clairement de booster les projets de ce type !

Une stratégie d’offshore peut en revanche présenter des résultats beaucoup plus immédiats, mais attention aux projets menés dans la précipitation. L’offshore d’activités sécurité est tout sauf tactique et nécessite un gros travail de cadrage pour comprendre les spécificités de chaque pays, établir une proximité avec le management local, et surtout intégrer sans couture l’offshore dans l’operating model SSI… Les opérations d’offshore réussies embarquent jusqu’à 20% des effectifs de la filière en offshore. La clé pour atteindre de tels volumes est de privilégier la fourniture de services standardisés en offshore (opérations, scans de vulnérabilités, traduction…), et de limiter les équipes étendues qui peuvent s’avérer séduisantes sur le papier mais souvent contre-productives car complexes à piloter.

Cet article La cyber n’échappera pas à la réduction des coûts est apparu en premier sur RiskInsight.

Un concours digne d’une compétition sportive

Au Paris Hotel de Las Vegas, Nevada, s’est déroulé en août 2016 cet étrange concours digne d’une compétition sportive. Pendant près de 12 heures, d’imposantes machines, appelées Cyber Reasoning Systems se sont affrontées dans l’arène devant un public de 3000 personnes, auquel les présentateurs expliquaient les tentatives d’attaques et les corrections de vulnérabilités grâce à des représentations en 3D très parlantes. Organisé par la DARPA, ce concours avait un double but : valider le concept de cyberdéfense automatisée et stimuler la recherche en offrant 4 millions de dollars de prix, dont 2 à l’équipe vainqueur.

Selon Mike Walker, responsable du programme du Cyber Grand Challenge, les failles de sécurité exploitées dans la nature le seraient pendant 312 jours en moyenne avant leur détection et le temps médian de correction après détection serait de 24 jours. Un délai très long pendant lequel les systèmes restent vulnérables et que la DARPA souhaiterait voir réduit à quelques minutes ou secondes, en confiant aux machines la tâche de détecter et de corriger elles-mêmes ces failles de sécurité.

Depuis l’annonce du concours en 2013, la DARPA qui prend le sujet très au sérieux, y a investi 55 millions de dollars. 7 équipes aux propositions intéressantes ont été invitées à participer au concours en recevant une aide financière mais l’entrée restait ouverte à toute équipe auto-financée souhaitant relever le défi. En juin 2015, les qualifications ont eu lieu sur Internet pendant 24 heures au cours desquelles les équipes devaient trouver le maximum de vulnérabilités affectant 131 programmes. Sur plus de 100 équipes les 7 meilleures se sont qualifiées pour l’événement final, touchant 750.000$ au passage afin de s’y préparer. Parmi elles, 3 équipes financées par la DARPA et 4 équipes auto-financées.

Au bout de 12 heures de compétition acharnée, c’est Mayhem, le CRS de l’équipe ForAllSecure qui a remporté la victoire malgré une difficulté technique qui l’a empêché de soumettre des correctifs pendant une partie de l’épreuve. Mayhem a eu le privilège de pouvoir concourir au concours « normal » de la conférence DEFCON où s’affrontaient les meilleures équipes de hackers du monde entier. Mayhem est arrivé bon dernier de ce concours, mais à quelques points seulement de la dernière équipe humaine. Ce résultat peut être comparé à la progression des machines contre les humains aux échecs en conditions de tournoi : entre les premières victoires des machines contre des maîtres au début des années 80 et le moment où les machines parvenaient à battre des grands maîtres de façon régulière au milieu des années 2000, 25 ans se sont écoulés.

Si les machines talonnent aujourd’hui les meilleures équipes de hackers, de quoi seront-elles capables dans 10 ou 20 ans ?

Vers un monde plus sûr ?

David Brumley, CEO de ForAllSecure spinoff de l’université Carnegie Mellon, souhaite que dans le monde ultra connecté qui est le nôtre, chacun puisse avoir la garantie que les objets et les applications que nous utilisons soient sûrs, sans s’en remettre uniquement à leurs développeurs. Mais si le développement d’une cyberdéfense automatisée est une aubaine pour la société civile, on peut bien imaginer quelles implications offensives ces recherches pourraient avoir. Découvrir rapidement et en grande quantité des bugs dans des programmes fournirait autant de munitions à un état décidé à attaquer des systèmes d’organisations ou d’autres nations n’étant pas alignées avec ses intérêts. Et l’on peut être sûr que la DARPA, dont la vocation première est militaire, en a parfaitement conscience.

Cet article Et si les machines assuraient leur propre cyberdéfense ? est apparu en premier sur RiskInsight.

La sécurité des Systèmes d’Informations Industriels (SII) est aujourd’hui au centre des préoccupations dans les entreprises concernées. Ces systèmes permettent une action directe dans le monde « physique » à l’aide d’instructions provenant du monde « logique » et pilotent les outils de production de nombreuses entreprises.

Du fait du manque de sécurité de ces systèmes, de nombreuses attaques ont été recensées dans le monde ces dernières années. La dernière en date ayant eu le plus gros impact est l’attaque du réseau électrique de l’Ukraine en décembre dernier [1]. De nombreuses personnes se sont retrouvées sans électricité suite à une attaque du réseau industriel.

Le plus bas niveau des SI industriels est le réseau de production. Les capteurs et les actionneurs sont reliés aux entrées/sorties des automates industriels. Les protocoles utilisés pour communiquer avec ces automates sont généralement des protocoles propriétaires. Parmi les plus utilisés, on retrouve : Modbus, S7comm, DNP3, Profibus, Hart… Ces protocoles manquent souvent des principales fonctions de sécurité à savoir l’authentification et le chiffrement des flux. Il est donc possible de rejouer des requêtes et de réaliser des actions malveillantes directement sur les automates.
Modbus, protocole de Schneider Electric publiquement documenté et libre de droits, est une norme de référence pour les communications industrielles. De nombreux outils utilisant ce protocole existent pour communiquer avec les automates Schneider :

Cet article S7comm : un outil de communication avec les Automates Programmables Industriels Siemens est apparu en premier sur RiskInsight.

La virtualisation de serveurs a apporté un premier niveau de réponse à ces besoins de flexibilité au sein du datacenter. Plus récemment, le cloud computing est arrivé avec son lot de promesses d’optimisations et de souplesse supplémentaire.

Au-delà des buzz générés successivement autour de ces solutions, dans quelle continuité s’inscrivent-elles et quelles différences y a-t-il entre deux concepts souvent confondus ?

Retour sur les évolutions apportées par la virtualisation 

La virtualisation système consiste à faire fonctionner sur un même serveur physique plusieurs systèmes d’exploitation en parallèle. Ceci est réalisé au travers d’un hyperviseur assurant aussi bien la virtualisation du serveur physique que celle de ses interfaces (réseau, stockage…). La virtualisation s’inscrit ainsi dans le modèle SOI comme un moyen d’implémenter une couche « ressource ».

La virtualisation permet :

• De réduire le nombre de serveurs physiques en les consolidant,
• De normaliser le socle d’hébergement des OS sous forme de VM,
• D’améliorer l’agilité en réduisant le temps de provisioning,
• De renforcer la disponibilité et la reprise d’activité en offrant des mécanismes de migration et de redémarrage automatique intégrés.

La virtualisation apporte ainsi de nombreux bénéfices qu’il reste à bien mettre en balance face à ses contraintes. En effet, il faut  noter qu’elle a tendance à augmenter la complexité de l’architecture et de son exploitation et que la facilité de création des machines virtuelles peut provoquer une prolifération des instances de serveurs. Par ailleurs, la virtualisation génère de nouvelles problématiques de sécurité  et peut être source de contentions entre les services. Enfin, mêmes virtualisées, le temps de déploiement des ressources reste conséquent.

 Le cloud computing : au-delà du buzz, un mode de consommation

Depuis 2008, parallèlement à l’évolution interne des SI est apparu le cloud computing publique, promettant un niveau supplémentaire d’agilité avec une mise à disposition très rapide de ressources élastiques et une facturation adaptée à la consommation réelle.

Malgré les promesses du cloud public, les entreprises restent aujourd’hui frileuses dans son adoption. Les freins majeurs étant  les risques de sécurité perçus (utilisation d’internet, confidentialité des données et soumission à des lois locales à l’opérateur) ainsi que la dépendance aux fournisseurs engendrée par le manque de standards.

Une notion intermédiaire est donc apparue, le cloud privé. Il a pour vocation d’amener la flexibilité du cloud public dans le SI des entreprises tout en répondant aux réticences des DSI sur la sécurité et la fiabilité des services fournis.

 De la virtualisation au cloud privé

La mise en place d’un cloud privé peut être vue comme un empilement de blocs fonctionnels mettant à disposition des utilisateurs les ressources du SI en self-service, de manière automatisée, tout en offrant un niveau de qualité de service et de sécurité calibré.

Pour obtenir une plate-forme de cloud privé interne IaaS*, les principales fonctionnalités agrégées autour d’un socle de virtualisation système  sont les suivantes :

• L’automatisation du provisioning : supprimer les actions manuelles des processus de mise à disposition de ressources ;
• L’orchestration : mettre en musique les actions sur les différents composants de la plate-forme ;
• La supervision : contrôler le bon fonctionnement et collecter les métriques d’usage ;
• L’authentification et le contrôle d’accès : gérer finement les droits d’accès aux ressources et à leur administration ;
• Le portail self-service : permettre à l’utilisateur de réaliser ses demandes de création, modifications, et éventuellement suppression de ressources ainsi qu’en consulter les informations (inventaire, facturation, utilisation…) ;
• La refacturation à l’usage : traduire les métriques d’utilisation des ressources en termes budgétaires et les basculer dans les systèmes de gestion internes ;
• Le catalogue de service : être le référentiel des caractéristiques de ce qui peut être déployé.

La majorité de ces blocs existent déjà dans les SI et sont alors adaptés à l’occasion du passage au cloud privé. Ce passage s’inscrit dans une démarche d’évolution à la suite des travaux de normalisation et standardisation, de catalogues de services, d’automatisation et mise en place de stratégies self-service dans les DSI. C’est un mouvement précurseur des grandes tendances d’automatisation globale du SI.

[Article rédigé en collaboration avec Julien Contal et Aurélien Delcros]

Pour en savoir plus sur la virtualisation et le cloud computing, consulter la synthèse Solucom : Virtualisation et cloud computing : jusqu’où aller ? 

* : Le marché du cloud privé est structuré de la même facon que le cloud publique entre SaaS, PaaS et IaaS. Ce billet traite principalement du cloud privé interne IaaS. La structuration de ce marché est décrite dans la synthèse Virtualisation et cloud computing : jusqu’où aller ? 

Cet article Cloud privé, à la recherche du Graal est apparu en premier sur RiskInsight.