IA Offensive et Défensive en Cybersécurité | Guide 2025

4.1 La reconnaissance automatisée : de la collecte à l'analyse

La phase de reconnaissance constitue la première étape de toute opération offensive et conditionne la réussite des phases ultérieures. Traditionnellement réalisée manuellement par des pentesters et des opérateurs offensifs, cette phase est profondément transformée par l'intégration de l'intelligence artificielle. L'IA ne se contente pas d'accélérer la collecte d'informations : elle apporte une capacité d'analyse, de corrélation et de contextualisation qui permet d'extraire des insights exploitables à partir de volumes massifs de données hétérogènes.

L'OSINT (Open Source Intelligence) automatisé par IA combine plusieurs disciplines : le web scraping intelligent, le traitement du langage naturel pour l'analyse de contenu textuel, la vision par ordinateur pour l'analyse d'images et de documents, et les techniques de graph analytics pour la cartographie des relations entre entités. Des frameworks comme SpiderFoot, Maltego et theHarvester intègrent progressivement des capacités de ML pour automatiser la corrélation d'informations provenant de sources multiples.

Dans le domaine de la reconnaissance technique, l'IA permet d'analyser automatiquement les résultats de scans réseau (Nmap), d'identifier les technologies web utilisées par une cible (Wappalyzer), de détecter les certificats SSL et leurs chaînes de confiance, et de corréler ces informations avec les bases de vulnérabilités connues (NVD, CVE). Des agents basés sur des LLM peuvent désormais interpréter les résultats de ces outils, identifier les vecteurs d'attaque potentiels et prioriser les cibles en fonction de leur exposition et de leur criticité estimée.

4.2 OSINT sur les réseaux sociaux et profilage par IA

Les réseaux sociaux constituent une source d'information inépuisable pour la reconnaissance offensive. LinkedIn, en particulier, fournit des données précieuses sur la structure organisationnelle d'une cible : organigramme, technologies utilisées (mentionnées dans les offres d'emploi et les profils techniques), partenaires et fournisseurs, et informations sur les processus internes. L'IA permet d'automatiser l'extraction et l'analyse de ces informations à grande échelle.

Les techniques de profilage par IA vont au-delà de la simple collecte de données factuelles. Des modèles de NLP analysent le style d'écriture, les centres d'intérêt et les interactions en ligne d'une cible pour construire un profil psychologique exploitable dans le cadre d'opérations d'ingénierie sociale. Les travaux de Kosinski et al. (2013) ont démontré que l'analyse des "likes" Facebook permettait de prédire avec précision des traits de personnalité, l'orientation politique et d'autres caractéristiques personnelles, des informations directement exploitables pour la conception de campagnes de phishing ciblées.

L'analyse de graphes sociaux par des algorithmes de ML permet d'identifier les individus occupant des positions clés dans le réseau relationnel d'une organisation, les relations informelles entre départements, et les points de vulnérabilité humaine dans la chaîne de sécurité. Des techniques de community detection et de centrality analysis identifient les personnes les plus influentes ou les plus connectées, qui constituent des cibles privilégiées pour le spear-phishing et les attaques par watering hole.

4.3 Scan de vulnérabilités augmenté par IA

L'analyse automatisée de vulnérabilités bénéficie considérablement de l'intégration du ML. Les scanners de vulnérabilités traditionnels comme Nessus, OpenVAS et Qualys reposent principalement sur des bases de signatures et des heuristiques prédéfinies. L'IA apporte une couche d'intelligence supplémentaire en permettant la découverte de vulnérabilités inconnues (zero-day) par analyse de patterns, la priorisation des vulnérabilités en fonction du contexte spécifique de la cible, et la génération automatique de scénarios d'exploitation.

Les modèles de NLP appliqués à l'analyse de code source permettent d'identifier des patterns de vulnérabilités qui échappent aux analyses statiques traditionnelles. Des travaux comme ceux de Li et al. (2018) avec VulDeePecker et de Zhou et al. (2019) avec Devign démontrent que les réseaux de neurones peuvent apprendre à détecter des vulnérabilités à partir du code source avec des taux de détection significativement supérieurs aux outils d'analyse statique classiques. Ces approches sont particulièrement efficaces pour les classes de vulnérabilités impliquant des interactions complexes entre plusieurs fonctions ou modules, comme les use-after-free, les race conditions et les dépassements de tampons dépendant du contexte.

L'analyse de surface d'attaque automatisée par IA intègre la reconnaissance réseau, l'identification des services exposés, l'analyse des configurations et la corrélation avec les bases de vulnérabilités pour produire une cartographie dynamique de la surface d'attaque d'une organisation. Des plateformes comme Censys, Shodan et Binary Edge fournissent les données brutes, tandis que les modèles de ML assurent l'analyse, la priorisation et la contextualisation. Le concept d'Attack Surface Management (ASM) basé sur l'IA est devenu une catégorie de produits à part entière dans l'écosystème de la cybersécurité.

4.4 Agents IA autonomes pour le pentesting

L'émergence d'agents IA autonomes capables de conduire des tests d'intrusion de manière semi-automatisée représente une avancée significative. Des projets de recherche comme PentestGPT (Deng et al., 2023) et AutoPT explorent l'utilisation de LLM comme moteur de raisonnement pour guider des opérations de pentesting. Ces agents peuvent interpréter les résultats d'outils de reconnaissance, formuler des hypothèses d'attaque, sélectionner et exécuter les outils appropriés, et adapter leur stratégie en fonction des résultats obtenus.

Le framework PentestGPT décompose le processus de pentesting en trois modules : un module de raisonnement basé sur GPT-4 qui planifie la stratégie d'attaque, un module de génération qui produit les commandes et scripts nécessaires, et un module de parsing qui interprète les résultats. Des évaluations sur des machines HackTheBox et des environnements CTF montrent que ces agents peuvent résoudre des scénarios de complexité intermédiaire de manière largement autonome, bien qu'ils nécessitent encore une supervision humaine pour les scénarios complexes impliquant du raisonnement créatif ou des techniques non conventionnelles.

Les implications pour la sécurité sont ambivalentes. D'un côté, ces agents démocratisent l'accès aux capacités de pentesting, permettant aux organisations disposant de ressources limitées de conduire des évaluations de sécurité plus fréquentes et plus exhaustives. De l'autre, ils abaissent la barrière d'entrée pour les acteurs malveillants, permettant à des attaquants moins qualifiés de mener des opérations offensives poussées. La communauté de la cybersécurité doit anticiper cette dualité et développer des défenses adaptées aux attaques semi-automatisées conduites par des agents IA.

Chapitre 5 : IA défensive - Détection d'anomalies et threat hunting assisté par ML

5.1 Détection d'anomalies réseau par machine learning

La détection d'anomalies réseau constitue l'application la plus mature et la plus répandue de l'IA défensive en cybersécurité. Contrairement aux systèmes de détection basés sur des signatures, qui ne peuvent identifier que des menaces préalablement répertoriées, les systèmes basés sur le ML apprennent le comportement normal du réseau et détectent les déviations statistiquement significatives, permettant théoriquement la détection de menaces inconnues (zero-day) et d'attaques avancées conçues pour contourner les signatures existantes.

Les approches non supervisées dominent ce domaine, car elles ne nécessitent pas de données étiquetées d'attaques, dont l'obtention est coûteuse et dont la représentativité est limitée. Les autoencodeurs, et plus particulièrement les autoencodeurs variationnels (VAE), sont largement utilisés pour apprendre une représentation compressée du trafic réseau normal. Les anomalies sont détectées par un score de reconstruction élevé, indiquant que le trafic observé dévie significativement du modèle appris. Les travaux de Mirsky et al. (2018) avec Kitsune ont démontré l'efficacité d'un ensemble d'autoencodeurs entraînés de manière incrémentale pour la détection d'anomalies réseau en temps réel, sans nécessiter de phase d'apprentissage supervisé.

Les modèles basés sur les graphes offrent une perspective complémentaire en modélisant les interactions entre entités du réseau (machines, utilisateurs, services) plutôt que les flux individuels. Les Graph Neural Networks (GNNs) et les techniques de graph embedding permettent de détecter des patterns d'attaque distribués qui seraient invisibles dans l'analyse de flux individuels, comme les mouvements latéraux, les communications C2 low-and-slow, et les exfiltrations de données utilisant des protocoles légitimes. Des travaux récents de Zhou et al. (2020) avec le système DeepLog et de Bowman et al. (2020) avec les Graph Attention Networks appliqués à la détection d'intrusion montrent des résultats prometteurs sur des datasets réalistes.

La détection d'anomalies sur les endpoints (EDR - Endpoint Detection and Response) utilise le ML pour analyser les séquences d'appels système, les comportements de processus et les modifications du système de fichiers. Les modèles séquentiels comme les LSTM et les Transformers sont particulièrement adaptés à l'analyse de séquences d'événements système, permettant de détecter des comportements malveillants comme l'injection de processus, l'élévation de privilèges et les techniques de persistance. Des solutions commerciales comme CrowdStrike Falcon, SentinelOne et Microsoft Defender for Endpoint intègrent massivement ces technologies.

5.2 Détection de malwares par deep learning

La détection de malwares par deep learning a connu des avancées spectaculaires au cours de la dernière décennie, dépassant significativement les performances des approches traditionnelles basées sur des signatures et des heuristiques. Les modèles de deep learning analysent les malwares à travers différentes modalités : analyse statique du code binaire, analyse dynamique du comportement en sandbox, et analyse du trafic réseau généré.

L'analyse statique par deep learning traite les fichiers exécutables comme des séquences de bytes bruts ou des images (technique de la visualisation de malwares). Les travaux pionniers de Raff et al. (2018) avec MalConv ont démontré qu'un CNN appliqué directement aux octets bruts d'un fichier PE pouvait atteindre des taux de détection supérieurs à 95% sur des datasets de grande taille. La technique de visualisation de malwares, initiée par Nataraj et al. (2011), convertit les fichiers binaires en images en niveaux de gris et applique des classificateurs d'images pour distinguer les familles de malwares. Cette approche, bien que contre-intuitive, capture des patterns structurels dans l'organisation du code binaire qui sont caractéristiques de chaque famille de malwares.

L'analyse dynamique utilise des sandboxes instrumentées pour capturer le comportement d'exécution des fichiers suspects : appels système, modifications du registre, communications réseau, création de fichiers et de processus. Des modèles séquentiels (LSTM, GRU, Transformers) analysent les séquences d'événements comportementaux pour détecter des patterns malveillants. L'avantage de l'analyse dynamique est sa résistance aux techniques d'obfuscation et de packing qui dégradent les performances de l'analyse statique. Cependant, les malwares avancés implémentent des techniques d'évasion de sandbox (sandbox detection) qui modifient leur comportement lorsqu'un environnement d'analyse est détecté.

Les architectures multimodales, combinant analyse statique et dynamique, représentent l'état de l'art actuel. Ces modèles fusionnent les caractéristiques extraites du code binaire, du comportement d'exécution et du trafic réseau pour produire une classification plus robuste. Les techniques d'attention (attention mechanisms) et les Transformers permettent au modèle d'identifier automatiquement les modalités et les caractéristiques les plus discriminantes pour chaque échantillon, adaptant dynamiquement la stratégie de détection.

5.3 Threat hunting assisté par IA : de la détection proactive à l'investigation

Le threat hunting, pratique proactive de recherche de menaces dans l'environnement d'une organisation, bénéficie considérablement de l'assistance de l'IA. Contrairement à la détection d'anomalies automatisée, qui génère des alertes de manière passive, le threat hunting implique une démarche active d'investigation guidée par des hypothèses. L'IA intervient à chaque étape de ce processus : formulation d'hypothèses, collecte de données pertinentes, analyse et corrélation, et évaluation des résultats.

La génération automatique d'hypothèses de threat hunting constitue une application directe des LLM. En analysant les flux de threat intelligence (rapports APT, indicateurs de compromission, bulletins de vulnérabilités), un LLM peut formuler des hypothèses de chasse adaptées au contexte spécifique de l'organisation : "Étant donné que le groupe APT29 a récemment ciblé le secteur [secteur de la cible] en utilisant des techniques de DLL sideloading via des mises à jour logicielles compromises, rechercher des charges DLL inhabituelles dans les répertoires de mise à jour des applications critiques." Cette capacité de contextualisation et de raisonnement transforme le threat hunting d'une activité réservée aux analystes les plus expérimentés en un processus plus accessible et systématique.

L'analyse comportementale des utilisateurs et des entités (UEBA - User and Entity Behavior Analytics) constitue un pilier du threat hunting assisté par ML. Les modèles UEBA construisent des profils comportementaux individuels pour chaque utilisateur et chaque entité (serveur, application, service) de l'organisation, détectant les déviations qui pourraient indiquer une compromission de compte, un mouvement latéral ou une exfiltration de données. Les techniques de clustering et de réduction de dimensionnalité (t-SNE, UMAP) permettent de visualiser les comportements anormaux dans un espace bidimensionnel, facilitant l'investigation par les analystes.

5.4 Réduction des faux positifs et fatigue d'alerte

L'un des défis majeurs des systèmes de détection basés sur le ML est la gestion des faux positifs. Un système de détection trop sensible submerge les analystes SOC sous un flot d'alertes non pertinentes, conduisant à la "fatigue d'alerte" (alert fatigue) et, paradoxalement, à une dégradation de la posture de sécurité lorsque les analystes commencent à ignorer systématiquement les alertes. Le rapport SANS 2024 sur les opérations SOC indique que 45% des analystes passent plus de la moitié de leur temps à traiter des faux positifs.

L'IA contribue à résoudre ce problème à travers plusieurs approches. Premièrement, les modèles de scoring de risque contextuel évaluent chaque alerte en fonction de multiples facteurs : la criticité de l'actif concerné, l'historique de l'utilisateur ou de l'entité, la corrélation avec d'autres alertes et indicateurs, et le contexte temporel. Deuxièmement, les techniques de clustering d'alertes regroupent les alertes liées à un même incident, réduisant le nombre total d'événements à traiter et facilitant l'investigation. Troisièmement, les modèles d'apprentissage actif (active learning) utilisent les décisions des analystes (vrai positif / faux positif) pour améliorer continuellement la précision du modèle, adaptant le seuil de détection au contexte spécifique de l'organisation.

Les métriques d'évaluation doivent être soigneusement choisies pour refléter les contraintes opérationnelles. Le taux de faux positifs (FPR) a un impact direct sur la charge de travail des analystes, tandis que le taux de vrais positifs (TPR ou recall) détermine la capacité de détection. L'optimisation du point de fonctionnement sur la courbe ROC doit intégrer le coût relatif des faux positifs (temps d'analyse perdu) et des faux négatifs (compromission non détectée), un équilibre qui varie selon l'organisation, le type de menace et la criticité des actifs protégés.

Chapitre 6 : SOAR et automatisation de la réponse à incident par IA

6.1 L'évolution du SOC : du SIEM au SOAR augmenté par IA

Le Security Operations Center (SOC) a connu une évolution architecturale profonde au cours de la dernière décennie. Les premières générations de SOC reposaient sur des systèmes SIEM (Security Information and Event Management) comme Splunk, IBM QRadar et ArcSight, qui agrègent et corrèlent les logs de sécurité selon des règles prédéfinies. L'introduction des plateformes SOAR (Security Orchestration, Automation and Response) a ajouté une couche d'automatisation, permettant l'exécution de playbooks de réponse standardisés en réponse à des types d'alertes prédéfinis.

L'intégration de l'IA dans les plateformes SOAR représente le prochain saut évolutif, transformant l'automatisation rigide basée sur des règles en une automatisation intelligente et adaptative. Les plateformes SOAR augmentées par IA, comme Palo Alto XSOAR avec Cortex XSIAM, Splunk SOAR avec Splunk AI, Microsoft Sentinel avec Copilot for Security, et Google Chronicle SOAR, intègrent des capacités de ML pour le triage intelligent des alertes, l'enrichissement automatique par threat intelligence, la corrélation cross-source et la recommandation de réponses adaptées au contexte.

Le concept de SOC autonome (autonomous SOC) représente la vision à long terme de cette évolution. Dans ce modèle, les systèmes d'IA gèrent de manière autonome la majorité des alertes de bas niveau et de complexité intermédiaire, permettant aux analystes humains de se concentrer sur les investigations complexes et les décisions stratégiques. Des études de Gartner estiment que d'ici 2026, les SOC augmentés par IA pourront traiter automatiquement 70% des alertes de niveau 1 (triage initial) et 40% des alertes de niveau 2 (investigation), réduisant significativement le temps moyen de détection (MTTD) et le temps moyen de réponse (MTTR).

6.2 Triage intelligent et priorisation des alertes

Le triage des alertes est la première étape où l'IA apporte une valeur immédiate et mesurable. Face à des volumes d'alertes quotidiens pouvant atteindre plusieurs dizaines de milliers dans les grandes organisations, la capacité de prioriser automatiquement les alertes en fonction de leur gravité réelle, plutôt que de leur sévérité théorique, est critique. Les modèles de ML pour le triage intègrent de multiples signaux : la nature de l'alerte, l'actif concerné et sa criticité business, l'utilisateur ou l'entité impliquée, le contexte temporel, la corrélation avec d'autres alertes récentes, et l'historique des décisions des analystes sur des alertes similaires.

Les techniques de classification multi-labels permettent d'assigner simultanément à chaque alerte une catégorie de menace (malware, phishing, insider threat, exfiltration), un niveau de criticité, et une recommandation d'action. Les modèles de ranking (learning to rank) ordonnent les alertes dans la file d'attente des analystes en optimisant un critère qui maximise la probabilité de détecter des vrais positifs critiques en premier. Des approches basées sur l'apprentissage par renforcement permettent d'adapter dynamiquement la politique de triage en fonction du feedback des analystes et de l'évolution du paysage des menaces.

6.3 Enrichissement automatique et contextualisation

L'enrichissement des alertes par des données de contexte est une étape essentielle mais chronophage de l'investigation de sécurité. Pour chaque alerte, l'analyste doit traditionnellement consulter de multiples sources : bases de threat intelligence (MISP, OTX, VirusTotal), registres WHOIS, bases de réputation IP, historique des interactions avec l'actif concerné, et documentation interne. L'IA automatise et accélère ce processus en interrogeant simultanément toutes les sources pertinentes et en synthétisant les résultats dans un rapport contextuel cohérent.

Les LLM apportent une dimension qualitative à l'enrichissement en étant capables de synthétiser des informations provenant de sources hétérogènes dans un rapport narratif compréhensible. Au lieu de présenter à l'analyste une liste de faits bruts (adresse IP répertoriée dans telle base de menaces, associée à tel ASN, utilisée dans telles campagnes précédentes), un LLM intégré dans la plateforme SOAR produit un résumé contextualisé : "Cette adresse IP est associée à l'infrastructure de commande et contrôle du groupe APT28 (Fancy Bear), utilisée dans la campagne [nom de campagne] ciblant le secteur [secteur] en [période]. Le pattern d'activité observé (connexions HTTPS périodiques toutes les 4 heures vers un domaine DGA) correspond au profil du malware X-Agent documenté dans le rapport [référence]."

6.4 Automatisation de la réponse à incident

L'automatisation de la réponse à incident par IA va au-delà de l'exécution de playbooks prédéfinis. Les systèmes SOAR augmentés par IA peuvent adapter dynamiquement la réponse en fonction du contexte spécifique de l'incident, de l'état de l'environnement et de l'évaluation du risque. Cette capacité d'adaptation est cruciale dans un environnement où les attaques sont de plus en plus polymorphes et où les réponses standardisées peuvent s'avérer inefficaces ou contre-productives.

Les actions de réponse automatisées se répartissent en plusieurs catégories de criticité. Les actions à faible risque, comme l'enrichissement de l'alerte, la création de tickets et la notification des équipes, peuvent être exécutées sans approbation humaine. Les actions à risque modéré, comme le blocage d'une adresse IP au niveau du firewall, la mise en quarantaine d'un email suspect ou la réinitialisation d'un mot de passe, nécessitent généralement une validation humaine mais bénéficient de recommandations pré-formulées par l'IA. Les actions à haut risque, comme l'isolation d'un serveur de production, le blocage d'un compte administrateur ou le déclenchement d'un plan de continuité d'activité, requièrent une approbation managériale et une évaluation d'impact que l'IA peut faciliter mais ne doit pas décider seule.

Le concept de "human-in-the-loop" est fondamental dans l'automatisation de la réponse à incident par IA. Les systèmes les plus avancés implémentent un modèle de confiance progressif, où le niveau d'autonomie de l'IA augmente graduellement en fonction de sa performance historique sur des types d'incidents spécifiques. Un système SOAR pourrait par exemple être autorisé à bloquer automatiquement les adresses IP identifiées comme malveillantes avec un score de confiance supérieur à 95%, tout en requérant une validation humaine pour les cas ambigus. Ce modèle de confiance doit être configurable par les équipes de sécurité et régulièrement révisé.

6.5 Métriques et mesure de l'efficacité

L'évaluation de l'efficacité des solutions SOAR augmentées par IA repose sur un ensemble de métriques opérationnelles et stratégiques. Le MTTD (Mean Time to Detect) mesure le temps entre l'occurrence d'un incident et sa détection. Le MTTR (Mean Time to Respond) mesure le temps entre la détection et la résolution. Le MTTI (Mean Time to Investigate) mesure le temps consacré à l'investigation proprement dite. L'IA impacte positivement ces trois métriques, avec des réductions documentées de 30 à 60% selon les déploiements.

Au-delà des métriques de temps, l'efficacité de l'IA en SOAR se mesure par le taux de résolution automatique (pourcentage d'alertes traitées sans intervention humaine), le taux de faux positifs réduit (comparé au système antérieur), le taux de détection de vrais positifs amélioré, et la satisfaction des analystes (mesurée par des enquêtes régulières). Les organisations matures intègrent ces métriques dans des tableaux de bord continus et les utilisent pour affiner les modèles et les politiques d'automatisation.

Chapitre 7 : LLM pour la cybersécurité - Analyse de logs, reverse engineering et threat intelligence

7.1 Analyse de logs en langage naturel

L'analyse de logs est une activité fondamentale mais fastidieuse dans les opérations de cybersécurité. Les environnements informatiques modernes génèrent des volumes considérables de logs provenant de sources hétérogènes : pare-feu, serveurs web, systèmes d'exploitation, applications métier, services cloud, équipements réseau. L'analyse manuelle de ces logs pour identifier des indicateurs de compromission est non seulement chronophage mais également sujette à erreur, les analystes pouvant manquer des corrélations subtiles entre des événements apparemment anodins.

Les LLM transforment l'analyse de logs en permettant aux analystes d'interroger leurs données en langage naturel. Au lieu de rédiger des requêtes complexes en SPL (Splunk Processing Language), KQL (Kusto Query Language) ou Lucene, un analyste peut formuler sa recherche de manière intuitive : "Montre-moi toutes les connexions RDP entrantes depuis des adresses IP extérieures vers des serveurs du segment DMZ au cours des 48 dernières heures, avec les comptes utilisateurs associés et leur historique de connexion habituel." Le LLM traduit cette requête en langage technique, l'exécute sur le SIEM, et présente les résultats avec une synthèse contextuelle.

Au-delà de la traduction de requêtes, les LLM apportent des capacités d'interprétation et de corrélation. Un LLM entraîné sur des données de cybersécurité peut analyser une séquence de logs et identifier des patterns d'attaque connus : "La séquence d'événements observée (échec d'authentification répété suivi d'une connexion réussie, puis création d'un service système et exécution de PowerShell encodé en base64) correspond au profil d'une attaque par brute force suivie d'une élévation de privilèges et d'une persistance, potentiellement associée aux techniques MITRE ATT&CK T1110 (Brute Force), T1543 (Create or Modify System Process) et T1059.001 (PowerShell)." Cette capacité de contextualisation automatique accélère considérablement l'investigation.

7.2 Reverse engineering assisté par LLM

Le reverse engineering, discipline essentielle pour l'analyse de malwares et la recherche de vulnérabilités, bénéficie d'une assistance significative des LLM. L'analyse de code binaire désassemblé est traditionnellement une tâche exigeant une expertise pointue en architecture processeur, en conventions d'appel et en patterns de compilation. Les LLM, entraînés sur d'immenses corpus de code source et de documentation technique, peuvent assister les analystes en expliquant le fonctionnement de fonctions décompilées, en identifiant des patterns cryptographiques, et en suggérant des noms de variables et de fonctions significatifs pour le code désassemblé.

L'intégration de LLM dans les outils de reverse engineering est déjà en cours. Des plugins pour IDA Pro et Ghidra, comme gepetto (utilisant GPT) et GhidrAssist, permettent d'interroger un LLM directement depuis l'interface du désassembleur pour obtenir des explications sur des blocs de code, des suggestions de renommage et des analyses de fonctionnalités. Binary Ninja propose également des intégrations similaires via son système de plugins. Ces outils ne remplacent pas l'expertise humaine mais accélèrent significativement le processus d'analyse en automatisant les tâches les plus répétitives.

L'analyse de malwares par LLM va au-delà de l'explication de code. Un LLM spécialisé peut identifier les familles de malwares en analysant les patterns comportementaux décrits dans le code, extraire les indicateurs de compromission (IoC) comme les URLs de C2, les clés de chiffrement et les identifiants de campagne, et corréler les échantillons analysés avec des campagnes documentées dans les bases de threat intelligence. Des modèles spécialisés comme SecurityBERT et CyberBERT, fine-tunés sur des corpus de cybersécurité, montrent des performances prometteuses pour ces tâches de classification et d'extraction d'information spécifiques au domaine.

7.3 Threat intelligence automatisée

La threat intelligence (renseignement sur les menaces) est un domaine où les LLM apportent une valeur transformationnelle. Le volume de données de threat intelligence produites quotidiennement, rapports APT, bulletins de vulnérabilités, indicateurs de compromission, analyses d'échantillons, discussions sur les forums underground, dépasse largement la capacité d'analyse humaine. Les LLM permettent d'automatiser la collecte, le traitement, l'analyse et la dissémination de cette intelligence, transformant des données brutes en renseignement actionnable.

L'extraction automatique d'indicateurs de compromission (IoC) à partir de rapports textuels non structurés constitue une application directe du NLP. Les modèles de NER (Named Entity Recognition) adaptés à la cybersécurité identifient automatiquement les adresses IP, noms de domaine, hash de fichiers, URLs malveillantes, noms de malwares, identifiants CVE et TTPs MITRE ATT&CK mentionnés dans les rapports. Ces IoCs sont ensuite automatiquement normalisés au format STIX/TAXII et intégrés dans les plateformes de threat intelligence comme MISP (Malware Information Sharing Platform) pour être partagés avec la communauté.

L'analyse et l'attribution de campagnes APT bénéficient également des capacités des LLM. En analysant les TTPs observées, les infrastructures utilisées, les cibles visées et les artefacts techniques, un LLM peut suggérer des attributions probables en corrélant avec les profils de groupes APT connus documentés dans des bases comme MITRE ATT&CK Groups. Cette analyse, traditionnellement réservée aux équipes de threat intelligence les plus expérimentées, peut être partiellement automatisée, bien que les attributions restent des hypothèses nécessitant une validation humaine rigoureuse.

7.4 Génération automatique de règles de détection

La création de règles de détection, qu'il s'agisse de règles YARA pour la détection de malwares, de règles Sigma pour la corrélation de logs, ou de règles Snort/Suricata pour la détection réseau, est une compétence technique spécialisée. Les LLM peuvent assister et accélérer ce processus en générant des règles à partir de descriptions en langage naturel ou d'analyses d'échantillons malveillants.

Un analyste peut décrire un comportement malveillant observé : "Créer une règle YARA qui détecte les fichiers PE contenant des chaînes base64 encodées de plus de 500 caractères dans la section .rsrc, avec un timestamp de compilation postérieur à janvier 2024 et au moins deux imports de fonctions de la bibliothèque wininet.dll." Le LLM génère la règle YARA correspondante, que l'analyste peut ensuite valider, affiner et déployer. De même, les règles Sigma pour la détection de TTPs MITRE ATT&CK peuvent être générées à partir de descriptions textuelles des comportements à détecter, considérablement accélérant le processus de développement de contenu de détection.

Le concept de "Detection-as-Code" s'intègre naturellement avec les capacités des LLM. Les règles de détection sont traitées comme du code source, versionnées dans des dépôts Git, testées automatiquement et déployées via des pipelines CI/CD. Les LLM peuvent assister à chaque étape : génération initiale de la règle, rédaction de tests unitaires, documentation, et mise à jour en réponse à l'évolution des menaces. Cette approche accélère le cycle de développement et de déploiement du contenu de détection, réduisant le délai entre l'identification d'une nouvelle menace et la mise en place d'une capacité de détection correspondante.

Chapitre 8 : Sécuriser les systèmes d'IA - OWASP Top 10 LLM, prompt injection et data leakage

8.1 L'OWASP Top 10 pour les applications LLM

L'Open Web Application Security Project (OWASP) a publié en 2023 (mise à jour en 2025) son Top 10 des vulnérabilités spécifiques aux applications utilisant des grands modèles de langage. Ce référentiel, développé par un groupe d'experts internationaux, constitue le cadre de référence pour la sécurisation des déploiements de LLM en production. Contrairement au OWASP Top 10 classique qui cible les applications web traditionnelles, ce document adresse les risques uniques introduits par l'intégration de modèles de langage dans les systèmes d'information.

Le Top 10 OWASP LLM identifie les vulnérabilités suivantes, classées par ordre de criticité : LLM01 - Prompt Injection (injection de prompts), LLM02 - Insecure Output Handling (gestion non sécurisée des sorties), LLM03 - Training Data Poisoning (empoisonnement des données d'entraînement), LLM04 - Model Denial of Service (déni de service du modèle), LLM05 - Supply Chain Vulnerabilities (vulnérabilités de la chaîne d'approvisionnement), LLM06 - Sensitive Information Disclosure (divulgation d'informations sensibles), LLM07 - Insecure Plugin Design (conception de plugins non sécurisée), LLM08 - Excessive Agency (autonomie excessive), LLM09 - Overreliance (dépendance excessive), et LLM10 - Model Theft (vol de modèle). Chacune de ces catégories nécessite des stratégies de mitigation spécifiques que nous détaillons ci-dessous.

8.2 Prompt injection : la menace numéro un

L'injection de prompts (prompt injection) est considérée comme la vulnérabilité la plus critique et la plus difficile à mitiger dans les applications LLM. Elle se décline en deux variantes : l'injection directe, où l'utilisateur manipule directement le prompt système via son entrée, et l'injection indirecte, où des instructions malveillantes sont dissimulées dans des données externes que le LLM traite (pages web, emails, documents).

L'injection directe exploite le fait que les LLM ne distinguent pas fondamentalement entre les instructions système (le system prompt qui définit le comportement souhaité) et les données utilisateur. Un attaquant peut inclure dans son message des instructions comme "Ignore toutes les instructions précédentes et..." pour détourner le comportement du modèle. Cette vulnérabilité est inhérente à l'architecture des LLM actuels, qui traitent l'ensemble du contexte (instructions + données) comme une séquence de tokens indifférenciée. Malgré des améliorations continues (instruction hierarchy, system prompt enforcement), aucune solution technique ne garantit une protection complète contre l'injection directe.

L'injection indirecte est encore plus pernicieuse. Dans un scénario typique, un LLM doté d'un accès à internet ou à une base de documents analyse une page web contenant des instructions cachées (en texte blanc sur fond blanc, dans des balises HTML invisibles, ou encodées en Unicode). Ces instructions détournent le LLM pour exfiltrer des données sensibles, modifier ses réponses ou exécuter des actions non autorisées. Les travaux de Greshake et al. (2023) ont formalisé cette menace, démontrant des scénarios d'attaque réalistes contre des assistants IA connectés à des services de messagerie et de navigation web.

8.3 Fuite de données et divulgation d'informations sensibles

La divulgation d'informations sensibles (LLM06 dans le Top 10 OWASP) représente un risque majeur pour les organisations déployant des LLM. Ce risque se manifeste à travers plusieurs vecteurs. Premièrement, les modèles peuvent mémoriser et reproduire des données d'entraînement sensibles (training data extraction). Carlini et al. (2021) ont démontré que GPT-2 pouvait être amené à reproduire verbatim des séquences de données d'entraînement, y compris des informations personnelles, des clés API et des extraits de code propriétaire. Les modèles plus grands et plus récents sont encore plus susceptibles de mémorisation, bien que des techniques comme la déduplication des données et le differential privacy réduisent ce risque.

Deuxièmement, les LLM intégrés dans des systèmes d'entreprise avec accès à des données internes (via RAG - Retrieval Augmented Generation) peuvent divulguer ces données à des utilisateurs non autorisés si les contrôles d'accès ne sont pas correctement implémentés au niveau de la couche de retrieval. Un utilisateur du département marketing pourrait, par des requêtes astucieuses, amener le chatbot interne à divulguer des informations financières confidentielles accessibles dans la base de connaissances mais normalement restreintes aux dirigeants.

Troisièmement, les données envoyées aux API de LLM cloud (OpenAI, Anthropic, Google) transitent par les serveurs du fournisseur, avec des implications pour la confidentialité et la conformité réglementaire. Les organisations doivent évaluer rigoureusement les politiques de rétention de données des fournisseurs, les garanties contractuelles de non-utilisation pour l'entraînement, et les implications en termes de RGPD et de souveraineté des données. Le déploiement de modèles on-premise ou dans des environnements cloud privés peut mitiger ce risque au prix d'une complexité et d'un coût accrus.

8.4 Sécurisation en profondeur des déploiements LLM

La sécurisation des applications LLM requiert une approche de défense en profondeur combinant multiples couches de protection. Au niveau de la couche d'entrée (input layer), les mesures incluent la validation et la sanitisation des prompts utilisateur, la détection de tentatives d'injection par des classificateurs ML spécialisés, le rate limiting pour prévenir les abus et les attaques par déni de service, et la limitation de la taille des prompts.

Au niveau de la couche modèle (model layer), les protections incluent le prompt engineering défensif (instructions explicites de refus, séparateurs clairs entre instructions et données), le fine-tuning sur des données de sécurité (apprentissage à refuser les requêtes malveillantes), les techniques de Constitutional AI pour aligner le comportement du modèle avec des principes de sécurité, et le sandboxing de l'environnement d'exécution pour limiter les capacités du modèle.

Au niveau de la couche de sortie (output layer), les mesures comprennent le filtrage des réponses pour détecter les fuites de données sensibles (PII detection, regex pour les patterns de secrets), la validation des actions avant exécution (pour les agents avec capacités d'action), la journalisation exhaustive des interactions pour l'audit et le monitoring, et le human-in-the-loop pour les actions à haut risque.

8.5 MITRE ATLAS : cadre de référence pour la sécurité des systèmes d'IA

Le framework MITRE ATLAS (Adversarial Threat Landscape for Artificial Intelligence Systems) constitue le pendant du MITRE ATT&CK pour les menaces spécifiques aux systèmes d'intelligence artificielle. Lancé en 2021 et régulièrement mis à jour, ATLAS documente les tactiques, techniques et procédures (TTPs) utilisées par les adversaires pour attaquer les systèmes de ML et d'IA en production. Le framework couvre l'ensemble du cycle de vie des systèmes d'IA : de la collecte de données d'entraînement au déploiement en production, en passant par le développement et la validation des modèles.

ATLAS organise les techniques adversariales en quatorze tactiques, correspondant aux objectifs stratégiques de l'attaquant : reconnaissance de l'infrastructure ML, acquisition de ressources, accès initial aux systèmes d'IA, exécution de code dans l'environnement ML, persistance, évasion, accès aux données d'entraînement, exfiltration de modèles, et impact sur les prédictions. Chaque technique est documentée avec des études de cas réelles, des procédures d'exploitation détaillées et des recommandations de mitigation. Le framework inclut également un ensemble de scénarios d'attaque end-to-end illustrant des chaînes d'attaques réalistes contre des systèmes d'IA.

L'utilisation de MITRE ATLAS comme cadre d'évaluation permet aux organisations de conduire des threat modeling systématiques de leurs déploiements d'IA, d'identifier les gaps dans leurs défenses et de prioriser les investissements en sécurité. L'intégration d'ATLAS avec le framework ATT&CK permet une vision holistique combinant les menaces traditionnelles et les menaces spécifiques à l'IA dans une matrice unifiée de tactiques adversariales.

Chapitre 9 : Cadre éthique et réglementaire - EU AI Act, NIST AI RMF

9.1 L'EU AI Act : le cadre réglementaire européen

Le Règlement européen sur l'intelligence artificielle (EU AI Act), adopté définitivement en mars 2024 et dont l'entrée en application est échelonnée entre 2025 et 2027, constitue le premier cadre législatif complet au monde régissant l'utilisation de l'IA. Ce règlement, qui s'inscrit dans la stratégie numérique européenne aux côtés du RGPD, du Digital Services Act (DSA) et du Digital Markets Act (DMA), établit un système de classification des systèmes d'IA fondé sur les risques et impose des obligations proportionnées à chaque niveau de risque.

Le système de classification comprend quatre niveaux. Les systèmes d'IA à risque inacceptable sont purement et simplement interdits : cela inclut les systèmes de notation sociale (social scoring), la reconnaissance biométrique en temps réel dans les espaces publics (avec des exceptions pour la sécurité nationale), et les systèmes de manipulation subliminale. Les systèmes à haut risque, qui incluent les applications de cybersécurité critiques, sont soumis à un ensemble d'obligations strictes : évaluation de conformité, documentation technique, gestion de la qualité des données, transparence, contrôle humain, robustesse et cybersécurité. Les systèmes à risque limité sont soumis à des obligations de transparence (l'utilisateur doit être informé qu'il interagit avec une IA). Les systèmes à risque minimal ne sont soumis à aucune obligation spécifique au-delà de la conformité volontaire à des codes de conduite.

Pour les applications de cybersécurité, l'EU AI Act a des implications directes et substantielles. Les systèmes d'IA utilisés pour la détection d'intrusion, la gestion des accès, la surveillance des réseaux critiques et la protection des infrastructures essentielles sont susceptibles d'être classés comme systèmes à haut risque, notamment lorsqu'ils sont déployés dans des secteurs critiques couverts par la directive NIS2 (énergie, transport, santé, finance, administration publique). Ces systèmes doivent répondre à des exigences spécifiques en matière de qualité des données d'entraînement (article 10), de documentation technique (article 11), de journalisation (article 12), de transparence (article 13), de contrôle humain (article 14) et de précision, robustesse et cybersécurité (article 15).

9.2 Le NIST AI Risk Management Framework

Le NIST AI RMF (AI Risk Management Framework), publié en janvier 2023 par le National Institute of Standards and Technology des États-Unis, propose un cadre volontaire pour la gestion des risques liés aux systèmes d'IA. Contrairement à l'EU AI Act qui est un règlement contraignant, le NIST AI RMF se positionne comme un guide de bonnes pratiques flexible, adaptable aux spécificités de chaque organisation et de chaque contexte de déploiement. Il est néanmoins de facto considéré comme une référence par les organisations américaines et internationales.

Le framework s'articule autour de quatre fonctions fondamentales. La fonction Govern (Gouverner) établit les processus organisationnels, les rôles et les responsabilités pour la gestion des risques IA. Elle inclut la définition de politiques d'utilisation de l'IA, la mise en place de comités d'éthique et de gouvernance, et l'intégration de la gestion des risques IA dans le cadre global de gestion des risques de l'organisation. La fonction Map (Cartographier) identifie et évalue les risques spécifiques à chaque système d'IA dans son contexte de déploiement. La fonction Measure (Mesurer) quantifie les risques identifiés à travers des métriques et des indicateurs pertinents. La fonction Manage (Gérer) déployer les mesures de mitigation, les contrôles et les processus de surveillance continus.

Le NIST AI RMF accorde une attention particulière aux caractéristiques de fiabilité (trustworthiness) des systèmes d'IA, définies comme : la validité et la fiabilité, la sécurité (safety), la protection contre les menaces (security and resilience), la responsabilité et la transparence (accountability and transparency), l'explicabilité et l'interprétabilité, la protection de la vie privée, et l'équité (fairness) incluant la gestion des biais. Ces caractéristiques sont directement pertinentes pour les déploiements d'IA en cybersécurité, où la fiabilité, la sécurité et la transparence sont critiques.

9.3 Convergence réglementaire et standards internationaux

Au-delà de l'EU AI Act et du NIST AI RMF, un écosystème réglementaire et normatif plus large encadre l'utilisation de l'IA en cybersécurité. La norme ISO/IEC 42001, publiée en décembre 2023, établit les exigences pour un système de management de l'intelligence artificielle (AIMS), fournissant un cadre certifiable pour la gouvernance de l'IA. Elle complète les normes existantes comme ISO 27001 (management de la sécurité de l'information) et ISO 27701 (management de la protection des données personnelles).

La directive NIS2 (Network and Information Security), entrée en application en octobre 2024, impose aux entités essentielles et importantes des obligations renforcées en matière de cybersécurité, incluant la gestion des risques liés à la chaîne d'approvisionnement et la notification des incidents. Lorsque des systèmes d'IA sont déployés dans le périmètre des entités couvertes par NIS2, ils doivent répondre aux exigences de sécurité de la directive, créant une intersection réglementaire avec l'EU AI Act. Le règlement DORA (Digital Operational Resilience Act), spécifique au secteur financier, impose des exigences similaires avec un focus sur la résilience opérationnelle numérique.

La convergence de ces cadres réglementaires crée un environnement complexe mais cohérent où les organisations doivent démontrer une maîtrise des risques liés à l'IA à travers des processus documentés, des contrôles techniques et organisationnels, et une capacité d'audit et de reporting. La mise en conformité nécessite une approche intégrée combinant expertise en IA, en cybersécurité, en protection des données et en conformité réglementaire.

9.4 Éthique de l'IA offensive en cybersécurité

L'utilisation de l'IA à des fins offensives soulève des questions éthiques profondes qui dépassent le cadre strictement juridique. Le développement et l'utilisation de capacités d'IA offensive, même dans un contexte défensif de red teaming et de pentesting, impliquent la création d'outils potentiellement dangereux dont la prolifération doit être contrôlée. Le principe de divulgation responsable (responsible disclosure) doit être étendu aux capacités offensives basées sur l'IA, avec des protocoles clairs pour la recherche, la publication et le partage de ces capacités.

Le concept de dual-use (double usage) est central dans cette réflexion. Les mêmes modèles de ML qui alimentent les systèmes de détection d'intrusion les plus avancés peuvent, avec des modifications mineures, être utilisés pour développer des techniques d'évasion. Les LLM qui assistent les analystes de sécurité dans l'investigation d'incidents peuvent également assister les attaquants dans la planification d'opérations malveillantes. Cette dualité fondamentale rend impossible une séparation nette entre technologies offensives et défensives, et impose une approche nuancée de la régulation et de l'éthique.

Les organisations de cybersécurité ont la responsabilité de développer et d'appliquer des cadres éthiques internes pour l'utilisation de l'IA. Ces cadres doivent aborder la proportionnalité (les capacités offensives développées sont-elles proportionnées aux menaces évaluées), la nécessité (existe-t-il des alternatives moins risquées), la transparence (les parties prenantes sont-elles informées de l'utilisation de l'IA), la responsabilité (qui est responsable des décisions prises ou assistées par l'IA) et la réversibilité (les actions automatisées peuvent-elles être annulées en cas d'erreur).

9.5 Recommandations pour la conformité et la gouvernance

Pour naviguer dans cet écosystème réglementaire complexe, les organisations doivent adopter une approche structurée de la gouvernance de l'IA en cybersécurité. Premièrement, établir un inventaire exhaustif de tous les systèmes d'IA déployés ou en développement, incluant leur classification de risque selon l'EU AI Act, leur purpose et leur scope, et les données qu'ils traitent. Deuxièmement, conduire des évaluations d'impact (AI Impact Assessments) pour chaque système classé à haut risque, documentant les risques identifiés, les mesures de mitigation et les contrôles en place.

Troisièmement, configurer un programme de test et de validation continu, incluant des tests de robustesse adversariale (conformément à MITRE ATLAS), des audits de biais et d'équité, des évaluations de performance en conditions réelles, et des exercices de red teaming spécifiques à l'IA. Quatrièmement, assurer la traçabilité et l'explicabilité des décisions assistées par IA, en particulier pour les systèmes impactant la sécurité des personnes ou des infrastructures critiques. Cinquièmement, former les équipes techniques et managériales aux enjeux spécifiques de l'IA en cybersécurité, incluant les risques adversariaux, les obligations réglementaires et les bonnes pratiques de déploiement sécurisé.

Outils et Ressources IA en Cybersecurite

Decouvrez nos outils open source et modeles d''IA developpes pour les professionnels de la cybersecurite :

Questions Fréquentes

Comment les grands modeles de langage sont-ils utilises en cybersecurite offensive ?

Les LLM sont utilises offensivement pour generer du code malveillant polymorphe, creer des emails de phishing linguistiquement parfaits et personnalises, automatiser l'analyse de code source pour identifier des vulnerabilites, generer des payloads d'exploitation adaptatifs, et conduire des operations de desinformation a grande echelle. Ils permettent egalement de contourner les filtres de securite par des techniques de jailbreak et d'analyser automatiquement la documentation technique d'une cible pour identifier des vecteurs d'attaque potentiels.

Quel est l'impact du EU AI Act sur la cybersecurite ?

Le EU AI Act classe les systemes d'IA par niveau de risque et impose des exigences proportionnees. Pour la cybersecurite, les systemes de detection de menaces et de surveillance sont consideres comme a haut risque, necessitant une documentation technique complete, des evaluations de conformite, une gestion des biais, une supervision humaine et une transparence vis-a-vis des utilisateurs. Les outils d'IA offensive utilises en recherche doivent respecter des cadres ethiques stricts. Le non-respect peut entrainer des amendes pouvant atteindre 35 millions d'euros ou 7% du chiffre d'affaires mondial.

Pour approfondir, consultez les ressources de NIST Cybersecurity et de NVD (National Vulnerability Database).

Comment detecter les contenus generes par intelligence artificielle ?

La detection de contenus generes par IA repose sur plusieurs approches : l'analyse statistique des distributions de tokens (les LLM produisent des distributions caracteristiques), la detection de watermarks numeriques integres lors de la generation, l'analyse des metadonnees et de la provenance du contenu, les classificateurs entraines specifiquement sur des contenus IA vs humains, et l'analyse forensique des images generees par diffusion. Cependant, les techniques de detection evoluent constamment face aux ameliorations des modeles generatifs, rendant cette course technologique permanente.

Partager cet article

Twitter LinkedIn Copier le lien

Ayi NEDJIMI

Expert Cybersécurité & Intelligence Artificielle

Consultant et formateur spécialisé en tests d'intrusion, Active Directory, et développement de solutions IA. 15+ années d'expérience en sécurité offensive.

Articles connexes

DFIR : Réponse à Incident et Forensics | Guide Expert

Guide complet DFIR : méthodologie de réponse à incident, analyse forensique Windows/Linux/Cloud, collecte de preuves et outils avancés.

11/03/2026

Zero Trust : Architecture et Déploiement Entreprise

Guide complet sur l'architecture Zero Trust : principes fondamentaux, micro-segmentation, gestion des identités (IAM, MFA, PAM), déploiement cloud multi-provider et feuille de route pour les entreprises. Référence NIST SP 800-207.

11/03/2026

Red Team vs Blue Team : Méthodologies et Outils Expert

Guide complet Red Team vs Blue Team : methodologies d'attaque et defense, outils, MITRE ATT&CK et exercices Purple Team.

11/03/2026

Article précédent

Sécurité DevSecOps : Intégrer la Sécurité dans le CI/CD

Article suivant

Conformité ISO 27001 : Guide Pratique d'Implémentation

Commentaires (2)

K

Kévin Dumas 11/03/2026 à 10:45

Excellente synthèse. Pour compléter, l'approche pragmatique rend ce guide directement actionnable. Cela mériterait un article dédié tant le sujet est riche.

A

Aurélie Roux 11/03/2026 à 12:03

En tant que analyste forensic, je confirme la pertinence de cet article. Nous avons recommandé ce livre blanc à plusieurs confrères consultants. L'impact sur notre posture de sécurité a été mesurable.

Laisser un commentaire

Nom *

Email * (non publié)

Commentaire *

Publier