Une entreprise industrielle a déployé un produit de surveillance de la sécurité réseau reposant sur l’IA, fourni par un fournisseur spécialisé : un système utilisant l’apprentissage automatique pour détecter le trafic réseau anormal et générer des alertes de sécurité à examiner par des analystes. L’indicateur phare du fournisseur était un taux de détection de 94% sur son jeu de données de test. L’entreprise avait mené une preuve de concept qui avait détecté plusieurs scénarios d’attaque simulés et avait été satisfaite des performances du produit. Après le déploiement en production, le système a généré dix-sept alertes en quatorze jours. Trois correspondaient à de véritables incidents de sécurité : un serveur mal configuré, un poste de travail compromis et une tentative de mouvement latéral. Quatorze étaient des faux positifs. L’examen des dix-sept alertes a mobilisé soixante-deux heures d’analyste. Les trois incidents réels étaient exactement du type que le jeu de données d’entraînement et de test du fournisseur avait privilégié. Ce que le modèle n’avait pas signalé, c’étaient vingt-trois anomalies qu’un analyste expérimenté a remarquées deux semaines plus tard en examinant un rapport de synthèse du trafic : exécution à distance via WMI depuis des sources inhabituelles, abus d’outils d’administration légitimes et schémas de reconnaissance lente et discrète, chacun dans les limites normales mais révélant ensemble un attaquant installé de longue date utilisant des techniques living-off-the-land. Ces techniques ne figuraient pas dans le jeu de données d’entraînement. Le seuil de confiance du modèle ne les avait pas signalées. Le tableau de bord a affiché un taux de détection de 94% tout du long. Les vingt-trois anomalies manquées étaient invisibles dans tous les indicateurs publiés.
Que sont les vulnérabilités des plugins de sécurité d’IA, au fond ?
Dans le contexte des outils de sécurité reposant sur l’IA, les vulnérabilités des plugins d’IA sont les angles morts structurels et les limites opérationnelles des systèmes de détection fondés sur l’apprentissage automatique : non pas des défauts de mise en œuvre de la technologie, mais des contraintes inhérentes au fonctionnement de l’apprentissage automatique supervisé, qui créent des écarts systématiques entre les indicateurs de détection publiés et la couverture de sécurité réelle. Ces écarts existent parce que les modèles de ML sont performants sur des entrées semblables à leurs données d’entraînement et peu performants sur des entrées qui en sortent, parce que les adversaires s’adaptent spécifiquement pour éviter les schémas de détection, et parce que les taux de faux positifs imposent des coûts opérationnels qui réduisent la capacité d’analyse disponible pour compenser les limites de l’IA.
La lacune de la distribution d’entraînement est la limite fondamentale. Tout produit de sécurité fondé sur le ML est entraîné sur un jeu d’exemples étiquetés : des schémas d’attaque classés comme malveillants, une activité bénigne classée comme normale. Le modèle apprend à détecter des schémas semblables à ceux de son entraînement et peine face à des schémas différents. Le taux de détection de 94% obtenu sur le jeu de données de test du fournisseur mesure la performance sur des données de test tirées de la même distribution que les données d’entraînement. Il ne mesure pas la performance face à des techniques réellement nouvelles, sous-représentées dans l’entraînement ou spécifiquement conçues pour éviter la logique de détection apprise par le modèle. L’indicateur phare et la lacune de couverture réelle sont tous deux réels : ils ne mesurent simplement pas la même chose.
L’angle mort des techniques living-off-the-land est une lacune précise et bien documentée de la distribution d’entraînement des produits d’IA de sécurité réseau. Les attaques living-off-the-land utilisent des outils d’administration légitimes (WMI, PowerShell, PsExec, certutil, Mshta) pour mener des opérations malveillantes d’une manière statistiquement semblable à une activité d’administration légitime. Un modèle entraîné à détecter des schémas réseau malveillants par leur différence statistique avec des schémas bénins aura du mal face aux techniques LOTL, précisément parce que chaque signal pris isolément reste dans la plage de l’activité légitime. La détection LOTL exige de corréler dans le temps plusieurs signaux qui, pris isolément, restent dans cette plage, une tâche difficile pour des modèles entraînés à classer des événements individuels.
Le mécanisme d’adaptation adverse amplifie la lacune d’entraînement au fil du temps. Les acteurs malveillants sophistiqués étudient les outils de détection déployés par leurs cibles et adaptent leurs techniques pour les éviter. Un modèle réputé détecter certains schémas réseau parce que son fournisseur a publié sa logique de détection sera contourné par des attaquants qui utilisent d’autres schémas. Les données d’entraînement, à jour au moment du développement du modèle, deviennent de moins en moins représentatives des techniques réellement employées par les adversaires sophistiqués. L’indicateur de taux de détection, mesuré sur le jeu de données de test d’origine, reste stable alors que l’efficacité réelle du modèle face aux techniques actuelles des adversaires diminue.
Le problème du coût des faux positifs est la conséquence opérationnelle qui aggrave la lacune de détection. Les produits de sécurité par IA qui génèrent d’importants volumes d’alertes faussement positives imposent une charge d’investigation aux équipes d’analystes : chaque alerte faussement positive exige du temps d’analyste pour être examinée et clôturée. Ce temps est pris sur la capacité des analystes qui servirait autrement à la chasse manuelle aux menaces, à l’examen du trafic et à l’analyse humaine qui compense les angles morts de l’IA. Un modèle qui génère quatorze faux positifs pour dix-sept alertes consomme cinquante-six heures d’analyste à examiner du bruit, précisément les heures qui auraient pu permettre de détecter les vingt-trois anomalies que le modèle a manquées.
Pourquoi c’est important
Les vulnérabilités des plugins de sécurité d’IA sont importantes pour la TPRM car la surveillance de sécurité fondée sur l’IA est de plus en plus présentée comme la couche de détection principale, remplaçant ou réduisant fortement l’examen par des analystes humains. Lorsque les fournisseurs déploient des produits de sécurité par IA comme capacité de détection principale, les lacunes de couverture de ces produits deviennent l’exposition de l’entreprise. Un fournisseur dont le produit de sécurité par IA affiche un taux de détection de 94% mais reste systématiquement aveugle aux techniques living-off-the-land présente une lacune de détection importante pour la catégorie d’attaques que privilégient précisément les adversaires sophistiqués de la chaîne d’approvisionnement.
Le risque de substitution est la préoccupation propre à la chaîne d’approvisionnement. Si le produit de sécurité par IA du fournisseur remplace la capacité des analystes au lieu de la compléter, c’est-à-dire si l’équipe d’analystes qui examinait auparavant le trafic manuellement a été réduite parce que l’IA se charge de la détection, l’effet net du déploiement de l’IA peut être une baisse de la couverture de sécurité pour les catégories de techniques que l’IA détecte mal. L’IA n’a pas accru la couverture. Elle l’a déplacée vers les techniques qu’elle détecte bien, au détriment de celles qu’elle détecte mal.
Là où la plupart des équipes se trompent
L’échec le plus constant consiste à accepter l’indicateur phare du taux de détection sans évaluer l’éventail de techniques du test qui l’a produit. L’indicateur est exact pour ce périmètre. C’est le périmètre qui détermine si l’indicateur a un sens au regard du paysage de menaces auquel le fournisseur est réellement confronté.
- Taux de détection accepté sans évaluation du périmètre du jeu de données de test
- Taux de faux positifs non évalué en tant que coût opérationnel : heures d’analyste nécessaires
- Couverture des techniques living-off-the-land non évaluée spécifiquement
- Tests de contournement adverse non menés : l’IA détecte-t-elle les attaques conçues pour lui échapper ?
- Complément d’analystes humains non défini pour les lacunes de couverture de l’IA
À quoi ressemblent les bonnes pratiques
Les évaluations matures des produits de sécurité par IA examinent trois catégories de détection en plus des taux de faux positifs : les schémas d’attaque connus issus de la distribution d’entraînement, les techniques nouvelles extérieures à cette distribution et les tentatives de contournement conçues de manière adverse, afin d’établir la couverture réelle au-delà de l’indicateur affiché.
- Évaluation en trois catégories : techniques connues, nouvelles et de contournement conçues de manière adverse
- Couverture des techniques LOTL explicitement évaluée : détection de l’abus de WMI, de PowerShell et des outils d’administration
- Taux de faux positifs en tant que coût opérationnel : heures d’analyste par mois au volume d’alertes de production
- Complément d’analystes humains précisé : quelle analyse manuelle compense les lacunes de l’IA
- Red team de contournement adverse : exercice de red team avec un objectif explicite de contournement de l’IA
Outils
Évaluation de la sécurité de l’IA : MITRE ATLAS pour le ML adverse, Atomic Red Team pour la validation de la détection des techniques LOTL
MITRE ATLAS fournit un cadre d’évaluation des menaces d’apprentissage automatique adverse, y compris des techniques spécifiquement conçues pour échapper à la détection par l’IA. Atomic Red Team fournit des implémentations de test des techniques ATT&CK, y compris des schémas LOTL, qui permettent de valider si un produit de sécurité les détecte. Pour les praticiens de la TPRM, demander si le produit de sécurité par IA du fournisseur a été évalué face aux techniques MITRE ATT&CK LOTL à l’aide des tests Atomic Red Team constitue une question précise sur la couverture en conditions réelles.
Sécurité réseau : Darktrace, Vectra, ExtraHop avec couverture explicite des techniques LOTL et des anomalies comportementales
Les produits d’IA de sécurité réseau diffèrent sensiblement dans leur couverture des techniques living-off-the-land et de reconnaissance lente et discrète. Les produits axés sur des références comportementales et sur la détection d’anomalies par corrélation de plusieurs signaux sont mieux adaptés à la détection LOTL que les produits optimisés pour la classification à fort volume de schémas connus. Pour les praticiens de la TPRM, demander comment le produit d’IA de sécurité réseau du fournisseur détecte spécifiquement les techniques LOTL, et demander une démonstration à l’aide des cas de test LOTL d’Atomic Red Team, constitue une évaluation concrète de la couverture.
Enjeux de gouvernance
Le défi de gouvernance posé par les limites des produits de sécurité par IA est le problème de la confiance accordée aux indicateurs. Des taux de détection élevés créent une confiance dans la couverture de l’IA qui peut ne pas être justifiée pour les techniques précises qui préoccupent le plus l’entreprise. La solution de gouvernance est une évaluation de la couverture technique par technique, qui examine la couverture du produit pour les schémas d’attaque précis pertinents au regard du modèle de menaces de l’entreprise, et pas seulement l’indicateur agrégé.
- Évaluer la couverture technique par technique au regard du modèle de menaces de l’entreprise
- Évaluer explicitement la capacité de détection LOTL : il s’agit d’une TTP courante des attaquants sophistiqués
- Calculer le coût opérationnel des faux positifs : heures d’analyste aux volumes de production
- Définir le complément d’analystes humains : ce que l’IA ne peut pas couvrir, l’analyse humaine doit le couvrir
- Mener une évaluation du contournement adverse : cadre MITRE ATLAS
Si vous êtes une petite équipe
Pour toute évaluation d’un produit de sécurité par IA, posez deux questions auxquelles la démonstration du fournisseur ne répondra pas. Premièrement : l’éventail des techniques couvertes par votre jeu de données de test est-il public, et inclut-il spécifiquement des schémas living-off-the-land et des techniques de contournement conçues de manière adverse ? Deuxièmement : pour une entreprise de notre taille et de la complexité de notre réseau, quel est le taux de faux positifs attendu par mois, et combien d’heures d’analyste cela implique-t-il ? La première révèle la lacune de couverture. La seconde révèle le coût opérationnel. Ensemble, elles décrivent la couverture de sécurité réelle qu’offre le produit.
- Demander si le jeu de données de test inclut les techniques LOTL et de contournement adverse
- Demander le taux de faux positifs en production et le nombre d’heures d’analyste qu’il implique à votre échelle
- Mener un test LOTL avec Atomic Red Team pendant la preuve de concept
- Définir le complément d’analystes humains pour les lacunes de couverture identifiées
Ce qu’il faut exiger
Demandez directement :
« Le jeu de données de test de votre produit de sécurité par IA inclut-il spécifiquement des techniques living-off-the-land et des schémas de contournement conçus de manière adverse ? Et pour une entreprise de notre taille, quels sont le volume mensuel de faux positifs et le nombre d’heures d’analyste attendus ? »
Preuves attendues
- Éventail des techniques couvertes par le jeu de données de test
- Confirmation de la couverture des techniques LOTL et du contournement adverse
- Taux de faux positifs en production dans des entreprises comparables
- Recommandations sur le complément d’analystes humains
Un fournisseur qui confirme un taux de détection de 94% doit être invité à préciser l’éventail de techniques ayant produit ce chiffre. L’indicateur est exact pour ce périmètre. C’est le périmètre qui détermine ce que l’indicateur signifie pour la couverture en conditions réelles.
Comment le prouver
- Dossiers d’évaluation du périmètre du jeu de données de test
- Évaluation de la couverture des techniques LOTL
- Évaluation du taux de faux positifs et du coût en analystes
- Documentation du complément d’analystes humains
À retenir
Taux de détection de 94%. Dix-sept alertes. Trois réelles. Quatorze faux positifs. Cinquante-six heures d’analyste. Vingt-trois anomalies LOTL manquées. Non signalées. Absentes du tableau de bord. Le taux de détection était réel pour la distribution d’entraînement. Les anomalies manquées étaient réelles pour les techniques qui en sortaient. L’examen des faux positifs a consommé précisément les heures d’analyste que l’examen manuel du trafic aurait consacrées à trouver les vingt-trois anomalies manquées. Les produits de sécurité par IA ne suppriment pas le besoin de jugement des analystes humains : ils le réorientent. Testez l’éventail de techniques. Calculez le coût des faux positifs. Définissez le complément humain. L’indicateur de 94% décrit la couverture de l’IA pour ce qu’elle a été entraînée à détecter. L’évaluation en trois catégories décrit sa couverture pour ce que l’adversaire utilise réellement.