L'annuaire est le sol sur lequel tout le reste repose

Un annuaire tombe rarement en panne. Il dérive. Un groupe gagne un membre lundi, une délégation accordée pour une migration n'est jamais retirée, un compte de service conserve des droits dont il n'a eu besoin qu'une fois. Chacun de ces changements a été approuvé par quelqu'un qui avait une raison, et aucun n'apparaît comme une faute dans la console d'administration. La question que tranche vraiment un acheteur porte sur l'instrument construit pour voir l'état que ces changements finissent par produire.

L'étape qui transforme un incident en reconstruction

Les opérateurs de rançongiciel n'ont pas besoin d'atteindre chaque serveur. Ils ont besoin d'atteindre le système auquel chaque serveur fait déjà confiance. Un compte qui détient des droits sur les contrôleurs de domaine peut s'authentifier sur toute machine jointe au domaine, réinitialiser n'importe quel mot de passe, émettre ses propres tickets Kerberos, couper la journalisation qui l'enregistrerait et atteindre l'infrastructure de sauvegarde, laquelle s'authentifie contre l'annuaire même qu'elle existe pour protéger. À partir de là, la question n'est plus de savoir quelles machines ont été chiffrées mais à quelles informations d'identification on peut encore faire confiance. Six agences publiques, dont l'Australian Cyber Security Centre de l'Australian Signals Directorate et le National Cyber Security Centre néo-zélandais, l'écrivent noir sur blanc dans leur guide commun sur la détection et l'atténuation des compromissions d'Active Directory, qui indique que répondre à une compromission impliquant Active Directory et s'en remettre peut prendre du temps, coûter cher et perturber l'activité.

La dérive est ce qui place un compte dans cette position, et la documentation de Microsoft montre à quel point cela se produit discrètement. Reducing the Active Directory Attack Surface note qu'un membre d'Enterprise Admins, de Domain Admins ou du groupe Administrators peut manipuler l'annuaire pour obtenir l'appartenance aux autres, de sorte qu'en termes de privilège potentiel les trois doivent être tenus pour équivalents. Sortir un administrateur de l'un et le laisser dans l'autre change l'organigramme, pas la portée.

La même page décrit ce qu'un nettoyage laisse derrière lui. Quand un compte est retiré d'un groupe protégé, son attribut adminCount reste à 1 tant que personne ne le remet à zéro à la main, et le compte continue de ne pas hériter des permissions de l'unité d'organisation où il se trouve. Votre modèle de délégation affirme que ce compte est gouverné par l'OU. Il ne l'est pas, et rien sur sa fiche de propriétés ne le signale. Le même guide des six agences cite le manque d'outils de diagnostic de sécurité parmi les quatre propriétés qui font d'Active Directory une cible intéressante, aux côtés des paramètres par défaut permissifs, des permissions complexes et de la prise en charge de protocoles anciens. La console liste des objets. Un chemin d'attaque est une relation entre objets.

Un scan ponctuel et un contrôle continu sont deux instruments différents

Le NIST définit la surveillance continue de la sécurité de l'information dans SP 800-137 comme le maintien d'une conscience permanente de la sécurité de l'information, des vulnérabilités et des menaces afin d'étayer les décisions de gestion du risque, et le même document ajoute que la collecte de données, aussi fréquente soit-elle, s'effectue à intervalles discrets. Continu n'est pas une affirmation de permanence. C'est l'affirmation que l'intervalle est assez court pour qu'une décision prise sur ces données porte encore sur le parc que vous avez.

C'est pourquoi la différence relève du produit et non du calendrier. Un scan ponctuel mesure l'annuaire par rapport à une référence et vous remet une liste. Purple Knight fonctionne ainsi, et sur un annuaire que personne n'a audité il produira des constats sur lesquels travailler. Ce qu'un scan ne peut pas vous remettre, c'est un écart, puisqu'il ne garde rien à soustraire. Semperis et Tenable Identity Exposure se placent à l'extrémité entreprise de la même catégorie, tous deux construits autour d'Active Directory. La question à poser à n'importe quel produit ici n'est pas à quelle fréquence il tourne. C'est ce qu'il conserve entre deux exécutions, et s'il sait vous dire qu'un chemin qui n'existait pas le mois dernier existe aujourd'hui, en nommant le changement qui l'a ouvert.

La couture entre un annuaire et un cloud

Ajouter un tenant Microsoft 365 à un parc qui possède déjà un annuaire crée un deuxième système d'identité et une relation de confiance entre les deux. Ajouter un compte AWS ou Google Cloud en crée un troisième. L'équipe de réponse à incident de Microsoft écrit dans ses leçons sur la prévention des compromissions d'identité cloud qu'elle est intervenue sur de nombreuses investigations où la compromission d'un Active Directory sur site a conduit à la compromission du tenant Microsoft Entra, et que les fournisseurs d'identité fédérés constituent un angle mort administratif, parce que l'identité hybride est architecturalement compliquée et comporte beaucoup de pièces mobiles.

Cet angle mort est organisationnel avant d'être technique. L'équipe annuaire et l'équipe cloud revoient leur périmètre à des dates différentes, et chacune peut avoir raison sur la moitié qu'elle tient pendant que le chemin passe par la couture. Un produit qui lit un côté et pas l'autre ne peut pas le voir, quel que soit son rythme.

Les comptes qui ne sont pas des personnes

Les comptes qui ne sont pas des personnes ne datent pas d'hier, mais la catégorie a changé de forme. Un compte de service était créé délibérément, par un administrateur, pour un système nommé, via une demande que quelqu'un devait approuver. Les identités désormais attribuées aux agents automatisés sont créées par des développeurs et par l'outillage lui-même. Un framework d'agents enregistre une application, demande une portée et reçoit un jeton, au rythme où le logiciel s'écrit et non au rythme où un comité de changement se réunit. La portée obtenue est celle qui arrangeait sur le moment, parce qu'une manière rapide de contourner une erreur de permission consiste à élargir la portée, et rien ne ramène personne à la réduire une fois que cela fonctionne. Puis le projet se termine et l'identité, non, car un agent ne démissionne pas et aucun processus d'arrivée, de mobilité et de départ n'a de partant à traiter.

C'est exactement la dérive décrite plus haut, arrivant par un autre côté et plus vite. Les intervenants de Microsoft rapportent que les identités de charge de travail reçoivent souvent des privilèges bien plus élevés que nécessaire, et que l'activité malveillante qui en provient passe inaperçue parce que la logique de détection est centrée sur les identités humaines. Un instrument qui analyse les comptes humains et traite tout le reste comme de l'infrastructure mesure une part qui rétrécit de la surface d'attaque. La question à poser à un éditeur n'est donc pas de savoir si les identités non humaines sont prises en charge. Trois questions plus étroites séparent un produit qui les traite d'un produit qui les affiche sur une fiche technique.

• Demandez lesquelles détiennent des portées qu'elles n'ont jamais utilisées, et comment le produit l'a établi.
• Demandez lesquelles ne se sont pas authentifiées depuis quatre-vingt-dix jours en portant encore un jeton ou une clé active.
• Demandez lesquelles atteignent un objet privilégié par une chaîne de deux ou trois attributions plutôt que par une seule.

IAM, PAM et contrôle de posture d'identité répondent à trois questions différentes

L'IAM décide qui doit avoir accès et ouvre puis ferme cet accès à mesure que les personnes arrivent, changent de poste et partent. Le PAM gouverne la manière dont l'accès privilégié est utilisé une fois qu'il existe, en gardant les informations d'identification dans un coffre, en les délivrant pour une fenêtre de temps et en enregistrant la session. Le contrôle de posture d'identité lit la configuration que ces deux produits ont créée, ainsi que tout ce qu'aucun des deux ne touche, et rapporte ce que cette configuration permet aujourd'hui. En posséder deux ne produit pas le troisième. Un parc peut faire tourner correctement l'IAM et le PAM et contenir quand même un chemin d'un compte ordinaire vers des droits de domaine, parce que ce chemin est fait d'imbrications de groupes, d'ACL, de délégations et de modèles de certificats, qu'aucun flux de provisionnement ne gouverne.

Nous portons le troisième et pas les deux autres. ICM a un produit de posture d'identité et n'a ni IAM ni PAM, ce que la page du domaine identité indique également. Un acheteur qui a besoin d'un coffre à secrets a intérêt à l'apprendre tôt plutôt qu'à la fin d'une page de portefeuille.

Où cela se situe dans notre portefeuille

Forestall lit ensemble Active Directory, Entra ID, Azure, Microsoft 365, AWS IAM, Google Cloud IAM et Google Workspace, au travers de connecteurs en lecture seule, sans agent sur les postes et sans demander Domain Admin ni un droit équivalent. Il cartographie les comptes, les groupes, les stratégies et les relations entre eux, analyse les identités qui ne sont pas des personnes aux côtés de celles qui le sont, et renvoie les chemins d'élévation de privilège avec l'étape de remédiation attachée.