La plupart des opérations de restauration après une attaque par ransomware commencent de la même manière. Quelqu'un met en œuvre un plan de reprise après sinistre. Un autre contacte le fournisseur de solutions de sauvegarde. Puis ce plan, qui avait probablement été conçu pour faire face à des catastrophes naturelles ou à des suppressions accidentelles, se heurte à la réalité et s'effondre.

Les lacunes en matière de préparation à la reprise sont étonnamment et obstinément constantes d'une organisation à l'autre, même parmi celles qui ont massivement investi dans la détection et la défense. Cela révèle un problème structurel. Les organisations ont passé des décennies à mettre en place des programmes de sécurité et à affiner leur capacité à anticiper les menaces. Elles n'ont consacré qu'une infime partie de ce temps à la capacité de reprise, et les modèles d'IA de pointe tels que Mythos mettent en lumière pourquoi il s'agit là d'une erreur coûteuse.

Les barrières à l'entrée, déjà faibles pour les auteurs de ransomware, seront bientôt pratiquement inexistantes. Aujourd'hui, les pirates peuvent contourner pratiquement n'importe quel système de défense s'ils sont suffisamment motivés. D'ici un an, grâce à un modèle d'IA capable de détecter de manière autonome les vulnérabilités, ils n'auront peut-être même plus besoin d'être aussi motivés.

Le coût d'un plan de reprise non testé ne cesse d'augmenter. Si votre organisation envisage ces changements uniquement sous l'angle de la détection plus rapide des menaces, vous ne résolvez que la moitié du problème.

Les erreurs que les organisations ne cessent de commettre

Les défaillances décrites ci-dessous ne sont pas l'apanage des organisations dont les programmes de sécurité sont déficients. Elles se produisent également dans des entreprises dotées de systèmes de détection éprouvés, d'équipes compétentes et de budgets de sécurité importants. Le point commun est que les capacités de reprise ont fait l'objet d'investissements et de tests moins importants que les capacités de détection.

Le déficit de confiance en matière de sauvegarde

C'est l'échec le plus dangereux, car on a l'impression qu'il est résolu.

Vous disposez de sauvegardes. Les tâches sont terminées. Le tableau de bord affiche le vert. Vous indiquez au conseil d'administration que les sauvegardes sont en place. Vous avez coché la case et êtes passé à autre chose, sans doute il y a des années.

C'est alors que l'attaque se produit. Ces sauvegardes peuvent-elles résister à un adversaire qui a cartographié l'environnement, dispose d'identifiants privilégiés et s'en prend délibérément à l'infrastructure de sauvegarde ?

Dans la pratique, Fenix24 constate souvent que l'infrastructure de sauvegarde se trouve sur le même segment de réseau que l'environnement de production. Nous découvrons des référentiels dits « immuables » sur lesquels le compte de service dispose toujours de droits de suppression. Nous constatons également que des tâches de sauvegarde s'exécutent sans encombre depuis des années sans que personne ne vérifie jamais la restauration complète des données.

Les auteurs de ransomware ciblent les sauvegardes, car celles-ci permettent aux victimes de s'en sortir sans avoir à payer. Les modèles d'IA de pointe capables de cartographier les environnements de manière autonome rendront ce ciblage encore plus précis. Si un modèle est capable de détecter des vulnérabilités sur l'ensemble d'un système d'exploitation, il pourra repérer le serveur de sauvegarde que votre équipe a mis en place il y a trois ans et qui n'a jamais été déplacé.

Pour être fiables, les sauvegardes doivent répondre à trois critères : l'immuabilité (un pirate disposant d'identifiants d'administrateur ne doit pas pouvoir les modifier ni les supprimer), la segmentation (l'environnement de sauvegarde doit être inaccessible depuis le réseau compromis) et la restauration validée (une restauration complète doit avoir été testée, et non pas simplement confirmée comme une tâche terminée). De nombreuses entreprises remplissent l'un de ces trois critères. Elles sont bien moins nombreuses à les remplir tous les trois. Et celles qui y parviennent l'ont généralement fait parce qu'elles ont appris à leurs dépens ce qui se passe lorsqu'on ne le fait pas.

La fiction RTO

Votre RTO prévoit un délai de 48 heures. Il a été intégré à un plan, présenté au conseil d'administration et est désormais pris en compte dans la vision commune des risques au sein de l'organisation.

Très bien, mais… personne n’a encore évalué le temps nécessaire à une reprise complète dans un scénario où l’identité est compromise, l’accès aux sauvegardes est limité et l’équipe travaille avec des moyens de communication réduits. Un exercice sur table où tout le monde dispose de notes et où le SIEM fonctionne ne compte pas. Une fenêtre de maintenance planifiée pendant laquelle un système est restauré à partir d’une sauvegarde ne compte pas non plus.

Un test de reprise après sinistre réaliste part du principe que le pire est arrivé. Le système d'authentification est hors service. L'accès aux sauvegardes est limité. Les communications sont perturbées. La moitié de l'équipe prend des décisions après avoir passé une nuit blanche. Le RSSI est en safari sans son téléphone portable.

Nous constatons les conséquences d'objectifs de temps de reprise (RTO) non testés dans presque toutes nos missions. Les chiffres indiqués sur le papier et la réalité sur le terrain sont rarement proches. Lorsque ces deux éléments divergent, les conséquences s'accumulent : perte de chiffre d'affaires, perturbation des opérations, perte de clientèle, atteinte à la réputation et exposition à des risques réglementaires que l'organisation n'avait jamais pris en compte dans son évaluation des risques, car elle se fiait à un chiffre que personne n'avait testé.

Reconstitution de l'identité

Active Directory est presque toujours au cœur de l'attaque. Il devrait occuper une place tout aussi centrale dans le plan de reprise. Dans la pratique, on constate l'existence de plans mûrement élaborés et bien organisés pour la restauration des applications et des bases de données, mais un silence total dès que la conversation aborde la reprise d'Active Directory. Pas de sauvegardes hors ligne. Pas de procédure de reconstruction documentée. Pas d'estimation testée du temps de reconstruction. Pas de réponse claire quant aux contrôleurs de domaine qui sont intacts, aux comptes de service dignes de confiance, ni à la manière dont les accès privilégiés seront rétablis en toute sécurité.

Cela revêt une importance bien plus grande que ne le reconnaissent la plupart des plans de reprise. On ne peut se fier à aucun élément en aval tant que l'identité n'a pas été rétablie et vérifiée comme étant intacte. Applications, bases de données, terminaux, partages de fichiers, accès administrateur, comptes de service, intégrations cloud, workflows privilégiés : tout cela dépend, d'une manière ou d'une autre, de l'identité. Si l'identité est compromise, tout ce qui s'y authentifie l'est par ricochet.

Les organisations qui gèrent efficacement la restauration de l'identité s'y sont préparées. Elles disposent de sauvegardes hors ligne d'Active Directory. Elles ont mis en place un processus documenté et testé pour effectuer une restauration à partir d'un état vierge. Elles savent combien de temps cela prend, car elles l'ont mesuré. Les autres ne le découvrent que lors de la pire semaine de leur carrière.

Cécité face aux dépendances

Lorsque l'environnement tombe en panne, quelqu'un pose toujours la question qui détermine la vitesse de reprise : « Qu'est-ce qui revient en premier ? »

Dans trop d'entreprises, la réponse se trouve dans la tête d'un seul ingénieur. Parfois, elle n'existe tout simplement pas.

La reprise après sinistre n'est pas une simple liste de systèmes. C'est une séquence. Il est impossible de remettre en service un système ERP si la base de données dont il dépend est toujours hors service. Il est impossible de remettre des applications en ligne si l'infrastructure d'identité à laquelle elles se connectent n'a pas été rétablie. Il est impossible de restaurer les flux de travail critiques si le réseau, le stockage, le DNS, les secrets et les comptes de service qui les soutiennent font défaut ou ont été compromis.

Sans modèle de dépendances à jour, les équipes de reprise perdent un temps précieux à procéder à la restauration dans le mauvais ordre. Elles remettent les applications en service avant que l'infrastructure dont elles dépendent ne soit prête. Elles découvrent alors, en cours de reprise et sous pression, que des dépendances font défaut, alors que l'activité en pâtit. Une reprise qui devrait prendre quelques jours s'étire sur plusieurs semaines, car l'ordre des opérations était erroné dès le départ.

Dans la plupart des entreprises, les données relatives aux actifs sont dispersées dans des dizaines d'outils. Elles sont obsolètes. Elles se contredisent. La CMDB indique une chose, l'équipe réseau en dit une autre, et le responsable de l'application qui avait une vue d'ensemble a quitté l'entreprise il y a huit mois. En temps normal, cette fragmentation est gênante. En cas de reprise d'activité, elle est catastrophique.

Les organisations qui se remettent le plus rapidement ne résolvent pas ce problème pendant l'incident. Elles savent déjà comment s'y prendre. Les systèmes de niveau 0 sont identifiés. Les dépendances sont cartographiées à partir de données en temps réel, et non de schémas statiques. Les séquences de reprise sont générées à partir de relations réelles et testées avant d'être nécessaires. Tous les autres élaborent leur plan à partir de zéro, dans l'urgence et à l'aveuglette.

Le décalage entre temps de paix et temps de guerre

Les programmes de sécurité sont élaborés et documentés en temps de paix. En temps de paix, le système SIEM fonctionne. Le centre d'opérations de sécurité (SOC) est doté du personnel nécessaire. Le partenaire spécialisé en analyse informatique est joignable d'un simple coup de fil. Le personnel est reposé. Les moyens de communication sont opérationnels. Les décisions peuvent faire l'objet de discussions s'étalant sur plusieurs jours, voire plusieurs semaines.

En temps de guerre, c'est tout le contraire.

Les organisations qui gèrent efficacement les situations de guerre s'y sont généralement préparées en temps de paix. Elles ont mené des simulations visant à tester les opérations de rétablissement, la coordination, l'enchaînement des actions et la prise de décision dans des conditions difficiles. Elles ont ainsi identifié les points faibles.

Les organisations en difficulté pensaient que leur plan tiendrait la route une fois que tout serait en feu. Les calendriers d'attaque accélérés par l'IA ne feront qu'ajouter de l'huile sur le feu.

Résilience et reprise dans un monde de l'IA post-frontière

La plupart des hypothèses concernant la résilience et la capacité de reprise s'avèrent erronées lors d'une attaque réelle.

• Il s'avère que les « sauvegardes immuables » ne sont finalement pas si immuables que ça.
• Ce ne sont pas seulement les données qui sont détruites, mais aussi les infrastructures.
• Une cartographie insuffisante des actifs et des dépendances entraîne des jours, voire des semaines, d'indisponibilité.
• Les RTO et les RPO ne sont pas réalistes.

Les analystes ne mâchent pas leurs mots lorsqu'il s'agit de l'avenir de la résilience. Vous souhaitez disposer d'un plan d'action pour concevoir et mettre en œuvre une véritable cyber-résilience ? Téléchargez le nouveau rapport de validation technique d'Omdia, « Concevoir et mettre en œuvre la résilience avec Fenix24 ».

Qu'est-ce qui détermine si vous survivez ?

Trois facteurs distinguent les organisations qui se remettent rapidement de celles qui restent dans le flou pendant des semaines (ou qui ne s'en remettent jamais). Frontier AI ne modifie pas les mécanismes. Elle modifie la vitesse. Cela rend chaque facteur encore plus crucial, et non l'inverse.

La gestion des identités doit être la priorité absolue. C'est un point non négociable, et c'est l'étape que la plupart des organisations ont le moins mise en œuvre. Active Directory et l'infrastructure d'identité comptent parmi les premières cibles d'une attaque moderne par ransomware. Elles doivent également figurer parmi les premiers éléments à restaurer. On ne peut faire confiance à aucun élément en aval tant que l'identité n'a pas été rétablie et vérifiée comme étant intacte. Applications, bases de données, comptes de service, workflows privilégiés, intégrations cloud. Tous s'authentifient d'une manière ou d'une autre par rapport à l'identité. Les attaques accélérées par l'IA ne modifient pas cette chaîne de dépendance. Elles réduisent considérablement le temps dont vous disposez pour y répondre.

Les sauvegardes doivent résister à une attaque, et pas seulement à une panne matérielle. La plupart des entreprises disposent de sauvegardes. Mais la plupart ne disposent pas de sauvegardes capables de résister à un attaquant qui dispose d’identifiants valides, comprend votre environnement et sait exactement où se trouve l’infrastructure de sauvegarde. Une stratégie de sauvegarde conçue pour faire face à une panne matérielle ou à une suppression accidentelle n’est pas la même chose qu’une stratégie de sauvegarde conçue pour contrer un adversaire intelligent disposant d’un accès privilégié.

La reprise doit suivre la chaîne de dépendances réelle, et non celle supposée. Il est impossible de remettre en service un système ERP si la base de données dont il dépend est toujours hors service. Il est impossible de restaurer des flux de travail critiques si l'infrastructure qui les soutient fait défaut ou est compromise. La reprise est une séquence, et cette séquence doit être correcte. Dans la plupart des organisations, les dépendances non cartographiées constituent l'une des principales sources de retard dans les reprises. Une cartographie automatisée des dépendances, établie à partir de données télémétriques en temps réel et mise à jour au fur et à mesure que l'environnement évolue, fait toute la différence entre un plan de reprise qui reflète la réalité et un plan qui reflète la dernière mise à jour d'une feuille de calcul.

Ces trois facteurs étaient d'actualité il y a cinq ans. Ils le seront encore dans cinq ans. Ce que Mythos et les avancées en matière d'IA changent, c'est le coût d'une erreur. Lorsque la cadence des attaques dépasse la vitesse de réaction humaine, chaque lacune dans la capacité de rétablissement devient plus coûteuse et plus visible.

Indicateurs de reprise qu'il convient de communiquer

Si vos rapports au conseil d'administration traitent de la détection mais pas de la remédiation, c'est le moment idéal pour y remédier. Il s'agit d'indicateurs qu'un RSSI peut présenter avec la même rigueur que les indicateurs de détection, et qui changent la donne.

Durée de reprise testée. Il ne s'agit pas du RTO (délai de reprise des opérations) indiqué dans la documentation. Il s'agit de la durée réelle mesurée lors d'un exercice de reprise dans le cadre d'un scénario de violation réaliste. Indiquez le nombre de tests et la date du dernier test effectué.

Taux de survie des sauvegardes. Pourcentage des référentiels de sauvegarde qui répondent aux trois critères suivants : immuables, segmentés et validés par une restauration complète. Un indicateur unique que le conseil d'administration peut suivre au fil du temps.

Couverture des dépendances de niveau 0. Pourcentage d'applications critiques dont les chaînes de dépendances ont été entièrement cartographiées et les procédures de reprise documentées. Cet indicateur permet de déterminer dans quelle mesure la reprise est planifiée ou improvisée.

Durée de reconstruction de l'identité. Temps nécessaire pour reconstruire Active Directory à partir d'un état vierge. Si cette valeur n'a pas été testée, indiquez qu'elle n'a pas été testée.

Que faire au cours des 90 prochains jours ?

Vous n'avez pas besoin de régler d'un seul coup toutes les questions liées à la préparation à la reprise, mais la fenêtre d'opportunité est bien réelle. L'attention des dirigeants se porte actuellement sur les menaces liées à l'IA. Il n'y aura jamais de moment plus propice pour justifier des investissements dans la reprise que le trimestre prochain.

Vérifiez la résilience des sauvegardes. Testez leur capacité à résister à un attaquant qui s'attaquerait délibérément à elles. Testez leur immuabilité, leur segmentation et la possibilité d'une restauration complète. Si vous ne pouvez pas effectuer ces tests en interne en toute confiance, faites appel à une société spécialisée dans la récupération après une attaque par ransomware, dont c'est le métier.

Cartographiez les chaînes de dépendances qui régissent l'ordre des opérations de reprise. Identifiez les systèmes de niveau 0. Indiquez clairement quelles applications dépendent de quelle infrastructure. Définissez des séquences de reprise en vous basant sur des relations réelles, et non sur des hypothèses. Si votre environnement est suffisamment complexe, cela nécessite des outils capables de corréler les données de télémétrie en temps réel à l'échelle de votre infrastructure, et non un simple tableur manuel qui sera déjà obsolète avant même que vous n'ayez eu le temps de l'enregistrer.

Déterminez un temps de reprise validé. Menez un exercice de reprise en simulant le pire scénario possible : compromission des identités, sauvegardes ciblées, communications perturbées. Chronométrez l'opération. Identifiez les points où l'équipe rencontre des difficultés. Ce temps deviendra votre référence et le chiffre que vous présenterez à votre conseil d'administration.

Mettez en avant la reprise après incident parallèlement à la détection. Intégrez les indicateurs ci-dessus à votre prochaine mise à jour du tableau de bord. Présentez la détection et la reprise comme les deux facettes d’un même ensemble. Le contraste parlera sans doute de lui-même.

Les lacunes en matière de reprise après sinistre ne sont pas des risques statiques que l'on peut réexaminer quand bon nous semble. Ce sont des actifs qui perdent de leur valeur. Chaque trimestre qui passe rend l'environnement plus difficile à cerner, les interdépendances plus complexes, et la courbe des capacités de l'adversaire prend de plus en plus d'avance sur vos propres capacités de reprise.

Les RSSI ont mis des années à se faire une place à la table des décideurs en démontrant leur capacité à réduire les risques. La prochaine décennie sera marquée par la nécessité de prouver que l’on est capable de maintenir les opérations en cas de violation de sécurité. Cela implique des compétences différentes, des investissements différents et des échanges différents avec la direction. Les organisations qui comprendront cela rapidement s’en remettront. Celles qui ne le feront pas passeront des semaines à tirer des leçons qu’elles auraient pu apprendre en temps normal.

Commencez par réaliser une évaluation de la résilience

Vos sauvegardes résisteront-elles à un pirate déterminé ? L'évaluation de la résilience proposée par Fenix24 met votre environnement à l'épreuve avant qu'un incident ne le fasse à votre place.

L'évaluation de la résilience s'appuie sur Argos99, notre plateforme de résilience destinée aux entreprises, qui met en corrélation les données de télémétrie en temps réel de l'ensemble de votre infrastructure afin de cartographier chaque ressource, chaque dépendance et chaque lacune. Cela signifie que l'évaluation de la résilience de Fenix24 analyse la couverture des sauvegardes au niveau des applications, et pas seulement l'état des tâches. Elle identifie les dépendances entre les éléments et génère des séquences de reprise à partir de ces relations. Tout ce que nous évaluons s'appuie sur les enseignements tirés de centaines de cas réels de reprise après incident.

Oubliez les audits basés sur des listes de contrôle. Ils visent souvent à confirmer ce que vous pensez déjà savoir, et non la réalité. Prenez rendez-vous dès aujourd'hui pour une évaluation de votre résilience. Contactez-nous au 423.305.7890 ou par e-mail à l'adresse info@fenix24.com.