Il est 3 h 14. Une machine de votre parc ouvre une connexion vers une adresse signalée. Votre outil de détection a vu juste, et il doit maintenant faire quelque chose. Trois gestes sont possibles : couper la machine du réseau, geler le processus fautif, ou le tuer. La plupart des documentations présentent ces options comme équivalentes, à choisir selon la gravité. Elles ne le sont pas. L’une se défait, les autres non.
Cet article n’est pas un panorama du marché. C’est le compte rendu d’un arbitrage que nous avons dû trancher en écrivant notre propre moteur de réponse, et que nous avons fini par inscrire en dur dans le code : le confinement réversible passe avant la destruction. Voici le raisonnement.
Les trois gestes, et ce qu’ils coûtent vraiment
Un système de détection qui réagit seul engage votre production. Le vrai critère de décision n’est donc pas « quelle action est la plus forte », mais « que se passe-t-il si l’alerte était fausse ». C’est sous cet angle que les trois options se séparent nettement.
1. L’isolation réseau
La machine reste allumée, la session de l’utilisateur reste ouverte, ses fichiers restent en place. Seules ses communications sont coupées, à l’exception du lien vers la console d’administration. Un logiciel de rançon perd son canal de commande, une exfiltration s’arrête net.
Coût en cas de fausse alerte : l’utilisateur perd le réseau pendant quelques minutes. Il appelle, on lève l’isolation, il reprend son travail là où il l’avait laissé. Rien n’est perdu.
2. La suspension de processus
Le processus est gelé, pas terminé. Sa mémoire reste intacte, ce qui présente un double avantage : il cesse de nuire immédiatement, et il reste analysable. Pour une investigation, un processus suspendu vaut infiniment mieux qu’un processus disparu.
Coût en cas de fausse alerte : une application se fige. On la relance, ou on la reprend. Désagréable, réparable.
3. L’arrêt forcé
Le processus est tué. C’est la seule réponse qui garantit qu’il ne fera plus rien, et c’est aussi la seule qu’on ne peut pas annuler.
Le cas qui tranche le débat : tuer un processus en pleine écriture sur un fichier ne le « nettoie » pas. Il laisse un fichier à moitié écrit. Sur une base de données, un export comptable ou un traitement de paie, la fausse alerte de 3 h 14 devient une corruption de données découverte à 9 h, et personne ne fera le lien.
Pourquoi nous avons figé l’ordre dans le code
Une règle de sécurité qu’on peut contourner dans l’urgence n’est pas une règle. Nous avons donc écrit la préférence directement dans le moteur, avec le commentaire qui l’explique, pour que la personne qui reprendra ce code dans deux ans comprenne pourquoi il est ainsi.
// On PRÉFÈRE le confinement réversible (network.isolate / // process.suspend) au kill. // Cap par poste/heure (anti-emballement). // Ne double jamais une isolation déjà active.
Les actions destructrices existent toujours, mais elles ne sont jamais le premier réflexe d’un automatisme. Elles restent disponibles pour un opérateur qui a vu le contexte et décide en connaissance de cause.
Le plafond horaire, ou pourquoi une défense doit savoir s’arrêter
La deuxième ligne du commentaire mérite autant d’attention que la première. Un système de réponse automatique qui s’emballe fait plus de dégâts que l’incident qu’il traite. Imaginez une règle de détection mal calibrée qui se déclenche sur un comportement légitime : sans garde-fou, elle isole votre parc entier en quelques minutes. Vous n’avez plus un incident de sécurité, vous avez une panne générale que vous avez provoquée vous-même.
D’où le plafond par poste et par heure, et la règle qui interdit de doubler une isolation déjà active. Ce sont deux lignes triviales à écrire, et elles font la différence entre un outil de défense et un outil de destruction.
Ce que ça donne concrètement
Sur un poste réellement compromis, la séquence tient en quelques secondes :
- 14:02:07Détection de la connexion sortante vers une adresse signalée.
- 14:02:09Isolation réseau. La session de l’utilisateur est conservée, son travail aussi.
- 14:02:11Notification, avec le motif et le nom de la machine.
Deux secondes entre la détection et le confinement. Et surtout, une action qu’un humain peut annuler d’un clic s’il constate que l’alerte était fausse.
Les questions à poser à votre prestataire
Si vous évaluez une solution de détection et réponse, ou l’infogérant qui l’exploite pour vous, quatre questions séparent rapidement les discours des pratiques :
- •Quelle action votre automatisme déclenche-t-il en premier, et est-elle réversible ?
- •Existe-t-il un plafond du nombre d’interventions automatiques par machine et par heure ?
- •Qui peut lever une isolation, et en combien de temps, à 3 h du matin ?
- •Que devient la mémoire du processus incriminé : conservée pour analyse, ou perdue ?
Une réponse embarrassée sur la deuxième question est le signal le plus révélateur. Elle indique que personne n’a envisagé le cas où la défense se retourne contre la production.
En résumé : confiner d’abord, détruire ensuite, et seulement si quelqu’un a regardé. Une isolation se lève en un clic ; un fichier corrompu par un arrêt brutal se répare sur une sauvegarde, quand elle existe et qu’elle a été testée.
C’est la logique que nous appliquons sur les parcs que nous supervisons, en infogérance comme sur les postes équipés de notre agent. Si vous voulez savoir ce qu’elle donnerait sur votre infrastructure, un échange de trente minutes suffit à en avoir le cœur net.