Ransomware : quelles applications restaurer en premier après une cyberattaque ?

Après une attaque par ransomware, la tentation est de redémarrer les serveurs les plus visibles. Pourtant, une application restaurée peut rester inutilisable si ses identités, ses données ou ses communications ne sont pas disponibles. La CISA recommande de définir les priorités à partir des services critiques et de leurs interdépendances. 1

Ne pas confondre importance métier et ordre technique

Une application de facturation peut être prioritaire pour l'entreprise, mais sa remise en service dépend d'un annuaire, d'un réseau, d'un système de stockage et d'une base de données. Le plan de reprise doit donc articuler deux classements : la priorité des fonctions métier et la séquence de restauration des composants.

Une analyse d'impact sur l'activité (BIA) permet de préciser les délais d'interruption acceptables et les pertes de données tolérables. Le NIST SP 800-34 recommande d'aligner les stratégies de reprise sur ces besoins et sur l'architecture des systèmes. 2

Une méthode en six étapes

1. Définir les fonctions à rétablir

Classer les fonctions selon la sécurité des personnes, les obligations essentielles, les opérations indispensables et les conséquences économiques. Faire valider ce classement par les métiers et la cellule de crise : l'informatique ne peut pas arbitrer seule.

2. Tracer les dépendances de bout en bout

Pour chaque fonction, relever applications, bases de données, annuaires, DNS, réseau, certificats, clés, stockage, services cloud et fournisseurs. Distinguer les dépendances indispensables des fonctions pouvant fonctionner temporairement en mode dégradé.

3. Vérifier la confiance avant de restaurer

Un système encore compromis ne doit pas être réintroduit dans un environnement de reprise propre. L'investigation, l'éradication, la rotation des secrets et la validation des sauvegardes conditionnent l'ordre réel des opérations. La CISA recommande de restaurer sur un réseau propre et de prévenir toute réinfection. 1

4. Construire une séquence réalisable

Le bon ordre n'est pas toujours « annuaire puis réseau puis application » : un réseau de reprise isolé, une gestion d'identités temporaire ou un environnement de secours peuvent modifier les prérequis. Chaque étape doit préciser ses entrées, son responsable, sa durée estimée et ses critères de succès.

5. Tester la fonction métier

Le démarrage d'une machine virtuelle n'est pas une preuve de reprise. Tester une connexion utilisateur, une transaction, une lecture et une écriture de données, puis les échanges avec les services tiers. Les scénarios de test doivent intégrer les dépendances et les ressources nécessaires. 3

6. Réviser après l'exercice

Consigner les écarts entre ordre prévu et ordre réel, les temps de restauration observés, les dépendances découvertes et les corrections. Un PRA est un processus entretenu, pas un document figé.

Exemple fictif : une PME industrielle

Une entreprise doit reprendre la prise de commandes sous 24 heures. Son ERP dépend d'une base de données, d'un annuaire et d'une passerelle d'échanges avec un transporteur.

| Composant | Rôle dans la reprise | Décision | | --- | --- | --- | | Réseau de reprise isolé | Accueillir des systèmes vérifiés | Préparer avant reconnexion | | Identités et DNS nécessaires | Permettre authentification et résolution | Restaurer ou fournir un service alternatif sûr | | Base de données ERP | Retrouver des données cohérentes | Vérifier intégrité et point de restauration | | Application ERP | Exécuter la prise de commandes | Tester de bout en bout | | Interface transporteur | Expédier les commandes | Rétablir après validation des flux |

L'entreprise peut choisir une saisie manuelle provisoire si l'interface transporteur est indisponible. Ce choix doit être prévu, testé et limité dans le temps.

Les erreurs qui retardent la reprise

• Un inventaire qui omet les services d'identité et les certificats.
• Des sauvegardes présentes mais jamais restaurées en exercice.
• Des dépendances fournisseurs sans procédure d'escalade.
• Une reconnexion prématurée d'équipements potentiellement compromis.
• Un indicateur « serveur en ligne » utilisé comme preuve de reprise métier.

La restauration après ransomware est autant un problème de connaissance du système d'information qu'un problème de sauvegarde. La meilleure séquence est celle que l'organisation peut exécuter dans un environnement sûr, puis démontrer par un test métier.