Cyberrésilience pour les ETI - Trois axes de travail à explorer pour se mettre sur le chemin : fluctuat nec mergitur
L’ESSENTIEL | Si vous n’avez que 3 minutes :
Les ETI sont dans la catégorie des principales cibles des attaques par ransomware, selon un rapport de l’ANSSI de 2023. Pour faire face à cette menace, une réponse doit être organisée en 3 volets :
D’abord, d’un point de vue technologique, mettre à l’abri les sauvegardes est une priorité absolue : sans elles, aucune reconstruction ne pourra avoir lieu, et l’organisation sera en péril grave. Or, celles-ci peuvent être rendues inaccessibles par l’attaquant, mais il existe des solutions. Une option tactique et un plan d’actions à moyen terme doivent être construits.
Ensuite, d’un point de vue des processus, l’indispensable est de recenser les 3 à 5 applications vitales pour la survie de l’organisation, celles sans lesquelles les clients ne peuvent être servis, les factures ne peuvent être émises, la production industrielle ne peut se poursuivre, les obligations légales ne peuvent être assurées, etc.
Enfin, d’un point de vue des compétences, réaliser des entraînements réguliers, à complexité et au réalisme croissant, est clé pour répéter les gammes et ainsi gagner un temps précieux durant une crise réelle. Commencer par l’aspect technique et donc par la restauration d’uneapplication, puis réitérer en introduisant plusieurs applications dans le périmètre de l’exercice. Ensuite, ajouter des tests fonctionnels en complément des tests techniques. Il s’agira enfin de compléter le dispositif interne, en initiant de premières discussions avec des prestataires de servicesIT, qui pourront être déclenchés en urgence en cas de crise.
34%. C’est la part de TPE / PME / ETI dans les victimes de ransomware selon l’ANSSI [1]. Ce type d’organisation est une cible de choix pour le chantage à la rançon de la part des attaquants, parce qu’elles sont souvent moins matures en matière de cybersécurité, moins préparées à réagir et moins protégées techniquement. Aborder la cyberrésilience de manière réaliste pour une ETI, c’est se préparer à résister à une indisponibilité quasi-totale de son système d’information pendant plusieurs semaines.
Ransomware : aussi appelé rançongiciel en français, logiciel malveillant déployé par un attaquant sur des serveurs ou des postes de travail, dans l’objectif de les bloquer (les fichiers sont chiffrés cryptographiquement et rendus inaccessibles) et d’exiger une rançon pour leur déblocage.
Plongeons au cœur de la crise. Les impacts directs et visibles d’une attaque par ransomware et les réponses organisationnelles qui devront y être apportées sont les suivants :
La majorité des postes de travail et/ou serveurs sont bloqués et indisponibles, avec perte potentiellement définitive des fichiers hébergés localement et des données métier, selon si les sauvegardes étaient en place et si elles ont été épargnées par les attaquants.
La plupart des processus métier sont fortement perturbés voire à l’arrêt (facturation, paiement, vente, contractualisation, prise de commande, logistique, livraison, fourniture de service, etc.) et des employés dans l’incapacité de travailler pendant quelques semaines, en raison de l’indisponibilité de l’IT.
Un mode de crise à déclencher : pour gérer et suivre le risque opérationnel et financier, l’impact d’image vis à vis des clients, les risques juridiques en jeu, etc.
Les premiers jours seront désagréables : le pilotage de crise sera encore en cours de mise en place avec beaucoup d’imperfections et de frustrations (difficulté à prendre des décisions, actions non mises en œuvre dans les temps, découverte tardive de points de blocages majeurs, etc.). La vision d’ensemble de la situation sera encore très incomplète, notamment d’un point de vue cyber où la compréhension de l’attaque sera encore à préciser.
Des arbitrages complexes seront à mener : accepter de consacrer du temps à renforcer et à protéger le SI avant de le redémarrer versus redémarrer plus rapidement les activités à l’identique. Comme souvent, la bonne décision est probablement nuancée : prendre des risques mesurés et éclairés mais avancer, pour la survie de l’organisation.
Cette situation possède une probabilité d’occurrence non négligeable. La logique veut donc qu’on en minimise la probabilité, en renforçant globalement la protection (chantier pluriannuel si l’on n’a jamais adressé le sujet cyber, votre notre publication sur le sujet), mais également, de manière tactique, en se préparant à une réaction rapide et efficace (e.g., formalisation de fiches réflexes) pour minimiser la durée de l’indisponibilité. S’agissant d’une transformation à mener, ce chantier doit être mené en mode projet (budget, planning, livrables, équipe projet, équipes contributrice, gouvernance et comitologie, etc.).
Renforcer la protection des sauvegardes : la priorité absolue
Parce que les données sera le cœur des préoccupations lors d’une attaque par ransomware, les mettre à l’abri, avec une véritable réflexion stratégique est primordial. Des sauvegardes régulières sont déjà réalisées ? En fonction de la manière dont elles sont techniquement mises en œuvre, celles-ci pourraient également être manquantes ou rendues indisponibles, au même titre que le reste du SI.
Une bonne stratégie de sauvegarde doit :
être alignée avec la criticité et les RTO / RPO [2] des applications ;
prévoir la durée de rétention type, en fonction des applications ;
prévoir des tests réguliers de restauration, pour valider la bonne fiabilité des sauvegardes ;
si elle prévoit une externalisation via un tiers, prévoir des clauses de sécurité, de territorialité et de confidentialité forte via le contrat.
D’un point de vue technique, une infrastructure de sauvegarde pouvant résister de manière réaliste au déploiement d’un ransomware doit :
être isolée d’un point de vue physique (e.g. hyperviseur et stockage) et d’un point de vue logique du reste du SI (e.g. adhérence avec l’Active Directory (AD), connexion via un réseau mutualisé) ;
être protégée de l’effacement de données (les sauvegardes ne doivent pas pouvoir être supprimées, elles doivent être immuables).
Très souvent, une infrastructure de sauvegarde construite il y a quelques années, sans prendre en compte la menace cyber actuelle, ne répond probablement à aucun de ces 2 critères. Par ailleurs, la standardisation et les normes d’urbanisation du SI ont aussi eu comme conséquence de créer une adhérence entre l’infrastructure de sauvegarde et l’AD (i.e. l’infrastructure est membre du domaine). Or, l’AD est quasiment toujours le vecteur de propagation utilisé par les attaquants, mettant en risque, de fait, les sauvegardes. Tout ceci expose donc l’organisation : elle pourrait constater, au pire moment, que la solution de couverture de risque d’indisponibilité qu’elle a mise en place (la solution de sauvegarde), est en fait indisponible elle aussi.
Les sauvegardes sur bandes, que l’on a vu disparaître progressivement ces dernières années, avaient l’avantage, par essence, d’être déconnectées du SI, donc non atteignables par une cyberattaque ou couvraient donc nativement le risque. Mais avec la modernisation de ces solutions de sauvegarde et l’augmentation très forte du volume de données à sauvegarder, elles ont eu tendance à perdre cet avantage, se limitant à couvrir seulement l’indisponibilité au sens IT (scénario de perte d’un datacenter pour cause d’incendie par exemple, couvert via la réplication en temps réel sur le second datacenter).
Finalement, pour couvrir ce nouveau risque, trois réponses techniques peuvent être apportées, selon l’application :
Cas des applications « simples », où un réimport des données est possible après une réinstallation rapide même de zéro. Exemple de mesure : ajouter une extraction régulière des données et sauvegarder celle-ci sur une plateforme et via un mécanisme différent de la sauvegarde classique.
Cas des applications « à (re)déploiement fréquent », où grâce au paradigme moderne du CI/CD, ces applications développées en interne reposant beaucoup sur l’automatisation sont déjà (re)déployées plusieurs fois par mois. Exemple de mesure : sauvegarder le dépôt hébergeant le code et les scripts de déploiement ainsi que les bases de données.
Cas des applications « complexes », où les données ne sont pas simples à exporter / importer, sauf via des outils spécialisés de l’éditeur ou de tiers, ou reposant sur plusieurs serveurs en interaction. Exemple de mesure : externaliser fréquemment la sauvegarde classique des VM sur une plateforme tierce et décorrélée en tout point.
Lorsque cela est possible et pertinent, faire une extraction de certaines données critiques, même sous forme d’un fichier manipulable avec une suite bureautique, peut s’avérer très utile. Par exemple, fournir un fichier des données clients au service client permettra d’assurer un niveau de réponse plus complet et plus contextualisé aux clients probablement inquiets ou sans visibilité, renvoyant une image rassurante et sereine, malgré la perturbation des services due à la cyberattaque.
Connaître les 3 à 5 applications à redémarrer rapidement
En fonction de son contexte (secteur d’activité, type d’organisation, types d’application hébergées localement versus celles en SaaS), chaque ETI doit déterminer à l’avance, à l’aide de sa Direction, quelles sont les quelques applications à restaurer rapidement. Au démarrage de la crise, cela aura l’avantage de :
diriger et d’aligner les efforts de toutes les équipes, lors de la phase de reconstruction, gommant ainsi les longs moments de tergiversation souvent observés lors des premiers jours de crise ;
donner un cadre, des priorités claires, des objectifs qui peuvent être suivis de manière rapprochée, en ayant la certitude d’aller dans la bonne direction, puisque cela aura été réfléchi en amont, en dehors de toute pression ou urgence.
Notre expérience montre que, souvent, même en-dehors de toute situation de crise, la supposée impossibilité de mener cet exercice de priorisation est opposée à l’équipe projet. Cet exercice serait trop complexe, trop fastidieux, trop théorique, trop dépendant des impacts de la crise : « Tout dépend de la crise, on ne peut pas savoir à l’avance ce qui va être touché, et prévoir tous les cas ».
Pourtant, cela sera un passage obligé de la résolution de la crise, et il est donc intéressant d’être préparé en amont. Cela permettra d’avoir une meilleure compréhension et maîtrise de l’écosystème applicatif de l’organisation, une meilleure vision des criticités des applications, et finalement un meilleur alignement entre IT et métier. L’illustration ci-dessus démontre bien qu’établir une liste exhaustive est la meilleure approche, puisqu’elle sera utile et pertinente quel que soit les impacts de la crise.
Une application qui vient fréquemment à l’esprit comme une application critique est celle permettant le versement des salaires. En effet, la régularité des versements des salaires est encadrée par la loi, et pourra, en cas de retard important, venir perturber les esprits et ajouter une crise à la crise. Pourtant, cette application n’est probablement pas si importante que cela, si l’on suit une approche pragmatique. En effet, il suffit de communiquer aux collaborateurs et collaboratrices de l’organisation qu’ils recevront le même montant de salaire que le mois précédent, et qu’une régularisation interviendra le mois suivant, et l’on simplifie grandement le traitement du cas de cette application
Et c’est bien cette façon de réfléchir qu’il faut suivre pour chaque application. Autre exemple : est-il possible, d’éditer des factures « manuellement », avec un simple extrait des commandes dans un fichier ? Cela sera beaucoup moins efficace qu’à l’accoutumé, c’est évident. Mais l’efficacité est une préoccupation de temps calmes. Lors d’une crise, parvenir à envoyer des factures est déjà une victoire !
Les questions à se poser lors de la constitution de cette liste :
Parmi les applications hébergées localement (à la différence de celles en SaaS qui seront probablement épargnées par ce type d’attaque, ou celle redéployables grâce au CI/CD), lesquelles sont réellement critiques ? Lesquelles mettraient réellement la survie de l’organisation en jeu ? Quels sont les processus métier vitaux : l’acquisition de client, la facturation client, les commandes fournisseurs, etc. ?
Comment pourrait-on parvenir à 80% du résultat, avec 20% d’IT disponible seulement ? Exemple : La gestion optimisée (au plus juste) des stocks / des fournisseurs est-elle critique pour la survie de l’organisation ? Ne peut-on pas retransmettre la même commande fournisseur que le mois-précédent, avec un peu de marge de sécurité ?
Quelles sont les applications qui soutiennent un processus métier mais qui ne permettent pas le fonctionnement « Sans IT » (voir définition ci-dessous), et pour lesquelles, la restauration sera donc décisive ?
La société est-elle cotée et a-t-elle des obligations règlementaires de publications de ses résultats dans des délais fixées ? Si oui, l’application financière peut, à certains moments de l’année, être l’une des plus prioritaires.
Une fois que cette liste est établie, plusieurs actions doivent être menées. D’abord, réfléchir à un processus « Sans IT » (un processus pouvant fonctionner temporairement, même de manière dégradée, avec un simple extrait des données de l’application) pour les applications qui le permettent. Et, pour celles-ci, existe-t-il des prérequis (rédaction d’un mode opératoire simplifié, sensibilisation, etc.) à ce mode de fonctionnement ?
Faire un test grandeur nature pour se mettre dans les conditions réelles
Progressivement, se dessine l’image de ce à quoi la crise pourrait ressembler, et l’idée d’une préparation pour éclaircir certains points d’ombre émerge. Cette préparation doit se faire étape par étape. D’abord pour ne pas décourager les équipes devant l’ampleur de l’exercice. Ensuite, pour ne pas générer de négativité devant le nombre important d’actions correctives qui seront identifiées lors du bilan de l’exercice.
Par exemple, une approche avec les 3 paliers de maturité suivants, à dérouler par exemple en 18 mois :
Niveau 1 : faire un test technique unitaire de restauration et de redémarrage d’une des applications de la liste des applications critiques. Bénéfice attendu : identifier la complexité de l’opération et les problèmes techniques rencontrés pour chaque application critique.
Niveau 2 : faire un test fonctionnel, avec quelques personnes du métier utilisant ces applications critiques, pour vérifier que les opérations critiques peuvent être réalisées avec les mesures « Sans SI » définies. Bénéfice attendu : sensibiliser et former les populations métier, et ajuster au mieux le processus pour chaque application critique.
Niveau 3 : réaliser un test technico-fonctionnel complet, des 5 applications les plus critiques, voire en s’intégrant à un exercice de crise cyber plus global (comprenant les volets gestion de la communication, des aspects juridiques, du pilotage technique, des investigations et de la remédiation cyber, etc.). Bénéfice attendu : identifier les interdépendances entre les applications, répéter des processus déjà testés une première fois.
Pour finir, c’est dans cette phase qu’il conviendra également d’entamer les discussions avec les prestataires informatiques (habituels ou nouveaux), pour connaître les modalités de mobilisation de ressources en cas de crise cyber. En effet, durant quelques semaines, des ingénieurs et techniciens (expertises attendues : système, réseau, stockage, sauvegarde, cyber, etc.) seront nécessaires pour mener les actions, et leur nombre influera directement sur le délai de remise en route des systèmes.
En définitive, l’ensemble des travaux menés par l’équipe projet sur ces 3 volets nourrissent une première version sérieuse de stratégie de cyberrésilience. Pour que ce document d’importance majeure pour l’entreprise soit pertinent et qu’il se traduise en actions et transformations au sein de l’organisation, il doit être formalisé sous le sponsorship de la Direction Générale. Doivent y contribuer les équipes IT au sens large, notamment sauvegarde, système, application, les équipes métier pour que les bonnes priorisations soient effectuées et les équipes cyber, dans leur rôle d’éclairage sur la menace, les risques et l’adéquation des contre-mesures.
Ces chantiers, dépendamment de la taille de l’organisation pourraient prendre entre 12 et 18 mois. La bonne avancée et la mise en application de l’ensemble des chantiers identifiés dans cette stratégie doivent être suivies et revues dans le temps par la Direction Générale, puisque la bonne préparation et la réaction adaptée de l’ensemble de l’organisation pourrait être déterminante pour sa survie.
[1] https://www.cert.ssi.gouv.fr/uploads/CERTFR-2024-CTI-001.pdf
[2] RTO (Recovery Time Objective) & RPO (Recovery Point Objective)