Pourquoi le ML échoue à détecter les menaces

Pourquoi le ML échoue à détecter les menaces

L’apprentissage automatique (machine learning, ML) peut repérer des signaux trop diffus pour une règle de détection, à condition de le traiter comme un composant de triage et non comme un oracle. Le compromis central est brutal : gagner de la couverture sur des comportements inconnus impose de perdre en explicabilité, en stabilité et en maîtrise du taux de faux positifs.

Explication de la marmotte

Le système ressemble à un vigile qui apprend les habitudes d’un bâtiment en regardant passer les gens. Il peut remarquer un comportement étrange que le règlement n’avait pas prévu, mais il risque aussi de suspecter le livreur régulier le jour où celui-ci change simplement de chapeau.

→ Lire l’explication complète de la marmotte

Les biais d’entraînement cassent la promesse de détection

Un modèle supervisé apprend à distinguer des exemples étiquetés comme légitimes ou malveillants. Son plafond est donc fixé par le jeu d’entraînement, pas par la puissance marketing du fournisseur. Si les journaux contiennent surtout des exécutions PowerShell historiques, le modèle apprend PowerShell. Il ne découvre pas spontanément une chaîne d’attaque qui passe par un binaire signé, une tâche planifiée ou une identité cloud compromise.

Le biais de sélection est le défaut dominant. Les incidents connus sont surreprésentés parce qu’ils ont été investigués et annotés. Les intrusions silencieuses, par définition inconnues, sont absentes. Un taux de détection mesuré sur ces données évalue la capacité à reconnaître le passé, souvent avec une précision cosmétique. Un modèle qui atteint 99 % sur un jeu de test dont les événements proviennent de la même période, des mêmes capteurs et des mêmes règles de labellisation n’a rien démontré sur une compromission future.

La fuite de données fausse encore davantage les résultats. Une variable disponible uniquement après l’investigation, comme le verdict d’un analyste ou le nom d’un ticket d’incident, ne doit jamais entrer dans les caractéristiques d’entraînement. Le modèle apprendrait le processus de réponse interne, pas l’attaque. Cette erreur produit des scores magnifiques et un réveil difficile. Les métriques adorent ce genre de magie, les attaquants beaucoup moins impressionnés.

Les étiquettes négatives posent aussi problème. Un événement non étiqueté malveillant n’est pas nécessairement bénin. Il peut être inconnu, non traité ou perdu dans une file d’alertes saturée. Il faut séparer explicitement les classes malveillant confirmé, bénin confirmé et inconnu, puis exclure cette dernière de l’apprentissage supervisé lorsque sa proportion n’est pas maîtrisée.

La recommandation est de ne pas utiliser un classifieur ML comme contrôle principal pour des techniques déjà connues et observables. Une règle explicite reste supérieure pour détecter l’ajout d’un membre à un groupe privilégié, une authentification réussie depuis une localisation interdite, ou la création d’une clé d’accès permanente. Ces événements ont une sémantique stable et une investigation déterministe. Les sujets de gestion des identités montrent d’ailleurs pourquoi l’événement d’autorisation compte souvent davantage que le score calculé après coup.

Concept drift et attaquant adaptatif : le modèle vieillit en production

Le concept drift désigne la dérive entre la distribution des données d’entraînement et celle observée en exploitation. Dans un système d’information, cette dérive est normale : nouvelle application, migration d’annuaire, changement d’agent de journalisation, télétravail, acquisition ou correction d’une horloge. Le modèle interprète parfois ce changement comme une attaque. Il n’a pas tort statistiquement, seulement opérationnellement.

La dérive adverse est plus grave. Un attaquant adaptatif observe les seuils, les blocages, les délais de réaction et parfois les messages de refus. Il peut répartir ses tentatives de mot de passe, ralentir une exfiltration, varier les commandes ou injecter du bruit légitime dans les journaux. Contrairement à une image de chat, une activité malveillante cherche activement à devenir autre chose dès qu’elle est reconnue. Le classifieur statique perd alors sa frontière de décision au rythme de l’adversaire.

Les attaques d’évasion modifient les caractéristiques visibles sans changer l’objectif offensif. Les attaques par empoisonnement contaminent les données utilisées au réentraînement, par exemple en faisant passer progressivement un comportement suspect pour normal. Les attaques d’inférence cherchent à déduire si une donnée a servi à entraîner le modèle. L’extraction de modèle vise à reproduire ses décisions par requêtes répétées. Exposer un score ou un verdict détaillé à un acteur non fiable revient à publier un manuel de contournement avec une reliure brillante.

La contre-mesure ne consiste pas à réentraîner chaque nuit par réflexe. Un réentraînement automatique sur des données non revues propage un empoisonnement plus vite qu’une campagne de phishing. Il faut versionner les jeux de données, conserver les critères de labellisation, valider les distributions avant déploiement et comparer le nouveau modèle à un modèle de référence sur un jeu de test gelé.

Les indicateurs de dérive doivent être supervisés : variation de fréquence des caractéristiques, hausse du taux d’alertes, baisse des confirmations par les analystes, changement de couverture des sources et délais de traitement. Un modèle dont la précision se dégrade sans alerte de santé est un détecteur décoratif. Très moderne, très coloré, très absent au moment utile.

Le ML utile : anomalies à grande échelle et priorisation des alertes

Le ML apporte un gain réel lorsqu’il agrège un volume de comportements qu’aucune règle manuelle ne peut décrire sans exploser en variantes. La détection d’anomalies comportementales est le cas le plus défendable : volume habituel de transfert, combinaison inhabituelle d’accès à des ressources, séquence rare d’actions administratives, ou écart de comportement entre identités techniques comparables.

Un modèle non supervisé, entraîné majoritairement sur des événements considérés comme normaux, peut classer les écarts sans prétendre reconnaître une attaque nommée. Son résultat doit être présenté comme un score de rareté ou d’écart, jamais comme un verdict de compromission. Cette nuance décide de l’architecture de réponse : un score élève une alerte dans la file, il ne désactive pas un compte privilégié sans corroboration.

La priorisation est un second cas rentable. Un modèle peut combiner la criticité d’un actif, l’ancienneté d’un compte, la présence d’un indicateur de compromission, la rareté d’une commande et l’historique de faux positifs. L’objectif n’est pas de remplacer l’analyste, mais de faire remonter les enquêtes qui croisent plusieurs signaux. Pour structurer ces signaux, les fondations de l’architecture cyber restent plus décisives que le choix d’un algorithme.

Une règle explicable doit reprendre la main lorsque la décision est bloquante, réglementée, ou exige une preuve exploitable. Bloquer une authentification, isoler un hôte, révoquer un secret ou ouvrir un incident majeur impose de répondre à trois questions : quel événement a déclenché la décision, quelle politique est violée, et comment reproduire le résultat ? Une forêt aléatoire (random forest) peut fournir des variables influentes, pas une chaîne de preuve complète. Pour l’investigation, c’est insuffisant.

La bonne architecture est hybride : règles déterministes pour les invariants de sécurité, corrélation pour les scénarios connus, modèle d’anomalie pour découvrir des écarts et modèle de priorité pour ordonner le travail. Le ML ne remplace pas les règles, il réduit la zone aveugle entre elles.

Exemple reproductible de score d’anomalie comportementale

Cet exemple utilise Python 3.11, pandas 2.2 et scikit-learn 1.4. Il calcule un score sur trois caractéristiques agrégées par identité et par heure : nombre d’authentifications, nombre d’adresses sources distinctes et volume transféré. Le fichier d’entrée doit être produit par une collecte dont les champs et l’horodatage sont versionnés.

# Installer des versions figées pour éviter de changer le modèle par accident.
python3.11 -m pip install "pandas==2.2.2" "scikit-learn==1.4.2"

# events.csv contient : identity,login_count,source_count,bytes_out
python3.11 - <<'PY'
import pandas as pd
from sklearn.ensemble import IsolationForest

events = pd.read_csv("events.csv")

# contamination fixe la proportion maximale d'écarts attendus.
# Elle doit être calibrée sur la capacité réelle de traitement des alertes.
features = events[["login_count", "source_count", "bytes_out"]]
model = IsolationForest(
    contamination=0.01,
    random_state=42,
    n_estimators=200,
)
events["anomaly_score"] = -model.fit(features).score_samples(features)
events["is_anomaly"] = model.predict(features) == -1

# Le résultat est un signal de triage, pas une décision de blocage.
events.sort_values("anomaly_score", ascending=False).to_csv(
    "scored-events.csv", index=False
)
PY

Cet exemple ne doit pas être alimenté directement par des journaux bruts hétérogènes. Les valeurs nulles, les changements de format et les retards d’ingestion modifient la distribution des caractéristiques et déclenchent des anomalies artificielles. Une normalisation stable, avec schéma versionné, est un prérequis. La page réseaux couvre les limites de visibilité qui affectent aussi cette collecte : un capteur absent n’est pas une absence d’activité.

Exploitation : données, accès, supervision et reprise

Les prérequis de plateforme sont précis : inventaire des sources, synchronisation temporelle, identifiants d’événements stables, stockage permettant de rejouer une période historique, pipeline de labellisation séparé de la production et capacité à attribuer chaque prédiction à une version de modèle et de données. Sans rejeu, une régression ne s’analyse pas. Elle se contemple, ce qui est une activité moins productive que prévue.

Les données de sécurité contiennent fréquemment des identifiants, des adresses, des noms d’hôtes et des jetons. L’accès aux jeux d’entraînement doit suivre le moindre privilège, avec chiffrement au repos, journalisation des exports et rétention définie. Les secrets d’accès aux collecteurs doivent être stockés dans un gestionnaire de secrets, rotés et distincts entre entraînement, inférence et administration. Un compte partagé capable de lire toutes les télémétries et de modifier le modèle est une porte dérobée avec un tableur de gouvernance.

La sauvegarde doit inclure le modèle sérialisé, son manifeste de dépendances, le schéma de caractéristiques, les seuils, le jeu de validation gelé et les métadonnées de provenance. Restaurer uniquement un fichier de modèle ne restaure pas une capacité de détection. Sans le prétraitement exact, la même entrée ne produit plus le même résultat.

La supervision doit mesurer la latence d’inférence, la fraîcheur des données, le taux d’événements rejetés, la dérive des caractéristiques, le volume d’alertes et la proportion de verdicts confirmés. Définir un mode dégradé est obligatoire : en cas d’indisponibilité du modèle, les règles déterministes continuent de fonctionner et la priorisation revient à une méthode fixe documentée. Le modèle ne garantit ni l’exhaustivité de la détection, ni l’absence de faux positifs, ni la compréhension d’une attaque. Le reste vient des capteurs, des règles, de l’investigation et de la réponse à incident.

🐝 Ce qui arrive si on s’en passe

Sans cette discipline, le score d’anomalie devient une décision que personne ne peut plus contester : quelques mois après, faute de caractéristiques et de version conservées, une alerte ne peut être ni rejouée ni justifiée devant un auditeur ou un utilisateur dont le compte a été suspendu. La connaissance de détection reste enfermée dans le modèle et ne se convertit jamais en règles lisibles, donc rien ne survit à un changement d’outil. Un volume d’alertes non calibré sur la capacité de traitement produit un tri par abandon : les files saturées font ignorer aussi les détections déterministes qui, elles, étaient fiables. Enfin, sans séparation des accès entre entraînement et exploitation, modifier les données d’apprentissage devient un moyen discret de rendre un comportement normal, sans déclencher la moindre alerte de sécurité.

🦫 Explication de la marmotte 🍫

L’apprentissage automatique sert à repérer des événements inhabituels dans de grandes quantités de traces informatiques. On lui fournit d’abord des données passées : connexions, commandes lancées, volumes de fichiers échangés et actions sur des comptes. Un programme cherche alors des ressemblances entre les événements déjà classés, ou repère ceux qui s’écartent fortement des habitudes observées.

Le résultat dépend directement des données fournies. Si les anciennes attaques sont nombreuses mais qu’une nouvelle technique n’apparaît jamais dans les exemples, le programme risque de ne pas la reconnaître. Si les habitudes changent après une migration ou l’arrivée d’un nouveau service, il peut signaler beaucoup d’activités normales. Les attaquants peuvent aussi modifier leur comportement pour ressembler davantage à une activité ordinaire.

Pour cette raison, un score produit par le programme ne doit pas être traité comme une preuve. Il sert à choisir quelles alertes examiner d’abord. Des règles écrites restent préférables pour les actions connues et dangereuses, comme l’ajout d’un administrateur ou l’utilisation d’un accès interdit.

Le système doit conserver les données utilisées, les réglages du programme et ses résultats. Il faut surveiller la qualité des données, vérifier les alertes avec des personnes compétentes et pouvoir revenir à des règles fixes si le programme tombe en panne ou commence à produire des résultats trompeurs.

À lire aussi

• Comment calibrer les alertes d’un SIEM sans noyer le SOCLa théorie de la détection explique pourquoi un SIEM trop bavard épuise les analystes, tandis qu’un SIEM silencieux masque les menaces réelles.
• Réduire la fatigue d’alerte dans un SOCConcevoir la priorisation, la corrélation et le tiering d’un SOC pour réduire la fatigue d’alerte sans masquer les incidents réels.
• Collecter et fiabiliser les logs de sécuritéCollecter, horodater, normaliser et contrôler les événements de sécurité conditionne la détection autant que le choix du SIEM.
• EDR : fonctionnement, angles morts et contournementsCe que fait un EDR (Endpoint Detection and Response) sur les terminaux, ce qu'il ne voit pas, comment les attaquants le neutralisent et comment l'exploiter sans en faire un risque de plus.

Pages voisines

La citent

• Comment calibrer les alertes d’un SIEM sans noyer le SOC
• EDR : fonctionnement, angles morts et contournements
• AI Act : exactitude, robustesse et cybersécurité d'une IA à haut risque (article 15)
• Différence entre IA et LLM : un champ entier, un type de modèle
• La fatigue d'alerte

Pourquoi le ML échoue à détecter les menaces

Elle cite

• Apprentissage automatique et réseaux de neurones, attaques du modèle
• Réduire l’alert fatigue sans perdre la détection
• Sécuriser les systèmes de recommandation contre l’empoisonnement