David Lieberman

Bonjour,

Voici la deuxième partie d'un blog que j'ai écrit précédemment. L'objectif de la première partie était de mieux comprendre les options qui s'offrent aux entreprises en cas de compromission de leur Active Directory. Comment peuvent-elles redevenir opérationnelles le plus rapidement possible ? Comment peuvent-elles le faire en ayant le plus de garanties possibles qu'elles ne restaurent pas de logiciels malveillants dans l'instance de la forêt Active Directory restaurée ?

Pour bien comprendre la deuxième partie, je vous encourage à lire la première partie qui se trouveici.

Pour ceux qui ont déjà lu la première partie, je vous remercie pour vos excellents commentaires. Tous les points et commentaires sont bons.

Commençons donc par revoir le cas d'utilisation que j'ai laissé dans la première partie...

Tout est crypté. Les parkings sont vides. Les usines sont silencieuses et le PDG est au téléphone toutes les 30 secondes pour dire quelque chose de "coloré" sur votre ascendance. Malheureusement, ce n'est pas un scénario que j'ai inventé. C'est une conversation que j'ai tous les mois et, de nos jours, presque toutes les semaines. Cela fait partie de mon métier et, ces derniers temps, il s'agit d'un dilemme réaliste et très difficile à résoudre.

Les commentaires que j'ai reçus sur la première partie du blog se répartissent en deux catégories. Le premier suggère d'utiliser un système de gestion des autorisations plus sûr. C'est toujours une bonne idée, mais dans ce cas, il est trop tard. Toutefois, nous pouvons envisager cette solution dans le cadre du processus de rétablissement. Nous y reviendrons plus tard. La seconde était une reconstruction partielle d'une forêt séparée. Cette seconde forêt serait essentiellement une forêt "VIP" où se trouveraient tous les actifs et informations importants de l'entreprise. Peut-être. Mais combien de temps cela prendrait-il ? L'entreprise dispose-t-elle des ressources nécessaires pour réarchitecturer une forêt entière à la volée ? N'oubliez pas que je dois être opérationnel dès hier.

Si le scénario ci-dessus correspond à une attaque et que vous connaissez l’heure à laquelle vous avez été infecté ainsi que la manière dont les pirates ont pénétré dans votre système, alors la réponse à la question de savoir ce que vous devez faire est, à mon sens, assez simple. Il s’agit de réaliser une sauvegarde de votre Active Directory datant de la veille de l’attaque et d’effectuer une restauration de la forêt. (J’aborderai le problème du rootkit dans un instant). La seule question qui se pose alors est la suivante : avez-vous investi dans une solution qui automatise la restauration de la forêt et permet de la remettre en état en quelques heures, ou votre sauvegarde s'apparente-t-elle davantage à une sauvegarde traditionnelle de l'état du système Active Directory, pour laquelle vous ne disposez pas de processus automatisés spécialisés permettant de restaurer Active Directory dans son intégralité ? Si c'est le cas, vous devez vous préparer à une interruption de quatre ou cinq jours ouvrés pour reconstruire manuellement votre forêt et lui redonner sa pleine capacité.

En réalité, certains des scénarios d'attaque ci-dessus pourraient contenir un rootkit. C'est une énigme intéressante... avec le scénario ci-dessus, comment supprimer un rootkit d'un contrôleur de domaine. C'est difficile parce que pour restaurer, il faut que l'état du système soit repris, ce qui risque fort de réintroduire l'attaquant. Cela signifie également qu'une sauvegarde/restauration en métal nu ne fonctionnera pas, car le risque est toujours le même.

Tout le monde se souvient-il du film « Die Hard », dans lequel les méchants savent que, lors d’une prise d’otages, le FBI coupe le courant et que c’est finalement ainsi qu’ils parviennent à pénétrer dans la chambre forte de la banque ? C’est exactement la même chose ici. Je sais, et vous savez, ce qu’il faut faire pour rétablir un contrôleur de domaine, mais le vrai problème, c’est que… les méchants le savent aussi. Ils vont compter sur le fait que tout le monde suive la « procédure opérationnelle standard » de Microsoft. Quel meilleur moyen de rester persistant ?

D'ACCORD, MAIS QUE FAIRE DANS LE CAS OÙ L'ATTAQUANT EST DANS VOTRE SYSTÈME DEPUIS UN CERTAIN TEMPS ? Que dois-je faire dans le cas où l'attaquant est dans votre système depuis un certain temps ou, comme dans la plupart des cas, vous ne savez pas vraiment quand il est entré, comment il est entré, etc.

La première étape consisterait à réinitialiser tous les mots de passe, ou du moins tous les comptes à privilèges/sensibles. Oui, c'est une tâche très difficile, mais je dirais qu'elle est beaucoup plus facile et rapide qu'une reconstruction totale ou partielle. N'oubliez pas que l'heure tourne. Bien entendu, il va sans dire que, dans le cadre de la restauration des autorisations, vous intégrez les meilleures pratiques en matière de définition ou, dans ce cas, de réinitialisation des autorisations.

L'étape suivante consisterait à adopter une solution automatisée de récupération des forêts. Pour être clair, cette solution doit être mise en place avant que tout cela ne se produise. Il ne s'agit pas d'un outil que l'on peut mettre en place le lendemain. L'avantage d'une récupération sur plusieurs jours par rapport à une récupération sur quelques heures est évident. Une autre considération que beaucoup ne réalisent pas est que pour que beaucoup de vos autres solutions de reprise d'activité fonctionnent, AD doit fonctionner, parce qu'elles s'appuient souvent sur AD pour l'authentification et l'autorisation d'accès à la solution de reprise d'activité.

La solution au problème des rootkits est intégrée à notre solution de restauration des forêts. Une partie de notre processus de restauration de la forêt est ce que nous appelons une "restauration propre". Je n'entrerai pas dans les détails (c'est un tout autre blog), mais le résultat est que nous nous assurons que seules les parties AD de l'état du système sont restaurées, et non le système d'exploitation lui-même. Il est désormais possible de prendre un nouveau serveur matériel, de charger une nouvelle version ISO de Windows et de restaurer AD sans risquer de réintroduire le logiciel malveillant.

Un autre avantage intégré à la solution Forest Recovery mérite d'être mentionné : la possibilité de ne pas tenir compte du matériel lors de la restauration d'AD sur un contrôleur de domaine. Avant cette fonctionnalité, si vous vouliez restaurer AD, vous deviez le faire sur le même matériel, le même système d'exploitation, les mêmes niveaux de correctifs et les mêmes niveaux de service pack. Si ce n'était pas le cas, vous risquiez d'obtenir un écran bleu lors de la restauration et de passer quelques heures à trouver les pilotes manquants, etc. Aujourd'hui, dans le cadre de notre solution Forest Recovery, nous sommes indifférents au matériel, aux Service Packs ou aux niveaux de correctifs du contrôleur de domaine ciblé. Le seul élément qui doit correspondre est qu'il doit être restauré avec le même numéro de système d'exploitation que celui sur lequel il a été sauvegardé.

Il en résulte une plus grande flexibilité pour des scénarios tels que la restauration physique à virtuelle, la création de laboratoires et la restauration d'AD dans le nuage.

J'ai mentionné audébut de lapremièrepartie que je voulais écrire sur ce sujet parce que, bien qu'il existe une certaine documentation et des "conseils" sur ce qu'il faut faire, j'ai trouvé qu'ils étaient lents, incomplets et, dans de nombreux cas, irréalistes. L'autre motivation est venue d'un point de vue temporel. Lorsque j'ai commencé à me pencher sur la question il y a quelques années, il s'agissait davantage d'une discussion académique ou théorique. Un article ici ou là. Aujourd'hui, l'IMO est passée d'un cas limite intéressant à une question régulière de planification d'urgence. Les organisations commencent à se rendre compte que si elles ont investi dans un accord de niveau de service d'un jour, par exemple, pour leur plan de reprise après sinistre, elles peuvent très bien avoir à ajouter de nombreux jours supplémentaires, puisque rien ne fonctionnera si le service AD n'est pas opérationnel.

Enfin, les enjeux n’ont jamais été aussi importants. C’est la survie même d’entreprises entières qui est en jeu. Ne vous méprenez pas : je n’ai pas LA « solution miracle ». Personne ne l’a. Mais j’espère avoir apporté quelques éléments de réflexion supplémentaires sur un problème très complexe.

Si vous souhaitez en savoir plus sur notre technologie ou si vous voulez simplement discuter avec moi ? N'hésitez pas à nous contacter.