Gérer un incident cyber en 7 étapes

Plus grave qu'une cyberattaque ? Ne pas y être préparé. Voici les sept étapes que j'utilise sur les incidents que j'accompagne, applicables avec ou sans CSIRT interne.

1. Déclenchement et qualification de l'alerte

L'alerte vient d'où ? D'un EDR, d'un canal Slack, d'un client qui signale un comportement anormal, d'une notification d'un fournisseur ? La première chose à faire est qualifier :

• Faux positif probable : un dev qui a fait tourner un script légitime, un test mal communiqué.
• Vrai incident, périmètre limité : un compte compromis sur un poste isolé.
• Vrai incident, périmètre large : ransomware, exfiltration en cours, intrusion confirmée.

Cette qualification se fait en 15 à 30 minutes max. Si on n'arrive pas à conclure, on passe en mode incident par défaut — mieux vaut sur-réagir que sous-réagir.

2. Mobilisation de la cellule de crise

La cellule de crise n'est pas l'équipe Tech entière. C'est un noyau réduit qui décide :

• Un décideur exécutif (DG, COO ou DPO selon contexte).
• Un coordinateur technique (CTO, lead infra ou RSSI s'il existe).
• Un responsable communication interne/externe.
• Un référent juridique (peut être externe, prévu d'avance).

Communication entre ces personnes : canal hors-bande. Signal, téléphone, WhatsApp privé. Pas Slack ni Teams interne — qui peuvent être compromis ou écoutés par l'attaquant.

3. Analyse rapide des signaux

Pendant que la cellule se met en place, l'équipe Tech rassemble :

• Logs du SIEM, du cloud provider, de l'EDR.
• Captures système des machines suspectes.
• Liste des comptes ayant eu une activité anormale dans les 72 dernières heures.
• Rapport antimalware, rapport IDS/IPS.

Objectif : identifier le vecteur initial (phishing ? identifiants volés ? vulnérabilité exploitée ?), le périmètre actuel (combien de machines, combien de comptes), et la nature de la menace (ransomware, exfiltration, persistance).

Ne pas effacer, ne pas redémarrer. Préserver les preuves est aussi important que contenir.

4. Confinement immédiat

Une fois le périmètre identifié, on coupe les canaux d'attaque :

• Désactivation des comptes compromis dans l'IdP (Okta, Entra ID, Google).
• Isolation réseau des machines infectées (segmentation, firewall, désactivation port).
• Révocation des tokens API, des sessions actives, des refresh tokens.
• Reset des secrets potentiellement compromis.
• Blocage des IP attaquantes au niveau du WAF.

L'isolation est plus aggressive que strictement nécessaire à ce stade — c'est volontaire. On peut toujours ré-ouvrir, on ne peut pas annuler une exfiltration.

5. Notification réglementaire et communication externe

Selon la nature de l'incident, des obligations légales s'enclenchent :

• CNIL : 72 heures si fuite de données personnelles (RGPD article 33). Un formulaire en ligne, à remplir même si tous les détails ne sont pas connus — la notification est obligatoire, pas optionnelle.
• Plainte police judiciaire : généralement le DG dépose plainte, ce qui déclenche une enquête. Un PV utile pour la cyber-assurance et la communication.
• Autorité sectorielle : ACPR (banque), ARS (santé), ANSSI pour les OIV, ENISA pour les produits sous CRA en 2026.
• Cyber-assurance : notification dans les délais contractuels (généralement 24-72h).
• Clients : selon les engagements contractuels (SLA, DPA). Posture transparente recommandée.

La communication externe se prépare avant la pression médiatique : message factuel, sans dramaturgie, sans minimiser. La maladresse classique est de communiquer trop vite avec des chiffres erronés qu'il faudra revoir à la hausse.

6. Préservation des preuves et investigation

Pendant et après le confinement :

• Duplication des logs critiques sur un stockage hors ligne (preuves légales).
• Snapshot des machines compromises avant nettoyage.
• Timeline détaillée de l'attaque reconstituée à partir des logs.
• Si externalisation : DFIR (forensic) avec un partenaire spécialisé. Coût élevé mais le retour en valeur d'enquête est important pour les enjeux légaux et l'amélioration.

Les sauvegardes sont vérifiées avant restauration : un attaquant qui a eu du temps a peut-être chiffré ou modifié les sauvegardes elles-mêmes.

7. Remédiation et debriefing

Une fois l'incident contenu et l'investigation aboutie :

• Remédiation technique : remplacement des machines compromises, rotation complète des secrets, déploiement des correctifs, durcissement des configurations.
• Restauration depuis sauvegardes vérifiées si nécessaire.
• Communication finale aux parties prenantes (clients, employés, régulateurs).
• Debriefing post-incident : qu'est-ce qui a marché ? Qu'est-ce qui a manqué ? Quels chantiers en sortent ?

Le debriefing produit une liste d'actions correctives priorisées, qui rentre dans la roadmap sécurité avec un sponsor exécutif. Sans ce dernier point, l'organisation ne capitalise pas et le prochain incident sera identique.

La règle d'or : écrit, testé, périodiquement

Ce runbook doit exister sous forme écrite avant l'incident. Pas dans la tête du CTO. Imprimable, accessible hors-bande, mis à jour annuellement. Testé par un exercice de table-top — 90 minutes par an minimum.

Pour les chantiers à industrialiser avant d'avoir besoin de ce runbook, voir Sécurité PME : 7 priorités avant un RSSI. Pour les exigences de notification spécifiques au CRA en 2026, voir CRA : roadmap des jalons.