Déclenchement de PRA, comment cela se passe en vrai ?

La préparation et les tests sont indispensables en amont du déclenchement d’un PRA (Plan de Reprise d’activité).
6 minutes de lecture
Sommaire

La préparation et les tests sont indispensables en amont du déclenchement d’un PRA (Plan de Reprise d’activité). Car ils permettent de réagir avec efficacité et sérénité face à un incident, une panne ou une attaque cybercriminelle. Cependant, cela reste difficile à comprendre pour qui n’a jamais vécu de véritable incident en situation de stress extrême. C’est pourquoi nous vous proposons d’examiner deux scénarios de déclenchement de PRA. Ils montrent l’impact de la préparation sur deux indicateurs clés : le RPO et le RTO. Ces exemples s’inspirent de cas vécus par les équipes Naitways qui accompagnent plus de 250 sociétés de toutes tailles face à leurs enjeux informatiques.

Qu’est-ce qu’un PRA?

Le Plan de Reprise d’Activité (PRA) vise à assurer la continuité en cas de sinistre majeur affectant l’activité de l’entreprise, des catastrophes naturelles aux attaques cybercriminelles. Le PRA anticipe les impacts informatiques, humains et business. L’objectif du PRA est de permettre un redémarrage rapide de l’activité avec une perte minimale de données et de chiffre d’affaires.

Deux indicateurs mesurent l’efficacité du PRA: le RPO (Recovery Point Objective) et le RTO (Recovery Time Objective).

Votre RPO est le temps entre la dernière sauvegarde et l’évènement « disrupteur ». Votre RTO est la durée maximale d’interruption admissible. RPO et RTO dépendent de votre activité et des standards de votre marché. Dans la finance ou l’e-commerce, une minute d’indisponibilité des systèmes informatiques peut signifier des milliers d’ordres ou de commandes perdues. Les calculs de risque et d’opportunités justifient alors d’investir dans un système totalement redondant aux pannes avec un PCA (Plan de Continuité d’activité).

Voyons à présent deux scénarios de déclenchement de PRA pour comprendre comment la préparation améliore les RPO/RTO et réduit le stress.

Scénario 1 : un DG non préparé est victime d’une cyberattaque

Daniel D est le directeur général d’une PME familiale industrielle. Lundi matin, 8h, en stress intense, il contacte le prestataire informatique qui un an auparavant a mis en place son PRA. Mais depuis le DG n’a jamais testé le PRA.

RPO : le point de reprise dépend de la dernière sauvegarde informatique, effectuée une fois par jour à xx h.

RTO : la durée maximale d’interruption est de 24 heures.

  • Appel et qualification de l’incident :

Daniel D. : Allo, aidez-moi ! Mon usine est à l’arrêt. Je ne comprends pas ce qui se passe. Je suis en déplacement sur un salon à l’étranger. C’est une catastrophe!

Support Informatique : Bonjour Daniel. J’ouvre tout de suite un ticket d’incident. Pouvez vous m’expliquer la nature de l’incident ?

Daniel D. : Non je ne peux pas! Le responsable de production me dit que plus rien ne marche. Si je ne peux pas honorer les commandes urgentes d’aujourd’hui, ma boîte va couler !

  • Les premières étapes du PRA :  

L’agent du support doit gérer le stress du DG et perd du temps pour qualifier le périmètre et la taille de l’incident. Il contacte finalement le responsable de production qui explique que tous les postes informatiques sont verrouillés. Un économiseur d’écran affiche un message d’une organisation cybercriminelle qui réclame un virement de 500 000 Euros pour débloquer les PC et la base de données comptables.

L’agent identifie qu’il s’agit d’une attaque de ransomware (rançongiciel) par cryptolocker (chiffrement). Il faut dans ce cas restaurer les serveurs à une date antérieur au déclenchement du ransomware, en dehors de toutes connexions internet. Un travail d’investigation est requis pour comprendre le déclenchement du ransomware et le supprimer avant qu’il ne se déclenche à nouveau.

Cette phase d’analyse et de compréhension de l’attaque prend du temps car l’infrastructure et les différentes interactions de ses éléments sont mal connus.

Les serveurs n’étant pas séparés dans des réseaux distincts, le ransomware a pu s’étendre facilement à tous, ainsi qu’à certains postes de travail. Il est donc nécessaire d’effectuer l’opération sur l’ensemble des serveurs de la société.

  • Les étapes suivantes du PRA :

Les postes de travail des utilisateurs sont également passés au peigne fin. Ils ont interdiction de se connecter au réseau ou à internet tant qu’ils n’ont pas été vérifiés par un outil Antivirus / EDR (Endpoint detection and response). Il faut les traiter un par un, car les utilisateurs sont le vecteur d’attaque majoritaire. Pour ceux qui seraient infectés, une réinstallation logicielle est obligatoire. Ainsi que le changement des mots de passe de l’ensemble du personnel.

Le redémarrage de l’infrastructure prend plusieurs semaines, car il faut en même temps restreindre les flux et les accès des postes utilisateurs vers les serveurs, ainsi que des serveurs entre eux. L’objectif est d’éviter une seconde propagation d’un « reliquat » du ransomware. 

  • Les conséquences :

Il faut plusieurs jours pour restaurer tous les systèmes et relancer la production. Certaines commandes ne sont pas honorées dans les délais. L’entreprise rate un appel d’offre important car l’équipe de direction est mobilisée pour prévenir les clients et redémarrer l’activité de l’entreprise.

Les données commerciales de l’entreprises sont également en vente sur le Darknet. La société a dû informer la CNIL, car ces données contiennent des informations business confidentielles, avec des données personnelles de certains clients.

Le test du PRA aurait permis de détecter que les serveurs et PC devaient être patchés. Cela aurait pu protéger l’entreprise d’une cyberattaque. Les délais de restauration des données auraient aussi été testés pour respecter le RTO. Avec le risque business de commandes à honorer sous 24h, un RTO plus court aurait pu être suggéré, ainsi que des sauvegardes plus fréquentes.

Scénario 2 : une directrice technique préparée fait face à une situation d’urgence

Marie M. est la directrice technique d’un éditeur de logiciel français en Saas. Elle sait que l’activité de son entreprise dépend totalement de son informatique. Dans son PRA, les RPO et RTO sont calculés pour minimiser les risques et pertes financières. Elle est formée à utiliser sa documentation de PRA qui liste les numéros de téléphone à contacter et la procédure à suivre. Elle a aussi participé à un test de PRA avec un scénario de cyberattaque. Mais lundi matin à 8h c’est finalement pour une autre situation d’urgence qu’elle déclenche son PRA.

RPO : la sauvegarde informatique est automatisée toute les 10 minutes.

RTO : la durée maximale d’interruption prévue est de 1h, pour correspondre aux SLA (Service Level Agreements) des clients. Au-delà, l’éditeur doit payer des pénalités financières.

  • Appel et qualification de l’incident :

Marie M. : Bonjour c’est Marie M. de la société WWW. Mon code d’identification est 123789. Je vous appelle pour déclencher mon PRA.

ROC* : Bonjour Marie. Pouvez-vous me donner des détails ? (*Les clients Naitways peuvent être accompagnés à l’année par un ROC, Responsable Opérationnel de Comptes. Pour un PRA, il prend en charge la coordination des parties prenantes dans le rétablissement du SI.)

Marie M. : Les pompiers nous ont évacués de nos locaux où se trouve aussi notre datacenter. Ils ont coupés l’ensemble des systèmes de climatisation. Il y a un incendie dans le restaurant de l’immeuble voisin, et de la fumée s’introduit dans notre bâtiment. Tous les employés vont bien, mais les serveurs ne vont pas tarder à surchauffer et à s’éteindre. Et les pompiers ne nous communiquent aucun délai. 

  • Les premières étapes du PRA :

Marie M. a pu calmement accéder à sa documentation de PRA avec son téléphone portable, via un lien sécurisé vers le cloud.

Le ROC, qui connait bien ce genre de situation pour avoir participé à plusieurs test avec son client, prévient les personnes en interne. Il organise un « call de crise » entre les différents intervenants et le client afin de suivre l’avancée des opérations. Ils sont guidés par le chronogramme, que tous connaissent pour avoir participé à certains tests avec ce même client. Ce chronogramme liste toutes les actions à enclencher, minute par minute, avec le temps estimé de l’action et l’heure de fin réelle. 

Un agent du support informatique Naitways participe à l’appel avec une vue en temps réel du système d’information de l’entreprise. Il utilise notamment des outils de monitoring à distance dont des sondes de températures de la salle serveurs située dans le bâtiment enfumé. Il peut ainsi confirmer qu’ils disposent d’un délai de trente minutes avant que la température ne soit trop élevée.

  • Les étapes suivantes du PRA :

Marie M., sereine, indique donc à l’agent de procéder aux étapes du chronogramme qui sont habituellement indiquées pour la « préparation d’un test de PRA ». Une étape est d’afficher une page de maintenance sur l’écran d’applicatif et d’effectuer une dernière sauvegarde incrémentielle avant de basculer les opérations informatiques sur le site secondaire, c’est-à-dire le datacenter de secours.

Le PRA étant testé régulièrement, les réseaux ainsi que les règles d’ouverture de flux sont déjà connus à l’avance, documentés et pour la plupart déjà renseignés dans les équipements en datacenter. La bascule s’opère donc sans perte de données, car l’agent et les utilisateurs finaux sont informés.

L’entreprise informe ses collaborateurs du déclenchement du PRA par un email préparé à l’avance. Ils sont formés à travailler à distance, avec des outils de webmeeting et des accès sécurisés à leurs applications métiers. Pour les réunions importantes, le PRA prévoit la réservation de salles dans un espace de coworking.

  • Les conséquences :

Le RTO de une heure est respecté. L’interruption de service pour les clients est de 45 minutes. L’entreprise les a prévenus par un email préparé en amont et l’affichage de la page de maintenance sur l’application. Au final, les clients saluent la réactivité de la société, qui respecte ses engagements.

Le PRA est autant humain que technique

Préparer et tester le PRA permet donc d’accélérer la reprise de l’activité et de réduire le stress associé à un incident. Cette préparation concerne autant le DG que ses directions informatiques et métiers, avec des outils sécurisés et un système de « codes d’identification ». La documentation du PRA doit aussi être testée pour s’assurer qu’elle est à jour (contacts clés, accès aux applications métiers, procédures logistiques). Enfin chaque test de PRA est l’occasion de mesurer et améliorer la réactivité de l’entreprise, afin de réduire les impacts financiers des incidents.

Le PRA est autant humain que technique

Préparer et tester le PRA permet donc d’accélérer la reprise de l’activité et de réduire le stress associé à un incident. Cette préparation concerne autant le DG que ses directions informatiques et métiers, avec des outils sécurisés et un système de « codes d’identification ». La documentation du PRA doit aussi être testée pour s’assurer qu’elle est à jour (contacts clés, accès aux applications métiers, procédures logistiques). Enfin, chaque test de PRA est l’occasion de mesurer et d’améliorer la réactivité de l’entreprise, afin de réduire les impacts financiers des incidents.

Vous avez des questions sur l’efficacité de votre PRA ?

Échangez avec un expert Naitways