Convergence d'ITDR, PAM et IGA. Lequel des trois est présent quand l'attaque arrive?

Mais comment le travail est-il divisé? Gestion de l'Accès Privilégié et Gouvernance de l'Identité et Administration gèrent la prévention: elles décident qui détient le privilège et quand il est autorisé de l'utiliser. Le travail de Détection et Réponse aux Menaces d'Identité est différent. Elle observe et vous dit quand quelque chose a déjà mal tourné. Regroupez les trois dans une console et dessous, vous avez toujours trois travaux séparés.

Nous avons découvert où cette division se rompt en payant des étrangers pour nous attaquer.

Ce que les vrais attaquants ont obtenu

Nous avons exécuté un programme de bug bounty géré via Bugcrowd contre un Active Directory modérément renforcé. Les attaques ont été soumises par des personnes rémunérées pour des résultats plutôt que de cocher une liste de contrôle. DCSync, vidage de processus LSASS et contournement d'accès NTDS.dit en faisaient partie. Nous avons constaté que 100% des attaques effectuées par des utilisateurs standard et des comptes administrateur informatique ont été détectées et prévenues.

Mais dans les cas où un pirate a commencé avec des identifiants d'administrateur de domaine valides, les attaques ont réussi, car les demandes provenant de ce compte étaient les demandes qu'un administrateur de domaine fait. Ce cas appartient à PAM. Découvrir quels comptes détiennent un pouvoir caché appartient à IGA.

La mise en retrait ne paie pas toujours

Nous avons arrêté tout ce qui figurait sur cette liste pendant qu'il était encore tenté, pas après coup. Cette distinction compte plus qu'il n'y paraît. Une attaque arrêtée à mi-parcours ne devient jamais un incident que quelqu'un doit enquêter; elle ne place jamais le nom de votre entreprise dans les titres des violations.

Une partie de celui-ci peut être annulée: restaurer une appartenance à un groupe, réinitialiser un mot de passe, supprimer une délégation, et vous êtes plus ou moins revenu au point de départ.

Mais avec certaines attaques, cela cesse de fonctionner. Prenez Certificate Services par exemple. Un modèle qui permet au demandeur de fournir son propre nom alternatif du sujet émettra un certificat nomment le demandeur comme quelqu'un d'autre. Inscrivez-vous, nommez un compte privilégié, et vous vous en allez avec une identifiant qui s'authentifie comme tel.

Aucun des correctifs habituels ne touche à cela. Réinitialisez le mot de passe et le certificat fonctionne toujours. Corrigez le modèle et vous avez seulement arrêté l'attaquant suivant, pas celui qui détient déjà une identifiant valide. Ramenez le répertoire et vous ne l'avez toujours pas touché, car le privilège n'était jamais dans le répertoire. Il se trouve dans un magasin de certificats, valable jusqu'à son expiration ou jusqu'à ce que quelqu'un révoque ce certificat spécifique manuellement.

À ce stade, une alerte vous dit simplement où commencer à chercher. Bloquer l'inscription est la seule chose qui l'arrête de manière fiable.

Où chaque pièce doit faire son travail

PAM, IGA et ITDR ne comptent que dans un moment spécifique d'une attaque. Si personne n'a jamais marqué un compte comme privilégié, c'est du ressort d'IGA. Si une identifiant permanente existait déjà pour ce compte, PAM était la seule chose qui aurait pu arrêter ce qui a suivi. Si le compromis a dépassé les deux et a commencé à agir comme un attaquant, ITDR était la dernière chance de le capturer avant qu'il ne s'éloigne davantage.

Comment Netwrix aide

Netwrix PingCastle et 1Secure évaluent la posture de sécurité des identités, mappent les résultats à MITRE ATT&CK et les classent par risque, de sorte que la correction commence par ce qui ferait vraiment du mal. Au niveau du protocole, la prévention des menaces brevetée bloque les lectures NTDS.dit, les vidages LSASS et les demandes de réplication non autorisées directement au contrôleur de domaine, avant qu'elles ne réussissent. Netwrix Threat Manager détecte et répond aux menaces qui ne peuvent pas être bloquées. Et quand quelque chose réussit à passer, la récupération automatique de la forêt AD et le retour en arrière granulaire dans AD, Entra ID et Okta ramènent les choses, jusqu'à l'objet spécifique qui a changé.

Si vous voulez le voir contre votre propre répertoire, nous pouvons l'arranger. Contactez-nous pour une démo.