Confinement, éradication et restauration

Bonne lecture et bon apprentissage ! Junior TSAFACK – 26/09/2026 ⏱️ Temps de lecture estimé : 12 minutes

1. Confinement

Deux temps

Type	Objectif	Horizon
Confinement immédiat	Arrêter les dégâts en cours (chiffrement, exfiltration)	Minutes
Confinement durable	Maintenir l’attaquant à l’écart le temps d’éradiquer, tout en gardant l’activité possible	Heures à jours

Le dilemme du confinement

Confiner, c’est toujours arbitrer entre stopper l’attaque, préserver les preuves et maintenir l’activité. C’est pourquoi le RACI (chapitre 2) précise qui a le droit de décider pour chaque niveau de criticité.

Option	Stoppe l’attaque	Préserve les preuves	Impact métier
Éteindre brutalement le serveur	✅	❌ (mémoire perdue)	Fort
Isoler le serveur du réseau (VLAN de quarantaine, EDR, pare-feu)	✅	✅	Fort
Bloquer uniquement l’IP de l’attaquant	⚠️ (l’attaquant peut changer d’IP)	✅	Faible
Surveiller sans agir	❌	✅	Nul

Ce qu’a fait LogiTrans

La politique autorise l’Incident Manager à isoler un serveur critique en cas d’activité destructrice en cours, avec information immédiate de la direction. C’est ce qui a été appliqué :

Heure UTC	Action	Exécutée par	Approuvée par
03:15	Capture de la mémoire vive de srv-erp01 (preuve P-01)	Analyste SOC	IM
03:30	Fermeture de la règle de pare-feu exposant l’accès SSH	Admin réseau	IM
03:30	Blocage des IP externes identifiées (entrant et sortant)	Admin réseau	IM
03:32	Déplacement de srv-erp01 dans le VLAN de quarantaine (seule la station d’analyse y accède)	Admin réseau	IM (délégation P1), DG informé 03:35
03:40	Désactivation du compte technique du prestataire et du compte créé par l’attaquant	Admin système	IM
04:00	Vérification : plus aucun flux sortant de srv-erp01	Analyste SOC	–

⚠️ Les actions sur le serveur compromis sont faites depuis la station d’analyse dédiée, jamais depuis un poste d’administrateur habituel.

Confinement durable

Surveillance renforcée du SIEM sur tous les serveurs (règles temporaires sur les IP et comptes identifiés).
Revue express de toutes les règles de pare-feu entrantes : deux autres règles obsolètes trouvées et fermées.
Blocage par défaut des flux sortants depuis la zone serveurs, sauf liste blanche (mises à jour, services nécessaires).
Mode dégradé pour le métier : prise de commandes sur formulaire papier et tableur, communiqué interne à 08 h 00.

2. Éradication

Objectif : supprimer toute présence de l’attaquant et corriger la cause racine.

Principe : on ne « nettoie » pas un serveur compromis, on le reconstruit

Un attaquant qui a eu les droits d’administration a pu modifier n’importe quoi. Supprimer les éléments connus ne garantit rien. La seule approche sûre : réinstaller à partir d’une source saine et restaurer uniquement les données.

Checklist d’éradication LogiTrans

Cause racine 1 corrigée : règle de pare-feu supprimée, processus de changement rendu obligatoire
Cause racine 2 corrigée : compte technique supprimé ; les accès prestataires passent désormais par le bastion avec MFA et durée limitée
Réinitialisation des mots de passe de tous les comptes à privilèges et des comptes de service de l’ERP
Rotation des secrets : mot de passe de la base de données, clés d’API d’Odoo, clés SSH des administrateurs
Recherche des indicateurs de compromission (IP, comptes, tâches planifiées) sur tous les serveurs via le SIEM et l’EDR : aucun résultat hors srv-erp01
Vérification de l’annuaire (srv-ad01) : pas de compte créé ni de modification de groupe privilégié pendant la période

3. Restauration

Le plan de reprise

Étape	Action	Critère de validation	Responsable
1	Installer un nouveau serveur à partir d’une image durcie à jour	Scan de vulnérabilités sans faille critique	Admin système
2	Vérifier l’intégrité de la sauvegarde hors ligne du 13/09 (empreinte, restauration test)	Empreinte conforme, base montée sans erreur	Admin système
3	Restaurer la base ERP et l’application	Tests fonctionnels validés par un utilisateur clé de la comptabilité	Admin + métier
4	Ressaisir les opérations du mode dégradé	Rapprochement avec les formulaires papier	Métier
5	Remise en service dans une zone réseau restreinte, accès d’administration via bastion + MFA uniquement	Test de connexion refusé depuis Internet	Admin réseau
6	Surveillance renforcée pendant 30 jours	Aucune alerte liée à l’incident	SOC

Les indicateurs du scénario

Jalon	Heure UTC
Premier signe d’attaque (balayage)	14/09 01:52
Première alerte critique (FIM)	14/09 02:41
Prise en charge par le SOC	14/09 02:50
Déclaration de l’incident	14/09 03:05
Confinement effectif	14/09 03:32
ERP remis en service	14/09 17:10
Clôture technique	14/10 (fin de la surveillance renforcée)

→ ERP indisponible 13 h 38, RTO de 8 h dépassé. RPO de 24 h respecté (sauvegarde de la veille). Ces écarts alimenteront le RETEX.

Le registre des décisions

Chaque décision importante y est tracée : c’est la preuve, pour la direction, l’assureur ou une autorité, que l’organisation a agi de manière raisonnée et documentée.

N°	Date/heure UTC	Décision	Options écartées	Justification	Approuvée par
D0	14/09 03:32	Isoler srv-erp01	Extinction, blocage IP seul	Chiffrement en cours ; préserver la mémoire	IM (délégation P1)
D1	14/09 07:20	Reconstruire depuis la sauvegarde du 13/09	Attendre la fin de l’enquête	Coût d’arrêt élevé, preuves déjà collectées	DG
D2	14/09 07:20	Réinitialiser tous les comptes à privilèges	Uniquement les comptes touchés	Périmètre de compromission incertain	RSSI
D3	14/09 07:20	Préparer la notification RGPD	Attendre la certitude de l’exfiltration	Délai de 72 h, risque pour les personnes probable	DG, sur avis du DPO
D4	14/09 07:20	Porter plainte, prévenir l’assureur	–	Obligation contractuelle, droits de l’entreprise	DG
D5	14/09 07:20	Aucun contact ni paiement à l’attaquant	–	Recommandation des autorités, aucune garantie	DG

Prochaine étape : Post-incident et conformité →