Em 15 de março de 2022, a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) divulgou um alerta detalhando um ataque cibernético russo a uma organização não governamental (ONG).
O agente russo usou um ataque de adivinhação de senha de força bruta para comprometer uma conta de usuário inativa da ONG. O agente da ameaça conseguiu então registrar um novo dispositivo com a conta de usuário da ONG. autenticação multifatorial (MFA), usando a conta comprometida. Ao explorar as configurações de "falha na abertura", o agente da ameaça conseguiu efetivamente desativar a MFA, desconectando o dispositivo da Internet.
Em última análise, o agente da ameaça encadeou senhas fracas, uma conta de usuário inativa, configurações padrão que privilegiavam a conveniência em detrimento da segurança e uma vulnerabilidade anterior do Windows. Isso lhes permitiu "acesso a contas de nuvem e de e-mail para exfiltração de documentos", de acordo com a CISA.
Esta postagem do blog não tem o objetivo de criticar outro provedor. Estou na RSA há quase 20 anos. Durante esse tempo, vivenciei minha cota de altos e baixos em segurança cibernética em primeira mão. Por isso, deixe-me dizer: o schadenfreude não ajuda exatamente ninguém.
O que eu vontade detalha alguns dos conselhos que a RSA deu aos clientes após o recente alerta da CISA. Também explicarei como essa recomendação se aplica a todas as soluções de MFA.
Alerta de spoiler menor: todos os recursos ou requisitos mencionados no restante deste artigo fazem parte do RSA.
A MFA é muito mais do que um método de autenticação
Para evitar ataques como esse, as organizações precisam reconsiderar o que é a MFA, como os usuários devem se inscrever inicialmente na MFA e como manterão essas inscrições durante o ciclo de vida dos usuários.
Tenha sempre em mente que o MFA não é apenas sobre ter um Senha única (OTP), aplicativo de autenticação ou um stick FIDO para fazer login. Se você acha que está seguro só porque você ou seus usuários usam a autenticação biométrica em um smartphone para fazer login em um aplicativo em nuvem, tenho más notícias para você: isso não é MFA.
Isso é apenas o mínimo necessário. Sim, isso permitiria que você marcasse a caixa de seleção "Usar MFA" na auditoria de conformidade, mas, do ponto de vista da segurança, isso seria uma perda de tempo e dinheiro.
A maioria dos autenticadores depende de alguma semente ou chave criptográfica para autenticar. Os autenticadores de hardware normalmente oferecem um nível mais alto de segurança porque protegem essa semente em um grau maior do que os autenticadores baseados em software. As empresas precisam entender suas necessidades de segurança e escolher um autenticador que ofereça segurança suficiente - tanto os autenticadores baseados em hardware quanto os baseados em software podem atender a requisitos individuais.
No entanto, o método em si - seja hardware ou software - é quase irrelevante se o registro dos autenticadores não estabelecer a confiança adequada. Mesmo que a sua organização esteja usando os melhores autenticadores, se você os gerenciar da maneira errada, eles serão praticamente inúteis para impedir ou retardar um ataque. Pense em um carro: só porque você colocou um motor potente nele e pintou as pastilhas de freio de amarelo, isso não significa que de repente você está ao volante de um carro de corrida. Você também precisará trocar os freios, a suspensão, os pneus e treinar o piloto para competir em uma corrida real. Há muito mais a ser considerado.
Ao analisar um ciclo de vida de identidade típico, explicarei como obter o máximo de uma solução MFA e garantir que ela realize o trabalho para o qual foi projetada: proteger seus usuários e proteger seus ativos digitais.
O registro é a primeira fase do ciclo de vida da identidade: durante o registro, um autenticador é atribuído a uma identidade (um usuário). Porém, mesmo antes de uma organização registrar um usuário específico, ela deve considerar algumas questões:
- Quem pode se inscrever no MFA?
- Como um usuário pode se inscrever na MFA?
Você pode pensar que a primeira pergunta tem uma resposta fácil: todos devem usar a MFA!
No entanto, pode haver usuários ou grupos que não devem ou não precisam se inscrever. Pense em contas que existem, mas não estão ativas, como um funcionário em licença parental, ou contas órfãs que nunca foram ou não são mais atribuídas a um usuário específico. Uma equipe de segurança não deve permitir que essas contas se inscrevam na MFA porque é improvável que qualquer inscrição de autenticador nova ou alterada emitida para essas contas seja notada. Por exemplo, os e-mails de notificação que informam as configurações alteradas ficarão parados em alguma caixa de entrada não monitorada.
A segunda pergunta é mais crucial porque precisa ser abordada sob duas perspectivas:
- Como a inscrição de sua organização pode atingir o nível de confiança desejado?
- Como o registro pode atender ao nível de confiança desejado de forma conveniente e eficiente tanto para o usuário quanto para a administração/serviço de assistência técnica?
Qualquer confiança em um autenticador é determinada pela forma como ele foi inicialmente registrado: o grau de segurança que um usuário tem no registro define seu teto de confiança enquanto esse usuário continuar usando esse autenticador.
Outra forma de dizer isso: independentemente de estar usando hardware ou software, os autenticadores só podem fornecer o nível de confiança necessário para um login de MFA ou uma autenticação por etapas se o registro inicial for suficientemente forte. Se você construir uma base instável, sua casa sempre será instável.
Há muitas maneiras de decidir quem pode se inscrever e como deve concluir o processo de forma a equilibrar segurança e conveniência. Mas, seja qual for a decisão de sua organização, certifique-se de que você não está somente usando senhas para se registrar.
Por que não? As senhas são convenientes. Os usuários já conhecem suas credenciais, portanto, os administradores não precisam se preocupar com nada além de apontar a solução MFA para um Active Directory. Certo?
Errado. Embora essa seja uma maneira fácil de concluir o registro da MFA, usar apenas senhas deixa sua organização aberta a todos os tipos de ataques. O pior cenário é que um invasor já tenha comprometido uma conta e, em seguida, registre essa conta na MFA. O registro de uma conta na MFA que não deveria estar inscrito na MFA é efetivamente o mesmo que ignorar a MFA por completo.
Foi exatamente isso que aconteceu no ataque bem-sucedido à ONG mencionada no início desta postagem. Embora houvesse etapas adicionais que o invasor usou para elevar seu acesso, o registro em si foi a falha fatal.
Existem maneiras mais inteligentes e seguras de registrar autenticadores. A SecurID recomenda enfaticamente que as organizações criem camadas de controles técnicos e processuais adicionais em torno do registro de MFA. De fato, o registro somente de senha não é possível por padrão na SecurID. Um cliente precisaria se esforçar para habilitar esse tipo de registro - e nós o aconselharíamos a não fazer isso em cada etapa do processo.
A determinação do registro adequado depende dos autenticadores disponíveis, dos níveis de confiança necessários, dos recursos da solução MFA da organização e das ferramentas e procedimentos disponíveis para a empresa.
Há muitos controles técnicos que podem ajudar a proteger e simplificar o processo de inscrição sem recorrer a senhas. Por exemplo, as organizações podem:
- Depender de um SMS ou Voice-OTP para um número de telefone pré-registrado antes da inscrição
- Exigir que os usuários entrem em contato com o help desk para obter um código de inscrição
- Distribuir um código de registro ao usuário por e-mail
- Imprima e compartilhe cartas de PIN para forçar os usuários a usar esse PIN exclusivo para se inscrever
- Atribuir e enviar tokens de hardware aos usuários (nesse cenário, as organizações devem manter os tokens desativados e permitir que o usuário ligue para o helpdesk para ativar o token de hardware)
- Permitir o registro somente de dentro da rede da empresa
Obviamente, há mais controles disponíveis e várias combinações também são possíveis. As organizações com populações de usuários grandes e diversificadas provavelmente devem considerar a possibilidade de oferecer mais de uma forma de inscrição, o que pode resultar em diferentes níveis de confiança, dependendo da função do usuário.
Todos esses controles acrescentam camadas de segurança em torno do próprio serviço de inscrição. E, embora o estabelecimento dessas camadas exija esforço para configurar e manter, esse investimento tem um grande retorno: autenticadores confiáveis.
Mas esse é apenas o primeiro passo para proteger o ciclo de vida da identidade de um usuário. Há muitos outros cenários que impedem que os agentes de ameaças tenham oportunidades significativas e muitas outras situações para as quais as organizações devem se preparar. Na próxima parte desta série, Na seção "Identidade", analisaremos as redefinições, as proteções contra falhas e outros pontos do ciclo de vida da identidade que as organizações devem priorizar para proteger a si mesmas e suas equipes.
