Fin juin 2017, une image avait marqué les esprits du monde de la cyber sécurité et de la continuité d’activité. Un open-space, rempli de postes de travail, tous affichant le même écran : le message de demande de rançon de NotPetya. Encore aujourd’hui, 90% des crises gérées par le CERT Wavestone sont causées par des rançongiciels [1]. Comment faire alors pour commencer les investigations, la reconstruction ou permettre au métier de continuer de travailler si aucun poste de travail ne fonctionne ? Quelle stratégie développer pour intégrer la composante poste de travail aux plans de continuité, qui l’adressaient majoritairement jusqu’alors sous l’angle du sinistre bâtimentaire ? 

Définir les besoins 

Pour commencer, il est important de définir le scénario cyber duquel on veut se protéger. Est-ce un scénario « Total blackout » où l’ensemble du SI est indisponible ? Ou un scénario ransomware Windows basique où une partie des serveurs Windows ainsi que les postes sont compromis, mais les équipements réseaux et les briques Linux fonctionnent toujours ?  

Ensuite et sur base des scénarios retenus, il est nécessaire de segmenter les populations en fonction de leur besoin : il n’est pas possible de fournir un nombre infini de postes en une période donnée, et il faut savoir à qui attribuer les premiers postes qui seront mis à disposition. Par exemple, on peut distinguer les équipes métier vitales de l’entreprise, dont l’activité ne peut être interrompue plus de 4 heures, et les activités métier moins critiques, pour lesquels l’activité peut être interrompu pendant 3 jours avec des impacts acceptables pour l’entreprise en mode de crise. De la même manière, les équipes IT et Cyber à mobiliser dans les toutes premières heures de la crise pour conduire les investigations et lancer la reconstruction doivent être identifiés.  

Autre point à prendre en compte, les fonctionnalités métier minimales pour que le poste reconstruit soit utile. Certaines populations métier utilisent des clients lourds sur leurs postes, dont l’installation et la maintenance se révèle complexe. De même, certains métiers ont besoin d’interagir avec des tiers pour leurs activités vitales, via des VPN dédiés ou un whitelist IP. Cadrer précisément combien de personnes ont ces besoins et à quelle échéance est donc essentiel pour définir les solutions techniques envisageables.  

On ne proposera aussi pas forcément la même solution aux équipes IT d’investigation et de reconstruction – qui ont besoin d’avoir accès au réseau interne – qu’aux équipes métier qui peuvent pour les quelques premiers jours de crise avoir des modes dégradés hors du système d’information (SI) de l’entreprise. 

Au final, on aura tendance à distinguer deux phases bien différenciées dans la stratégie de fourniture de poste de travail en cas de crise ransomware : 

• Une première phase lors des tous premiers jours de crise pour une population limitée, qui s’appuiera en général sur des solutions ayant le moins d’adhérence possible avec le Système d’Information nominal, afin d’assurer les activités métier critiques ; 
• Une seconde phase lorsque les investigations auront avancé, avec une reconstruction de poste massive en utilisant le master de l’entreprise, qui aura pu être durci au préalable en tirant les leçons des investigations passées.  

Adapter la solution à son contexte  

Plusieurs paramètres sont à prendre en considération lorsqu’on planifie sa stratégie de reconstruction de postes. En effet, une solution pourrait fonctionner pour une entreprise, mais être inadaptée pour une autre.  

Par exemple, de nombreuses mesures de sécurité et de contrôle d’accès ont été mis en place ces dernières années concernant l’accès au réseau interne des postes de travail. Le NAC (Network Access Control) est de plus en plus répandu et dans les bâtiments récents, les prises Ethernet accessibles à chaque bureau tendent à disparaître. Les accès Office 365 sont restreints via du conditional access et l’authentification aux passerelles VPN (Virtual Private Network) se fait par certificat sur le poste. Lorsque toutes ces contraintes existent, une stratégie pour les premiers jours de crise basée sur le BYOD (Bring Your Own Device) ne peut être la réponse – en tout cas pas seule.  

Également, la façon dont sont gérés les postes est déterminante et ne permet pas forcément d’envisager les mêmes solutions techniques de reconstruction. On retrouve en général deux principales approches :  

• D’une part une approche dite « historique » avec des solutions de gestion de flotte s’appuyant sur une architecture classique type Microsoft System Center Configuration Manager (SCCM), qui est aujourd’hui la solution la plus répandue.  

• D’autre part une approche plus « moderne » (i.e Modern Management) avec des solutions Cloud de gestion de flotte type Microsoft Intune, qui monte en puissance ces dernières années. 

La méthodologie de reconstruction est également à anticiper. Deux méthodes sont envisageables : la restauration et la réinstallation. La restauration représente un retour à un état antérieur de l’environnement (OS et/ou applications et/ou données) grâce à une sauvegarde. La réinstallation, signifie comme son nom l’indique qu’on reconstruit de zéro le poste, en perdant les documents locaux.  

Dans le cas des postes de travail, le nombre de documents conservés en local tend à diminuer. En effet, la plupart des documents sont à présent stockés dans des serveurs de fichiers (NAS ou Sharepoint) pour le travail en commun, ou au sein du OneDrive personnel de l’utilisateur. Ainsi, on aura tendance à privilégier la réinstallation de zéro des postes, plutôt que de prendre le risque de restaurer le système à un état antérieur, où le ransomware était peut-être déjà présent mais non encore activé. D’autant que les ransomware récents s’attaquent aux points de restauration locaux [2].   

Choisir les méthodes de reconstruction les plus adaptées à sa stratégie 

Plusieurs méthodes de mise à disposition de poste de travail peuvent être envisagées en fonction de l’état des lieux et de la formalisation des besoins dont nous avons parlé plus haut. Voici une liste des principales solutions que nous avons rencontrées sur le terrain, et notre avis sur les avantages et inconvénients de chaque solution.  

• La constitution d’un stock de PC de crise 

Méthode souvent appliquée dans les plans de secours classiques (répondant au scénario perte de bâtiment / de site), des PC de crise sont placés dans des caissons type Ergotron, prêt à être utilisés en cas de sinistre. Ils sont connectés au réseau local via l’Ergotron, et reçoivent donc automatiquement les mises à jour. Une stratégie peut également être de se baser sur le stock de roulement des postes dans les services IT, ou de conserver des postes décommissionnés pour constituer un stock de secours. 

Notre avis : Si cette approche répond bien aux scénarios de résilience type perte d’un bâtiment / d’un site, elle présente un risque face au ransomware car ces PC seraient compromis au même titre que les autres puisqu’accessibles et visibles sur le réseau local. Il faudrait alors avoir une gestion de ces postes « hors ligne », nécessitant une charge de MCO (Maintien en condition opérationnelle) plus forte puisqu’il faudrait manuellement allumer les PC et les mettre à jour régulièrement. De plus, avoir du matériel dormant non utilisé pose la question de l’optimisation des ressources et de l’empreinte carbone. Cette solution est à considérer pour une population restreinte ayant un temps d’interruption acceptable très faible. Par ailleurs, pour les populations utilisant des clients lourds, il est possible de gagner du temps en les préinstallant sur ces postes dormants.  

• L’utilisation de PC non managés, via le BYOD (Bring Your Own Device) ou l’utilisation de « PC grand public » acheté en cas de crise 

Cette stratégie est en général associée à un scénario « Total IT Blackout » où l’on considère que l’ensemble du système d’information est compromis et qu’il faut travailler sans lien avec celui-ci. On utilise alors des postes non managés soit personnels soit mobilisables en cas de crise via un contrat avec un fournisseur.    

Notre avis : les fonctionnalités de cette solution sont limitées car le poste n’a pas d’accès au VPN de l’entreprise, et si du NAC est déployé, en se rendant sur site le PC n’aura pas non plus accès aux ressources internes encore fonctionnelles. Elle peut cependant être considérée en la couplant avec des mesures de crises qui auront été prévues en amont et permettront d’améliorer les fonctionnalités du poste (coupure d’urgence du NAC ; modification temporaire du Conditional Access O365 avec ouverture sur internet ; stockage de données critiques métier dans un Vault de crise hors du SI pour continuer de travailler). Dans la plupart des cas, cette solution sera surtout réservée aux populations métier, et éventuellement aux populations IT en charge de la reconstruction – en la couplant avec une stratégie de retour sur site et une levée du NAC, permettant l’accès au réseau interne en physique. Cela reste une solution qui peut être très efficace lorsque bien anticipée avec la combinant avec les mesures de crise citées plus haut.  

• L’existence nominale de postes sous un autre OS 

En cas d’attaque visant les environnements Windows spécifiquement (les plus couramment rencontrés sur le terrain), les ordinateurs impactés peuvent être remplacés par la solution fonctionnant sur un autre OS.  

Notre avis : cette solution implique un MCO (Maintien en Conditions Opérationnelles) d’au moins deux technologies, et elle ne garantit pas que les utilisateurs travaillants habituellement sous Windows pourront travailler sous Linux ou MacOS (clients lourds non compatibles, etc.). Cependant, c’est une solution tout à fait envisageable pour des populations très précises, comme les équipes d’investigation. Ces équipes préfèrent en général utiliser des distributions spécifiques comme Kali Linux, et ce sont les personnes qui doivent avoir accès au SI dans les premières heures de la crise. 

• La remasterisation des postes de travail sur banc  

En cas de crise, les équipes se rendent dans les différents sites possédant des bancs de masterisation avec leur PC compromis pour être remasterisé. Même dans les entreprises les plus conséquentes, les bancs de remasterisation de run ont une capacité de reconstruction limitée (quelques centaines de postes/jour maximum par site). Pour augmenter cette capacité, des bancs de remasterisation supplémentaires de crise peuvent également être prévus dans le cadre d’un contrat avec un fournisseur externe.  

Notre avis : la méthode de remasterisation en mode nominal sur banc demande une bonne préparation en amont pour être efficace en cas de crise au vu du volume de poste à reconstruire. Il convient d’avoir préparé un plan pour organiser le retour sur site de nombreuses personnes en parallèle (répartition par site, communication aux utilisateurs sur les créneaux de passage, etc.) en fonction de la capacité de remasterisation des bancs par site physique.  

• La remasterisation des postes de travail via clés USB  

En cas de crise, des clés USB préparée en amont (ou à générer pendant la crise avec une procédure prédéfinie) avec une image de Windows sont utilisées pour réinstaller un OS neuf sur la machine. Cela peut être un OS Windows vierge, ou une image propre à l’entreprise.  

Notre avis : méthode éprouvée sur le terrain en cas de crise qui peut permettre de gagner beaucoup de temps si elle est anticipée. Il faut disposer d’un nombre suffisant de clés USB, avec une image de Windows récente, et une méthode pour cloner rapidement les clés. Il convient également de définir un moyen de distribuer ces clés aux utilisateurs (soit en amont de la crise mais cela complexifie la mise à jour des clés et il existe risque de perte des clés – ou alors pendant la crise en se rendant en kiosque IT, comme pour les bancs). Aussi, il est nécessaire de pouvoir booter sur un média externe. Si cette fonctionnalité est bloquée dans le BIOS, cette méthode ne peut fonctionner, ou en tout cas pas sans une procédure de levée de cette restriction. Cette méthode peut se combiner avec les bancs pour maximiser le nombre de poste à remasteriser en parallèle sur site (une partie des PC passent sur les bancs, l’autre partie lancent le process via clé USB). De même, en cas de compromission du bootstrap du poste, une clef USB avec un Windows vierge peut se combiner avec une remasterisation Intune dans un second temps.  

• L’utilisation de VDI de crise (Virtual Desktop Infrastructure)  

Des utilisateurs se connectent à un bureau virtuel à distance, via un navigateur. Cette solution doit nécessairement se combiner avec une autre (BYOD, PC grand public acheté pour l’occasion, ou autre) car il est nécessaire d’avoir un PC pour se connecter à la VDI distante. Les VDI peuvent présenter des fonctionnalités plus ou moins avancées en fonction de leur lien avec le SI de l’entreprise (accès au réseau interne, pré-installation de client lourd, etc.) 

Notre avis : Ce système permet d’avoir des environnements de travail rapidement opérationnels, en limitant le risque de fuite de données puisqu’il est possible d’interdire le copier/coller des VDI vers le poste hôte. Par ailleurs, en s’appuyant sur des VDI dans le Cloud, il est possible d’avoir un fort potentiel de scale-up (passer de 1 VDI à 200 VDI actives très rapidement en cas de crise). Le principal risque reste que plus l’infrastructure VDI est corrélée au SI de l’entreprise, plus la probabilité qu’elle soit elle aussi compromise par l’attaque est grande. Et dans ce cas, se reposer uniquement sur cette solution est un pari risqué. A l’inverse, une VDI complètement décorrélée du SI fonctionnera, mais présentera des fonctionnalités limitées sans aucun accès aux briques non compromises du SI de l’entreprise.  

• La re-masterisation depuis le Cloud via Intune 

Le master déployé sur les postes de travail est externalisé dans Intune, un service SaaS hébergé dans le cloud Microsoft. Au démarrage ou après un reset d’usine, le poste de travail demande à l’utilisateur de renseigner son email Microsoft et identifie ainsi son appartenance à l’entreprise, ce qui déclenche le téléchargement et l’installation automatique du master, sans autre intervention nécessaire. Avec un prérequis de taille, puisqu’il faut que sa flotte soit gérée nativement via Intune pour pouvoir utiliser ces méthodes.  

Notre avis :  Cette méthode est parmi les plus efficaces, notamment car il est possible de modifier l’image (en cas de compromission passant par un protocole vulnérable / un défaut de patching), puis lancer à distance et depuis Intune une remasterisation massive des postes de travail compromis. Il est également possible de réaliser cette remasterisation en self-service du côté de l’utilisateur, mais un prérequis existera alors : posséder la clé de récupération BitLocker (ou autre technologie de chiffrement le cas échéant) du poste, si le disque dur du poste est chiffré dans le cadre des mesures de protection du poste déployé par l’entreprise. Pour des raisons de praticité le jour de la crise, la remasterisation de masse lancée depuis la console Intune est donc à privilégier, ce qui permet de s’affranchir de la contrainte BitLocker. Encore faut-il garantir l’accès à Intune par les administrateurs pour pouvoir le faire – et considérer qu’Intune lui-même ne serait pas compromis. Enfin, même si cela est peu commun, si le ransomware détruit le bootstrap du poste, il ne sera pas possible de le remasteriser avec Intune seul et il faudra alors ajouter l’installation d’un Windows vierge sur le poste en prérequis (via une clef USB par exemple).  

A noter qu’il existe également quelques cas exceptionnels de crise dans lesquels, du fait de moyens d’intervention et de gestion limités, certaines organisations peuvent choisir d’autoriser les collaborateurs à travailler en mode dégradé sur des machines compromises pendant une durée déterminée si elles sont encore opérationnelles. Cela peut être notamment le cas lorsque seuls les fichiers bureautiques ont été chiffrés, que le malware est passif et ne communique pas avec un Command and Control, et en supprimant l’accès à internet des postes pour éviter toute prise de contrôle à distance.  

En synthèse, quels facteurs de réussite pour une stratégie de résilience de l’environnement bureautique ? 

Il n’existe pas de solution « magique » adaptée à tous les cas de figure, chaque solution répond bien au besoin de retrouver un poste de travail opérationnel mais le choix de la meilleure solution dépend de plusieurs paramètres propres à chaque organisation. Aussi afin de s’assurer une stratégie efficace, il est important de :  

• Segmenter les différentes populations de l’entreprise afin de définir la priorisation de mise à disposition des postes, et de proposer des solutions adaptées aux besoins spécifiques de chacune.  
• Diversifier et adapter les solutions retenues. Tout miser sur une solution peut s’avérer dangereux si celle-ci venait à se révéler défaillante. Le but est bien d’avoir une boîte à outil de solutions techniques, que la cellule de crise pourra choisir d’activer ou non en fonction de la nature exacte de la crise rencontrée.  
• Tester les solutions : quelles que soient les solutions et les stratégies mises en œuvre pour la reconstruction de postes, elles doivent systématiquement s’accompagner de la planification de tests. Une solution qui n’est pas utilisée régulièrement est une solution qui risque de ne pas fonctionner en cas de crise. Il faut donc lorsque cela est possible utiliser la solution de secours en day to day pour remasteriser des PC, ou si on parle de VDI, que ces VDI soient utilisées régulièrement. Si cela n’est pas possible, il faut intégrer la solution dans un plan de test de continuité métier et/ou IT, afin de la tester en condition réelle a minima une fois par an.   

Les solutions les plus utilisées sur le terrain comprennent les remasterisation de masse sur banc, la constitution d’un stock de poste de travail de crise, l’utilisation des solutions Cloud type Intune et de bureau virtuel type VDI couplé au BYOD. Mais ces solutions prises une à une ne peuvent suffire, car comme indiqué sur le principe de diversification, mettre tous ses œufs dans le même panier peut poser problème. On pourrait par exemple imaginer une crise où l’accès à la console Intune est impossible et/ou l’image Intune elle-même a été altérée par l’attaque. Dans ce cas, avoir une solution de repli type VDI externe ou remasterisation par clef USB est indispensable.  

[1] https://fr.wavestone.com/fr/insight/cyberattaques-en-france-le-ransomware-menace-numero-1/  

[2] https://attack.mitre.org/techniques/T1490/  

Cet article Cyber Résilience : comment anticiper la reconstruction de l’environnement bureautique est apparu en premier sur RiskInsight.

La réflexion sur la bonne manière de traiter ce sujet dans les organisations se trouve à la croisée des projets de renforcement de la sécurité de l’AD et des projets de cyber-résilience.

Infrastructure et agent de sauvegarde : un point faible voire un vecteur de compromission

Nos différents états des lieux réalisés ces derniers mois nous le montrent : les stratégies de sauvegarde n’ont pas toujours évolué vers l’état de l’art.

Premier problème : les infrastructures de sauvegarde ne sont pas résilientes au risque cyber par défaut. L’authentification sur ces infrastructures de sauvegardes est par exemple très souvent liée à l’Active Directory lui-même. Par rebond, le système de sauvegarde pourrait être compromis par l’attaquant, induisant une potentielle destruction des sauvegardes… y compris celles de l’Active Directory !

Et les sauvegardes sont une cible de choix pour les attaquants. Dans plus de 20% des incidents gérés par le CERT Wavestone en 2021, les sauvegardes étaient impactées. Il convient donc d’intégrer le scénario cyber – et tout particulièrement le scénario rançongiciel – lorsque l’on pense à la résilience des sauvegardes.

Deuxième problème : les sauvegardes des Domain Controllers (DC) sont hébergées dans l’outil de sauvegarde, qui a souvent un niveau de sécurité plus faible que celui d’Active Directory. En effet, une organisation ayant déjà mené des travaux de sécurisation d’AD aura potentiellement fortement renforcé son tier 0 (l’on revient toujours au tiering !) : mise en place de postes dédiés pour l’administration, authentification multi-facteurs, filtrage réseau, matériel dédié, limitation du nombre de comptes à privilèges, etc. Cela ne sera hélas pas forcément le cas pour l’infrastructure de sauvegarde. Ces sauvegardes n’étant pas nécessairement chiffrées, un attaquant pourrait la récupérer et l’exfiltrer d’un DC en passant par l’infrastructure de sauvegarde, plus facile à compromettre. Une fois la sauvegarde exfiltrée, l’attaquant sera en mesure d’étendre encore son périmètre de compromission via une attaque de type pass the hash, après récupération des condensats ou encore une attaque par force brute, après extraction des secrets de la base ntds.dit pour récupérer des mots de passe en clair à rejouer sur des services dont l’authentification ne se base pas sur Active Directory.

Troisième problème : les méthodes traditionnelles de sauvegarde reposent sur des agents installés sur les Domain Controllers, dont les hauts privilèges servent parfois de vecteurs de compromissions. Les agents de sauvegarde nécessitent pratiquement toujours des droits d’administration sur l’actif sauvegardé, ce qui expose mécaniquement le Domain Controllers et donc les domaines Active Directory. L’on arrive donc à la situation paradoxale où la mesure de réduction de risque d’indisponibilité (installation d’un agent de sauvegarde sur un DC) devient elle-même la vulnérabilité à l’origine d’un risque pouvant devenir critique (indisponibilité de l’ensemble du système d’informations).

Sauvegarde sur média déconnecté, immuable ou dans le cloud : de multiples stratégies pour de multiples cas de figure

Pour résoudre ces deux problèmes, de multiples solutions existent et leur combinaison permet de construire une stratégie robuste. Cette stratégie doit prendre en compte le contexte de l’organisation ainsi que sa maturité en matière de cybersécurité.

Pour pallier le premier problème induit par l’agent vulnérable deux approches existent, toutes les deux viables :

1. Diminuer la probabilité d’exploitation de la vulnérabilité induite par l’agent de sauvegarde. Cela passe, au-delà des classiques sujets de maintien en condition de sécurité (mise à jour régulière, correction rapide de vulnérabilités de l’agent, etc.), par l’intégration d’un outil de sauvegarde dédié dans le tier 0, dont le niveau de sécurité aura été renforcé.
2. Se débarrasser de l’agent de sauvegarde. Comment ? En utilisant la fonction de sauvegarde native de Windows (Windows Backup), qui permet de réaliser et d’exporter une sauvegarde, que l’on pourra chiffrer et sortir du tier 0, vers un actif du tier 1, qui lui-même pourra être sauvegardé par la solution standard de sauvegarde de l’entreprise.

Pour renforcer la résilience des sauvegardes de l’Active Directory, plusieurs mesures doivent autant que possible se combiner :

1. Externaliser la sauvegarde sur média (version hors ligne). La première déclinaison peut être mise en place rapidement et à faible coût : un disque dur externe à déconnecter une fois la sauvegarde faite. Il s’agit simplement de mettre en place le processus organisationnel associé pour que l’action humaine puisse être faite sans oubli. La seconde déclinaison, pour les rares organisations qui en sont encore dotées, est de s’appuyer sur le système de sauvegarde sur bandes. Dans ce cas aussi, un point d’attention est de rigueur : la sauvegarde et l’externalisation régulière du catalogue de sauvegarde, pour ne pas perdre de temps en cas de restauration, dans le cas où celui-ci a disparu lui aussi (histoire s’inspirant de faits réels rencontrés par nos équipes de réponse à incident). Point d’attention : la sauvegarde sur bandes doit être vue comme un dernier recours pour s’assurer de conserver une copie des données, en cas de scénario catastrophe. En effet, ce format de sauvegarde ne se prête pas à la reconstruction rapide, en raison de délais incompressibles conséquents, avant même de pouvoir commencer à restaurer sur le SI de production : délai de rapatriement des bandes et délai la lecture de leur contenu.
2. Externaliser la sauvegarde en dehors du système d’information (version en ligne). Que cela soit réalisé à l’aise de scripts maison ou de solutions du marché (voir notre radar), après chiffrement robuste, une sauvegarde peut être externalisée. L’avantage des solutions du marché est qu’elles intègrent directement la partie reconstruction rapide (cf. partie suivante) d’un DC.
3. S’appuyer sur une sauvegarde complémentaire mais indépendante. Pour augmenter la disponibilité de l’infrastructure de sauvegarde, il suffit de la redonder en s’assurant qu’il n’y ait pas de risque de compromission simultanée. Pour cela, profitant de leur transition vers le cloud, de nombreuses organisations ont choisi récemment d’ajouter un DC supplémentaire, mais hébergé dans le cloud (les autres étant traditionnellement encore on-premises), bénéficiant ainsi naturellement des mécanismes de sauvegarde qui lui est propre. Du fait des mécanismes de réplication internes à AD, le DC hébergé dans le cloud sera compromis (compromission de certains comptes ou de certaines configurations d’AD) dans la même échelle de temps que ceux on-premises, mais l’étanchéité entre actifs sauvegardés et système de sauvegarde étant supposé meilleur dans le cloud, l’on aura plus de chance d’avoir une sauvegarde d’un DC encore disponible.
4. Rendre son infrastructure de sauvegarde immuable, en s’appuyant au maximum sur les solutions proposées par les éditeurs des logiciels de sauvegarde. En effet, la plupart des éditeurs proposent désormais des mécanismes d’immuabilité, qui parfois ne nécessitent pas l’achat de baies de stockage supplémentaires. En rendant les sauvegardes immuables sur leur stockage primaire, on s’assure d’un temps de reconstruction optimal puisqu’il ne sera pas nécessaire de rapatrier les sauvegardes depuis un stockage hors ligne (axe 1) ou en ligne (axe 2) avant de pouvoir commencer à restaurer. N.B.: l’axe 2 peut et doit bénéficier de ce concept (Amazon S3, Azure blob, etc.).

Enfin, dernier point de détail, connaître quel(s) DC sauvegarder et utiliser pour la restauration en cas de besoin est indispensable (DC Global Catalog, version d’OS la plus récente, etc.), tout comme la fréquence (sûrement quotidienne) et la durée de rétention (sujet beaucoup plus subjectif).

Reconstruction rapide : des capacités souvent incomplètement testées

Les tests de reconstruction sont aussi vieux que le concept de PCA/PRA. Mais là encore, l’on ne peut pas juste reposer sur ces tests annuels pour se considérer prêt, à la lumière de l’état de la menace. En effet, ces tests reposent très souvent sur des hypothèses qui ne seront pas vérifiées en cas de cyberattaque majeure : sauvegardes disponibles, confiance dans l’état du système d’information, outils collaboratifs (poste de travail, messagerie, outil de ticketing, etc.) fonctionnels, infrastructure d’accueil cible prête et disponible, etc.

De ce que l’on observe dans les organisations, les temps affichés et communiqués sur les temps de reconstruction d’un domaine AD sont souvent sous-estimés a priori. Les temps de déclenchement et d’arrêt du chronomètre sont bien souvent discutables : déclenchement au moment où l’on appui sur le bouton de démarrage de la restauration de la sauvegarde, arrêt au moment où un DC est restauré et opérationnel (procédure AD forest recovery exécutée [2]). Pour autant, l’on fait souvent fi de certains points qui peuvent difficilement être écartés pour comparer cette durée à celle du RTO :

• dépendance non satisfaite à un autre domaine indispensable (domaine présentant une ou plusieurs relation(s) d’approbation avec d’autres domaines) ;
• capacité à tenir la charge d’authentification que représentera une réouverture de service ;
• temps d’exécution des opérations de « toilettage » (changement de mot de passe en masse, désactivation de certains services ou compte, remise au propre dans les objets et les groupes, etc.) ;
• etc.

Lorsque l’infrastructure AD est paralysée par une cyberattaque majeure, sa reconstruction deviendra rapidement la priorité de la cellule de crise, en raison de la dépendance des applications et utilisateurs à celle-ci. C’est d’ailleurs un service dont le RTO est le plus faible. Dans le cas où les sauvegardes sont disponibles, se posent rapidement certaines questions qui doivent nourrir la stratégie de cyberdéfense que l’on est en train de définir (voir notre Top 10 des pièges à éviter pour une gestion de crise rançongiciel réussie) :

• Faut-il avoir une zone permettant d’accueillir la future infrastructure saine ?
• La création des utilisateurs dans Azure AD durant la crise permet-elle de rouvrir le service plus rapidem ent ?
• Dans le cas où il existe de nombreux domaines AD (cas des très grandes organisations) dans quel ordre procéder ?

Sur le volet infrastructure, d’abord, dans la vaste majorité des cas, disposer d’une zone isolée et sécurisée de reconstruction permet de gagner du temps. Celle-ci doit être disponible, prête à accueillir le nombre de VM permettant d’atteindre le niveau service considéré comme acceptable dans une telle situation et à la main (comptes avec les droits suffisants, accessibilité, etc.) de l’équipe responsable du service Active Directory uniquement. Cela pour réduire le risque de compromission mais aussi pour ne pas créer de freins (demandes à effectuer à une autre équipe) le jour où le besoin survient.

Cette zone peut-être on-premises ou dans un service cloud, dépendamment des coûts et de la posture cybersécurité de l’organisation quant à l’hébergement de DC sur un cloud (dans le cas où celui-ci est public). Cette zone dormante peut d’ailleurs être mise à profit pour accueillir les tests de restauration réguliers de l’Active Directory, pour être au plus proche d’une situation réelle. Enfin, cette infrastructure doit évidemment être dans le tier 0, si l’organisation s’appuie sur ce framework.

Sur le volet des processus, ensuite, il convient de préparer en amont plusieurs informations indispensables le jour où le besoin de reconstruire le service surviendra :

• déterminer le nombre de DC minimal ainsi que leur localisation (zone de reconstruction dans le cloud / on-premises, mais également géographiquement en cas de présence sur de multiples plaques) ;
• déterminer la méthode de réplication (réplication standard ou recours à IFM [3]) des DC permettant de minimiser le temps entre la disponibilité du premier et du dernier DC nécessaire à la réouverture du service ;
• des règles de filtrage prêtes et désactivées, qu’il suffira d’activer avant l’ouverture du service ;
• du niveau de risque acceptable pour la reconstruction (reconstruction simple et « toilettage » des objets ou méthode du pivot) ;
• (dans les organisations avec de multiples domaines servant plusieurs métiers) une séquence de reconstruction, qu’il aura fallu déterminer au-préalable avec les responsables métier, pour rouvrir le service selon les bonnes priorités.

Ici aussi, les outils de sauvegarde / restauration spécialisés AD apportent de la valeur : ils permettent d’exécuter la procédure de restauration d’une forêt AD en quelques clics et de manière automatisée. La parallélisation de ces opérations est également rendue possible, faisant de ces outils un accélérateur indéniable à considérer pour les organisations possédant de nombreuses forêts !

Sur le volet des ressources, enfin, il convient de disposer d’une organisation permettant de répondre à cette surcharge de travail ponctuelle mais très importante. Pour cela, l’automatisation des activités de reconstruction qui peuvent l’être, mais également le fait d’avoir des ressources ayant déjà pratiqué l’exercice à de multiples reprises s’avère souvent décisif.

Certaines organisations profitent des tests de Disaster Recovery (DR) pour simuler la pire situation possible pour le service Active Directory, plutôt que de simplement simuler une reprise seulement partielle. C’est indubitablement une bonne pratique.

En définitive, se poser la question de la résilience de son infrastructure Active Directory tire le sujet plus global de la résilience du système d’information, mais également celui du tiering, celui des exercices grandeur nature, à mener régulièrement. L’on pourrait même faire un pont avec le DevOps : ne rêverait-on pas de parvenir au redéploiement d’une infrastructure AD quasiment automatiquement, à l’image de ce que parviennent à faire les DevOps grâce au concept d’Infrastructure as Code ? En attendant, l’entraînement régulier reste le seul moyen d’atteindre un degré de sérénité sur ses capacités à rouvrir rapidement un service AD minimal, s’il venait à être entièrement détruit.

[1] https://www.wavestone.com/en/insight/cert-w-2022-cybersecurite-trends-analysis/

[2] https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide

[3] Install From Media : https://social.technet.microsoft.com/wiki/contents/articles/8630.active-directory-step-by-step-guide-to-install-an-additional-domain-controller-using-ifm.aspx

Cet article RECONSTRUCTION D’ACTIVE DIRECTORY : COMMENT SE DONNER LES MOYENS D’Y PARVENIR ? est apparu en premier sur RiskInsight.

Un besoin de défense active …

Aujourd’hui, des attaques de plus en plus sophistiquées touchent tous les secteurs d’activité et ciblent des organisations spécifiques en utilisant des techniques toujours plus complexes. Ces attaques visent à contourner le périmètre de défense existant, mais également à persister sur le SI cible sans déclencher immédiatement l’attaque. Ainsi, l’attaquant améliore sa connaissance de la cible depuis l’intérieur pour lancer ensuite une attaque aux conséquences importantes pour les métiers (vols de données, destruction du SI, usurpation d’identité…).

L’exemple le plus marquant reste l’attaque Carbanak/Anunak, qui a visé plus d’une centaine d’établissements bancaires. Les attaquants se sont introduits discrètement dans le système via du spear phishing (mail malveillant ciblé et personnalisé) puis une série de rebonds. Ils s’y sont ensuite maintenus sur le long terme, observant patiemment les actions des opérateurs bancaires pendant plus d’un mois et demi. Les systèmes de surveillance des banques n’ont pas repéré les traces de persistance laissées par les attaquants, qui ont veillé à rester en dessous des seuils de détection. Une fois les procédures internes des banques identifiées, les attaquants ont pu détourner lentement mais sûrement plusieurs dizaines de millions de dollars.

Les stratégies traditionnelles de défense passive inspirées du modèle du château fort, c’est à dire visant à se protéger (fermeture des flux, antivirus, IPS, etc.), ne suffisent plus à elles seules, et ne sont pas adaptées pour répondre à ce type de menaces.

Il est ainsi devenu nécessaire d’accepter le caractère inévitable de l’intrusion et se préparer à y faire face. Dans cette optique, la défense active vise à détecter puis réduire l’efficacité ou supprimer une attaque.

… pour 3 niveaux d’intervention

En fonction de la portée des moyens utilisés par l’attaquant, on peut identifier plusieurs niveaux de réponse active :

1)     Répondre avec les moyens propres de l’entreprise

Les actions de réponse active visent ici à tromper l’attaquant ou encore le désinformer et collecter des informations sur ses méthodes.

Dans un premier temps, pour analyser les actions des attaquants de façon proactive on pourra utiliser des serveurs honeypot, qui simulent des serveurs d’importance accessibles afin d’y attirer les attaquants et de les surveiller, ou encore des clients honeypot, des clients volontairement vulnérables pour détecter les tentatives d’attaques telles que le waterholing ou le drivebydownload en les faisant naviguer sur les sites visités par les collaborateurs de l’entreprise.

Dans un second temps, pour duper et/ou ralentir l’attaquant on pourra renvoyer de fausses informations sur le système d’exploitation lorsque l’attaquant lance des scans, ou encore simuler de faux services (en utilisant Portspoof par exemple pour simuler des ports ouverts et des services factices capables d’interagir avec l’attaquant).

L’augmentation du temps de réponse de certains services par l’utilisation de techniques de type « tarpit » (seau de goudron) permet de gêner l’attaquant sans impacter les utilisateurs légitimes. De plus, on peut réduire la fenêtre d’attaque en restaurant régulièrement les serveurs web dans un état propre connu (SCIT server) de sorte à réduire la fenêtre de temps durant laquelle l’attaquant peut compromettre le serveur.

Dans le but d’épuiser les ressources et la motivation de l’attaquant, on pourra le tromper avec de fausses vulnérabilités sur un serveur web. Enfin, bloquer les adresses IP tentant d’appeler des ports inhabituels (Artillery) jugulera ses manœuvres d’expansion dans le réseau.

La défense active permet ainsi de comprendre les attaques, de les ralentir et d’épuiser les ressources de l’attaquant. Les informations ainsi obtenues permettent d’adapter et d’optimiser les moyens de défense traditionnels pour bloquer les attaques plus efficacement.

2)     Intervenir sur les moyens entre la cible et l’attaquant

Dans la chaîne de communication utilisée par les attaquants se trouvent un certain nombre d’acteurs : des FAI, des tiers compromis par l’attaquant, des hébergeurs, des noms de domaines malveillants, etc.

Il est possible d’intervenir sur les moyens intermédiaires utilisés par l’attaquant pour juguler l’attaque, en prenant contact avec les acteurs en charge de ces moyens. On pourra par exemple contacter les FAI en cas d’attaque DDoS, pour filtrer le trafic avant l’arrivée sur le SI de l’entreprise ou encore faire saisir les noms de domaines par décision de justice (par exemple pour démanteler un botnet).

On pourra également contacter un hébergeur pour faire fermer un site malveillant ou faire disparaitre le trafic en amont avec du DNS Sinkholing (faire pointer le trafic malveillant vers un domaine inexistant).

Ces actions permettent à la fois d’obtenir des informations de façon indirecte sur l’attaquant (compte utilisé pour acheter un nom de domaine malveillant, etc.) mais aussi de le ralentir et de le contrarier dans ses plans. De plus, elles doivent être anticipées – si possible – en créant des réseaux de contacts auprès des principaux fournisseurs ou équipes de réponse à incident, en particulier pour pouvoir agir rapidement à l’étranger.

3)     Contre-attaquer directement chez l’attaquant

Il est à noter que ce type de réponse est identifié comme illégal en France par la loi Godfrain de 1988 et plus particulièrement par les articles 323-1 et suivant du Code pénal traitant des atteintes aux systèmes de traitement automatisé de données.

Il est cependant intéressant de mentionner ces méthodes car elles peuvent être utilisées par d’autres pays où elles sont autorisées mais également par les forces de l’ordre dans un certain nombre de cas bien particuliers.

On peut distinguer deux types de réponse dans ce troisième niveau :

• les actions de réponse visant à recueillir des informations sur l’attaquant ;
• les actions de réponse visant à rendre inopérant les systèmes d’attaque directement chez le cybercriminel.

Dans le premier type de réponse on pourra mentionner l’envoi de fichiers « piégés », des fichiers balisés, capables de renvoyer un beacon dès lors que celui-ci est ouvert/copié dans un endroit inhabituel ou utiliser des failles de sécurité chez l’attaquant pour prendre le contrôle du serveur de commande et de contrôle (C&C) et identifier les données exfiltrées.

Dans le second type de réponse on peut penser à injecter du code malveillant dans un fichier exfiltré par l’attaquant et par la suite détruire logiquement ses systèmes, ou encore tenter de viser sa bande passante par un DoS ciblé. Finalement on peut envisager autant de scénarios que de canaux d’attaques.

Ces méthodes doivent être manipulées par les autorités compétentes afin de se conformer aux exigences légales.

Pour conclure, les mesures de défense active ne se résument pas uniquement à contre-attaquer directement mais bien à se doter de moyens permettant de mieux comprendre, détecter et réagir aux attaques. En complément des stratégies traditionnelles de défense, l’importance de la réponse active se révèle aujourd’hui un sujet en plein développement dans les équipes de réponse à incident les plus avancées. Le paradigme à garder en tête reste inchangé : toujours avoir un coup d’avance !

Cet article Défense active : répondre activement aux attaques cybercriminelles est apparu en premier sur RiskInsight.