Ransomware : comment protéger ses sauvegardes et travailler sa résilience
La destruction des sauvegardes lors de cyberattaques de ransomware est une réelle menace. Mais ce n’est pas la seule. Quatre experts nous livrent leurs conseils pour préparer, en amont, la résilience de son organisation.
Le suivi de nombreuses négociations entre attaquants et victimes de ransomware nous a permis de pointer des exemples de destruction de sauvegarde. Habitués du terrain, plusieurs experts confirment la réalité de cette menace.
Cyrille Barthelemy, PDG d’Intrinsec, a indiqué avoir commencé à constater ce genre de destructions « à partir de 2019. Il y a probablement eu des précédents, mais c’est à cette période que nous avons commencé à le voir de plus en plus fréquemment ». Directeur cyberdéfense d’I-Tracing, Laurent Besset, estime toutefois « assez rare » de voir des attaquants « rechercher et attaquer volontairement des serveurs de sauvegarde ou des infrastructures de stockage ».
Et de se pencher spécifiquement sur le cas particulier de Veeam, que nous évoquions précédemment : « ce que l’on voit le plus souvent n’est pas une attaque délibérée du serveur Veeam, mais son chiffrement comme une machine lambda du domaine Active Directory compromis par l’attaquant ». Et c’est dû à une approche de déploiement : « d’un point de vue opérationnel, la solution de facilité est d’intégrer le serveur Veeam dans le domaine, notamment pour simplifier les droits d’accès sur les machines à sauvegarder. C’est ce choix qui revient en boomerang lorsque d’une attaque réussie sur le domaine ».
Isoler les sauvegardes
Dès lors, la première recommandation de Laurent Besset est « de limiter l’adhérence avec le domaine ». Et pour cela, « la manière la plus simple de le faire est de sortir purement et simplement le serveur Veeam du domaine et d’utiliser des comptes locaux ». Las, explique-t-il, « cela devient vite lourd sur de gros environnements ». Alors dans ces cas-là, « la solution se situera plutôt dans la mise en œuvre d’une forêt dédiée à l’administration ou/et l’exploitation, distincte de celle dans laquelle seront gérés les autres actifs Windows ».
Logique d’une approche en deux axes : limitation des risques de compromission latérale de la sauvegarde en cas de compromission de l’AD, et mise en place d’une architecture isolée.
Pauline Donon, consultante séniore chez Intrinsec, rappelle l’importance d’une architecture d’administration en trois tiers pour les comptes Active Directory (AD), même si « cela induit une charge importante en conception et exploitation ». Surtout, elle s’inscrit sur la même logique avec une approche en deux axes : limitation des risques de compromission latérale de la sauvegarde en cas de compromission de l’AD, et mise en place d’une architecture isolée.
Dans la pratique, pour le premier axe, on retrouve donc l’utilisation de comptes, pour le système de sauvegarde, étrangers à l’AD, et l’exclusion des infrastructures de sauvegarde de l’AD. Ce qui, d’ailleurs, peut être natif, selon « le suivant technologique » autour du système de sauvegarde.
Pour le second volet, Pauline Donon suggère un « VLAN dédié aux sauvegardes, filtré par pare-feu, avec ouverture de flux pour les synchronisations, éventuellement sur des plages horaires dédiées ». Et de souligner l’importance de disposer de « sauvegardes à froid, sur bandes ou en cloud », et « hors-ligne ou équivalent ».
Tester…
Dans cette logique, Benjamin Leroux, d’Advens, rappelle l’approche 3-2-1 de Veeam : trois copies des données au moins, sur deux types de supports différents, et l’une d’entre elles hors-site.
Si les architectures de sauvegarde et d’administration sont efficaces pour protéger les backups des attaquants et de leurs rançongiciels, encore faut-il qu’ils soient exploitables. Ainsi, Laurent Besset relève que « tout le monde s’accordera à dire que des sauvegardes régulières et fonctionnelles – dont la restauration a été testée positivement – restent la meilleure chance pour une entreprise victime d’une attaque par ransomware, de limiter la casse sans envisager de payer la rançon ».
Benjamin Laroux ne dira pas autre chose : « l’objectif principal est de s’assurer de l’intégrité des sauvegardes en gardant à l’esprit qu’il faudra peut-être repartir from scratch en cas d’attaque. Des sauvegardes hors lignes avec une rotation régulière et des coupures protocolaires permettent de repartir plus sereinement ».
Las, concède Laurent Besset, « nous voyons régulièrement, lors de nos prestations de réponse sur incident, des entreprises découvrant après le chiffrement qu’il leur manque certaines sauvegardes ou/et que celles-ci ne sont pas exploitables ».
… y compris dans des conditions très dures
« Il faut pouvoir reconstruire facilement son infrastructure à partir de rien. »
Benjamin LerouxDirecteur marketing, Advens
Mais attention à ne pas tester les restaurations dans n’importe quel contexte. Cyrille Barthelemy souligne un point clé : « s’intéresser à la sécurité de la continuité », en tenant compte du risque « d’atteinte aux systèmes de résilience ». Et pour cela, Pauline Donon explique qu’il convient de « tester les restaurations, pas juste unitairement », « mais y compris dans un cadre de test de crise cyber, prenant donc en compte l’indisponibilité de nombreux moyens considérés acquis dans un scénario d’indisponibilité ».
Benjamin Leroux s’inscrit dans la même logique, dépassant les traditionnels plans de continuité et de reprise de l’activité (PCA/PRA) : « il faut pouvoir reconstruire facilement son infrastructure à partir de rien, en disposant par exemple des scripts des administrateurs permettant de rejouer toutes les actions faites depuis la mise en place du SI, avec automatisation, images disques, licences, etc. ».
La résilience s’apparente donc à un important chantier, combinant sauvegardes pour restaurer lorsque c’est possible, et automatisation et documentation pour reconstruire lorsque c’est nécessaire – ou simplement préférable. De toute évidence, cela n’a donc rien de trivial. Mais cela peut faire une lourde différence lorsque survient la cyberattaque et que, malheureusement, les signaux faibles trahissant les activités manuelles des assaillants, préalables à la détonation du ransomware, n’ont pas été détectés.
