Au-delà des problématiques techniques de remise en route des infrastructures et de leur sécurisation, le volet du redémarrage et de l’ordre des redémarrages est essentiel pour réussir sa reconstruction.
Existe-t-il des organisations prêtes ?
Une fois, lors d’une intervention, le client avait préparé un document très complet, avec la liste des systèmes triés par criticité, les motifs associés, les durées d’indisponibilité acceptables et l’ordre de redémarrage… L’équipe de crise n’a pu s’appuyer que sur un seul exemplaire papier du document : parmi les premières cibles du ransomware, les copies électroniques avaient été chiffrées. Alors, on se le note : préparer un plan de redémarrage, c’est bien ; le stocker sur un espace de secours, déconnecté du SI principal, c’est mieux pour pouvoir l’utiliser le jour J.
Par où commencer lorsque rien n’est prêt ?
Le challenge est de réussir à définir en un temps record le plan de continuité d’activité métier de l’organisation attaquée. Ce genre de projet est très chronophage et complexe en situation normale. En cas de crise, deux éléments sont clés. Le premier est de se rappeler que l’on parle de plan de reprise métier, et pas informatique. Il faut trancher par rapport à la criticité métier des fonctions et des processus impactés. Le second élément est l’obligation d’efficacité et de pragmatisme qui s’impose en cas de crise. Il est plus simple de définir une et une seule fonction de priorité 1. On peut définir plusieurs P2, P3 voire P4. En revanche, il n’y aura qu’une seule P1. Elle peut être conséquente, et engendrer la remise en place d’une partie importante de l’infrastructure. Mais c’est LA fonction prioritaire à redémarrer.
Alors, on ne redémarre qu’un seul métier ?
Oui, on reste concentré sur la P1. Mais en pratique, et notamment si on constate que ce redémarrage sera plus long que prévu, on peut s’autoriser à marquer quelques points faciles. Sans chambouler les opérations, redémarrer quelques composants annexes fera du bien au moral des équipes. Rappelons également que se concentrer sur une seule P1 présente aussi des avantages pour l’étape d’investigation, qui n’est pas toujours finalisée à ce stade. Au lieu de paralléliser les redémarrages, on se concentre sur la P1 et on laisse les autres pans du SI à disposition des analystes CERT chargés de mener l’enquête sur les causes et l’étendue de l’attaque.
Quand faut-il aborder le sujet du redémarrage ?
Le plan de redémarrage est à aborder au plus vite ! Lors des interventions du CERT, la première réunion porte sur les investigations. La seconde réunion, qui peut survenir assez vite, a pour objet la reprise d’activité et la préparation du redémarrage : qu’est-ce qui est prioritaire ? Quels impacts sur la collecte des éléments de preuve pour le forensic ? Quelles validations nécessaires pour entériner le plan de redémarrage ?
Qui va piloter la définition du plan de redémarrage ?
Ce genre de réunion n’est pas facile à animer ! Chaque métier considère qu’il est plus prioritaire que les autres… Et il est parfois complexe d’identifier toutes les dépendances amenées par le démarrage d’une fonction donnée. En pratique, on s’appuie au début sur le pilote de la cellule de crise, qui est issu de notre CERT. Mais pour suivre toute la définition du plan, il faudra trouver un relai, idéalement un profil de “super PMO”. Cette personne doit avoir une vision la plus transverse possible du fonctionnement de l’organisation, va animer des réunions avec un grand nombre d’intervenants… et doit être capable de dompter un fichier Excel parfois très complexe lorsqu’on y a inscrit l’ensemble des fonctions, processus et applications à redémarrer – avec leur ordre de priorité, bien sûr !
Qui tranche en cas de désaccord ?
La direction générale, tout simplement. Les critères de décision varient d’une structure à l’autre. Cependant, dans le secteur privé, le critère premier reste celui du chiffre d’affaires. Il faut parfois aussi intégrer dans la réflexion la capacité de certaines fonctions métiers à résister plus longtemps au mode dégradé. Dans la sphère publique, comme dans un hôpital ou dans une collectivité, il y a souvent un consensus assez rapide sur les fonctions les plus critiques. Quoi qu’il en soit, ce genre d’arbitrage se fait généralement assez vite.
Et le RSSI dans tout ça ?
Il est essentiel pour apporter la vision “risque” dans ce dialogue entre les métiers, la DSI et la direction générale. Ce n’est pas obligatoirement lui qui va animer les travaux de définition du plan de redémarrage – il n’aurait pas nécessairement le temps ni les compétences. Mais il sera sollicité pour… “faire son job” au final, à savoir pour valider le bon niveau de sécurité d’un redémarrage donné Il est important de noter qu’aucun RSSI n’a été “viré” lors des interventions que nous avons menées. D’une part, le rôle d’un CERT n’est pas de juger ni de chercher un coupable. D’autre part, lorsque l’on considère la crise avec un peu de recul, c’est très souvent un ensemble de défaillances qui ont mené à l’incident. Et ça n’est jamais imputable à une seule personne.
Focus sur la reconstruction de l’AD
L’Active Directory est un composant particulier pour la reconstruction. D’une part, il est souvent mis à mal, car c’est ce que les attaquants visent pour prendre la main sur le système d’information. D’autre part, il a un rôle central et sera très vite concerné par le redémarrage. En pratique, après avoir remis en place une architecture réseau convenable, l’AD est souvent la première brique remontée.
Pour la reconstruction, il ne suffit pas de le réinstaller. Dans les grandes lignes, il faut créer une zone réseau isolée dédiée à l’AD, puis réinstaller un contrôleur de domaine sain auquel on ajoutera un par un les services nécessaires (et strictement nécessaires). Il faut appliquer le tiering model pour partir sur des bases saines et robustes. En parallèle, il est utile de mener régulièrement des contrôles à l’aide d’outils comme PingCastle ou PurpleKnight pour valider le niveau de sécurité à chaque étape de la reconstruction.
Article initialement paru dans Cyberun
