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 da ameaça combinou 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 no Windows. Isso permitiu que eles tivessem "acesso a contas de nuvem e de e-mail para extração de documentos".ation".
Em Parte 1 Na primeira parte desta série, o arquiteto de identidade da RSA Global Cloud, Ingo Schubert, analisou algumas das práticas recomendadas que a RSA compartilhou com os clientes após esse ataque, discutindo a finalidade da autenticação multifator (MFA), inscrevendo usuários na MFA e como minimizar o uso de senhas. Nesta segunda parte da série, Ingo analisa as redefinições de autenticação, as proteções contra falhas e outros cenários que podem levar a incidentes de segurança.
Digamos que você tenha concluído o registro. Além disso, você seguiu nossas práticas recomendadas e criou inscrições que resultam em um teto de confiança alto, permitindo que os usuários se autentiquem com um alto grau de confiança enquanto usarem esse método de autenticação.
Nosso trabalho está concluído? Longe disso. O que acontece com um usuário que perde ou extraviou seu autenticador? E quanto a um usuário que adquire um novo smartphone e precisa reinstalar o aplicativo?
Esses cenários acontecerão, e sua organização precisa estar preparada para lidar com eles de forma segura e fácil de usar.
Isso lhe parece familiar? Deveria. Sua organização provavelmente substituir autenticadores de uma forma que se assemelhe ao seu registro inicial. Em todos os estágios, as organizações devem se certificar de que não estão se expondo a ataques.
Não quebre a confiança que você estabeleceu durante o registro ao substituir um autenticador. Lembre-se: o registro de novos dispositivos, a substituição de dispositivos registrados e as redefinições de autenticação são alguns dos momentos favoritos dos hackers no ciclo de vida da identidade. Eles incorrem em um grau de mudança maior do que o normal e, como resultado, representam algumas das instâncias mais prováveis para os invasores obterem acesso não autorizado.
Não deixe que eles o façam. Procure uma empresa moderna autenticação multifatorial (MFA) que pode proteger esses momentos, oferece integrações de API em seu gerenciamento de identidade e acesso (IAM) e integra suas operações de helpdesk, tudo em um só lugar.
Mesmo que você tenha feito tudo certo durante a fase de registro e tenha garantido a substituição da autenticação e o acesso de emergência, pergunte-se: de que adianta tudo isso se você não usa a MFA em todos os lugares ou se um invasor pode simplesmente desativá-la e contorná-la?
Resolver o primeiro cenário é fácil: use a MFA em todos os lugares (pelo menos para os usuários certos).
Para fazer isso com sucesso, sua solução MFA deve fornecer uma variedade de métodos e interfaces para permitir que os usuários se autentiquem quando e como que eles preferem. Também pode ser necessário verificar se alguns aplicativos legados podem fornecer as interfaces corretas e garantir que eles possam utilizar novos métodos de autenticação, como o FIDO sem senha, ou se você está preso ao bom e velho RADIUS.
Vamos supor que você tenha protegido todos os seus aplicativos com MFA. Você também precisará garantir que um invasor não possa desativar a MFA. No recente Alerta da CISA, No caso da ONG, ela usava uma solução de MFA que permitia que os usuários fizessem login sem MFA se não pudessem se conectar à Internet. O agente da ameaça explorou isso, permitindo que eles desativassem efetivamente a MFA apenas desligando a conexão com a Internet.
Portanto, a solução MFA de sua organização deve ser à prova de falhas e/ou ter um modo de falha de failover off-line que garanta que a MFA seja aplicada mesmo que o backend da MFA (na nuvem ou no local) não possa ser acessado.
Entendo o raciocínio quando se trata de fail-open: para manter o negócio funcionando, é melhor permitir logins com apenas uma senha em vez de bloquear todos.
Por mais compreensível que seja essa escolha, ela cria vulnerabilidades significativas em sua postura de segurança. A melhor abordagem - e mais segura - é garantir que a autenticação forte funcione mesmo que o backend da MFA não esteja disponível. Não importa se o backend da MFA é baseado na nuvem ou no local: os provedores de autenticação devem oferecer soluções off-line que funcionem para ambos.
A proteção da autenticação MFA off-line é algo que encontramos com frequência. Normalmente, aconselhamos as empresas a fornecer métodos diferentes de autenticação, dependendo se o usuário está on-line ou off-line. Por exemplo, se um notebook estiver on-line, o login no Microsoft Windows será protegido usando notificações push ou biometria. Se o notebook estiver off-line, Senha única (OTP) é aplicada.
Como a OTP não é tão fácil de usar, nesse cenário, sacrificamos um pouco da conveniência para aumentar a segurança. Isso garante que não haja falha na abertura e que um invasor não possa desativar a MFA.
O comportamento à prova de falhas não é importante apenas para o PC Windows de um usuário individual: ele também deve ser aplicado a todos os seus aplicativos locais.
E se o serviço de nuvem MFA que você usa estiver off-line? Isso pode e vai acontecer. Talvez o provedor de MFA tenha sofrido uma interrupção, talvez sua conexão com a Internet tenha caído. Talvez um invasor tenha manipulado seu serviço de DNS de forma a fazer com que o serviço de nuvem MFA pareça estar off-line: independentemente da situação, o planejamento de um comportamento à prova de falhas/failover pode ajudar sua organização a manter a continuidade e a segurança dos negócios, mesmo quando seus usuários não conseguirem se conectar à Internet.
A Configuração de MFA híbrida no local/nuvem de alta disponibilidade salvará o dia. Normalmente, seus aplicativos se comunicam com o componente MFA local, que, por sua vez, encaminha as solicitações para o serviço de nuvem MFA. Se a nuvem MFA ficar indisponível, todos os aplicativos que conversam com o componente de failover do serviço MFA local ainda poderão autenticar fortemente os usuários.
Assim como no cenário do PC com Windows, nesse caso de uso, a autenticação off-line será conduzida somente por meio de OTP porque as notificações push para os smartphones dos usuários não estarão disponíveis devido a uma interrupção da Internet. Se houver a opção de aplicar OTPs em caso de interrupções na nuvem da MFA ou usar como padrão a abertura por falha, eu escolheria OTPs 10 em 10 vezes.
Configurar adequadamente a MFA desde o início, pensar no registro e eliminar a MFA de abertura com falha são algumas das melhores maneiras de se preparar para todos esses cenários.
Outro componente essencial é o desenvolvimento de uma prática de governança que ajude a sua equipe de segurança a obter visibilidade das identidades em todo o seu ciclo de vida.
Governança e ciclo de vida da SecurID garante que as contas e os direitos dos usuários estejam atualizados. Como as decisões de autorização, inclusive as inscrições na MFA, serão baseadas em dados de identidade, é fundamental que esses dados sejam confiáveis.
Algo que ainda não mencionei é o Identity Confidence Scoring: O SecurID pode avaliar a confiança na transação MFA atual de um usuário com base em seu contexto atual e comportamento anterior. O Identity Confidence Scoring é algo que estamos fazendo há quase duas décadas. Ele faz parte do mecanismo de risco da SecurID e análise baseada em riscos.
A SecurID oferece suporte a todas essas práticas recomendadas: desde a garantia do registro inicial até a redefinição das autenticações, passando pela implantação da autenticação híbrida e pelo gerenciamento da governança de identidade, aproveitamos nossas décadas de experiência na criação de soluções inteligentes, simples e seguras.
Esteja você on-line ou off-line, no local ou na nuvem, há uma maneira de você e sua equipe se manterem seguros. Vamos lhe mostrar como.
