IA et cybersécurité : quand la formation devient menace

39 secondes. C’est un ordre de grandeur réaliste du temps moyen qu’il faut aujourd’hui à un attaquant pour automatiser des tentatives d’accès à grande échelle une fois une chaîne d’outils prête (scripts, identifiants volés, infrastructure). Le vrai problème n’est plus la « vitesse » brute. C’est la qualité des adversaires — et leur capacité à apprendre.

L’info qui circule autour du groupe de hackers Salt Typhoon (lié à la Chine) illustre un angle souvent sous-estimé : deux personnes associées à des entreprises reliées au groupe auraient figuré dans des registres d’un programme de formation Cisco, des années avant que la campagne d’espionnage ne cible des équipements Cisco. Rien n’indique qu’un cours transforme quelqu’un en attaquant. Mais le signal est là : des acteurs très compétents peuvent être passés par les mêmes formations que vos équipes.

Dans cette série « Intelligence artificielle dans la cybersécurité », j’insiste sur un point simple : la défense “statique” (règles, signatures, checklists) ne tient pas face à des adversaires adaptatifs. L’IA n’est pas un gadget : c’est une réponse pragmatique à un adversaire qui itère, apprend et se cache.

Salt Typhoon : ce que l’histoire raconte vraiment

Réponse directe : cette affaire rappelle que la compétence technique n’est pas rare, y compris côté offensif, et que la confiance ne peut pas reposer sur “ils ne sauraient pas faire”.

Le résumé RSS dit peu de choses, mais il est déjà révélateur : des noms liés à des structures associées à Salt Typhoon apparaissent dans un programme de formation Cisco, bien avant une campagne d’espionnage visant des dispositifs Cisco. Le message à retenir n’est pas « la formation est dangereuse ». Le message, c’est : l’écosystème cyber est poreux.

De la certification au ciblage : le même manuel, deux usages

La plupart des formations réseau/sécurité enseignent :

• comment fonctionnent les équipements (routage, VPN, ACL, logs)
• comment diagnostiquer (troubleshooting, captures, corrélation)
• comment durcir (segmentation, principes de moindre privilège)

Un attaquant formé utilise souvent les mêmes bases, mais à l’envers :

• comprendre où les organisations se trompent (configurations “par défaut”, exceptions, dettes techniques)
• repérer l’endroit où l’observabilité est faible (journaux absents, SIEM mal alimenté)
• exploiter les écarts entre théorie et exploitation (procédures non appliquées)

Phrase à garder en tête : “La compétence n’est pas un facteur de confiance. C’est un facteur de risque à surveiller.”

Pourquoi les acteurs étatiques sont si difficiles à arrêter

Les groupes liés à des États cumulent généralement :

• patience (campagnes longues, reconnaissance discrète)
• ressources (infrastructure, relais, opérations multiples)
• priorités d’espionnage (accès silencieux plutôt que sabotage)

Résultat : même une entreprise bien organisée peut manquer le moment où « tout bascule » — parce que le but est justement de ne pas déclencher d’alarme.

Le vrai risque : l’attaquant “qui connaît votre environnement”

Réponse directe : le danger augmente quand l’adversaire maîtrise vos technologies, votre jargon et vos habitudes d’exploitation.

Quand un acteur a une culture “réseau” solide (qu’il l’ait acquise via une académie, un emploi, ou de l’autoformation), il sait où frapper :

1) Les points d’infrastructure qui voient tout… mais qu’on surveille mal

Routeurs, firewalls, concentrateurs VPN, contrôleurs Wi‑Fi : ce sont des nœuds à haute valeur. Ils sont souvent :

• moins patchés que les postes utilisateurs (fenêtres de maintenance difficiles)
• gérés par peu de personnes (compétence rare)
• faiblement journalisés (logs non centralisés, volumes trop importants)

2) L’abus d’outils légitimes (le “living off the land”)

Les campagnes d’espionnage aiment les techniques qui ressemblent à de l’admin :

• comptes de service
• SSH/RDP/administration distante
• modifications “mineures” de configuration

Dans les SOC, j’ai vu cette confusion partout : “ça ressemble à un admin pressé”. Et c’est précisément ce que l’attaquant veut.

3) L’angle mort des identités

Les identités (humaines et machines) sont devenues le vrai périmètre. Un adversaire expérimenté cherche :

• tokens, clés API, certificats
• comptes à privilèges, délégations, exceptions MFA
• chemins de rebond entre environnements (IT ↔ OT, on‑prem ↔ cloud)

Où l’IA change concrètement la donne en détection

Réponse directe : l’IA est utile quand elle réduit le bruit et met en évidence des comportements anormaux que les règles ne capturent pas.

Les outils traditionnels (signatures, IOC, règles fixes) restent nécessaires, mais ils cassent face à :

• des techniques “propres” (peu de malware)
• des actions rares mais légitimes (changement de config)
• des attaques lentes (low and slow)

Détection comportementale : l’IA pour repérer l’invisible

L’IA (souvent sous forme de machine learning + modèles de séries temporelles) sert à établir une ligne de base :

• quels admins se connectent à quels équipements, à quelles heures
• quels volumes de commandes/config sont habituels
• quels flux sortants sont normaux depuis un équipement réseau

Exemples de signaux hautement actionnables :

• connexion admin à un routeur critique à 03:17, depuis un pays jamais observé, suivie d’un changement d’ACL
• augmentation progressive des authentifications échouées puis succès sur un compte “rarement utilisé”
• nouveau tunnel sortant chiffré depuis un équipement qui n’émet normalement que vers le SIEM

Corrélation multi-sources : l’IA comme “colle” entre logs

L’intérêt monte quand l’IA corrèle :

• journaux d’identité (IdP, MFA, PAM)
• logs réseau (NetFlow, DNS, proxy)
• télémétrie endpoints et serveurs
• événements équipements (config, syslog)

Un événement isolé ne prouve rien. Une chaîne (identité → équipement → exfiltration) raconte une histoire.

IA générative : utile, mais seulement avec garde-fous

La GenAI peut aider à :

• résumer un incident (timeline lisible)
• proposer des hypothèses d’investigation
• accélérer l’écriture de requêtes (KQL/Splunk) et playbooks

Mais elle ne doit pas être “juge et jury”. Les bonnes pratiques que je recommande :

• conserver une traçabilité des sources (événements cités)
• imposer un mode justification (“pourquoi tu penses ça ?”)
• limiter l’automatisation à des actions réversibles (isoler un poste, bloquer un token) avec validation humaine

Prévenir l’effet “insider compétent” : une stratégie pratico-pratique

Réponse directe : on réduit ce risque avec un mix de contrôle d’accès, observabilité, hygiène de config et réponses automatisées.

Le cas Salt Typhoon pousse à se poser une question inconfortable : et si l’attaquant connaît nos outils aussi bien que nous ? La réponse n’est pas la parano. C’est l’ingénierie.

1) Durcir les équipements réseau comme des serveurs critiques

Checklist courte, mais qui fait la différence :

• patch management avec inventaire réel (pas “théorique”)
• suppression des comptes partagés, traçabilité des actions admin
• configurations sauvegardées, contrôles d’intégrité
• désactivation des services inutiles, restriction d’admin par bastion

2) Mettre les identités au centre (PAM + MFA + moindre privilège)

Les actions à fort ROI :

• PAM pour toutes les sessions admin (enregistrement, approbation, rotation)
• MFA résistante au phishing sur comptes sensibles
• rotation et gouvernance des secrets (API keys, certificats)

3) Construire une détection “par scénario”, pas par outil

Au lieu de “on a un SIEM”, viser :

• scénario « prise de contrôle équipement réseau »
• scénario « création de persistance via compte/clé »
• scénario « exfiltration discrète via canal chiffré »

Chaque scénario doit avoir : sources de logs, détections, seuils, et réponse.

4) Automatiser la réponse là où ça compte

L’IA et l’automatisation (SOAR) sont rentables quand elles réduisent le délai :

• quarantaine d’un compte à risque
• blocage temporaire d’un accès admin hors politique
• mise en lecture seule d’une config pendant enquête
• ouverture automatique d’un ticket enrichi (preuves, timeline)

Une règle simple : automatiser ce qui est fréquent, réversible, et mesurable.

Questions fréquentes (et réponses franches)

Réponse directe : oui, l’IA aide, mais elle doit être opérationnelle, pas décorative.

“L’IA peut-elle détecter un attaquant très qualifié ?”

Oui, si vous alimentez les modèles avec de la télémétrie pertinente (identité, réseau, équipements) et si vous cherchez des écarts comportementaux plutôt que des signatures.

“Est-ce que former plus de gens à la cybersécurité augmente le risque ?”

Non. Le risque vient de l’usage malveillant, pas de la connaissance. En revanche, cette réalité impose une défense mature : contrôles, surveillance, réponse.

“Par quoi commencer si on a peu de budget ?”

Commencez par : inventaire des équipements critiques, centralisation des logs essentiels, MFA/PAM sur admins, et 2–3 scénarios de détection prioritaires. L’IA n’a aucune valeur si les données sont pauvres.

Ce que cette affaire change pour 2026 (et pourquoi agir maintenant)

La fin d’année (décembre 2025) est un moment propice pour regarder froidement son exposition : budgets 2026, audits, renouvellements SOC, projets IAM. Si vous ne deviez retenir qu’une idée : la frontière entre “défense” et “attaque” n’est pas la compétence, c’est la gouvernance et la détection.

Pour la série « Intelligence artificielle dans la cybersécurité », cet épisode sert de rappel : l’IA n’est pas là pour remplacer les équipes. Elle est là pour voir plus vite et relier des signaux faibles que personne n’a le temps de recoller manuellement.

Si vous suspectez que vos équipements réseau, vos identités privilégiées ou vos logs sont des angles morts, la bonne prochaine étape est simple : cartographier vos scénarios d’attaque prioritaires et vérifier si votre stack (SIEM/XDR/SOAR + IA) sait réellement les détecter et y répondre.

Et vous, quel serait le plus coûteux pour votre organisation : un ransomware bruyant… ou une campagne d’espionnage silencieuse qui dure six mois ?