Votre entreprise est actuellement en proie à une crise ransomware conséquente. Comme dans 100% des crises de cette nature, les cybercriminels ont compromis l’Active Directory, en raison de son rôle central dans la gestion des accès, de l’authentification et des ressources réseau au sein de toute organisation.

Si les attaquants ont déclenché la charge malveillante, vos systèmes sont maintenant chiffrés. Ils peuvent sinon être isolés et hors ligne. Dans les deux cas, votre entreprise ne dispose plus des ressources nécessaires pour fonctionner correctement, et votre activité est alors à l’arrêt ou très fortement ralentie !

Dans cette situation, la confiance en votre système d’information est rompue. Vos équipes commencent à subir une pression des métiers et une question revient sans cesse : quand pourront-nous rouvrir nos services ? Votre objectif devient donc clair, il faut impérativement remettre sur pied l’Active Directory avec un niveau de confiance suffisant pour rouvrir les services.

La reconstruction d’un Active Directory est une étape complexe de la gestion d’une crise. Si elle est mal exécutée, votre organisation s’expose à deux risques majeurs : l’amplification des impacts opérationnels pour les métiers, ou une nouvelle compromission de votre environnement.

L’ANSSI vient de publier 3 guides très complets à ce sujet [1], et nous vous en conseillons la lecture.

Dans cet article nous allons revenir sur quelques points qui nous ont marqué lors de la gestion de crise. Durant leurs interventions, nos équipes ont en effet pu se confronter à de nombreux obstacles. Quels sont les principaux problèmes rencontrés ? Comment y remédier ?

De la compromission à la remise en service : les conseils pour surmonter les obstacles

Démarrez efficacement la remédiation grâce à une organisation éprouvée

La perte de temps due à une mauvaise organisation au moment de la crise peut aggraver les conséquences de la compromission d’Active Directory. Les équipes sont souvent incertaines quant à la marche à suivre, les personnes à mobiliser et les objectifs à atteindre. Une réponse ralentie augmentera les coûts associés à la remédiation, les pertes de revenus ainsi que les impacts sur la réputation de l’entreprise.

En amont de la crise…

Il est nécessaire d’identifier l’ensemble des acteurs clés à impliquer dans la reconstruction de l’Active Directory :

• Le comité exécutif pour arbitrer les questions structurantes. Par exemple, priorise-t-on une réouverture rapide des services critiques pour des questions business, ou plus lente et plus sécurisée ? Plusieurs postures sont possibles et présentent chacune leurs avantages et inconvénients [1 – Volet stratégique]. L’ensemble du plan de remédiation étant construit à partir de cette décision, il est nécessaire que le comité exécutif puisse trancher pour commencer les travaux rapidement.
• Les équipes métier pour identifier et prioriser le rétablissement des services les plus critiques. La compromission de l’Active Directory impacte la majorité des services de l’entreprise et vos équipes ne pourront traiter toutes les demandes à la fois.
• Les équipes d’intervention (techniques et sécurité) pour définir et déployer le plan de remédiation. L’expertise et les efforts humains requis pour reconstruire un Active Directory nécessitent un renfort ponctuel de vos équipes pour traiter la remédiation : maîtrise des outils de revue de configuration (PingCastle, Purple Knight, etc.), priorisation des vulnérabilités détectées, déploiement et contrôle des mesures, etc.

Afin d’optimiser le temps de réaction de chacun des acteurs, il est primordial de définir des processus et fiches réflexes. Au-delà de leur écriture, des simulations et exercices réguliers doivent être organisés pour entraîner vos équipes à réagir efficacement.

Pendant la crise…

Déployez rapidement un dispositif de suivi de projet, incluant des rapports réguliers, un suivi des actions et une coordination entre les différentes équipes impliquées. Le manque de communication et la perte d’informations engendrent trop souvent un ralentissement de la remédiation. Par exemple, il n’est pas rare de voir des administrateurs prendre des initiatives sans prendre le temps de les communiquer : ouverture de plus de ports réseaux que nécessaire, parallélisation de deux tâches du plan de remédiation, etc… Ces initiatives partant d’une bonne intention peuvent avoir des impacts significatifs sur la remédiation, allant de la complexification des travaux à une vision altérée du niveau de sécurité réel à la suite des travaux de sécurisation et donc un risque de nouvelle compromission éclair.

Assurez la résilience de vos sauvegardes en définissant une stratégie robuste

L’indisponibilité des sauvegardes (altérées ou compromises) est un défi majeur lors de la gestion d’une compromission d’Active Directory. Les attaquants prennent souvent le temps de cibler et de rendre indisponibles les sauvegardes ou de perturber les serveurs de sauvegarde. Cela a pour conséquence de rendre la restauration de l’Active Directory et la reprise des opérations plus difficiles et plus longues.

En amont de la crise …

Élaborez une stratégie de sauvegarde résiliente en tenant compte des bonnes pratiques et des recommandations (sauvegarde sur média déconnecté, immuable ou dans le cloud) [2]. Force est de constater qu’il existe aujourd’hui un écart entre l’état de l’art et les stratégies de sauvegardes (authentification des infrastructures de sauvegardes portées par l’Active Directory, sauvegardes des contrôleurs de domaine non sécurisée, etc.).

Pendant la crise …

Envisagez l’option d’assainir l’environnement Active Directory à partir d’un contrôleur de domaine compromis. Cette méthode de « double bascule » peut permettre de récupérer et de sécuriser les données essentielles afin de restaurer le service Active Directory sans sauvegarde. Un tel dispositif est à privilégier lorsque les sauvegardes sont indisponibles et que l’on ne souhaite pas reconstruire l’Active Directory de zéro.

Anticipez les problèmes techniques tels que la configuration du DNS Active Directory en entretenant votre environnement

La vaste majorité des environnements Active Directory souffre d’une dette technique accumulée au fil des années (architecture réseau complexe, rôles tel que DHCP portés par des contrôleurs de domaine plutôt que des serveurs dédiés, etc.). De plus, les environnements Active Directory sont aujourd’hui synchronisés avec Azure Active Directory, définissant de nouvelles dépendances entre les technologies pouvant complexifier la remédiation en cas de compromission de l’Active Directory (synchronisation Active Directory/Azure Active Directory). Ces deux éléments peuvent, le jour de la crise, engendrer de nombreuses problématiques techniques qui ralentiront la remédiation (perte de synchronisation avec Azure Active Directory, indisponibilité du service DHCP porté par un contrôleur de domaine devant rester éteint, etc.)

En amont de la crise …

Maintenez à jour la documentation technique et les inventaires de l’Active Directory (infrastructure, synchronisation Azure Active Directory, etc.). Il est trop souvent complexe d’obtenir une vision claire de l’environnement et du périmètre à remédier. Des inventaires à jour amélioreront grandement les travaux de remédiation et assurera la définition d’un plan de remédiation cohérent. De plus, cela vous permettra d’identifier et de remédier les mauvaises pratiques pouvant se transformer en problèmes conséquents le jour de la crise (configuration du service DNS, DHCP, etc.)

Pendant la crise …

Les services portés par Azure Active Directory pouvant être rendus indisponibles après 30 jours de désynchronisation avec l’Active Directory, cela peut engendrer un effet de bombe à retardement. Assurez-vous d’évaluer les impacts liés à la perte des services Azure Active Directory et de ne pas vous reposer sur ces services pour traiter vos activités essentielles (communication via e-mail, etc.).

De nombreux défauts techniques seront mis en lumière par la crise (rapport de configuration Active Directory via les outils d’audit, problématiques réseau, etc.). Assurez-vous de traiter uniquement les problèmes liés aux objectifs fixés par le plan de remédiation (cf. Conseil n°5 – Définissez un cap et gardez le pendant la remédiation !).

Optimisez la réinitialisation des secrets à travers des processus adaptés à votre contexte

La compromission de l’Active Directory engendre la perte de confiance dans l’ensemble de ses secrets. Une réinitialisation de ces derniers est donc requise pour atteindre le niveau de sécurité nécessaire à la réouverture des services et éviter une nouvelle compromission éclair. Pour des environnements conséquents avec plusieurs milliers d’utilisateurs et plus d’une centaine d’applications, réinitialiser un grand nombre de mots de passe d’utilisateurs et de comptes de service peut avoir des impacts opérationnels significatifs. Les travaux concernant les comptes de service nécessitent de comprendre comment l’application utilise le compte pour être en mesure de lui fournir le nouveau mot de passe. Pour les utilisateurs, il vous faudra trouver un moyen de distribuer les nouveaux mots de passe à large échelle de manière sécurisée.

En amont de la crise …

Il est nécessaire d’avoir les idées claires sur le processus de distribution de nouveaux mots de passe aux utilisateurs. Plusieurs méthodes sont possibles et dépendent de l’environnement étudié : convocation des utilisateurs avec présentation de la carte d’identité, transmission du nouvel identifiant/mot de passe via courrier physique, courriel, SMS, etc. Indépendamment de la méthode sélectionnée, il est nécessaire d’exiger de l’utilisateur qu’il réinitialise son mot de passe à la prochaine connexion. Il est aussi possible que les utilisateurs puissent réinitialiser eux-mêmes leurs mots de passe grâce à des solutions s’appuyant, par exemple, sur l’authentification à deux facteurs.

Afin d’effectuer les travaux liés aux comptes de service, il est primordial d’en dresser un inventaire en identifiant les applications associées et les méthodes de réinitialisation des mots de passe pour chacune d’entre elles. L’obtention de cet inventaire par les équipes de remédiation est souvent complexe (indisponible, non maintenu, etc.) et nécessite donc d’investir un temps non-négligeable sur des tâches pouvant être réalisées hors crise. Au-delà des travaux de remédiation, cet exercice vous sera utile au quotidien dans la gestion de vos comptes de service. L’une des bonnes pratiques étant de changer fréquemment les mots de passe de ces comptes.

Pendant la crise …

Une fois les mots de passes réinitialisés, il convient de contrôler que la mesure a été déployée sur l’ensemble de l’environnement. Cela peut se faire simplement via un script PowerShell et assure que l’attaquant n’a plus de compte valide à exploiter.

Définissez un cap et gardez le pendant la remédiation !

Lors de la reconstruction d’un Active Directory, il est souvent complexe de trouver le juste milieu entre s’exposer à des risques en rouvrant trop rapidement et engendrer des pertes financières importantes en rouvrant trop lentement. Attention à ne pas tomber dans les pièges classiques de gestion d’une crise rançongiciel. [3]

En amont de la crise …

Il est nécessaire d’effectuer un travail de réflexion sur les différentes postures de remédiation : restaurer au plus vite des services vitaux, reprendre le contrôle du système d’information ou saisir l’opportunité pour préparer une maîtrise durable du système d’information. [1]

Au-delà de la posture à définir, assurez-vous de maîtriser votre cœur de confiance Active Directory composé des actifs les plus critiques (Tier 0). Les actions de remédiations se concentrent en premier lieu sur ces composantes (contrôleurs de domaine, etc.) afin de restaurer les services vitaux l’Active Directory et d’assurer un niveau de sécurité ne permettant pas à l’attaquant de compromettre à nouveau l’entièreté de l’environnement.

Pendant la crise …

Assurez-vous que vos équipes se concentrent sur le cap défini. De nouvelles problématiques apparaîtront au fur et à mesure de l’exécution du plan de remédiation (indisponibilité du contrôleur de domaine portant l’un des rôles FSMO nécessaire à la remédiation, problématiques réseaux, etc.). Il sera nécessaire de se poser la question de la pertinence de sa remédiation à court terme par rapport aux objectifs fixés (la réponse étant fonction de la posture choisie par le comité exécutif : réouverture rapide, ou plus lente et plus sécurisée).

De plus, sachez considérer les opportunités offertes par la crise. Par exemple, si le service DHCP était géré par un contrôleur de domaine, profitez de l’occasion pour mettre en place un serveur dédié au DHCP, dissociant ainsi le service du contrôleur de domaine.

Nos enseignements

L’amélioration du processus de reconstruction en amont de la compromission d’Active Directory repose finalement sur trois axes principaux :

1. La rédaction de processus fonctionnels et fiches réflexes pour être capable de :
   1. Mobiliser les bonnes personnes en temps opportun.
   2. Se concentrer sur les objectifs principaux.
   3. L’entretien de l’environnement Active Directory, qui requiert de :
2. Définir et maintenir une architecture conforme aux bonnes pratiques.
   1. Avoir des inventaires à jour.
   2. S’assurer de la résilience des sauvegardes.
3. La réalisation de tests pour :
   1. Valider l’applicabilité des processus théoriques en conditions réelles.
   2. Améliorer la réactivité et l’efficacité de vos équipes face à une situation de crise.

Un travail adéquat sur ces trois sujets en amont permettra de réduire la complexité et le coût liés à la reconstruction de l’Active Directory en cas de compromission. Cette approche proactive contribuera à renforcer la résilience et la sécurité de l’entreprise face aux cybermenaces.

[1] https://www.ssi.gouv.fr/actualite/lanssi-publie-pour-appel-a-commentaires-un-corpus-documentaire-sur-la-remediation/

[2] https://www.riskinsight-wavestone.com/2023/02/reconstruction-dactive-directory-comment-se-donner-les-moyens-dy-parvenir/

[3] https://www.riskinsight-wavestone.com/2023/01/top-10-des-pieges-a-eviter-pour-une-gestion-de-crise-rancongiciel-reussie/

Cet article Survivre à une compromission d’Active Directory : les principaux enseignements pour améliorer le processus de reconstruction est apparu en premier sur RiskInsight.

Rappels sur le tiering

Le tiering est un modèle de sécurité applicable à l’Active Directory. L’idée principale est de séparer les comptes à privilèges dans différentes couches (les tiers) et périmètres fonctionnels, afin de restreindre leur utilisation possible dans leur tier d’origine uniquement, de sorte que si un tier est compromis, cela n’entraine pas la compromission des autres tiers. Cela permet par exemple de contenir une attaque par rançongiciel dans le tier d’origine de l’attaque uniquement, ou bien de se prémunir du scénario classique vu et revu de découverte et rejeu d’un identifiant administrateur de domaine sur un poste de travail. Typiquement le modèle se décompose comme il suit :

• Le tier 0 est le plus critique. Il est constitué de l’AD lui-même, donc les contrôleurs de domaine qui le portent, ainsi que des composants qui interagissent directement avec lui, où qui peuvent le compromettre par rebond. Ceux-ci sont typiquement les ADLDS, ADCS, PKI, mais aussi les composants IT nécessaires à son fonctionnement : hyperviseurs, SCCM, SCOM, sauvegarde, et postes d’administration dédiés (PAW, pour Privileged Access Workstation). Les comptes d’administration de ces composants sont ceux à plus hauts privilèges, car il s’agit forcément des comptes administrateurs de domaine (les comptes ayant des droits sur tout le parc Windows de l’organisation), mais aussi des comptes des autres composants pouvant s’attribuer indirectement les droits administrateurs de domaine, vu leur interaction avec les contrôleurs de domaines.
• Le tier 1 se compose classiquement des applications de l’entreprise et des serveurs qui les hébergent. Les comptes à privilèges sont donc ceux des administrateurs fonctionnels des applications ainsi que ceux des administrateurs techniques des serveurs.
• Le tier 2, pour finir, regroupe tout ce qui gravite autour de l’environnement utilisateur. En plus des comptes et postes bureautique, on peut y trouver les imprimantes, la téléphonie, ainsi que tous les comptes des différents niveaux de support utilisateur.

Pour rendre l’étanchéité possible entre les tiers, et donc limiter le périmètre de compromission, des « deny logon GPOs » (plus simple à mettre en place) ou des Authentication Policy Silos (plus sécurisées) sont mis en place, pour interdire à un compte d’un tier supérieur de se connecter à un composant appartenant à un tier inférieur. Aussi, un autre objectif du projet de mise en œuvre du tiering, pouvant avoir un impact sur le PAM, est de restreindre le nombre d’administrateurs du tier 0 au minimum, toujours dans l’optique de réduire la surface d’attaque et l’étendue d’une potentielle compromission. Une fois ce nouveau concept établi, examinons l’existant.

Bastion ? Vous avez dit bastion ?

Le bastion de sécurité est un outil très répandu dans les organisations pour implémenter le PAM. Le principe est d’héberger les comptes à privilèges dans des coffres sécurisés, et d’imposer les connexions des administrateurs (avec un compte sans privilège) vers une machine de rebond centrale, qui jouera ces comptes à privilèges pour l’administrateur, sans révéler son mot de passe. Autre avantage du bastion pour les organisations : la facilité de mise en place de l’authentification multi-facteurs, l’enregistrement et la traçabilité des actions d’administration, la gestion automatisée de la rotation de mot de passe, etc.

Jusqu’ici, rien d’incompatible avec le modèle en tiers. Et pourtant des adhérences existent. La structure de comptes à privilèges qui a été créée dans le bastion (par périmètre et/ou par équipe fonctionnelle et/ou type de composants, etc.), l’a été sans prendre en compte le concept amené par le projet de sécurisation AD : la notion de tiers.

Afin d’identifier les potentiels impacts, plaçons-nous dans l’optique du tiering et posons les questions simplement par rapport au bastion.

Comment adapter le bastion au modèle en tiers ?

Si l’on synthétise le problème à résoudre, cela donnerait le schéma ci-dessus qui est une pure vue de l’esprit. Pour réussir à l’adapter, il faut faire des choix.

Faut-il mettre le bastion dans un tier spécifique ? Faut-il le dupliquer dans chaque tier ?

Comme décrit dans le schéma d’un point de vue purement théorique du tiering, il faudrait une instance de bastion dans chaque tier, et même d’éditeurs différents afin de se prémunir d’une faille 0-day sur la technologie utilisée. Mais la mesure se heurte à une réalité financière, la possession de plusieurs bastions ayant un certain coût, doublé d’une réalité opérationnelle supportant mal la multiplication d’outils pour un même besoin. Heureusement des adaptations sont possibles. Dans la réalité, aucune entreprise ne met de bastion sur le tier 2. Ce tier étant relativement homogène et monolithique en matière de responsabilité, on autorise de s’y connecter directement, avec un compte à privilège du tier 2 évidemment, ou avec le compte administrateur local (protégé par LAPS) qui a l’avantage d’être robuste à une compromission totale du tier 2 en cas de compromission d’un seul compte à privilège du tier 2.

Pour les tiers 0 et 1, leur sort est lié et dépend à la fois du contexte de l’organisation et de l’existant. Première option, comme mentionné, le plus simple mais le plus couteux, est de déployer un bastion dédié dans chaque tier. En étant un peu plus réaliste maintenant, si une seule instance de bastion est possible, alors celle-ci devrait nécessairement être positionnée dans le tier 1. La raison de ce choix est très simple : le bastion répond à un besoin fonctionnel d’administration, or le périmètre de machines et de comptes le plus important est au sein du tier 1, à l’inverse du tier 0 dont on souhaite restreindre l’exposition (i.e. le nombre d’administrateurs y ayant accès).

Le tier 0 lui peut être plus simplement géré par des PAW, postes d’administration dédiés et durcis dans le but spécifique d’accéder à des comptes et ressources privilégiées. L’accès à la zone réseau hébergeant le tier 0 est soumise à une connexion VPN, autorisée seulement à partir de ces PAW. Il existe des organisations ayant fait une combinaison des deux : bastion et PAW. Cette implémentation reste tout à fait valable d’un point de vue sécurité, mais sa faisabilité dépend de la capacité de l’entreprise à déployer des PAW pour l’ensemble de ses administrateurs du tier 1, ce qui représente une population cible et un coût nettement supérieur. Dernier point pour conclure ce sujet : l’utilisation de bastion et PAW ne sont pas incompatibles entre eux, bien au contraire, les bénéfices sécurité sont complémentaires pour la protection des comptes à privilèges.

Dans le cas d’un bastion unique, peut-on administrer les autres tiers via celui-ci ?

Cette hypothèse simplifierait les choses, mais malheureusement elle n’est pas souhaitable. Administrer le tier 0 depuis le tier 1 briserait toute la segmentation que l’on cherche à mettre en place, notamment parce que des comptes privilégiés du tier 0 seraient hébergés dans le tier 1 et accessibles par les administrateurs du tier 1 du bastion. Cela dit, une infime possibilité existe, mais elle est très techno-dépendante car peu de bastions offrent les fonctionnalités adéquates. Sur le principe en positionnant le bastion dans le tier 0, administré par le tier 0, il serait possible de créer des groupes de machines de rebond, ainsi que des coffres (logiques), actifs ou passifs, dédiés dans chaque tier. Néanmoins notons que les rares organisations ayant tenté l’expérience font aujourd’hui machine arrière, face aux problèmes de gestion technique des coffres et à la lourdeur administrative induite.

Faut-il revoir l’attribution et la répartition des comptes dans le bastion ?

Pas nécessairement, mais encore une fois, cela dépend du contexte et de l’existant. En premier lieu, les comptes issus de chaque tier doivent être hébergés dans des coffres différents, afin de respecter la segmentation et l’étanchéité de chaque tier. Rien n’empêche si nécessaire de fragmenter, au sein de chaque tier, les coffres en sous périmètres pour répondre à l’organisation technique ou fonctionnelle existante (e.g. équipes ayant la charge du MCO/MCS des composants hébergeant des bases de données sont différentes des celles ayant la charge du MCO/MCS d’applications métier). Enfin, il est recommandé d’utiliser au maximum des comptes nominatifs et non des comptes génériques ou partagés. Si en effet rien n’empêche de mettre en coffre un compte unique administrateur de tous les serveurs du tier 1 utilisé par tous les administrateurs du périmètre, et que cette façon d’opérer ne va pas non plus contre les principes du tiering, il est quand même préférable de pouvoir immédiatement identifier le propriétaire du compte qui a fait l’action, afin de mieux maitriser les accès et habilitations de chacun, même si le bastion permettrait quand même de retrouver l’identité de manière indirecte via un recoupement dans les logs.

Bien encadrer la mise en place du tiering

Le tiering est aujourd’hui le chantier qui réduit le plus les risques de compromission des comptes à hauts privilèges et de l’AD de manière générale. C’est cependant également un sujet complexe, qui a beaucoup d’impacts sur l’ensemble des infrastructures et qui nécessite un très grand nombre d’adaptations de l’existant, pour que sa mise en place soit considérée comme réussie. Le PAM étant une brique essentielle à la gestion de ces comptes et accès d’administration, il est nécessaire de s’assurer que son implémentation n’interfère pas avec les principes du tiering voire ne vienne pas rompre la segmentation et l’isolement en couches. S’il n’y avait qu’une chose à retenir pour bien réussir cette transformation, ce serait que la mise en place du tiering, contrairement à ce que l’on croit, est loin de n’être qu’un simple sujet AD, mais qu’il doit conduire à repenser toutes les pratiques d’administration dans leur globalité.

Cet article Bastion de sécurité et modèle en tiers Active Directory : comment concilier les deux paradigmes ? est apparu en premier sur RiskInsight.