Na maioria das vezes, a reação imediata a incidentes de segurança, como os ataques de ransomware que atingiram os cassinos de Las Vegas no início do outono, é procurar a causa. Eu entendo esse impulso. O impacto dos ataques - os hóspedes que tiveram de fazer o check-out usando caneta e papel, até $100 milhões em perdas para uma única vítima - demonstram os altos custos das falhas de segurança. Ninguém quer ser a próxima vítima de uma violação de dados.
Mas na segurança cibernética, geralmente não há apenas uma causa. Na maioria dos incidentes de segurança, os invasores tiram proveito de uma cadeia de vulnerabilidades que gradualmente lhes dá mais acesso e controle de um ambiente. Não é produtivo procurar causa e efeito quando geralmente não há nenhum. Em vez disso, as equipes de segurança precisam analisar o ambiente geral, a arquitetura e as formas de operação da tecnologia, bem como os processos e cultura de negócios e aproximá-los da arquitetura de confiança zero.
Assim como os cassinos que foram atingidos por esses ataques, tanto os ataques cibernéticos quanto a segurança cibernética tendem a jogar com as probabilidades. Normalmente, não é um calcanhar de Aquiles que põe em risco a segurança cibernética de uma organização. Em vez disso, são as chances estatísticas e os riscos que se combinam entre si. As equipes de segurança não devem procurar uma bala de prata; em vez disso, devem entender as condições que podem transformar um floco de neve em uma avalanche.
Embora provavelmente nunca saberemos a história completa sobre como o ALPHV / BlackCat lançou seus ataques, sabemos sobre algumas das condições que os ajudaram a violar suas vítimas e como essas condições criaram riscos que favoreceram os atacantes.
Em seus declaração, De acordo com a ALPHV, o cassino "desligou todos os seus servidores Okta Sync depois de saber que estávamos à espreita em seus servidores Okta Agent, detectando as senhas de pessoas cujas senhas não podiam ser decifradas".
O ALPHV foi capaz de fazer isso devido a Sincronização de senhas de aplicativos do Okta, que "usa APIs padrão para sincronizar senhas e aplicativos locais quando eles estão disponíveis". A documentação do produto continua: "Quando Okta to Application - Sync Okta Password está ativado, o comportamento padrão é sincronizar a senha existente. A senha do Okta é a senha usada para fazer logon no Okta."
O que isso significa em linguagem simples é que a Okta tem as senhas do Active Directory de seus usuários. Isso se deve, em grande parte, à arquitetura do fornecedor que prioriza a nuvem: a sincronização de senhas ajuda no tempo de execução e facilita a rápida implantação e implementação do sistema MFA.
Embora essa opção ajude as organizações a implantar a solução mais rapidamente, ela vem com grandes compensações de segurança que vão contra um princípio fundamental de segurança cibernética: Evitar dados ou, em outras palavras: não armazenar ou transmitir dados que não precisam ser armazenados ou transmitidos.
Essa é uma regra de longa data porque, se uma organização transmite algo, é mais fácil para um invasor roubá-lo. Foi isso que aconteceu com o BlackCat e o ALPHV: eles provavelmente comprometeram o servidor em que o Okta Agent AD estava sendo executado. A partir daí, eles poderiam configurar um vampiro para copiar senhas, injetar uma DLL, despejar segmentos de memória ou realizar qualquer outra ação. E esse é o ponto: não importa realmente quais ações específicas os atacantes realizaram quando estavam no servidor comprometido.
Em vez disso, o risco começou com a implementação de uma arquitetura que sincroniza as senhas. Essa escolha estabeleceu as condições que permitiram que todo o resto viesse a seguir. Essa decisão é o equivalente em termos de segurança cibernética a optar por construir um edifício sobre a areia em vez de sobre a rocha: o que você constrói pode ficar de pé, mas por que correr o risco?
Os ataques do BlackCat / ALPHV ressaltam a dificuldade de proteger os servidores. Várias atualizações, senhas de administrador e repetição de senha formam uma superfície de ataque grande, complexa e frágil. Esse tipo de configuração geralmente favorece os invasores.
A alternativa é desenvolver o Secure by Design e o Secure by Default princípios, que priorizam a segurança em todos os recursos, operações e processos do produto e aproximam as organizações da confiança zero.
Como em muitas coisas, o Secure by Design e o Secure by Default têm tudo a ver com os detalhes. É fácil afirmar que um produto prioriza a segurança, mas é difícil entregar algo que realmente atenda a esse padrão.
A RSA desenvolve soluções que priorizam a segurança e que começam com esses princípios. Não sincronizamos as senhas do Active Directory ou do LDAP - não temos essas credenciais. Em vez disso, exigimos que os clientes implantem um dispositivo virtual reforçado que se conecte aos seus repositórios de usuários locais e valide as senhas em tempo real, em vez de farejá-las e sincronizá-las com a nuvem.
Essa escolha tem algumas desvantagens: leva um pouco mais de tempo e esforço para implantar um dispositivo virtual reforçado e nosso roteador de identidade virtual. Mas esse é um custo que nossos clientes e nossa equipe acham que vale a pena, pois, ao não sincronizar as senhas, minimizamos a superfície de ataque em vez de aumentá-la. Se não as sincronizarmos, não poderemos perdê-las - e um invasor não poderá explorá-las. Também argumentamos que as soluções de outros fornecedores consomem mais tempo e esforço a longo prazo, pois as soluções "mais rápidas" resultam em uma superfície de ataque muito maior com uma sobrecarga ainda maior.
RSA® Trava móvel, O Mobile Lock, que estabelece a confiança em dispositivos não gerenciados e ajuda a proteger o BYOD, também exemplifica os princípios Secure by Design e Secure by Default. O Mobile Lock só procura ameaças quando os usuários tentam se autenticar usando o RSA Authenticator para iOS e Android, e só restringe a autenticação quando detecta uma ameaça. Ele também consulta apenas o mínimo absoluto de dados para executar suas funções, e nosso parceiro Zimperium nunca vê informações pessoais sobre os usuários finais. Os ganhos de segurança de fazer algo mais - como verificar continuamente o dispositivo de um usuário - seriam mínimos, especialmente em comparação com a possibilidade de um invasor ter como alvo um serviço em segundo plano sempre ativo.
O mesmo acontece com nosso agente de autenticação multifator (MFA). No caso de uma interrupção da Internet, nosso agente de MFA é à prova de falhas para uma implementação no local, em vez de falhar na abertura ou entrar em um modo off-line em que a validação de OTP ocorre no próprio agente de MFA. Isso significa que os agentes de ameaças não podem Evitar a MFA simplesmente desconectando-se da Internet ou fazendo com que o serviço de back-end do MFA pareça estar off-line, que é essencialmente o que os agentes patrocinados pelo Estado fizeram com um ONG no ano passado.
A verdadeira segurança nunca é projetada em excesso: ela se baseia em uma combinação sensata de soluções simples sempre que possível e mais complexas quando necessário. Cada componente de um serviço precisa ser projetado para limitar a superfície de ataque sempre que possível. Isso significa coletar apenas o mínimo de informações de que um sistema absolutamente precisa e usar essas informações apenas quando necessário. Isso também significa tomar decisões arquitetônicas que minimizem a superfície de ataque em vez de expandi-la desnecessariamente.
A segurança cibernética tende a ser uma questão de jogar com as probabilidades. Melhore a sua fazendo a jogada inteligente e apostando em fornecedores que colocam a segurança em primeiro lugar.
