Les étapes d'une réponse à incident

Un jour, malgré tous les efforts, un incident se produit. Le moment où l'on découvre un rançongiciel ou un compte compromis est rarement le bon moment pour improviser. Les organisations qui s'en sortent le mieux ne sont pas forcément celles qui n'ont jamais d'incident : ce sont celles qui avaient une méthode. Cette leçon décrit les cinq étapes d'une réponse à incident et vous fait bâtir un plan de réponse dans la dernière pièce du chapitre.

Le cycle en cinq temps

Les référentiels de réponse à incident, comme ceux du NIST (nist.gov), s'accordent sur une même logique. Nous la retiendrons en cinq étapes :

1. Préparation ;
2. Détection et analyse ;
3. Confinement ;
4. Éradication et reprise ;
5. Retour d'expérience.

Pensez à la gestion d'un feu dans un bâtiment : on a prévu des extincteurs et des consignes (préparation), on repère la fumée et on identifie la source (détection), on ferme les portes coupe-feu pour que ça ne se propage pas (confinement), on éteint le foyer et on répare (éradication et reprise), puis on analyse la cause pour que cela ne se reproduise pas (retour d'expérience).

1. La préparation : ce qu'on fait avant

C'est l'étape la plus importante et la moins visible. Elle comprend :

• Un plan de réponse écrit : qui fait quoi, qui décide, qui prévenir ;
• Une liste de contacts d'urgence, accessible même si le réseau est hors service (une version papier, par exemple) ;
• Des sauvegardes testées, déconnectées du réseau principal, selon la règle 3-2-1 étudiée au premier cours ;
• Des journaux collectés et conservés (leçon 1) ;
• Des outils et des accès d'urgence prévus à l'avance ;
• Des exercices réguliers (exercice sur table, chapitre 3) ;
• Un inventaire des actifs critiques : on ne protège bien que ce qu'on connaît.

2. La détection et l'analyse

Un incident peut être signalé par une alerte, par un employé ou par un tiers (un client, une autorité). L'analyste cherche à répondre à quelques questions :

• Est-ce un vrai incident ? On élimine les faux positifs.
• Quelle est l'étendue ? Quelles machines, quels comptes, quelles données ?
• Quelle est la gravité ? On classe selon l'impact sur les activités et les données.
• Que sait-on sur l'attaquant ? Indicateurs, comportements (leçons 2 et 3).

Deux règles pratiques : tenir un journal horodaté de toutes les décisions et actions, et préserver les preuves (copies des journaux, images mémoire ou disque lorsque c'est nécessaire) avant de modifier les systèmes. Une machine éteinte sans précaution perd des informations qui n'existent qu'en mémoire.

3. Le confinement

Le but est d'empêcher la propagation et de limiter les dégâts, sans détruire les preuves. On distingue :

• le confinement à court terme : isoler du réseau une machine compromise, suspendre un compte, bloquer une adresse hostile ;
• le confinement à plus long terme : segmenter, appliquer des règles temporaires, surveiller étroitement.

Un dilemme classique : isoler tout de suite (on stoppe l'attaque, mais on prévient l'attaquant et on risque de perdre des informations) ou observer un peu (on en apprend plus, mais le risque augmente). La décision se prend selon la gravité, avec la direction, et elle doit être anticipée dans le plan. Une autre règle de bon sens : ne pas tout « éteindre » par réflexe, car l'extinction peut détruire des preuves et ne suffit pas à éliminer la cause.

4. L'éradication et la reprise

Confiné, on s'attaque à la cause :

• Éradication : supprimer les éléments malveillants, fermer la faille exploitée, réinitialiser les identifiants compromis (tous, y compris les comptes de service), revoir les accès créés par l'attaquant. Dans les cas graves, on reconstruit les machines à partir de sources saines plutôt que de tenter de les « nettoyer ».
• Reprise : remettre les systèmes en service de façon progressive, en commençant par les plus critiques, à partir de sauvegardes vérifiées (une sauvegarde peut contenir elle-même la menace). On surveille très étroitement la période qui suit, car un attaquant peut tenter de revenir.

5. Le retour d'expérience

Dans les jours ou semaines qui suivent, on réunit les personnes concernées. On y examine, sans chercher de coupable :

• la chronologie : comment l'attaque s'est déroulée, quand elle a été détectée ;
• ce qui a bien fonctionné et ce qui a échoué ;
• les causes profondes (une absence de correctif, un droit excessif, une formation manquante) ;
• les actions d'amélioration, avec un responsable et une échéance.

C'est ici que la boucle se referme : les enseignements alimentent la préparation, les règles de détection et la formation. Sans cette étape, l'organisation paie un incident et n'en tire rien.

Communication et obligations

La technique ne représente que la moitié d'une réponse à incident. L'autre moitié est la communication : direction, salariés, clients, partenaires, assurance éventuelle, autorités. Quelques points à connaître :

• Un incident qui expose des données personnelles peut obliger à notifier l'autorité de protection des données (la CNIL en France) dans un délai de 72 heures après en avoir pris connaissance, lorsque la violation présente un risque pour les personnes. Cette obligation relève du RGPD ; vérifiez toujours les conditions exactes avec les juristes de l'organisation.
• Le dépôt de plainte est une démarche utile, notamment pour les assurances ; cybermalveillance.gouv.fr détaille les démarches.
• Une communication claire et honnête, sans minimiser ni dramatiser, protège la confiance. Désignez un porte-parole unique.

Un exemple fictif en une page

À vous de jouer

Rédigez votre plan de réponse à incident en une page pour un scénario fictif de compte de messagerie compromis chez Atelier Boréal. Pour chacune des cinq étapes, écrivez deux actions concrètes et le rôle de la personne qui en est responsable.

Vous disposez maintenant d'un dossier de défense. Le chapitre suivant déplace le regard vers les environnements modernes : le cloud, les API et les conteneurs, où les mêmes principes s'appliquent à de nouvelles surfaces d'attaque.