- Andrew Harris, ancien employé de Microsoft, affirme avoir découvert en 2016 la vulnérabilité Golden SAML dans AD FS et avoir demandé pendant des années qu’elle soit traitée, mais que l’entreprise aurait évoqué uniquement une alternative à long terme plutôt qu’un correctif immédiat
- Cette vulnérabilité permet, après le vol de la clé privée d’un serveur AD FS, d’accéder à des services cloud comme un utilisateur légitime au moyen de jetons falsifiés ; elle laisse peu de traces dans les journaux d’audit et peut aussi contourner l’authentification multifacteur
- La désactivation du seamless SSO proposée par Harris se heurtait aux inquiétudes liées à la gêne pour les clients du gouvernement fédéral, au contrat cloud du Pentagone, à la concurrence avec Okta et à la dégradation de l’expérience utilisateur
- Après l’attaque SolarWinds de 2020, des hackers russes ont exploité cette faiblesse pour collecter des données sensibles auprès de la National Nuclear Security Administration, des NIH, du Treasury Department, entre autres ; Microsoft a ensuite recommandé aux clients Microsoft 365 de désactiver le seamless SSO d’AD FS
- Microsoft affirme que la protection des clients est sa priorité absolue et que les questions de sécurité ont été examinées à plusieurs reprises, mais les témoignages d’anciens employés mettent en lumière un cas de conflit entre culture de sécurité et priorités business
La vulnérabilité Golden SAML découverte dans AD FS
- Andrew Harris travaillait chez Microsoft au sein de Ghostbusters, une équipe secrète chargée de répondre aux incidents de piratage touchant des clients sensibles ; en 2016, alors qu’il enquêtait sur la compromission d’une grande entreprise technologique américaine, il s’est concentré sur un problème d’AD FS
- AD FS est un produit qui permet aux utilisateurs d’accéder à plusieurs applications professionnelles après une seule connexion, et il est utilisé par des millions de personnes
- Le risque principal identifié par Harris était que, dans l’authentification basée sur SAML, un attaquant puisse se faire passer pour un employé légitime afin d’accéder à des programmes hébergés dans le cloud
- L’attaquant commence par s’introduire dans un serveur on-premise, puis extrait la clé privée du serveur AD FS
- Il peut ensuite falsifier des jetons et apparaître comme un utilisateur doté de privilèges élevés
- Comme les informations de connexion semblent normales, la détection via les journaux d’audit classiques est difficile
- Harris estimait que ce problème pouvait toucher non seulement Microsoft Azure, mais aussi les organisations utilisant d’autres fournisseurs cloud comme Amazon
« security boundary » et l’évaluation du MSRC
- Harris a signalé le problème au Microsoft Security Response Center, ou MSRC, mais celui-ci a estimé qu’il ne nécessitait pas de correction
- Le MSRC considérait que, puisqu’un attaquant devait d’abord accéder au serveur on-premise, ce point constituait la frontière de sécurité, et que le passage ultérieur vers le cloud ne représentait pas une frontière de sécurité distincte
- D’anciens employés du MSRC expliquent qu’à l’époque, le centre traitait de nombreux rapports de vulnérabilités avec des effectifs insuffisants, et qu’il existait une culture conduisant à conclure « won’t fix »
- Ils se souviennent que l’expression « security boundary » n’était alors pas clairement définie et qu’elle était souvent utilisée comme motif pour que Microsoft ne corrige pas un problème
- Dans une note de 2002, Bill Gates avait écrit qu’entre l’ajout de fonctionnalités et la résolution de problèmes de sécurité, il fallait choisir la sécurité, mais d’anciens employés affirment que l’influence du MSRC s’est affaiblie avec le temps
Une solution temporaire en conflit avec la logique business
- Harris estimait qu’un correctif à long terme pouvait prendre du temps et a proposé, comme solution temporaire, de désactiver le seamless single sign-on (SSO)
- Cette fonctionnalité de confort de Microsoft permet à un utilisateur, après une seule connexion, d’accéder à des serveurs on-premise et à plusieurs services cloud
- Selon Harris, le responsable produit Mark Morowczynski s’y est opposé, estimant que la divulgation de la vulnérabilité pourrait donner des indices aux attaquants et causer de gros désagréments aux clients du gouvernement fédéral
- Les employés du gouvernement fédéral devaient, conformément aux règles, se connecter avec une carte à puce
- Si le seamless SSO était désactivé, l’accès au cloud nécessiterait une seconde connexion, et la carte à puce obligatoire ne pourrait pas être utilisée dans ce processus, explique Harris
- Le grand contrat cloud du Pentagone et la concurrence avec Okta ont aussi été cités comme raisons d’opposition
- Microsoft était alors en concurrence avec Okta, et le seamless SSO faisait partie de ses avantages concurrentiels
- La proposition de Harris créait une friction obligeant les utilisateurs à s’authentifier deux fois, en contradiction avec la stratégie produit
- Harris se souvient que Morowczynski aurait qualifié cette décision non pas de décision technique, mais de décision business
Les alertes d’entreprises de sécurité externes
- En 2017, CyberArk a publié un billet de blog et une preuve de concept décrivant cette technique sous le nom de Golden SAML
- Brad Smith a ensuite écrit, dans une réponse écrite au Senate Intelligence Committee, que Microsoft avait pris connaissance du problème lors de la publication de CyberArk en 2017
- Lavi Lazarovitz, de CyberArk, affirme qu’avant la publication, le problème avait été partagé dans une discussion WhatsApp privée réunissant des chercheurs en sécurité de plusieurs entreprises, dont un chercheur de Microsoft
- Harris explique qu’après la publication de CyberArk, il a jugé le problème plus urgent et l’a de nouveau porté auprès du groupe produit et du MSRC, mais que le MSRC a maintenu sa position initiale
- En 2019, des chercheurs de Mandiant ont démontré lors d’une conférence en Allemagne comment une compromission d’AD FS permettait d’accéder à des comptes cloud et à des applications, et ont également publié un outil
- Mandiant indique avoir informé Microsoft avant sa présentation
- C’était la deuxième fois, en environ 16 mois, qu’une entreprise externe signalait à Microsoft un problème lié à SAML
Les avertissements de Harris aux clients et le cas du NYPD
- En 2019, Harris a publié sur LinkedIn une alerte indirecte, invitant ceux qui connaissaient quelqu’un ne comprenant pas les relations d’authentification AD FS à le contacter
- Il a tenté d’informer directement les clients avec lesquels il entretenait déjà une relation, dont le New York Police Department
- Harris a expliqué la faiblesse d’AD FS à Matthew Fraser, responsable IT du NYPD, et lui a recommandé de désactiver le seamless SSO
- Fraser a confirmé cette réunion et indiqué que la faiblesse SAML avait été identifiée comme un domaine nécessitant protection et isolation
- Harris a quitté Microsoft en août 2020 pour rejoindre CrowdStrike, et affirme avoir de nouveau soulevé la faiblesse SAML lors de son entretien de départ
Contournement de l’authentification multifacteur et attaque SolarWinds
- Harris explique avoir compris, lors d’une conversation avec un collègue en 2018, qu’un attaquant disposant de jetons falsifiés pouvait aussi contourner l’authentification multifacteur
- Le problème était que, même avec des étapes de sécurité supplémentaires, un attaquant possédant un jeton falsifié pouvait toutes les ignorer
- Fin 2020, l’attaque SolarWinds a été rendue publique, et le gouvernement américain a déclaré qu’elle impliquait des hackers soutenus par l’État russe
- Les attaquants ont inséré un malware dans une mise à jour logicielle de SolarWinds pour obtenir un accès backdoor aux réseaux, puis ont exploité des vulnérabilités post-compromission comme Golden SAML afin de voler des données cloud et des e-mails
- Les attaquants ont exploité la faiblesse signalée par Harris pour collecter des données sensibles dans plusieurs organismes
- National Nuclear Security Administration
- National Institutes of Health
- plusieurs comptes e-mail du Treasury Department
- Brandon Wales, alors à la CISA, a déclaré qu’environ un tiers des victimes n’utilisaient pas le logiciel SolarWinds
- Microsoft a également été compromise et, juste après l’attaque, l’entreprise a recommandé aux clients Microsoft 365 de désactiver le seamless SSO dans AD FS et les produits similaires
Position publique de Microsoft et mesures ultérieures
- En 2021, le président de Microsoft, Brad Smith, a déclaré devant le Congrès qu’aucune vulnérabilité de produit ou service Microsoft n’avait été exploitée dans l’attaque SolarWinds
- Smith a expliqué que Golden SAML avait été utilisé dans 15 % des 60 cas identifiés par Microsoft, tout en reconnaissant que les victimes chez qui des données avaient été observées ou volées ne se limitaient pas à ces cas
- Smith a déclaré que si les organisations avaient pris plusieurs mesures, comme l’achat d’un antivirus tel que Microsoft Defender et la protection des appareils avec Intune, elles n’auraient presque pas subi de dommages
- Après SolarWinds, Microsoft a pris des mesures pour atténuer le risque SAML, et les fonctionnalités permettant de détecter efficacement les effets du piratage ont été incluses dans Sentinel, un produit additionnel payant
- Dans un billet de blog, Microsoft a qualifié cette absence de détection de « blind spot »
Les démentis de Microsoft et la controverse sur la culture de sécurité
- Microsoft n’a pas rendu disponibles pour des interviews des dirigeants de haut rang comme Brad Smith, mais n’a pas contesté les conclusions de l’enquête de ProPublica
- Dans une réponse écrite, l’entreprise a affirmé que la protection des clients était toujours sa priorité absolue, que ses équipes de réponse sécurité traitaient tous les problèmes avec sérieux et que ceux-ci faisaient l’objet d’évaluations manuelles ainsi que d’examens par des partenaires en ingénierie et en sécurité
- Microsoft explique que, lors de l’évaluation des menaces potentielles, elle prend en compte la possibilité d’interruption pour les clients, la probabilité d’exploitation et les mesures d’atténuation disponibles
- En 2023, un incident dans lequel des hackers liés au gouvernement chinois ont exploité une faille de sécurité de Microsoft pour accéder aux e-mails de hauts responsables américains a également fait l’objet d’une enquête du House Homeland Security Committee
- Dans son enquête sur cet incident, le Cyber Safety Review Board a estimé que la culture de sécurité de Microsoft était inadéquate et nécessitait une refonte complète
- Après le rapport du conseil, Satya Nadella a demandé aux employés de choisir la sécurité lorsqu’elle entre en conflit avec d’autres priorités
Concurrence dans le cloud et conséquences
- Satya Nadella, devenu CEO en 2014, a misé l’avenir de Microsoft sur l’activité cloud Azure, alors très en retard sur Amazon
- Microsoft a proposé aux entreprises et aux clients gouvernementaux une stratégie de cloud hybride, consistant à conserver une partie des serveurs on-premise tout en déplaçant la majeure partie du calcul vers le cloud
- La sécurité était un argument central dans la vente du cloud, avec l’avantage présenté que des équipes de sécurité dédiées prendraient en charge les correctifs et les mises à jour
- Harris et d’anciens employés affirment que le grand contrat cloud du Pentagone et la pression liée à la croissance d’Azure ont influencé les décisions de l’équipe produit
- Microsoft a finalement obtenu, aux côtés d’Amazon, Google et Oracle, une partie du programme cloud pluriannuel du Department of Defense, d’un montant de plusieurs milliards de dollars
- Après la publication de SolarWinds, l’action Microsoft a progressé de 106 %, principalement portée par le succès d’Azure et de produits d’IA comme ChatGPT
- Le produit de remplacement à long terme d’AD FS que Morowczynski aurait mentionné à Harris en 2017 a commencé à être proposé en 2022
1 commentaires
Commentaires Hacker News
La solution consiste à appliquer un zéro trust complet au sein de l’organisation et à ne pas faire confiance au réseau. Le réseau interne doit lui aussi être traité comme l’extérieur, c’est-à-dire comme un environnement hostile.
Google a été l’un des premiers exemples d’adoption à grande échelle du zéro trust avec BeyondCorp, et je pense qu’il n’y a pas eu de compromission de l’organisation interne de Google depuis Aurora.
Il faut des endpoints entièrement administrés, un durcissement fort des endpoints, un inventaire complet de toutes les ressources de l’organisation, des certificats par appareil, et un moteur de listes de contrôle d’accès qui décide de l’accès aux ressources par utilisateur.
On peut aussi détecter des anomalies avec des heuristiques comme les horaires de travail, et toutes les applis internes de Google sont exposées sur Internet et redirigent vers un portail SSO, mais en réalité on ne peut pas y entrer. Une bonne partie de ces problèmes de sécurité est déjà résolue ; il ne reste qu’à l’implémenter.
La plupart des grandes organisations ont accumulé des technologies internes et externes pendant des décennies ; les anciens systèmes sont de fait laissés à l’abandon, et l’hétérogénéité est forte à cause des fusions-acquisitions et de la liberté laissée aux départements de choisir leurs outils.
Passer au zéro trust nécessite une migration massive, de la « formation » pour convaincre des responsables IT récalcitrants, ainsi qu’une transition vers le modèle centralisé à la Google.
Même si les deux premiers points obtiennent un budget, le troisième peut coûter très cher. L’une des raisons pour lesquelles Google abandonne beaucoup de choses est aussi que, dans un modèle centralisé, il faut continuellement migrer et effectuer des mises à niveau cassantes.
Dans une startup, on aimerait offrir aux clients cette uniformité fondée sur les bonnes pratiques, mais un jour un client pourra demander à « désactiver le zéro trust et utiliser une liste blanche d’IP ». On peut hésiter à accepter pour décrocher un gros contrat, et on ne peut pas non plus annuler une acquisition uniquement parce que l’entreprise rachetée n’a pas de zéro trust.
Au contraire, pour la plupart, cela ressemble à des défis extrêmement difficiles, et à une réponse du type « il suffit de dessiner tout le hibou ». Imaginez par exemple Shaw Industries, le plus grand fabricant américain de moquettes et de revêtements de sol, avec 22 000 employés, essayer de faire cela.
Si l’on adopte une attitude consistant à se croire absolument « en sécurité », on cesse de chercher activement les compromissions, et l’on finit par rater celle qui arrivera un jour.
Le zéro trust est une philosophie, et une assez bonne philosophie, mais ce n’est pas une solution en soi. Il vaut mieux y penser comme à une philosophie et à de bonnes pratiques que comme à une solution absolue.
Je ne pense pas que ce type d’architecture convienne à toutes les entreprises. La plupart des entreprises technologiques qui ne font pas du logiciel subissent des dommages à cause de simples attaques d’ingénierie sociale, d’e-mails frauduleux ou de problèmes de transmission d’identifiants à des tiers, et l’espionnage économique est aussi une menace importante.
Google peut avoir d’autres préoccupations de sécurité, comme des lanceurs d’alerte internes ou des groupes d’activistes en conflit avec la vision de la direction, et cette structure peut être adaptée à ce type de problèmes. Mais cela ne signifie pas que tous les vecteurs de menace de toutes les entreprises soient identiques.
Les problèmes de sécurité peuvent être résolus, mais l’infrastructure nécessaire n’est pas triviale, et de nombreuses stacks logicielles d’ingénierie ne prennent tout simplement pas en charge l’authentification par des tiers.
Les développeurs, même lorsqu’ils ne sont pas développeurs logiciel, sont souvent réticents face aux « endpoints administrés ». Cela fonctionne chez Google, mais c’est plutôt un cas particulier ; dans la réalité, une segmentation réseau raisonnable peut être bien plus efficace.
Le décalage des incitations entre sécurité et profits est difficile à corriger sans un immense changement culturel, surtout dans les entreprises cotées. Je ne sais même pas ce qui pourrait déclencher un tel changement.
J’ai fait de la cybersécurité en parallèle de plusieurs rôles, mais si je n’en ai pas fait mon métier à plein temps, c’est à cause de ce que j’ai vu directement dans le secteur. L’accent est massivement mis sur la conformité plutôt que sur de véritables bonnes pratiques de sécurité, et les critères eux-mêmes sont insuffisants ou faiblement appliqués.
Il faut un changement culturel, mais je pense qu’il doit venir du côté des clients. Ce sera difficile pour les consommateurs, mais si les clients entreprises évaluent correctement la sécurité, exigent des garanties contraignantes et prennent leurs décisions d’achat en conséquence, le secteur réagira.
Bien sûr, Microsoft est tellement ancré sur le marché du desktop qu’il sera difficile pour cette approche d’être pleinement efficace.
Mais c’est aussi une réaction directe à l’absence de culture qui se soucie de la sécurité. Les équipes sécurité n’ont généralement que deux options :
soit dire « la sécurité est importante, construisons des produits sûrs » et se faire tourner en ridicule, soit utiliser la conformité exigée par les auditeurs pour faire avancer les choses, ne serait-ce qu’un tout petit peu, vers plus de sécurité.
Les particuliers aussi choisissent parfois l’argent plutôt que la sécurité. Les gouvernements semblent eux aussi avoir choisi une main-d’œuvre plus productive plutôt que des coûts plus élevés et une productivité plus faible.
Quand une entreprise vend à l’État, l’argent qu’elle peut gagner et l’effet de communication sont tellement importants qu’il existe une incitation à cacher les vérités qui dérangent. Cela rappelle un certain constructeur aéronautique
Cela peut aller du simple fait de dissimuler quelque chose d’un peu embarrassant jusqu’à une fraude massive, systématique et délibérée, et finir avec le temps par couvrir tout le spectre
Si les dirigeants disent « privilégiez la sécurité/la qualité » sans réellement la récompenser, le terrain est déjà préparé
Si l’on récompense ou punit chaque jour en fonction d’objectifs financiers, puis qu’on ne sanctionne qu’un ou deux subalternes quand on se fait prendre de temps en temps, ce que l’entreprise prend au sérieux, c’est l’argent, pas la sécurité/la qualité
Pour atteindre un objectif, il faut mettre en place des incitations. La vente est très stressante et on peut facilement s’y faire licencier, mais en cas de succès on peut gagner beaucoup d’argent. En sécurité, le succès signifie seulement ne pas être licencié, et l’échec signifie l’être
Le résultat d’un bon travail de sécurité, c’est « rien ne se passe » : pas d’intrusion, pas de catastrophe, pas de remue-ménage, ce qui est aussi difficile à mesurer. C’est le problème de quantifier une absence
Au final, les ventes ont beaucoup de carottes et les mêmes bâtons que tout le monde, alors que la sécurité n’a pas de carotte, seulement le bâton, et ce bâton peut être une batte cloutée. La réponse est dans la culture, et je pense que changer la culture est ce qu’il y a de plus difficile
Il ne faut pas attendre des commerciaux qu’ils se préoccupent de sécurité ; leur priorité doit être la croissance. Le problème est de ne pas donner au camp d’en face l’autorité et le périmètre nécessaires pour dire « non » quand les correctifs de sécurité doivent passer avant les nouvelles fonctionnalités
Si un chef de projet incité à la croissance décide des priorités, il choisira naturellement la croissance plutôt que la sécurité
Ce n’est pas que l’équipe sécurité ignore les problèmes ; c’est que les corrections ne deviennent pas prioritaires et que la culture comme les processus ne parviennent pas à équilibrer les deux côtés
Côté gouvernement aussi, au moins pour la carrière des décideurs individuels, il existe de fortes incitations à ce que le contrat soit conclu
Les deux parties veulent que la transaction se fasse, et ont intérêt à cacher les défauts tant que l’utilisateur final ne s’en aperçoit pas avant de partir à la retraite
Le modèle de priorité à la sécurité façon Microsoft, quand Satya Nadella dit : « si vous devez choisir entre la sécurité et une autre priorité, la réponse est claire : faites la sécurité », me semble être ceci
On met des publicités dans tous les recoins de Windows, on installe un enregistreur qui journalise tout ce que fait l’utilisateur, on envoie un e-mail aux employés disant « faites de la sécurité », et mission accomplie
Cela m’a fortement donné l’impression que la plupart des formations, e-mails et processus servent surtout à assurer une dénégation plausible
Chez Microsoft, il y a aussi des gens qui se soucient sincèrement de la sécurité. J’en ai rencontré moi-même. Mais dans l’ensemble, ces dispositifs permettent à Satya de dire devant un tribunal ou le Congrès : « nous leur avons dit de mieux faire en sécurité ; c’est la faute de l’équipe produit ou de contributeurs individuels, pas celle de la politique et des incitations de Microsoft »
La formulation d’un e-mail ne pèse rien. Dès qu’un dirigeant choisit de troquer la sécurité contre autre chose, le signal nécessaire a déjà été envoyé aux employés
Je pense à la controverse autour du fait que Canonical enregistrait les recherches via la touche Super, et aux publicités Amazon présentes par défaut dans Ubuntu
Les passionnés d’informatique peuvent installer Arch, Gentoo ou NixOS Minimal et auditer les paquets, mais il est irréaliste d’attendre de la plupart des non-ingénieurs logiciels qu’ils fassent de même
Pas seulement Microsoft : toutes les entreprises ont toujours intérêt à afficher autant de publicités que possible et à collecter un maximum de données. Je ne suis pas sûr de soutenir la régulation, mais je ne vois pas vraiment d’autre solution
Comme toujours, le poncif des dirigeants sur la « priorité à la sécurité » n’a pas d’importance
Si l’on récompense et promeut les gens pour des fonctionnalités sans récompenser une culture de sécurité, les personnes et les échelons de management ne sont pas idiots et optimiseront dans ce sens
Je ne sais pas comment concevoir ces incitations pour résoudre le problème, mais les choses continueront à aller dans cette direction
Tant que les responsables ne seront pas sanctionnés et que personne ne paiera le prix, il ne se passera probablement rien
En général, une fonctionnalité entre dans le produit quand le marketing montre qu’elle génère plus de croissance business que son coût. On peut appliquer la même idée
Du genre : « cette vulnérabilité affecte X % des clients, Y % partiront, et les dégâts de réputation entraîneront une grosse perte financière. En revanche, on peut la corriger pour une petite somme en Z jours. Décision ? »
Je pense qu’un indice assez important est négligé dans cette histoire. Désactiver le SSO transparent a des effets larges et particuliers sur les cartes à puce physiques que les employés du gouvernement utilisent pour se connecter à leurs appareils
Ces cartes, requises par les règles fédérales, génèrent un mot de passe aléatoire à chaque connexion, mais en raison de la configuration de la technologie sous-jacente, supprimer le SSO transparent empêche les utilisateurs d’accéder au cloud avec leur carte à puce
Le gouvernement américain est l’un des plus gros clients de Microsoft, avec une base d’utilisateurs et une échelle Active Directory énormes. Pour avoir travaillé dans ce domaine, la gestion des utilisateurs et des rôles est presque un cauchemar, avec des identifiants compromis, des comptes verrouillés, etc., et elle est constamment ciblée
Le gouvernement américain essaie depuis longtemps de faire basculer tout le monde vers l’authentification par carte à puce afin de réduire ce type de problèmes ; supprimer les mots de passe et passer tout le monde à l’authentification à deux facteurs réduit fortement la surface d’attaque
Or, ce que cette personne proposait revenait à dire aux clients de simplement la désactiver dans le cadre du correctif
Je ne nie pas le risque lié à la faille SAML initiale, mais je pense que Harris a jugé injustement le reste de la réponse de Microsoft. C’est comme s’il avait demandé de désactiver l’authentification à deux facteurs à l’échelle de toute une agence
La mesure d’atténuation à court terme aurait fortement dégradé la sécurité et aurait pu exposer davantage les clients précisément au type d’attaques qu’ils cherchaient à empêcher. Cette histoire a été présentée comme un énième exemple d’une entreprise qui se moque de la sécurité, mais cela ressemble plutôt à la réaction d’un « lanceur d’alerte » qui avait une vision étroite de la posture de sécurité globale du client
La plupart des administrateurs de systèmes de sécurité informatique des agences gouvernementales auraient probablement dit, pour les mêmes raisons, que ce n’était pas une option viable
C’est finalement le propos de l’article. Ils ont continué à vendre en sachant qu’il n’existait aucun moyen de le gérer en toute sécurité
Je ne cherche pas à défendre Microsoft, mais je ne sais pas si l’on peut citer précisément une entreprise qui place la sécurité avant le profit
Bill Gates disait en 2002 que « s’il faut choisir entre ajouter des fonctionnalités et résoudre des problèmes de sécurité, il faut choisir la sécurité », et Satya Nadella a tenu le même genre de propos en 2024 en disant de « faire de la sécurité »
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
https://www.theverge.com/24148033/satya-nadella-microsoft-se...
Il y a effectivement des fonctionnalités que j’utiliserais et pour lesquelles je paierais davantage, mais qu’ils ne développent pas parce que le protocole ne serait pas totalement sûr ou parce qu’il faudrait l’intégrer à des clients de calendrier classiques
Si les clients qui paient n’accordent pas de valeur à la sécurité, alors, en l’absence de réglementation ou d’obligation légale, le fournisseur ne lui en accordera pas non plus
Mais quand on pense que les grandes organisations et les gouvernements sont des clients de Microsoft, ce cas est étrange. Il y a peut-être eu une arrogance du type « cela ne nous arrivera pas » ou « personne ne le saura »
Ils constatent probablement maintenant que les dégâts de réputation risquent aussi de nuire aux profits futurs
Imaginez qu’un grand pont ait été construit par une entreprise de BTP. Un inspecteur de sécurité interne a averti à plusieurs reprises ses supérieurs d’un défaut structurel pouvant entraîner un effondrement, puis, avec le temps, deux alertes publiques externes ont également été émises, mais l’entreprise en a minimisé l’importance
Le pont finit par s’effondrer, et l’on découvre que l’entreprise n’a rien fait parce qu’elle ne voulait pas perdre des contrats de vente pour d’autres ponts défectueux
Le public serait à juste titre furieux, et les personnes concernées subiraient des conséquences judiciaires. Je ne vois pas ce qui est différent dans notre secteur au point de permettre à des entreprises et à des managers de faire passer une telle malveillance
Tant qu’il n’y a pas assez de vies sacrifiées, les gens ne semblent généralement pas vraiment s’en soucier
https://www.nrk.no/innlandet/statens-vegvesen-legg-fram-rapp...
Le logiciel ne met pas immédiatement des vies en danger. C’est pourquoi, à part dans la santé et l’aérospatial, on fonctionne presque comme au Far West
Voir des données personnelles fuiter sur Internet est terrible, mais comparé à une porte d’avion qui se détache, il reste tout de même du temps pour agir
Le gouvernement pourrait commencer à faire évoluer les choses en exigeant, dans les contrats de logiciels vendus à l’État, la signature et l’approbation d’une personne titulaire d’une licence
Le téléphérique du Mottarone l’était clairement. Il a fonctionné pendant des années avec le dispositif de sécurité désactivé, et lorsque le câble de traction a rompu, la cabine a dévalé vers le bas, tuant tous les passagers
Golden SAML est moins une vulnérabilité qu’un type d’attaque qui, comme le rappelle l’article de CyberArk cité dans le texte, nécessite d’abord de compromettre complètement la machine.
À moins que je n’aie mal compris quelque chose, je ne vois pas de faille précise. Pour reprendre la formule moqueuse de Microsoft citée dans l’article, ce n’est pas un franchissement de frontière de sécurité.
Le SSO implique toujours ce genre de compromis. Si l’infrastructure SSO est compromise, tout ce qui l’utilise risque de l’être aussi.
Ce point est survolé, mais j’ai l’impression que le vrai « piratage » se situe plutôt là.
Tant qu’on utilise le SSO, l’atténuation n’est pas simple non plus. Une méthode consiste à faire en sorte que le service cible exige un second facteur en plus d’un jeton SAML valide, mais cela oblige chaque utilisateur à maintenir à jour ce second facteur pour chaque service cible.
Cela devient vite ingérable, et il n’existe pratiquement aucun SaaS ni aucune application auto-hébergée qui prennent en charge à la fois le SSO et un second facteur.
C’est un peu comme créer une attaque appelée « GOLDEN ADMIN » : si vous avez des identifiants administrateur, vous pouvez vous connecter en tant qu’administrateur et faire tout ce que vous voulez.
Je comprends bien qu’il soit mauvais qu’un attaquant puisse s’authentifier n’importe où sans laisser de logs, mais je suis quand même d’accord avec le commentaire initial.
Je pense qu’il existe des moyens de le faire.
Ce n’est pas un problème propre à Microsoft. En tant qu’ingénieur sécurité, si l’on veut à la fois garder sa santé mentale et obtenir des résultats dans cette carrière, il faut travailler dans un endroit qui dispose de compétences techniques et qui se soucie culturellement de la sécurité, soit grâce à de fortes incitations réglementaires et à un budget, soit parce que son modèle de menace est fortement lié aux profits.
Les principaux exemples qui correspondent à mes critères sont les startups pré-IPO qui doivent passer SOC2 et autres audits pour entrer en Bourse, le secteur crypto où les modèles de menace comme le vol de clés et les incitations financières sont très clairs, ainsi que les entreprises technologiques publiques qui fournissent beaucoup d’infrastructures critiques.
Cela dit, certaines dérivent vers le côté « trop grosses pour échouer », comme Microsoft, tandis que d’autres semblent avoir des équipes de sécurité internes solides, comme Google/Project Zero, Verizon/Paranoids ou Cloudflare.
Les banques ont de l’argent, une culture d’aversion au risque et une forte réglementation, donc elles peuvent être intéressantes, mais je ne voudrais absolument pas travailler dans la santé, malgré une réglementation stricte, à cause du volume d’attaques et de l’indifférence.
Donc, sauf si vous voulez rejoindre l’équipe DART pour voir beaucoup d’acteurs de menace réels et de réponses à incident variées, ou faire de la sécurité OS à très bas niveau, je ne recommande pas d’aller chez Microsoft comme ingénieur sécurité.
Je ne connais pas bien le travail d’ingénieur sécurité chez Apple. C’est aussi pour cela que la durée moyenne d’une carrière en sécurité tourne autour d’une dizaine d’années. La santé mentale s’use, et comme la rémunération est assez bonne, on peut, dans la trentaine ou la quarantaine, faire autre chose avec l’argent mis de côté.