Automatiser la réponse à incident avec l’IA : jusqu’où aller

L’automatisation de la réponse promet de compenser le manque d’analystes. Elle tient cette promesse sur une partie du travail, et crée des incidents nouveaux sur le reste.

La bonne question n’est pas « peut-on automatiser », mais « que se passe-t-il si l’automatisme se trompe ».

Le critère de décision : la réversibilité

Une action automatisable est une action dont l’erreur est peu coûteuse et rapidement annulable.

Enrichir une alerte avec le contexte d’un actif : si c’est faux, on perd trente secondes. Isoler un serveur de facturation : si c’est faux, on arrête l’entreprise.

Ce critère suffit à trier la plupart des cas.

Ce qu’on peut automatiser sans réserve

• L’enrichissement : rattacher un actif, son propriétaire, sa criticité, son exposition ; interroger des sources de renseignement.
• La corrélation : regrouper des alertes liées en un incident unique avec chronologie.
• La qualification de premier niveau sur des motifs connus et stables.
• La collecte de preuves : figer des journaux, capturer un état, préserver ce qui pourrait disparaître. Action purement additive, sans effet de bord.
• La notification des bonnes personnes selon des règles d’escalade.

Ces cinq usages représentent l’essentiel du gain de temps réel, et aucun ne comporte de risque d’interruption.

Ce qui demande une validation humaine

• L’isolement d’un système de production. Décision d’entreprise, pas décision technique — voir ce que la détection ne fait pas.
• La désactivation d’un compte. Couper le compte d’un dirigeant en pleine négociation sur un faux positif a un coût.
• Le blocage d’un flux réseau, dont les effets de bord sont rarement anticipables.
• La suppression de fichiers, action non réversible par nature.
• La communication externe. Aucun automatisme ne notifie une autorité ou un client.

La zone intermédiaire : automatiser sous conditions

Entre les deux, une catégorie utile : automatiser avec des garde-fous.

Par périmètre. Isolement automatique autorisé sur les postes de travail, interdit sur les serveurs. La règle est simple et couvre la majorité des cas.

Par plage horaire. Automatisation la nuit et le week-end, quand aucun analyste n’est disponible et que l’impact métier est moindre.

Avec expiration. Isolement automatique de trente minutes, levé automatiquement sauf confirmation humaine. On gagne le temps critique sans figer une erreur.

Avec seuil de confiance. Action automatique uniquement si plusieurs signaux indépendants concordent.

Ce que l’IA ajoute — et ce qu’elle complique

Un modèle apporte de la souplesse sur des cas non prévus par une règle. Il apporte aussi de l’opacité.

Une automatisation par règle est auditable : on lit la règle et on sait pourquoi l’action s’est déclenchée. Une automatisation guidée par un modèle demande de pouvoir expliquer la décision après coup, notamment si elle a causé une interruption.

D’où une exigence non négociable : toute action automatisée doit être journalisée avec son déclencheur et les éléments ayant conduit à la décision. Sans cela, vous ne pourrez ni corriger, ni justifier.

Le NIST AI Risk Management Framework traite précisément ces questions de traçabilité et de supervision humaine.

Le risque qu’on sous-estime

Un attaquant qui comprend vos automatismes peut les déclencher volontairement. Provoquer l’isolement automatique de systèmes légitimes est une façon simple de créer une indisponibilité — ou de détourner l’attention pendant qu’il agit ailleurs.

Toute action automatique doit donc avoir une limite de fréquence et une alerte au-delà d’un seuil.

Une progression raisonnable

1. Automatiser l’enrichissement et la collecte de preuves. Gain immédiat, risque nul.
2. Automatiser la corrélation et le regroupement.
3. Introduire le confinement automatique sur les postes de travail, avec expiration.
4. Étendre progressivement, chaque extension étant précédée d’une période d’observation sans action.

La quatrième étape est celle qu’on saute le plus souvent, et c’est celle qui évite les incidents.

Sources

• NIST AI Risk Management Framework
• ISO/IEC 27002:2022, mesures 5.24 à 5.28 — gestion des incidents
• MITRE ATT&CK

Aller plus loin

Ces arbitrages font partie de la conception de notre infogérance SOC. Voir aussi IA et analyse de journaux.