Container-2.svg
Comment stopper les attaques basées sur l'IA :

Saison 1, 8 épisode

intérieur Active DirectoryL'histoire des origines de : Aaron Turner revient sur la mission « Tuer Novell » de Microsoft

Lorsque votre mission est d'éliminer votre concurrent, concevoir votre produit en privilégiant la sécurité n'est pas vraiment votre priorité absolue.  

C’est ce qu’a expliqué Aaron Turner, professeur à l’IANS et ancien stratège principal en sécurité chez Microsoft, à nos co-animateurs lorsqu’il a détaillé l’origine de Active Directory.  

Dans la première partie de cette série en deux volets, Aaron nous ramène dans les années 1990 pour parler de Active DirectoryL’objectif initial de [nom de l’entreprise] – et comment cela nous a conduits, près de 30 ans plus tard, à une situation de dette de sécurité massive. 

Il partage des exemples concrets rencontrés chez Microsoft qui nous aident à comprendre pourquoi Active Directory n'a jamais été conçu comme une solution de sécurité, mais uniquement comme un mécanisme de déploiement Windows : « On a vu des cas où l'ensemble d'un domaine était composé d'administrateurs de domaine, tout simplement parce que c'était plus facile. Et si l'on se penche sur la plupart des difficultés rencontrées à nos débuts, lorsque nous essayions d'appliquer le principe du moindre privilège, les applications ne fonctionnaient pas sans des droits d'administrateur étendus. » 

Alors que de nombreuses organisations internationales utilisent encore aujourd'hui Active Directory sur site, cet épisode est incontournable pour comprendre pourquoi la sécurité d'Active Directory reste une priorité absolue pour mettre en place des défenses robustes. 

À retenir: 

  • Pourquoi Active Directory a façonné notre conception actuelle de l'identité et son impact sur la cybersécurité 
  • Les raisons pour lesquelles certains domaines de la cybersécurité, comme les pare-feu, ont bénéficié de centaines de milliards d'investissements alors que la gestion des identités commence à peine à intégrer le débat sur la sécurité
  • Ce que le piratage du Trésor américain par la NSA nous apprend sur les bonnes pratiques en matière de sécurité des identités, et les recommandations d'Aaron pour y parvenir. 

Aaron Turner :[00: 00: 00]
Il faut d'abord se mettre à la place de Bill Gates au milieu des années 90. Son objectif était que Novell génère d'importants profits grâce à Enterprise Directory. Microsoft a donc déclaré : « Il faut leur voler leurs parts de marché. » La première version des spécifications fonctionnelles d'Active Directory visait à éliminer Novell. C'était la mission première.

Active Directory a d'abord été perçu comme un moyen de vendre plus de Windows et d'Office. C'était un mécanisme de déploiement, et non pas nécessairement une barrière de sécurité. Prenons l'exemple des pare-feu : 250 milliards de dollars ont été dépensés. Qu'en est-il de la gestion des identités ? À peine 2 %. Ce manque d'investissement nous a conduits à un déficit colossal en matière d'identité.

Ils vont donc devoir investir dans des solutions axées sur les systèmes existants pour se dire : « Comment vais-je faire pour corriger 25 ans d'objets de stratégie de groupe défaillants ? » Voilà la décision qu'il faut prendre.

Roy Akerman :
L'identité n'est pas seulement un problème opérationnel, c'est aussi un problème de sécurité, et la plupart des équipes le découvrent en temps réel.

Rob Ainscough :
Voici le podcast où nous décryptons la notion de sécurité d'identité, en partageant des conversations franches sur les personnes qui construisent, corrigent et repensent la sécurité d'identité de l'intérieur.

Roy Akerman :
Je suis Roy Akerman.

Rob Ainscough :
Et je suis Rob Ainscough.

Roy Akerman :
Plongeons dedans.

Rob Ainscough :
Faisons le.

Bienvenue à nouveau. Salut Roy. Comment vas-tu ?

Roy Akerman :
Je vais bien. Content de te voir, Rob.

Rob Ainscough :
Ravi de vous voir également. Je suis très enthousiaste car, pour cet épisode, nous avons le plaisir d'accueillir Aaron Turner. Aaron a 30 ans d'expérience dans le secteur, il a fondé sa propre entreprise, mais surtout, pour nous, il a travaillé chez Microsoft. Active Directory C'était en train de devenir une chose, n'est-ce pas, à cette époque charnière.

Il était là, au camp de base. C'était super excitant pour nous de pouvoir lui parler.

Roy Akerman :
Comme le designer, l'architecte.

Rob Ainscough :
C'est lui le coupable. Euh, mais…

Aaron Turner :
Soyons très prudents. J'étais tout en bas de l'échelle hiérarchique.

Roy Akerman :
Alors il a dit

Rob Ainscough :
Ça… Mais tu étais là… tu as subi le premier impact. Tu étais là.

Roy Akerman :
Oui.

Aaron Turner :
Oh,

Rob Ainscough :
J'y étais. Tu y étais.

Aaron Turner :
J'étais là, mais j'étais, euh, techniquement, ingénieur support, ce qui signifiait que je devais gérer tous les bugs et toutes les galères, vous voyez ? Donc, j'ai vu le pire du pire.

Rob Ainscough :
Waouh. Oui. C'est tout de même une position privilégiée, alors nous allons en parler un peu. Nous allons parler de l'évolution de l'identité au fil des ans. Active DirectoryLe rôle de [nom du joueur], ce que cela signifie pour les attaquants aujourd'hui, et pour les défenseurs, n'est-ce pas ?

Je pense donc que nous allons avoir une séance très intéressante. Pour commencer, Aaron, pourriez-vous nous donner un bref aperçu de votre parcours professionnel et de votre biographie ?

Aaron Turner :
J'ai entrepris ce voyage parce que j'ai vu le film WarGames. Genre, en 1984, le film WarGames est sorti, et je me suis dit : « Ça a l'air incroyable. »

Je me suis demandé si j'en étais capable. Et c'est comme ça que j'ai commencé à avoir des problèmes avec les ordinateurs, pas vrai ? Et puis, j'ai fini par comprendre comment gagner de l'argent en faisant des bêtises avec les ordinateurs. J'étais l'un des premiers testeurs d'intrusion, au début des années 90, et j'ai fini par me dire que je pouvais peut-être trouver un travail mieux rémunéré que ce que je gagnais en faisant des petits boulots de tests de sécurité.

Microsoft a publié une offre d'emploi pour une personne bilingue, maîtrisant Internet et ayant une expérience de Novell, afin de rejoindre son équipe. Ils souhaitaient se concentrer sur les opportunités en Amérique latine, et comme je parle espagnol et que j'ai vécu un temps au Mexique, j'avais déjà une certaine connaissance d'Internet grâce aux projets atypiques que j'avais menés depuis WarGames. J'ai ensuite décroché cette incroyable opportunité chez Microsoft et j'ai participé à une aventure où nous avons posé les fondements mêmes de ce qui allait devenir Internet et l'informatique d'entreprise.

J'y ai passé huit ans. Une période formidable pour apprendre énormément.

Roy Akerman :
Nos agents du renseignement nous ont dit deux choses que je dois absolument vous confirmer. La première, c'est qu'après un an de mandat, Bill Gates en personne vous a donné carte blanche pour mener à bien n'importe quel projet, à condition bien sûr qu'il ait une grande valeur.

Et le deuxième sujet concerne une étoile d'or. Si vous pouviez commencer par celui-ci, puis passer à nos discussions sur l'identité, ce serait super. Pourriez-vous nous en dire un peu plus ?

Aaron Turner :
Donc, euh, entre 1998 et 99, le gouverneur du Venezuela est venu voir Microsoft et a déclaré : « Nous voulons construire une plateforme d'identité nationale pour chaque citoyen du Venezuela. »

Roy Akerman :
Wow.

Aaron Turner :
Ils sont donc descendus sur place et ont essayé de construire cette plateforme d'identité d'entreprise avec NT4, mais la migration n'a pas été à la hauteur. Ça semblait prometteur. Et ça n'arrêtait pas de planter. Sans cesse. Personne dans notre équipe n'a osé aller au Venezuela, car le Venezuela a encore plus mauvaise réputation aujourd'hui, mais même à l'époque, c'était un endroit incertain.

Comme je connaissais bien l'Amérique latine, je me suis dit : « D'accord, j'y vais. » J'ai donc levé la main et je suis allé sur place. Ayant contribué à la résolution de ce problème, j'ai trouvé comment modifier le code NT, ce qui a ensuite permis d'intégrer ce code à Windows 2000. Grâce à cette modification et à mon courage d'aller au Venezuela, j'ai reçu en 1999 une étoile d'or, une distinction très rare décernée à l'époque par Bill Gates.

Mais en tant que bénéficiaire, j'ai eu la possibilité d'expérimenter, n'est-ce pas ? J'avais une certaine liberté pour me dire : « Tu as accompli quelque chose de formidable. Voyons ce que tu peux faire pour développer davantage Microsoft. » Ainsi, ma connaissance de l'espagnol et mon courage d'être allée au Venezuela m'ont permis de réaliser des choses extraordinaires et de travailler sur… Active DirectorySQL Server, Windows Mobile, Xbox Live.

J'ai eu la chance de travailler sur plein de trucs vraiment géniaux pendant mon séjour là-bas.

Roy Akerman :
Tout cela du point de vue de l'identité

Aaron Turner :
Parfois l'identité, parfois la destruction.

Roy Akerman :
Oui.

Aaron Turner :
Mm-hmm. C'est vrai ? Parfois, cela aide les gens à réfléchir aux modèles de menaces. Vous savez, nous n'avions pas vraiment d'équipe de cybersécurité à part entière avant 2002 ou 2003.

Vous savez, j'étais là au début, quand on a dû… Personne n'avait encore conçu un système de mise à jour d'envergure professionnelle comme Windows Update, n'est-ce pas ? Personne n'avait réfléchi à la manière de mettre à jour deux milliards d'ordinateurs à l'époque. Personne n'avait pensé au chiffrement des disques durs en cas de perte d'un ordinateur portable.

Personne n'y avait pensé, vous savez, à ces choses-là. Alors nous avons dû réfléchir à des choses auxquelles personne n'avait pensé auparavant.

Rob Ainscough :
Alors aujourd'hui, nous allons nous concentrer sur ça. Active Directory C'est une histoire, n'est-ce pas ? Donc, pour la plupart des entreprises, on parle encore du cloud et de toute la transition qui s'est opérée au cours des 10 ou 15 dernières années.

Mais la réalité, c'est que ça reste le centre névralgique de l'identité d'entreprise pour beaucoup de sociétés, n'est-ce pas ? C'est absolument essentiel. Et, comme on l'a dit, vous occupez une position vraiment intéressante, ayant été là depuis sa naissance, son développement et son évolution jusqu'à ce qu'il devienne ce qu'il est aujourd'hui. Je suis vraiment curieux de savoir d'où ça vient. Active Directory viens de?

À quoi était-il destiné ? Quel était votre objectif ? Active Directory à ce moment-là?

Aaron Turner :
Il faut donc d'abord se mettre dans la peau de Bill Gates au milieu des années 90. Bill Gates avait pour mission de bâtir une entreprise prospère, car il était constamment hanté par la crainte que ce qui était arrivé à Wang, ce qui était arrivé à Digital, se reproduise. Il suffit de regarder les nombreux échecs dans le secteur informatique des années 80 et 90.

Roy Akerman :
Mm.

Aaron Turner :
Il était donc obsédé par l'idée qu'il fallait absolument conquérir le marché. Il a donc fixé comme objectif à Novell de générer d'importants profits grâce aux annuaires d'entreprise. Novell était une entreprise très performante, pionnière dans ce domaine. Comment garantir une expérience informatique optimale aux utilisateurs ?

Comment créer un nom d'utilisateur et un mot de passe ? Comment organiser correctement ses fichiers ? Microsoft s'est alors dit : « Il faut qu'on vole cet argent. Il faut qu'on vole le budget de Novell. » C'est ainsi que la première version de… Active Directory Le cahier des charges était de tuer Novell. C'était, en gros, la mission.

Euh, on n'avait pas grand-chose d'autre, alors le reste était intéressant, pas vrai ? Par exemple, j'étais un grand fan de Kerberos. Kerberos était assez nouveau à l'époque. Le MIT venait de publier la norme Kerberos. Je me disais : « Kerberos, c'est génial ! Ça va vraiment être bien mieux. » Parce qu'on utilisait encore NTLM, pas vrai ?

NTLM, ce protocole extrêmement vulnérable et facilement réversible, avec des hachages cassés, etc. On parle encore de NT LAN Manager, un protocole Windows NT4. Le problème, c'est que si notre seul objectif est de neutraliser Novell, comment en faire un système de sécurité ?

Et c'est là que résidait la tension. Mm. Vous savez, nous autres, passionnés de sécurité, Active Directory Au départ, on y voyait plutôt un moyen de vendre plus de Windows, plus d'Office. C'était en quelque sorte… un mécanisme de déploiement. Ce n'était pas forcément une barrière de sécurité.

Roy Akerman :
Vraiment intéressant. Et, ouais, c'est intéressant d'être là et de reconstruire quelque chose d'autre, peut-être mieux, qui remplacera quelque chose qui, vous savez, a commencé à se développer.

Et, vous savez, je parie qu'il a fallu faire de nombreux compromis, n'est-ce pas ? Parce qu'il y avait le délai de commercialisation et plein d'autres choses, et un changement dans le monde de l'informatique. Pouvez-vous nous ramener en arrière, je ne sais pas, vers 98, peut-être un peu plus tard, et nous dire quels étaient les compromis initiaux sur lesquels les constructeurs et les concepteurs auraient dû se décider ?

Aaron Turner :
Eh bien, donc, euh, comme je l'ai mentionné, l'objectif de Active Directory L'objectif était de vendre plus de Windows et plus d'Office, n'est-ce pas ? La rapidité de déploiement, c'est ça ? Comment déployer un grand nombre de systèmes ? Et donc, dans cette course à la commercialisation, certaines fonctionnalités ont été négligées, comme l'authentification multifacteurs. L'AMF n'était pas un principe de conception fondamental. Active Directory, droite?

On se disait : « Peut-être que certains partenaires trouveront une solution. » Et des entreprises comme RSA et Gemalto, oui, ont proposé de s'en charger. Par exemple, l'une des tâches qui m'a été confiée était d'effectuer les tests de régression pour tous les jetons MFA tiers.

À cette époque, le seul moyen de faire fonctionner un jeton MFA était de remplacer GINA. Il fallait créer une interface GINA… Oh, c'est complexe ! Il s'agit d'opérations au niveau du noyau, sur un contrôleur de domaine Windows, parfois même sur le poste de travail. Disons que si je ne voyais pas 300 écrans bleus par jour, je ne faisais pas mon travail, pas vrai ?

Parce que ces directives GINA étaient mal rédigées. Chez Microsoft, nous avons fourni de mauvaises instructions à ce sujet, et donc, quand quelqu'un venait nous voir en disant : « Déployons l'authentification multifacteur », et qu'il faisait une preuve de concept et qu'il obtenait 10 écrans bleus, il disait : « Non, ça va. Je peux me passer de l'authentification multifacteur, merci. »

« Je ne veux pas utiliser l'authentification multifacteur. » Voilà un exemple de manque de concentration du point de vue de la sécurité, car aujourd'hui, nous considérerions l'authentification multifacteur comme essentielle, une fonctionnalité fondamentale qui doit être… Voilà un exemple. Autre exemple : nous avions ces barrières de sécurité, appelées forêts, n'est-ce pas ?

Il y avait les forêts, puis les domaines, et on pouvait créer des approbations entre forêts, et on pouvait avoir… hum… des approbations unidirectionnelles ou bidirectionnelles, etc. Et puis, il y avait les groupes, les groupes imbriqués, les objets de stratégie de groupe, etc. Tout cela était conçu de manière fonctionnelle…

Comme un déploiement Windows du point de vue du déploiement, et non du point de vue de la sécurité.

Rob Ainscough :
Oui.

Aaron Turner :
Comment imposer le niveau de granularité adéquat à une approbation inter-forêts ? Et au fait, concernant les licences Microsoft : une fois mises en place, la plupart des utilisateurs n’étaient pas incités à utiliser un compte de domaine pour l’administration du domaine et un autre pour leur serveur Exchange (notamment pour la boîte de réception).

Vous mélangeriez tout ça, n'est-ce pas ? Vous avez donc maintenant mélangé votre plan de contrôle : le même compte que vous utilisez pour lire vos e-mails est aussi celui que vous utilisez pour l'administration du domaine.

Roy Akerman :
Mm.

Aaron Turner :
N'est-ce pas ? Et donc, ce n'est pas une bonne situation.

Roy Akerman :
Ouais. Mm. Donc… on dirait qu’il y avait beaucoup de niveaux d’abstraction en matière de confiance, comme entre domaines et entre forêts.

Comment instaurer la confiance lorsqu'on crée une entité unique, différente des autres, qu'il faudra valider et authentifier pour établir cette confiance ? Je suis sûr que ce sujet a fait l'objet de nombreuses discussions.

Aaron Turner :
Eh bien, tout d'abord, même si d'autres avaient déjà essayé de le faire, par exemple AT&T avec une grande partie de son travail sur Unix, le gouvernement, vous savez, ce genre de choses, des gens avaient essayé de suivre cette voie, mais ils n'avaient jamais essayé de le faire à un coût total de possession aussi faible que celui que Microsoft essayait d'obtenir, n'est-ce pas ?

Mm-hmm. Donc, par exemple, concevoir un système d'authentification d'entreprise complexe avec des docteurs travaillant chez Bell Labs, c'est une chose. Les gens d'AT&T savaient ce qu'ils faisaient. Mais si vous prenez un administrateur système d'un hôpital local et que vous le nommez administrateur de domaine, l'administrateur système d'un hôpital local n'est pas comparable à un docteur travaillant chez Bell Labs.

Ce sont deux personnalités différentes. Ce sont deux profils différents. Et donc, en introduisant ces systèmes très performants (serveurs Windows, serveurs Exchange, serveurs SQL) dans des environnements d'entreprises de taille moyenne à faible, où l'architecture de sécurité et les équipes d'exploitation de la sécurité sont peut-être insuffisantes, cela a créé des situations très problématiques, du genre : « Pourquoi ne pas donner à tout le monde les droits d'administrateur de domaine ? »

Ça simplifie les choses. Tout le monde est administrateur de domaine.

Roy Akerman :
Oui.

Aaron Turner :
Et nous l'avons constaté, lorsque des administrateurs de domaine étaient chargés de gérer l'ensemble du domaine, tout simplement parce que c'était plus facile. Cela leur simplifiait la tâche. Ils n'avaient pas à chercher pourquoi telle ou telle application ne fonctionnait pas. Oui. Et si l'on considère la plupart des difficultés rencontrées à nos débuts, lorsque nous essayions d'appliquer le principe du moindre privilège, certaines des premières applications Adobe, par exemple, ne fonctionnaient pas sans des droits d'administrateur élevés.

Mm-hmm. Non, ça ne marcherait pas.

Rob Ainscough :
Courir. C'est courant, oui.

Aaron Turner :
Et voilà comment on se retrouve dans des situations de privilèges excessifs. Très souvent, l'écosystème des fournisseurs est contre vous, n'est-ce pas ? Imaginons que je veuille appliquer le principe du moindre privilège. Mais je ne peux pas, car j'ai besoin d'utiliser cette application.

Rob Ainscough :
Mm-hmm.

Aaron Turner :
Ah d'accord.

Roy Akerman :
Eh bien, c'est un élément à prendre en compte, car parfois on a tendance à blâmer les constructeurs d'infrastructures ou, vous savez, les éléments fondamentaux comme… Active Directory, qu'ils devaient également satisfaire à de nombreux autres besoins de développement, comme d'autres fournisseurs.

Et, et je pense encore une fois, ces compromis sont aujourd'hui le pain quotidien de nombreux attaquants, n'est-ce pas ? Oui. On parle non seulement de… Active Directory En tant qu'outil, mais aussi en tant qu'ensemble de concepts qui ont véritablement façonné notre conception actuelle de l'identité. J'espère donc ne pas aller trop vite dans cette voie, mais comme je le fais, je suis curieux.

Passons un instant à aujourd'hui. On y reviendra peut-être plus tard. Comme vous le voyez, la question de l'identité est un sujet brûlant d'actualité. Des sommes colossales ont été investies pour tenter de la résoudre. Elle évolue avec l'IA, l'assurance maladie nationale et bien d'autres concepts à la mode.

Comment voyez-vous les stratégies des attaquants et des défenseurs face à cela ? Quels sont les principes fondamentaux qui sont encore exploités, ou non, par les attaquants aujourd'hui ? Et quelles sont, encore une fois, les stratégies qui en découlent ?

Aaron Turner :
Commençons donc par examiner l'économie de l'identité, d'accord ? Prenons donc le montant total dépensé pour les pare-feu de 1999 à aujourd'hui.

Avant cela, en préparant ce projet, j'ai fait quelques recherches préliminaires. Disons que 250 milliards de dollars ont été dépensés en pare-feu ces 25 dernières années. Et combien a-t-on dépensé en gestion des identités ?

Rob Ainscough :
Oui.

Aaron Turner :
Peut-être 2 % de ça. Genre, vraiment pas, hein ? Je veux dire, juste une fraction. Et ça s'explique en partie par la stratégie de Microsoft qui consistait à… Active Directory au marché.

Ah, achetez une licence Windows Server, et au fait, vous obtenez ce système de gestion des identités gratuitement, gratuitement… Mm… inclus. Mm. Et donc, si on demande à un DSI : « Quelle est votre stratégie en matière d’identité ? », il répondra : « Eh bien, c’est… » Active Directory." Bien, Active Directory n'est pas une stratégie identitaire. Active Directory Il s'agit peut-être d'un système d'authentification.

Ce n'est pas une plateforme de gouvernance des identités. Ah oui. Ce n'est pas une plateforme de gestion des privilèges. Ce n'est pas une plateforme de fédération, n'est-ce pas ?

Rob Ainscough :
Mm.

Aaron Turner :
Donc, en raison de ce manque d'investissement, nous nous retrouvons avec une dette colossale en matière d'identité par rapport aux pare-feu, n'est-ce pas ? Oui. Alors que les pare-feu ont bénéficié d'une ligne budgétaire pendant 25 ans, l'identité, elle, n'en obtient qu'une depuis peu.

Voilà donc la question économique de l'identité qui a mis les gens dans une situation délicate. Si l'on part de ce constat, il faut d'abord se demander : « Comment allons-nous bouleverser nos systèmes d'identité traditionnels pour nous en sortir grâce à la transformation numérique ? » Par exemple, est-ce que je vais me débarrasser de ces problèmes d'identité en migrant vers des identités natives du cloud, ou est-ce que je vais devoir moderniser mes systèmes d'identité existants pour les consolider et les rendre durables ?

Roy Akerman :
Mm.

Aaron Turner :
Et donc, c'est la décision qui doit être prise, et malheureusement, la plupart des entreprises ne peuvent pas se sortir de ce problème par la seule disruption, elles vont donc devoir investir dans des solutions héritées pour se dire : « D'accord, que vais-je faire pour corriger 25 ans d'objets de stratégie de groupe défaillants et d'une infrastructure SCIM médiocre, et tout ce que j'ai mis en place ? »

On m'a posé, euh, une de mes questions préférées, à une personne très expérimentée. Active Directory L'administrateur de domaine demande : « Combien de fois avez-vous vérifié le nombre de GPO encore en circulation ? Par exemple, combien de GPO sont encore présentes dans Active Directory parce que vous ne les avez pas nettoyées ? »

Roy Akerman :
Mm.

Aaron Turner :
Et pour une organisation qui utilise Active Directory depuis, euh, deux décennies, il y a généralement des centaines de GPO inutilisées.

Rob Ainscough :
Oui

Aaron Turner :
Il était là, et… oui… quelqu’un l’a déployé. Personne n’a jamais été chargé de nettoyer les lieux, et c’est… c’est…

Rob Ainscough :
Dette latente. Et c'est vraiment intéressant parce que, comme vous le disiez, je vois des entreprises, lorsque je leur parle maintenant, qui se retrouvent en quelque sorte coincées au milieu du processus de consolidation de cette dette par rapport à sa modernisation, n'est-ce pas ?

Oui. Ni l'un ni l'autre ne maîtrisent particulièrement bien les outils existants, et ils se retrouvent un peu bloqués, se disant : « Bon, peut-être que dans cinq ans, je serai passé au cloud, à l'éphémère, et à toutes ces choses formidables qui, je le souhaite, amélioreront le monde. » Mais concrètement, qu'en est-il des cinq prochaines années, pendant lesquelles vos systèmes critiques fonctionnent encore ? Active Directory?

Que faisons-nous là ? Parce qu'il faut que ce soit intentionnel, n'est-ce pas ?

Roy Akerman :
Donc, c'est une complexité qui a commencé à engendrer une dette, une dette architecturale qui a conduit à une vulnérabilité.

Rob Ainscough :
Yep.

Roy Akerman :
Et, et encore une fois, comme toutes ces choses négligées, les GPO et les approches du genre « si ça marche, on ne touche à rien » et autres choses de ce genre nous ont amenés à un stade où c'est l'une des surfaces les plus vulnérables à l'attaque de notre époque.

Bien que nous parlions d'une technologie conçue en 28, et, euh, pardon, en 1998, et qui avait encore largement le temps de se corriger.

Aaron Turner :
Prenons un exemple. Vous savez, si l'on regarde la chaîne d'attaque d'une situation typique de ransomware-as-a-service… Mm-hmm… d'accord, le ransomware-as-a-service, si vous n'êtes pas familier avec ce terme, c'est lorsqu'un groupe de Russes a mis en place une plateforme de ransomware-as-a-service et que vous, en tant que franchisé, pouvez acheter leurs outils auprès d'eux, n'est-ce pas ?

Donc, oui, les RBA… ils vous vendent essentiellement des outils de vol d'informations, des outils de déplacement latéral. C'est comme un pack, vous obtenez ces outils. Tous ces outils dépendent d'une vulnérabilité LSASS. Donc, si vous considérez la pile logicielle… Active DirectoryCar s'ils peuvent accéder à LSASS sur un serveur Windows non patché, peu importe qu'il s'agisse d'un contrôleur de domaine.

Rob Ainscough :
Mm.

Aaron Turner :
Parce que LSASS, conçu en 1998, est prévu pour mettre en cache toutes les informations d'identification utilisées sur le serveur tant que le système est démarré, n'est-ce pas ? Or, du fait de l'importance accordée à la disponibilité, le processus LSASS continue de s'exécuter. Nous n'avons jamais conçu LSASS pour fonctionner indéfiniment. Nous l'avons conçu pour être redémarré, par exemple, une fois par semaine.

Du genre : « Non, on va juste actualiser ça », etc. Du coup, si un attaquant appartenant à un groupe de ransomware parvient à accéder à un serveur Windows non patché, et si le processus LSASS est actif depuis des mois, voire des années (ou aussi longtemps que le serveur est en service), alors toutes les informations d'identification utilisées sur ce serveur sont présentes.

Waouh. Et ils le peuvent, et ils les récupèrent tous, ce qui leur permet de se déplacer latéralement et de simplement se dire : « Hmm ». Et ensuite, les spécialistes du ransomware-as-a-service, ils récupèrent ce processus LSASS et leurs outils l'utilisent automatiquement pour voir : « D'accord, est-ce que je dispose d'identifiants d'administrateur de domaine ? D'accord, j'en ai un. »

Bon, je vais utiliser une GPO pour déployer mes outils de chiffrement… Oui, oui… et déployer ma gestion, et extraire mes données, et faire tout ce que j'ai à faire. C'est exactement ce qui se passe avec les ransomwares en tant que service. Ils n'ont besoin d'aucune compétence. Ils disposent des outils grâce à leur contrat de franchise avec le groupe de ransomware en tant que service.

Roy Akerman :
Mm.

Aaron Turner :
Voilà donc un exemple de LSASS conçu en 1998, un processus que nous n'avions jamais envisagé de fonctionner en continu. Or, comme il fonctionne désormais en continu, toutes ces informations d'identification restent latentes et peuvent être volées.

Rob Ainscough :
Mm.

Roy Akerman :
Et c'est toujours là. Et je pense que ça a aussi été transféré vers le cloud parce qu'on essaie encore d'établir la connectivité, n'est-ce pas ?

Donc on synchronise nos identifiants AD, euh, euh, ou… vous savez, avec le cloud, et on est tous au courant de toutes ces attaques, n'est-ce pas ?

Rob Ainscough :
Droite.

Roy Akerman :
Euh, et d'autres encore. Donc, le problème traîne en longueur, au lieu d'être résolu. Oui. Ou, comme vous l'avez dit, cela permet à de nombreux fournisseurs de venir ajouter des couches de protection supplémentaires.

Rob Ainscough :
Oui. Je trouve ça vraiment intéressant parce que, euh, du point de vue de la sécurité, nous sommes presque victimes du succès de Active DirectoryN'est-ce pas ? Avec les utilisateurs, vous savez, tous leurs ordinateurs Windows seront évidemment connectés. SQL Server, connectons-le. Oh, et pourquoi ne pas créer un pont entre Linux et Active Directory ?

On a commencé à développer ce risque systémique, puis le cloud est arrivé et a dit : « Tiens, synchronisons ces identifiants, pas vrai ? Simplifions-nous la vie ! » Résultat : le cloud est victime de son propre succès, ce qui, vous savez, nous rend beaucoup plus vulnérables face à ce risque systémique pour les entreprises.

Aaron Turner :
Beaucoup d'organisations ne comprennent pas ce que Active Directory est en train de servir.

Ils disent juste : « Oh, ça marche tout simplement », pas vrai ? Moi, je ne sais pas si c’est NTLM, NTLMv2, LDAP, Kerberos. Je ne sais pas exactement ce qui est utilisé.

Rob Ainscough :
Mm.

Aaron Turner :
Je pense donc que la première étape pour toute organisation est d'activer le suivi des succès, ce qui est coûteux et demande beaucoup de ressources. Toutes les organisations n'ont pas encore activé ce suivi.

La plupart des organisations disposent d'un système de journalisation des échecs, notamment lorsqu'une authentification échoue. La première étape consiste donc à activer temporairement la journalisation des succès et à vous assurer de disposer d'une capacité de stockage suffisante pour enregistrer tous ces journaux.

Rob Ainscough :
Yep.

Aaron Turner :
Vous avez donc maintenant ces journaux de succès. J'adore utiliser des outils, vous savez, des outils de données à faible coût, et des outils d'analyse.

Mon logiciel préféré, qui propose une version communautaire, s'appelle Gravwell (GRAV comme Victor). Cette version permet d'ingérer les journaux XML bruts d'un contrôleur de domaine et de créer des graphiques orientés force, par exemple pour visualiser tous les utilisateurs qui utilisent LDAP aujourd'hui, ou tous ceux qui utilisent LLM.

Je veux voir tous les serveurs qui envoient des requêtes Kerberos ou autres. Je peux donc maintenant créer ces zones visuellement, car nous, les humains, avons besoin de visualisation. C'est comme ça qu'on élabore des stratégies. Du coup, j'ai une visualisation qui me permet de me dire : « Mon Dieu, je n'avais pas réalisé que 1 500 utilisateurs dépendent d'un annuaire LDAP en clair ! »

C'est mauvais signe. Vous ne le saurez pas tant que vous n'aurez pas activé la journalisation des succès. Voilà pour la première étape. La deuxième étape consiste, maintenant que vous savez ce qui est en jeu, à éliminer les services qui utilisent ces technologies. Une de mes astuces préférées consiste à… Imaginons que vous ayez ces cinq serveurs qui utilisent LDAP.

Que font-ils ? Ah, c'est pour un système de conformité fiscale qui fonctionne avec une base de données Access. D'accord. Eh bien, prenons ces données, intégrons-les à une plateforme Power Platform, rendons-les natives du cloud et supprimons ce serveur. Comme ça, je n'ai plus à me soucier de LDAP, pas vrai ? J'ai éliminé la source du problème tout en répondant au besoin métier, car je peux exécuter cette base de données Access sur la plateforme Power Platform.

Je n'ai plus besoin de ce serveur. Comment puis-je moderniser mon infrastructure pour éliminer cette dépendance ? Enfin, une fois cette étape franchie, comment puis-je mettre en place des stratégies d'identité segmentées, en séparant la gestion des privilèges dans le cloud de celle sur site ?

Je vais distinguer les travailleurs du savoir des utilisateurs privilégiés. Je vais procéder à une segmentation des identités qui soit pertinente. D'ailleurs, en 2020, la NSA a publié, à mon avis, l'un des documents déclassifiés les plus importants concernant l'identité, révélant comment elle a infiltré le Trésor américain et obtenu des fonds russes.

Voici donc un compte rendu détaillé de six mois de lutte entre la NSA et les Russes, et bravo à eux d'avoir eu l'humilité de le faire car peu de gens auraient levé la main et dit : « Hé, il nous a fallu six mois pour régler ce problème. » Et c'est ce qu'ils ont fait, et dans ce document, ils expliquent en détail : « Voyez… » Le problème fondamental était que le Trésor disposait de cinq plans d'identité.

Ils utilisaient Active Directory sur site, AD FS pour la synchronisation avec Entra (qui s'appelait alors Azure AD), Okta et Duo. Ils disposaient donc de cinq couches d'identité différentes. Et ce qui est intéressant, c'est que beaucoup disent : « J'ai déjà migré vers le cloud car j'utilise Okta. »

Je n'ai jamais vu un projet Okta fonctionner sans Active DirectoryOuais. Genre, j'ai jamais vu un truc Okta de base fonctionner tout seul.

Rob Ainscough :
C'est ce que je veux dire, c'est le centre névralgique, n'est-ce pas ? C'est, c'est suspendu à cette sécurité fondamentale de Active Directory au coeur.

Aaron Turner :
Oui. Et donc, dans l'étude de cas de la NSA, où ils parlent de ce qui est arrivé au Trésor, les Russes se cachaient parce que la NSA s'approchait, et disons qu'ils s'approchaient avec Active Directory Des signes de compromission, et ils se lançaient à leur poursuite, puis les Russes partaient vivre quelque temps à l'intérieur d'Okta, et ils vivaient de la terre à Okta.

Puis ils s'approchaient d'Okta, puis allaient un petit moment à Duo. Ils s'approchaient encore à Duo, puis allaient à Entra. Et une fois à Entra, ils s'approchaient encore et allaient à AD FS. En gros, ils se déplaçaient là où, comme des cafards, la lumière ne pénétrait pas, et c'est ainsi qu'ils vivaient.

Je recommande donc vivement de simplifier au maximum votre système d'identité. Éliminez l'utilisation de… D'ailleurs, dans le livre blanc de la NSA, à la page trois, ils affirment : « Si vous utilisez Exchange Online, vous êtes fou d'utiliser Entra Protect. » C'est très clair.

Vous devriez être très vigilant quant à votre utilisation de l'identité dans le cloud.

Roy Akerman :
Mm-hmm. Je pense que cette histoire est plausible. Cependant, la segmentation est vraiment très complexe. Il faut connaître les ressources. Nous devons connaître les applications internes, l'essence même de l'accès, n'est-ce pas ? Donc, euh, je crois que même le Trésor disposait de cinq fournisseurs d'identité (IdP), ou plutôt de cinq annuaires différents qui devaient être synchronisés. Et chacun d'eux était probablement géré par une entité différente, n'est-ce pas ?

En raison de cette complexité de segmentation… Hm… euh… vous savez… certains actifs ou ressources auxquels nous essayons d'accéder… Euh… je me demande si vous avez probablement constaté la même chose dans la grande enseigne de distribution où vous travailliez, en tant que responsable de la gestion de l'information. Combien de… euh… des dizaines, des centaines de milliers… d'identités humaines, sans parler des identités non humaines, n'est-ce pas ?

Ouais,

Rob Ainscough :
Absolument. Donc je dirais 400 000 personnes dans l'entreprise. Oui. Euh, vous savez, entre 400 000 et 500 000… ça dépend de la période de l'année, c'est énorme…

Roy Akerman :
Une segmentation, ouais, la segmentation, c'est un gros mot ou, en fait, c'est possible ?

Rob Ainscough :
Je pense que c'est possible. Il y a deux choses importantes. Premièrement, il faut changer de mentalité quant au rôle de l'identité, et comprendre qu'elle ne sert pas uniquement à protéger les comptes ou à ajouter l'authentification multifacteur.

Votre rôle est de protéger ce qui compte pour votre entreprise. Et comme vous le dites, il est essentiel de comprendre ce qui compte, de comprendre les flux d'authentification et les modalités d'accès, puis de concevoir les règles correspondantes. Pour cela, il est primordial de disposer d'une technologie qui vous permette de le faire efficacement.

Ce n'est pas chose facile à cette échelle. C'est d'autant plus difficile face à une telle fragmentation et une telle complexité. Mais je pense que la première étape consiste à adopter cette approche, puis à se forger une vision d'ensemble pour comprendre la situation, afin de pouvoir ensuite agir. Car, vous le savez, il est impossible de tout protéger partout et en même temps, mais vous pouvez faire des progrès significatifs pour protéger ce qui compte vraiment pour votre entreprise.

Aaron Turner :
Donc tu as besoin

Roy Akerman :
pour voir la

Rob Ainscough :
forêt entière

Aaron Turner :
avant

Rob Ainscough :
Vous êtes en train de… Exactement… de faire ça.

Roy Akerman :
Exactement.

Rob Ainscough :
Et

Roy Akerman :
alors vous

Aaron Turner :
Effectuez les contrôles appropriés.

Roy Akerman :
Quelles leçons nos adeptes peuvent-ils tirer, A, de la manière dont les cartels utilisent la technologie pour mener leurs opérations, euh, fluides, et d'autre part, de la manière dont l'identité peut être manipulée, compromise, dupliquée, du côté des forces de l'ordre ?

Ouais, on dirait qu'on est en train de construire un épisode très intéressant. Intéressant.

Rob Ainscough :
C'est tout pour cet épisode d'Identity Decoded.

Aaron Turner :
Si cette conversation a changé quoi que ce soit à votre réflexion sur la sécurité de l'identité, partagez-la avec quelqu'un qui travaille dans ce domaine.

Roy Akerman :
à travers les mêmes défis.

Rob Ainscough :
Et n'oubliez pas de suivre l'émission pour ne rien manquer !

suivant.

Identité décodée

avec Roy Akerman et Rob Ainscough

Abonnez-vous pour ne jamais manquer un nouvel épisode.