- O ex-funcionário da Microsoft Andrew Harris afirma que, após descobrir em 2016 a vulnerabilidade Golden SAML no AD FS, passou anos pedindo uma resposta, mas a empresa falou apenas de alternativas de longo prazo em vez de corrigir o problema de imediato
- Essa vulnerabilidade permite, após o roubo da chave privada de um servidor AD FS, acessar serviços em nuvem como se fosse um usuário legítimo com tokens falsificados, deixando poucos rastros em logs de auditoria e podendo até contornar autenticação multifator
- A proposta de Harris de desativar o seamless SSO entrava em conflito com preocupações sobre inconvenientes para clientes do governo federal, o contrato de nuvem do Pentágono, a concorrência com a Okta e piora na experiência do usuário
- Após o ataque à SolarWinds em 2020, hackers russos usaram essa fraqueza para coletar dados sensíveis de órgãos como a National Nuclear Security Administration, o NIH e o Treasury Department; depois disso, a Microsoft passou a recomendar a clientes do Microsoft 365 a desativação do seamless SSO no AD FS
- A Microsoft declarou que a proteção dos clientes sempre foi prioridade máxima e que revisou questões de segurança várias vezes, mas o relato do ex-funcionário expõe um caso de conflito entre cultura de segurança e prioridades de negócio
Vulnerabilidade Golden SAML encontrada no AD FS
- Andrew Harris trabalhava na Microsoft em uma organização sigilosa chamada Ghostbusters, responsável por responder a incidentes de invasão envolvendo clientes sensíveis, e em 2016 passou a focar em um problema no AD FS ao investigar a violação de uma grande empresa de tecnologia dos EUA
- O AD FS é um produto que permite ao usuário fazer login uma vez e acessar vários programas de trabalho, sendo usado por milhões de pessoas
- O principal risco identificado por Harris era que, em autenticação baseada em SAML, um invasor poderia se passar por um funcionário legítimo para acessar programas em nuvem
- O invasor primeiro compromete um servidor on-premises e depois extrai a chave privada do servidor AD FS
- Em seguida, pode forjar tokens e parecer um usuário com privilégios elevados
- Como as informações de login parecem normais, é difícil detectar isso com logs de auditoria comuns
- Harris acreditava que o problema poderia afetar não só o Microsoft Azure, mas também organizações que usam outros provedores de nuvem, como a Amazon
“security boundary” e a avaliação do MSRC
- Harris reportou o problema ao Microsoft Security Response Center, ou MSRC, mas o centro concluiu que ele não se enquadrava como algo a ser corrigido
- O MSRC entendeu que, como o invasor precisava primeiro acessar um servidor on-premises, esse ponto era o limite de segurança, e o salto posterior para a nuvem não configurava outro limite de segurança separado
- Ex-funcionários do MSRC disseram que, naquela época, o centro lidava com muitos relatos de vulnerabilidade com equipe insuficiente e havia uma cultura de encerrar casos com “won’t fix”
- Eles também recordam que a expressão “security boundary” não era claramente definida naquele período e era frequentemente usada pela Microsoft como justificativa para não corrigir algo
- Em um memorando de 2002, Bill Gates escreveu que, entre adicionar funcionalidades e resolver problemas de segurança, a escolha deveria ser pela segurança, mas ex-funcionários afirmam que, com o tempo, a influência do MSRC enfraqueceu
Solução temporária entrava em conflito com a lógica de negócios
- Harris avaliou que a correção definitiva poderia levar tempo e propôs como medida temporária a desativação do seamless single sign-on (SSO)
- Esse recurso de conveniência da Microsoft permite que, com um único login, o usuário acesse servidores on-premises e vários serviços em nuvem
- Segundo Harris, o responsável pelo produto Mark Morowczynski se opôs, argumentando que divulgar a vulnerabilidade poderia dar pistas a atacantes e causar grande inconveniente para clientes do governo federal
- Funcionários federais eram obrigados por norma a fazer login com smart cards
- Harris explicou que, se o seamless SSO fosse desligado, seria necessário um segundo login para acessar a nuvem, e nesse processo os smart cards exigidos não poderiam ser usados
- O grande contrato de nuvem do Pentágono e a concorrência com a Okta também foram citados como motivos para a oposição
- Na época, a Microsoft competia com a Okta, e o seamless SSO era uma das vantagens competitivas da empresa
- A proposta de Harris criava atrito ao exigir que o usuário se autenticasse duas vezes, em conflito com a estratégia de produto
- Harris relembra que Morowczynski teria dito que essa decisão não era técnica, mas uma decisão de negócios
Alertas de empresas externas de segurança
- Em 2017, a CyberArk publicou um post de blog e uma prova de conceito chamando a técnica de Golden SAML
- Mais tarde, Brad Smith escreveu em respostas por escrito ao Senate Intelligence Committee que a Microsoft só tomou conhecimento do problema quando a CyberArk o divulgou em 2017
- Lavi Lazarovitz, da CyberArk, disse que antes da divulgação o problema foi compartilhado em um chat privado no WhatsApp com pesquisadores de segurança de várias empresas, incluindo pesquisadores da Microsoft
- Harris disse que, após a divulgação da CyberArk, passou a considerar o problema ainda mais urgente e voltou a levá-lo ao grupo de produto e ao MSRC, mas o MSRC manteve sua posição anterior
- Em 2019, pesquisadores da Mandiant demonstraram em uma conferência na Alemanha como invadir o AD FS para acessar contas e aplicações em nuvem, além de divulgar ferramentas
- A Mandiant afirmou que notificou a Microsoft antes da apresentação
- Esse foi o segundo caso, em cerca de 16 meses, em que uma empresa externa alertou a Microsoft sobre o problema de SAML
O alerta a clientes feito por Harris e o caso da NYPD
- Em 2019, Harris publicou no LinkedIn um alerta indireto, dizendo que quem conhecesse alguém que não entendesse a relação de autenticação do AD FS poderia entrar em contato
- Ele tentou avisar diretamente clientes com os quais já tinha relacionamento, e um deles foi o New York Police Department
- Harris explicou a fraqueza do AD FS a Matthew Fraser, responsável de TI da NYPD, e recomendou desativar o seamless SSO
- Fraser confirmou a reunião e disse que a fraqueza em SAML foi identificada como uma área que exigia proteção e isolamento
- Harris deixou a Microsoft em agosto de 2020 para ir para a CrowdStrike e afirma que voltou a levantar a fraqueza em SAML também na entrevista de desligamento
Contorno da autenticação multifator e o ataque à SolarWinds
- Harris afirma que, em uma conversa com um colega em 2018, percebeu que um invasor com tokens falsificados também poderia contornar a autenticação multifator
- O problema era que, mesmo com etapas extras de segurança, um invasor com um token falsificado podia pular todas elas
- No fim de 2020, o ataque à SolarWinds veio a público, e o governo dos EUA afirmou que hackers apoiados pelo Estado russo estavam envolvidos
- Os atacantes inseriram malware em atualizações de software da SolarWinds para obter acesso de backdoor às redes e depois usaram vulnerabilidades pós-invasão como o Golden SAML para roubar dados em nuvem e e-mails
- Os atacantes coletaram dados sensíveis de vários órgãos usando a fraqueza apontada por Harris
- National Nuclear Security Administration
- National Institutes of Health
- várias contas de e-mail do Treasury Department
- Brandon Wales, da CISA na época, disse que quase um terço das vítimas não usava o software da SolarWinds
- A própria Microsoft também foi comprometida e, logo após o ataque, passou a recomendar a clientes do Microsoft 365 que desativassem o seamless SSO no AD FS e em produtos semelhantes
Posição pública da Microsoft e medidas posteriores
- Em 2021, o presidente da Microsoft, Brad Smith, declarou ao Congresso que não havia vulnerabilidade em produto ou serviço da Microsoft explorada no ataque à SolarWinds
- Smith explicou que o Golden SAML foi usado em 15% dos 60 casos identificados pela Microsoft, mas reconheceu que não foram apenas essas as vítimas em que dados foram observados ou roubados
- Smith afirmou que, se as organizações tivessem adotado várias medidas, como comprar antivírus como o Microsoft Defender e proteger dispositivos com o Intune, o dano teria sido quase nulo
- Após a SolarWinds, a Microsoft adotou medidas para mitigar riscos de SAML, e os recursos para detectar de forma eficiente os efeitos da invasão foram incluídos no Sentinel, um produto adicional pago
- Em um blog, a Microsoft descreveu a ausência dessa detecção como um “blind spot”
Contestação da Microsoft e debate sobre cultura de segurança
- A Microsoft não disponibilizou executivos de alto escalão, como Brad Smith, para entrevistas, mas também não negou os resultados da investigação da ProPublica
- Em resposta por escrito, a empresa disse que a proteção do cliente é sempre a maior prioridade e que as equipes de resposta de segurança tratam todos os problemas com seriedade, passando por avaliação manual e revisão de engenharia e de parceiros de segurança
- A Microsoft explicou que, ao avaliar ameaças potenciais, considera a possibilidade de interrupção para o cliente, a explorabilidade e as mitigações disponíveis
- Um caso de 2023, em que hackers ligados ao governo chinês exploraram uma falha de segurança da Microsoft para acessar e-mails de autoridades de alto escalão dos EUA, também virou alvo de investigação da House Homeland Security Committee
- Ao investigar esse caso, o Cyber Safety Review Board concluiu que a cultura de segurança da Microsoft era inadequada e precisava de uma reformulação total
- Após o relatório ao conselho, Satya Nadella disse aos funcionários que, se segurança e outras prioridades entrarem em conflito, a escolha deve ser pela segurança
Competição no negócio de nuvem e consequências
- Satya Nadella, que se tornou CEO em 2014, apostou o futuro da Microsoft no negócio de nuvem do Azure, que na época estava muito atrás da Amazon
- A Microsoft propôs a clientes corporativos e governamentais uma estratégia de nuvem híbrida, mantendo parte dos servidores on-premises enquanto transferia a maior parte da computação para a nuvem
- A segurança era um argumento central de venda da nuvem, destacando como vantagem o fato de equipes especializadas cuidarem de patches e atualizações
- Harris e ex-funcionários afirmam que o grande contrato de nuvem do Pentágono e a pressão pelo crescimento do Azure influenciaram decisões das equipes de produto
- No fim, a Microsoft conquistou, ao lado de Amazon, Google e Oracle, parte de um contrato multianual de nuvem do Department of Defense avaliado em dezenas de bilhões de dólares
- Desde a revelação do caso SolarWinds, as ações da Microsoft subiram 106%, impulsionadas principalmente pelo sucesso do Azure e de produtos de IA como o ChatGPT
- O produto de longo prazo para substituir o AD FS, que Morowczynski teria mencionado a Harris em 2017, começou a ser oferecido em 2022
1 comentários
Opiniões no Hacker News
A solução é aplicar zero trust completo dentro da organização e não confiar na rede. A rede interna também deve ser tratada como a externa, ou seja, como um ambiente hostil
O Google foi um dos primeiros casos de adoção ampla de zero trust com o BeyondCorp, e acredito que, depois do Aurora, não houve comprometimento da organização interna do Google
São necessários endpoints totalmente gerenciados, hardening forte dos endpoints, inventário de todos os recursos da organização, certificados por dispositivo e um mecanismo de listas de controle de acesso que determine o acesso a recursos por usuário
Também é possível detectar anomalias com heurísticas como horário de trabalho, e todos os apps internos do Google ficam expostos à internet e redirecionam para um portal de SSO, mas na prática não é possível entrar. Uma boa parte desses problemas de segurança já foi resolvida; basta implementar
A maioria das grandes organizações acumulou tecnologias internas e externas por décadas, sistemas antigos estão praticamente abandonados, e há muita heterogeneidade por causa de fusões e aquisições e da liberdade de cada departamento escolher suas ferramentas
Migrar para zero trust exige uma grande migração, “educação” para convencer equipes de TI resistentes e uma transição para um modelo centralizado ao estilo Google
Mesmo que as duas primeiras coisas consigam orçamento, a terceira pode sair muito cara. Uma das razões pelas quais o Google descarta tantas coisas é que, em um modelo centralizado, é preciso continuar migrando e fazendo upgrades que quebram compatibilidade
Em uma startup, dá vontade de oferecer aos clientes essa uniformidade baseada em boas práticas, mas em algum momento um cliente pode exigir “desligar o zero trust e nos deixar usar uma lista de IPs permitidos”. Você pode ficar em dúvida se aceita em nome de um contrato grande, e também não dá para cancelar uma aquisição só porque a empresa adquirida não tem zero trust
Pelo contrário, para a maioria elas estão mais perto de ser tarefas extremamente difíceis, e a resposta soa como “é só desenhar o resto da coruja”. Por exemplo, basta imaginar a Shaw Industries, maior fabricante de carpetes e pisos dos EUA, com 22 mil funcionários, tentando fazer isso
Se você assume uma postura de que está absolutamente “seguro”, deixa de procurar violações com afinco e, no fim, acaba deixando passar uma violação que inevitavelmente ocorrerá algum dia
Zero trust é uma filosofia, e uma filosofia bastante boa, mas não é uma solução por si só. É mais correto pensar nisso como uma filosofia e um conjunto de boas práticas do que como uma solução absoluta
Não acho que essa arquitetura sirva para todas as empresas. A maioria das empresas de tecnologia que não são de software sofre danos por engenharia social simples, e-mails fraudulentos e problemas de repassar credenciais a terceiros; espionagem econômica também é uma grande ameaça
O Google pode ter outras preocupações de segurança, como denunciantes internos ou grupos ativistas em conflito com a visão da diretoria, e essa estrutura pode ser adequada para esses problemas. Mas isso não significa que os vetores de ameaça de todas as empresas sejam os mesmos
Problemas de segurança podem ser resolvidos, mas a infraestrutura necessária não é trivial, e muitas stacks de software usadas em engenharia nem sequer dão suporte a autenticação de terceiros
Desenvolvedores, mesmo quando não são desenvolvedores de software, muitas vezes rejeitam “endpoints gerenciados”. Funciona no Google, mas é algo próximo de um caso especial; na prática, uma segmentação de rede razoável pode ser muito mais eficaz
O desalinhamento de incentivos entre segurança e lucro é difícil de corrigir sem uma enorme mudança cultural, especialmente em empresas de capital aberto. Também não sei o que poderia desencadear essa mudança
Já acumulei funções de cibersegurança em vários cargos, mas o motivo de não ter ido para isso em tempo integral foi o que vi diretamente no setor. Há um foco esmagador em compliance, em vez de boas práticas reais de segurança, e esses padrões também são insuficientes ou pouco aplicados
É necessária uma mudança cultural, mas acho que ela precisa vir dos clientes. Para consumidores isso é difícil, mas, se clientes corporativos avaliarem segurança de verdade, exigirem garantias vinculantes e tomarem decisões de compra com base nisso, o setor vai reagir
Claro que a Microsoft está tão profundamente enraizada no mercado de desktops que é difícil esse método ser totalmente eficaz
Ainda assim, isso também é uma reação direta à ausência de uma mudança cultural que leve segurança a sério. Normalmente, equipes de segurança só têm duas opções
Defender “segurança é importante, então vamos criar produtos seguros” e ser ridicularizadas, ou usar o compliance exigido por auditores para fazer a empresa se mover pelo menos um pouquinho na direção da segurança
Indivíduos também às vezes escolhem dinheiro em vez de segurança. O governo também parece ter escolhido uma força de trabalho mais produtiva em vez de custos mais altos e menor produtividade
Quando uma empresa vende para o governo, o dinheiro que pode ganhar e o efeito de relações públicas são tão grandes que surge um incentivo para esconder verdades inconvenientes. Lembra um certo fabricante de aeronaves
Isso pode se espalhar com o tempo por todo o espectro, desde esconder algo um pouco constrangedor até fraudes gigantescas, sistemáticas e deliberadas
Se a liderança diz “priorize segurança/qualidade”, mas na prática não recompensa isso, o terreno já está preparado
Se todos os dias recompensa ou pune com base em metas financeiras e, quando algo é descoberto de vez em quando, pune apenas um ou dois subordinados, então o que a empresa leva a sério é dinheiro, não segurança/qualidade
Para atingir uma meta, é preciso dar incentivos. Vendas é estressante e a pessoa pode ser demitida facilmente, mas, se tiver sucesso, pode ganhar muito dinheiro. Em segurança, se você tem sucesso, apenas não é demitido; se falha, é demitido
O resultado de um bom trabalho de segurança é “nada acontecendo”: sem invasões, sem desastres, sem alvoroço, e isso também é difícil de medir. É o problema de como quantificar uma ausência
No fim, vendas tem muitas cenouras e o mesmo chicote que todo mundo, mas segurança não tem cenouras, só chicote — e esse chicote pode ser um porrete cheio de pregos. A resposta está na cultura, e acho que mudança cultural é a coisa mais difícil
Não se deve esperar que vendas se preocupe com segurança; o foco de vendas deve ser crescimento. O problema é não dar ao outro lado a autoridade e a jurisdição para dizer “não”, que correções de segurança precisam entrar antes de novas funcionalidades
Se um gerente de projeto incentivado por crescimento decide prioridades, naturalmente vai escolher crescimento em vez de segurança
Não é que a equipe de segurança desconheça os problemas; é que as correções não viram prioridade, e a cultura e os processos não conseguem equilibrar os dois lados
Também do lado do governo, pelo menos para a carreira dos tomadores de decisão individuais, há incentivos consideráveis para que o contrato seja fechado
Ambos os lados querem que a transação aconteça, e têm incentivo para esconder defeitos desde que o usuário final não perceba antes da aposentadoria deles
Acho que o modelo da Microsoft de prioridade à segurança, quando Satya Nadella disse “se tiverem de escolher entre segurança e outra prioridade, a resposta é clara: façam segurança”, é algo assim
Colocar anúncios em todos os cantos do Windows, instalar um gravador que registra tudo o que o usuário faz e mandar um e-mail aos funcionários dizendo “façam segurança”; missão cumprida
Aquilo deixou muito claro para mim que grande parte dos treinamentos, e-mails e processos existe para criar uma negação plausível
Há pessoas na Microsoft que realmente se importam com segurança. Já conheci algumas pessoalmente. Mas, em geral, esses mecanismos permitem que Satya diga em um tribunal ou no Congresso: “Nós dissemos para fazerem segurança melhor. Foi culpa da equipe de produto ou de colaboradores individuais, não das políticas e incentivos da Microsoft”
A redação de um e-mail não tem peso algum. No momento em que um líder escolhe trocar segurança por outra coisa, o sinal de que os funcionários precisam já foi enviado
Vêm à mente a controvérsia de a Canonical ter registrado buscas pela tecla Super e o fato de o Ubuntu ter vindo com anúncios da Amazon por padrão
Quem gosta de computadores pode instalar Arch, Gentoo ou NixOS Minimal e auditar pacotes, mas é irrealista esperar que a maioria dos não engenheiros de software faça isso
Não só a Microsoft, mas todas as empresas sempre têm incentivos para colocar o máximo possível de anúncios e coletar o máximo possível de dados. Não tenho certeza se apoio regulação, mas também não vejo muito outro caminho
Como sempre, os clichês da diretoria sobre “segurança em primeiro lugar” não importam
Se você recompensa e promove pessoas por funcionalidades, mas não recompensa uma cultura de segurança, as pessoas e as camadas gerenciais não são idiotas e vão otimizar nessa direção
Não sei como esses incentivos deveriam ser desenhados para resolver o problema, mas as coisas vão continuar seguindo assim
Até que os responsáveis sejam punidos e alguém pague o preço, provavelmente nada vai acontecer
Normalmente, uma funcionalidade entra no produto quando o marketing consegue mostrar que ela gerará mais crescimento para o negócio do que seu custo. A mesma ideia pode ser aplicada
Algo como: “Esta vulnerabilidade afeta X% dos clientes, Y% vão embora, e ainda haverá dano reputacional, resultando em uma grande perda financeira. Por outro lado, ela pode ser corrigida por um valor pequeno em Z dias. Qual é a decisão?”
Acho que uma pista bem grande está sendo ignorada nessa história. Desativar o SSO contínuo tem um impacto amplo e específico sobre os smart cards físicos que funcionários do governo usam para fazer login nos dispositivos
Esses cartões, exigidos por regras federais, geram uma senha aleatória a cada login, mas, por causa da configuração da tecnologia subjacente, remover o SSO contínuo impede que os usuários acessem a nuvem com o smart card
O governo dos EUA é um dos maiores clientes da Microsoft, e sua base de usuários e a escala do Active Directory são enormes. Pela minha experiência trabalhando nessa área, gerenciar usuários e funções é quase um pesadelo, com credenciais roubadas, contas bloqueadas etc., e é um alvo constante
O governo dos EUA vem tentando migrar todo mundo para autenticação por smart card para reduzir esses problemas; eliminar senhas e colocar todo mundo em autenticação de dois fatores reduz bastante a superfície de ataque
Só que essa pessoa basicamente estava dizendo para mandarem os clientes simplesmente desligarem isso como parte da correção
Não estou negando o risco da falha original no SAML, mas acho que Harris julgou de forma injusta o restante da resposta da Microsoft. Foi como se ele tivesse pedido para desativar a autenticação de dois fatores em uma agência inteira
A mitigação de curto prazo prejudica muito a segurança e pode deixar os clientes mais expostos justamente ao tipo de ataque que se tentava impedir. A história foi apresentada como mais um caso de uma empresa que não se importa com segurança, mas parece mais a reação de um “denunciante interno” que olhou de forma estreita para a postura de segurança geral do cliente
A maioria dos administradores de sistemas de segurança da informação de órgãos governamentais também teria dito, pelos mesmos motivos, que isso não era uma opção viável
No fim, é esse o ponto do texto. Eles continuaram vendendo mesmo sabendo que não havia uma forma segura de administrar aquilo
Não quero defender a Microsoft, mas não sei se dá para apontar uma empresa que priorize segurança em vez de lucro
Bill Gates disse em 2002 que “se houver uma escolha entre adicionar funcionalidades e resolver problemas de segurança, devemos escolher a segurança”, e Satya Nadella disse algo na mesma linha em 2024, com “façam segurança”
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
https://www.theverge.com/24148033/satya-nadella-microsoft-se...
Na prática, há funcionalidades que eu usaria e pelas quais pagaria mais, mas que eles não fazem por não serem um protocolo totalmente seguro ou por exigirem integração com clientes de calendário comuns
Se o cliente que paga não valoriza segurança, o fornecedor também não vai valorizá-la, a menos que haja regulação ou exigência legal
Mas, considerando que grandes organizações e governos são clientes da Microsoft, este caso é estranho. Pode ter havido a arrogância de achar que “isso não vai acontecer conosco” ou que “ninguém vai descobrir”
Agora eles provavelmente estão vendo que o dano reputacional pode prejudicar até os lucros futuros
É como imaginar que uma empreiteira construiu uma grande ponte. Um inspetor interno de segurança alertou repetidamente seus superiores sobre uma falha estrutural que poderia levar ao colapso e, com o tempo, também surgiram dois alertas públicos externos, mas a empresa minimizou a importância
No fim, a ponte desaba, e fica claro que a empresa não fez nada porque não queria perder contratos para vender mais pontes defeituosas
O público ficaria justificadamente indignado, e haveria consequências legais para os envolvidos. Mas, no nosso setor, não sei o que é diferente para permitir que empresas e gestores escapem desse tipo de má-fé
Parece que, em geral, as pessoas não se importam muito se não houver vidas suficientes perdidas
https://www.nrk.no/innlandet/statens-vegvesen-legg-fram-rapp...
Software não ameaça vidas de forma imediata. Por isso, fora saúde e aeroespacial, as coisas funcionam quase como no Velho Oeste
Ter dados pessoais vazados na internet é terrível, mas, comparado a uma porta de avião se desprendendo, ainda há tempo para agir
O governo poderia começar a mudar isso exigindo, em contratos de produtos de software vendidos ao governo, a assinatura e a aprovação de uma pessoa licenciada
O teleférico de Mottarone certamente foi parecido. Ele operou por anos com o dispositivo de segurança desativado e, quando o cabo de tração se rompeu, a cabine despencou morro abaixo, matando todos a bordo
Golden SAML é menos uma vulnerabilidade em si e mais, como o artigo da CyberArk citado no texto reforça, um tipo de ataque que só é possível depois de comprometer completamente a máquina primeiro
A menos que eu tenha entendido algo errado, não vejo uma falha específica. Para usar o jeito como a Microsoft foi ridicularizada na matéria, isso não cruza uma fronteira de segurança
Em SSO sempre existe esse tipo de trade-off. Se a infraestrutura de SSO for comprometida, tudo que a utiliza corre o risco de ser comprometido
Essa parte é passada meio por cima, mas acho que o “hack” de verdade está mais perto disso
Enquanto você usa SSO, a mitigação também não é fácil. Uma forma seria fazer o serviço de destino exigir um segundo fator além de um token SAML válido, mas aí cada usuário teria de manter o segundo fator atualizado para cada serviço de destino
Isso rapidamente se torna impossível de gerenciar, e praticamente quase não existem SaaS ou apps auto-hospedados que deem suporte simultâneo a SSO e segundo fator
É parecido com inventar um ataque chamado “GOLDEN ADMIN”: se você tem credenciais de administrador, pode fazer login como administrador e fazer o que quiser
Entendo que seja ruim um atacante conseguir se autenticar em qualquer lugar sem deixar logs, mas ainda assim concordo com o comentário original
Acho que há formas possíveis
Não é um problema exclusivo da Microsoft. Como engenheiro de segurança, se você quer manter a sanidade e ter impacto nessa carreira, precisa trabalhar em um lugar que tenha competência técnica e se importe culturalmente com segurança por causa de fortes incentivos regulatórios e orçamento, ou por causa de um modelo de ameaças fortemente ligado ao lucro
Os principais exemplos que se encaixam nos meus critérios são startups pré-IPO que precisam passar por SOC2 etc. para abrir capital, o setor de criptomoedas, onde modelos de ameaça como roubo de chaves e incentivos de lucro são claros, e empresas públicas de tecnologia que fornecem muita infraestrutura crítica
Dito isso, há empresas como a Microsoft, grandes demais para quebrar, que acabam indo nessa direção, e também lugares como Google/Project Zero, Verizon/Paranoids e Cloudflare, onde as equipes internas de segurança parecem fortes
Bancos têm dinheiro, cultura avessa a risco e forte regulação, então há potencial, mas em saúde eu jamais gostaria de trabalhar, apesar da forte regulação, por causa do volume de ataques e da indiferença
Portanto, a menos que você queira ver muitos agentes de ameaça reais e vários tipos de resposta a incidentes na equipe DART, ou queira fazer segurança de SO em nível bem baixo, eu não recomendaria ir para a Microsoft como engenheiro de segurança
Não conheço bem o trabalho de engenheiro de segurança na Apple. Esse também é o motivo de a permanência média em carreiras de segurança ficar por volta de uns 10 anos. A sanidade vai se desgastando, e a remuneração é boa o suficiente para, aos 30 ou 40 e poucos anos, permitir fazer outra coisa com o dinheiro economizado