Exercice de crise & gouvernance
Exercice COMEX/COPIL : votre entreprise face à une attaque par ransomware
Mardi, 8 h 17. Plusieurs utilisateurs signalent qu’ils ne peuvent plus accéder aux fichiers partagés. Quelques minutes plus tard, les premiers services deviennent indisponibles. À ce stade, personne ne sait encore si l’entreprise fait face à une panne, à un incident isolé ou au début d’une crise majeure.
Cet exercice sur table propose de placer un COMEX ou un COPIL face à une attaque par ransomware qui perturbe progressivement le système d’information, l’ERP puis la production. L’objectif n’est pas de tester les compétences techniques des participants, mais leur capacité à comprendre la situation, décider sous incertitude et assurer la continuité de l’entreprise.
L’objectif
Un ransomware n’est pas seulement un incident informatique
Lorsqu’une attaque par ransomware commence, les premiers symptômes peuvent sembler purement techniques : un serveur inaccessible, quelques fichiers impossibles à ouvrir, des utilisateurs qui ne peuvent plus se connecter.
Mais dans une entreprise dont les activités reposent fortement sur son système d’information, la situation peut rapidement changer de nature.
Si l’ERP devient indisponible, ce ne sont plus seulement les équipes informatiques qui sont concernées.
Les nouvelles commandes ne peuvent plus être enregistrées normalement.
Les ordres et priorités de production deviennent indisponibles.
Les lignes et machines dépendantes du SI fonctionnent en mode dégradé ou s’arrêtent.
La préparation et le suivi des livraisons sont perturbés.
L’entreprise ne peut plus facturer normalement ses clients.
L’incident cyber devient alors une crise opérationnelle, industrielle, commerciale et financière.
La question centrale de l’exercice
Combien de temps votre entreprise peut-elle réellement fonctionner sans son système d’information ?
L’exercice proposé ici ne cherche donc pas à savoir si les membres du COMEX connaissent le fonctionnement d’un ransomware.
Il cherche à observer leur capacité à décider lorsque les informations sont incomplètes, que les contraintes métiers augmentent et que chaque heure d’indisponibilité produit de nouvelles conséquences.
Le scénario
Une entreprise industrielle fortement dépendante de son SI
Pour cet exercice, nous utiliserons le cas fictif d’une entreprise industrielle dont l’activité repose sur un ERP central.
L’ERP assure notamment la gestion des commandes, la planification de production, le suivi des stocks, les expéditions et la facturation.
Une partie des équipements et machines de production échange également des informations avec le système d’information. La disponibilité de l’ERP conditionne donc directement le fonctionnement normal de l’activité industrielle.
L’entreprise dispose de sauvegardes et a confié une partie de sa surveillance sécurité à un prestataire spécialisé.
Ce prestataire reçoit certains journaux de sécurité dans sa propre infrastructure.
Le scénario est volontairement générique. Il peut être adapté à une PME, une ETI, une organisation multisite ou à tout environnement dans lequel l’indisponibilité du SI entraîne rapidement une dégradation de l’activité.
Avant de commencer
Les règles de l’exercice
Il s’agit d’un exercice sur table. Aucun système informatique n’est réellement arrêté et aucune action technique n’est réalisée.
Un animateur présente progressivement les événements. Les participants doivent réagir uniquement à partir des informations dont ils disposent à cet instant.
L’animateur communique un nouvel événement ou un changement de situation.
Les participants identifient les impacts techniques, métiers et organisationnels.
Le COMEX ou COPIL doit formaliser une décision, même si l’information reste incomplète.
La décision, son responsable et les actions demandées sont consignés.
Ne donnez pas toutes les réponses
Une crise réelle ne fournit jamais immédiatement une vision complète de la situation. Certaines informations doivent rester incertaines, partielles ou même contradictoires. C’est précisément ce qui permet de tester la capacité de décision.
Mardi — 8 h 17
Le premier signal
Plusieurs utilisateurs contactent le support informatique.
Certains ne peuvent plus ouvrir les fichiers présents sur les espaces partagés. D’autres signalent des ralentissements importants ou des erreurs lors de leur authentification.
Le support pense initialement à un problème d’infrastructure.
À 8 h 28, les équipes informatiques constatent que plusieurs serveurs présentent simultanément des comportements inhabituels.
Premières questions
Qui doit être informé à ce stade ? À partir de quel niveau déclenche-t-on une organisation de crise ? Qui dispose de l’autorité nécessaire pour prendre les premières mesures conservatoires ?
À ce moment précis, le mot ransomware n’a pas encore nécessairement été prononcé.
C’est volontaire.
L’un des objectifs de l’exercice consiste justement à observer à quel moment l’organisation cesse de traiter la situation comme un simple incident informatique.
8 h 42
Le SI devient progressivement inaccessible
L’équipe informatique confirme que plusieurs fichiers ont été chiffrés.
Un message inhabituel apparaît sur un serveur. D’autres systèmes deviennent inaccessibles.
Une compromission plus large est désormais envisagée.
Les équipes techniques recommandent d’isoler rapidement certains environnements afin d’éviter une propagation supplémentaire.
Premier arbitrage
Isoler immédiatement le SI peut limiter la propagation, mais cette décision peut également interrompre des services qui fonctionnent encore. Qui peut prendre cette décision ?
Le COMEX doit maintenant arbitrer avec une information encore très imparfaite.
L’étendue de la compromission est inconnue. La durée de l’interruption l’est également.
9 h 15
L’ERP devient indisponible
Les utilisateurs ne peuvent désormais plus accéder normalement à l’ERP.
La situation change immédiatement de dimension.
Les nouvelles commandes ne peuvent plus être saisies.
La planification de gestion de production n’est plus accessible.
Les équipes disposent difficilement d’une vision fiable des stocks et des encours.
La préparation des expéditions commence à être perturbée.
La facturation est interrompue.
L’incident informatique est devenu une crise d’entreprise
Le sujet n’est désormais plus uniquement de restaurer des serveurs. Il faut déterminer quelles activités peuvent continuer, lesquelles doivent être arrêtées et pendant combien de temps l’entreprise peut fonctionner dans cette situation.
10 h 00
La production est à son tour touchée
Les responsables industriels signalent que plusieurs lignes ne disposent plus normalement des informations issues de l’ERP.
Certaines machines peuvent encore fonctionner. D’autres sont fortement dépendantes des ordres ou données provenant du système d’information.
La cadence de production commence à ralentir.
Le directeur de production propose de maintenir certaines opérations manuellement afin de limiter l’impact sur les engagements clients.
Le dilemme du COMEX
Faut-il continuer à produire en mode dégradé alors que la traçabilité, les ordres de fabrication, les stocks et la synchronisation future avec l’ERP ne sont plus totalement garantis ?
Cette question est volontairement difficile.
Continuer à produire peut limiter les pertes immédiates. Mais une production réalisée avec des informations obsolètes ou partielles peut créer d’autres risques : erreurs de référence, défaut de traçabilité, difficultés de rapprochement des stocks ou impossibilité de réintégrer correctement les opérations dans l’ERP.
Une question de continuité métier
Votre organisation dispose-t-elle réellement d’un mode dégradé documenté, connu des équipes et régulièrement testé ?
10 h 35
Les sauvegardes existent… mais personne ne veut restaurer trop vite
L’équipe infrastructure confirme que des sauvegardes sont disponibles.
C’est une bonne nouvelle, mais elle ne résout pas immédiatement la situation.
Il reste à déterminer si les sauvegardes sont saines, jusqu’où remonte la compromission et quel point de restauration peut être considéré comme suffisamment fiable.
Quels systèmes doivent être restaurés en priorité ?
Les sauvegardes disponibles peuvent-elles être considérées comme saines ?
Quelle perte de données est acceptable pour reprendre l’activité ?
Qui peut valider le retour en production d’un service restauré ?
Restaurer n’est pas seulement une décision technique
Accepter de restaurer une version antérieure d’un ERP peut signifier accepter la perte de plusieurs heures de commandes, de mouvements de stocks ou d’opérations de production.
11 h 05
Le prestataire sécurité n’accède plus au réseau… mais possède encore les journaux
L’entreprise délègue une partie de sa surveillance de sécurité à un prestataire externe.
À la suite de l’isolement du réseau, ce prestataire ne peut plus accéder aux systèmes internes du client.
Il dispose cependant, dans son propre environnement, des journaux de sécurité qui lui ont été transmis avant la coupure.
En les analysant, il identifie plusieurs authentifications inhabituelles dans les heures précédant le début de l’incident.
Une ressource située hors du SI compromis
Le prestataire a perdu sa capacité d’intervention directe, mais il conserve une information essentielle pour reconstruire la chronologie de l’attaque.
Cette situation permet d’aborder une question rarement posée avant une crise :
Qu’est-ce qui restera disponible si notre SI ne l’est plus ?
Les données, journaux, sauvegardes, contacts et outils externalisés ou isolés peuvent devenir déterminants lorsqu’une partie importante de l’infrastructure interne n’est plus accessible.
11 h 45
La crise sort de l’entreprise
Un client stratégique contacte le service commercial.
Sa commande doit être expédiée dans l’après-midi. Il demande si le délai pourra être tenu.
Quelques minutes plus tard, un fournisseur souhaite savoir si les échanges habituels pourront reprendre dans la journée.
La direction financière confirme qu’aucune nouvelle facture ne peut être produite.
Parallèlement, l’équipe en charge de la sécurité indique qu’une exfiltration de données avant chiffrement ne peut pas encore être exclue.
La crise devient multidimensionnelle
Production, clients, fournisseurs, trésorerie, juridique, communication et cybersécurité doivent désormais être traités simultanément.
Une attaque de ce type ne peut plus être pilotée uniquement par la DSI.
Les décisions appartiennent désormais pleinement à la gouvernance de l’entreprise.
12 h 20
Un message de rançon est identifié
L’équipe informatique confirme la présence d’un message attribué aux attaquants.
Celui-ci contient une demande de paiement et affirme que des données ont été copiées avant leur chiffrement.
Rien ne permet encore de confirmer l’ensemble de ces affirmations.
Qui décide maintenant ?
Qui possède l’autorité de décision ? Quels conseils doivent être sollicités ? Quels partenaires internes ou externes doivent être associés à l’analyse ? Quelles informations manquent encore avant de prendre une décision ?
L’objectif pédagogique n’est pas de réduire toute la crise à la question du paiement.
Le véritable sujet reste la capacité du COMEX à conserver une méthode de décision alors que les pressions opérationnelles et externes augmentent.
Décider sous incertitude
Les questions que le COMEX doit réellement trancher
Tout au long de l’exercice, les participants doivent être amenés à formaliser leurs décisions.
Qui dirige la crise et qui possède l’autorité finale de décision ?
Faut-il isoler totalement le SI au risque d’interrompre des services encore disponibles ?
Quelles activités doivent être restaurées en priorité ?
La production peut-elle continuer sans ERP et sous quelles conditions ?
Quelle perte de données l’entreprise peut-elle accepter pour reprendre plus rapidement ?
Combien de temps l’activité peut-elle fonctionner sans facturation ?
À quel moment les clients, partenaires et autres parties prenantes doivent-ils être informés ?
Qui peut autoriser la remise en service d’un système restauré ?
Quels critères permettent de considérer que la reprise est suffisamment maîtrisée ?
L’exercice doit produire des décisions
Une discussion intéressante ne suffit pas. Chaque décision importante devrait être accompagnée d’un responsable, d’une action et, lorsque cela est pertinent, d’un délai.
Un autre angle de résilience
Les ressources de crise sont-elles elles-mêmes disponibles ?
Une crise de cette nature révèle souvent une dépendance à laquelle personne n’avait réellement pensé.
Les procédures existent, mais elles sont stockées dans une GED inaccessible.
Le numéro du prestataire sécurité se trouve dans la messagerie de l’entreprise.
Les mots de passe d’administration sont conservés dans un coffre-fort dont l’authentification dépend de l’annuaire compromis.
Le PCA est présent sur un partage réseau devenu indisponible.
Une question simple à poser avant la crise
Les outils dont vous aurez besoin pendant une crise dépendent-ils eux-mêmes des composants que vous risquez de perdre ?
Cela concerne les procédures, les moyens de communication, les sauvegardes, les outils d’administration, les contacts externes, les journaux de sécurité et les solutions utilisées pour piloter la crise.
La résilience ne consiste donc pas uniquement à disposer de sauvegardes.
Elle consiste également à savoir avec quelles informations, quels outils et quels partenaires l’organisation pourra encore fonctionner lorsque son système d’information principal ne sera plus disponible.
Isoler certains outils peut être une piste
Héberger certains outils nécessaires à la gestion de crise sur une infrastructure distincte peut améliorer leur disponibilité. Mais l’isolation d’un serveur ne suffit pas : réseau, DNS, authentification, stockage et autres dépendances doivent également être examinés.
Avant, pendant, après
En quoi ORKA peut aider ?
ORKA n’empêche pas un ransomware de s’exécuter et ne restaure pas un ERP compromis.
Ce n’est pas son rôle.
En revanche, une situation comme celle décrite dans cet exercice montre l’intérêt de disposer, avant la crise, d’une vision structurée des risques, des dépendances, des documents et des événements concernant le système d’information.
Le scénario ransomware peut déjà être étudié dans la gestion des risques d’ORKA.
Les procédures, documents de référence et éléments utiles peuvent être centralisés.
Si ORKA reste disponible, l’incident peut conserver les événements, actions et éléments de chronologie.
Le retour d’expérience peut alimenter les risques et les futures actions d’amélioration.
Avant la crise : jouer le scénario dans la gestion des risques
Avant qu’un ransomware ne survienne réellement, l’organisation peut déjà étudier cette situation comme un scénario de risque.
L’indisponibilité de l’ERP peut être reliée à ses conséquences : perte de capacité de production, impossibilité de saisir les commandes, rupture de la planification, perturbation des expéditions ou interruption de la facturation.
L’exercice COMEX permet ensuite de confronter cette analyse à la réalité.
Les impacts évalués sont-ils cohérents ? Les dépendances avaient-elles toutes été identifiées ? Les mesures prévues sont-elles réellement applicables ?
Pendant la crise : si ORKA reste disponible
Si son environnement reste accessible et non compromis, ORKA peut être utilisé pour ouvrir l’incident, centraliser les informations utiles et maintenir une chronologie de la situation.
Ouverture et qualification de l’incident.
Historisation des événements significatifs.
Suivi des actions réalisées.
Conservation d’une chronologie exploitable pour le retour d’expérience.
Centralisation de pièces et documents utiles.
À une condition essentielle
ORKA ne peut participer au suivi de la crise que s’il reste lui-même disponible. Son emplacement, son authentification et ses dépendances techniques doivent donc être intégrés à la réflexion de continuité.
Faire fonctionner ORKA sur une infrastructure distincte du SI courant peut constituer une piste. Encore faut-il vérifier que son accès ne repose pas exclusivement sur un annuaire, un réseau ou un service qui pourrait être indisponible pendant la crise.
Après la crise : transformer l’événement en amélioration
Une fois l’activité restaurée, la valeur de l’historique devient particulièrement importante.
Les événements, décisions, actions et constats permettent de reconstruire précisément ce qui s’est passé et d’alimenter le retour d’expérience.
Reconstituer la chronologie et les décisions.
Identifier les difficultés et les dépendances découvertes.
Réévaluer les risques et lancer les actions correctives.
La philosophie ORKA
Savoir ce que l’on sait, ce que l’on décide et ce que l’on doit améliorer.
En situation de crise, la technologie reste indispensable. Mais la qualité du pilotage dépend également de la connaissance du SI, de la disponibilité de l’information et de la capacité à conserver une histoire cohérente des décisions prises.
Après l’exercice
Le débrief est presque plus important que le scénario
L’exercice ne doit pas se terminer lorsque le dernier événement est présenté.
Son intérêt principal réside dans les écarts qu’il permet de révéler.
Quelles décisions ont été les plus difficiles à prendre ?
Quelles informations nous ont manqué ?
Savions-nous clairement qui devait décider ?
Nos procédures étaient-elles réellement accessibles et utilisables ?
Le mode dégradé imaginé sur le papier était-il réellement applicable ?
Connaissions-nous suffisamment les dépendances entre SI et production ?
Les partenaires dont nous avions besoin étaient-ils encore joignables ?
Les outils indispensables à la gestion de crise seraient-ils restés disponibles ?
Ces constats doivent ensuite devenir un plan d’amélioration.
Mettre à jour les procédures et les responsabilités.
Revoir les dépendances, sauvegardes, accès et moyens de communication.
Vérifier réellement les modes dégradés et capacités de restauration.
Organiser un nouvel exercice pour mesurer les progrès réalisés.
Ressource pratique
Un exercice prêt à l’emploi pour votre COMEX ou COPIL
Pour permettre aux organisations de reprendre ce scénario et de l’utiliser directement, ORKA CS a préparé un kit d’exercice complet.
Guide de l’animateur.
Scénario complet réservé à l’animateur.
Chronologie de crise.
Fiches inject à remettre progressivement aux participants.
Feuille de décisions COMEX/COPIL.
Grille d’évaluation des ressources disponibles pendant la crise.
Support de débrief et retour d’expérience.
Plan d’amélioration à compléter après l’exercice.
Kit ORKA CS
Exercice COMEX/COPIL — Attaque par ransomware
Un support conçu pour permettre à une Direction, une DSI ou un RSSI d’organiser un exercice sur table sans avoir à construire entièrement son scénario.
Un scénario à adapter
L’exercice doit être adapté à l’organisation, à ses activités, à son architecture, à ses dépendances métiers et à ses propres procédures de gestion de crise.
Le principe à retenir
Une crise se prépare avant qu’elle commence
Une attaque par ransomware révèle rarement une seule faiblesse.
Elle révèle des dépendances, des responsabilités parfois mal définies, des procédures qui ne sont pas toujours accessibles, des modes dégradés insuffisamment testés et des informations que l’organisation pensait connaître jusqu’au moment où elle en a réellement besoin.
C’est précisément l’intérêt d’un exercice de crise.
Il permet d’apprendre sans subir l’incident réel.
La question à poser au débrief
Parmi les informations qui vous ont manqué aujourd’hui, lesquelles devriez-vous posséder avant la prochaine crise ?
La réponse constitue probablement l’un des meilleurs points de départ pour améliorer la résilience et la gouvernance du système d’information.