PT EN ES

Como as instituições de serviços financeiros estão lidando com o gerenciamento de exposição contínua 

11 de agosto de 2023
XM Cyber

As principais instituições de serviços financeiros estão identificando proativamente suas exposições de alto risco com uma plataforma de Exposure Management (Gerenciamento de Exposição). Esta postagem relata quatro vezes que elas descobriram caminhos de ataque para seus dados de negócios – e priorizaram a correção para evitar o ataque

Nas instituições financeiras, as equipes de segurança investem continuamente nas melhores ferramentas de detecção e resposta. Com o tempo, isso levou a um Tempo Médio de Detecção (MTTD, na sigla em inglês) e Tempo Médio de Resposta (MTTR, na sigla em inglês) bastante aprimorados. E os tempos de permanência também diminuíram. Em 2021, o número médio de dias entre o comprometimento e a detecção caiu para apenas três semanas, de acordo com o Mandiant M-Trends Report. 

Este é um grande passo à frente – mas apesar de todas as melhorias feitas pelos defensores nas áreas de detecção e resposta, violações e incidentes ainda acontecem. Não importa se leva 21 dias para identificar uma violação – se o invasor atingir seu alvo em menos dias, já pode ser o fim do jogo. 

Embora continuem a confiar em soluções de endpoint protection e ferramentas de log correlation como uma forma necessária de prevenir e alertar sobre ataques em tempo real, muitas instituições de serviços financeiros estão fazendo a mudança para a prevenção proativa, para garantir sua resiliência. 

Isso ocorre porque os invasores não analisam a exposição individual – em vez disso, eles aproveitam uma combinação de vulnerabilidades, configurações incorretas, identidades excessivamente permissivas e outras lacunas de segurança para se mover pelos sistemas e atingir ativos confidenciais. Essa rota é chamada de caminho de ataque e esse tipo de movimento lateral pode passar despercebido por semanas ou meses, permitindo que os invasores causem danos significativos e contínuos enquanto se escondem nas redes. Compreender os caminhos de ataque disponíveis demonstra como os invasores comprometem ativos críticos em redes de nuvem locais e híbridas. 

De um possível ataque man-in-the-middle — uma forma de ataque em que os dados trocados entre duas partes são, de alguma forma, interceptados pelo invasor sem que a vítima perceba — à identificação de um risco importante na cadeia de suprimentos, aqui estão quatro caminhos de ataque reais que encontramos e corrigimos nas redes do setor financeiro. 

  1. Potencial ataque man-in-the-middle em uma seguradora 

Uma grande seguradora com a qual trabalhamos descobriu que um pequeno subconjunto de máquinas estava enviando transmissões DHCPv6, permitindo que um invasor se posicionasse como um intermediário (man-in-the-middle) para explorar uma vulnerabilidade de atualização do Windows presente nesse sistema. Um desses sistemas era a máquina de um desenvolvedor com várias chaves SSH privadas desprotegidas em suas pastas de downloads. Usando essas chaves SSH, um invasor poderia comprometer facilmente cerca de 200 sistemas Linux com seu centro de processamento de dados local e em seu ambiente de nuvem. 

Isso poderia ter permitido que grande parte de seus servidores Linux fosse comprometida. A partir desses sistemas, o invasor poderia cometer ataques adicionais, criptografar sistemas e dados para ransomware (sequestro de dados) ou realizar data exfiltration.  

Como isso foi remediado? 

Ao desabilitar o DHCPv6 e corrigir a máquina do desenvolvedor, tanto a vulnerabilidade quanto a configuração incorreta foram resolvidas. Também foi um bom momento para revisar as melhores práticas com os desenvolvedores para conscientizá-los sobre as chaves SSH que colocam seus sistemas Linux em risco, para limitar o risco futuro. 

  1. Instituição financeira global garante que desenvolvedores offshore não possam acessar dados de produção 

Uma instituição financeira global com a qual trabalhamos passou o último ano fortalecendo o ambiente sandbox — ambiente isolado usado por desenvolvedores e programadores para ter segurança ao realizar testes em novos aplicativos, programas e plataformas — no qual seus desenvolvedores offshore (ou seja, localizados fora da sede) trabalham. 

Eles não achavam que algum dos desenvolvedores conseguiria acessar seu ambiente de produção, mas queriam ter certeza. Uma ameaça interna maliciosa, como um desenvolvedor offshore que começa a agir por conta própria ou falta de controle sobre como os contratados offshore lidam com sua própria segurança (por exemplo, não usar autenticação multifator ou senhas complexas ou armazenar senhas em aplicativos de anotações não criptografados) pode representar riscos significativos aos dados de produção da empresa. 

Percebemos rapidamente que não só era possível, mas também muito fácil para qualquer um dos desenvolvedores abusar de uma função do Lambda na AWS (Amazon Web Services) — um serviço de computação que permite executar código sem o provisionamento ou gerenciamento de servidores —, assumir uma função com privilégios e, em seguida, mover-se lateralmente para o ambiente de produção. 

Como isso foi remediado? 

A equipe de segurança compartilhou esse caminho de ataque com a equipe de arquitetura de nuvem, que removeu a configuração incorreta do Lambda para corrigir esse problema e garantir que não houvesse potenciais caminhos de ataque do ambiente de sandbox do desenvolvedor para os sistemas de produção. Eles agora executam a mesma simulação todos os dias para demonstrar à liderança que não há como nenhum contratado terceirizado acessar seus dados de produção. 

  1. Banco global pensou que o patch ZeroLogon foi implantado 

Como parte da patch Tuesday — termo não oficial que se refere à segunda terça-feira de cada mês, quando a Microsoft lança correções para erros em seus sistemas operacionais — um de nossos clientes, um banco global, tentou corrigir todos os servidores usando o SCCM (solução de gerenciamento de endpoint para dispositivos, aplicativos e servidores da Microsoft). Isso incluiu o patch para a vulnerabilidade ZeroLogon (CVE-2020-1472) nos controladores de domínio, que são muito sensíveis e de missão crítica; portanto, nem todos foram reinicializados após a atualização do patch

O patch foi implantado, mas a correção não foi totalmente implementada devido à reinicialização que foi suprimida. Isso deixou um caminho aberto que invasores poderiam usar para comprometer os controladores de domínio. 

Como isso foi remediado? 

Assim que souberam do problema, eles mudaram seus procedimentos para garantir que, no futuro, não se esqueçam de reiniciar após o patch, quando necessário. 

  1. O banco e o caminho de ataque complicado 

Uma instituição financeira global identificou uma automação usando uma conta de serviço que tinha iniciado uma ação na porta SMB (Server Message Block). Isso poderia arriscar que as credenciais dessa conta de serviço fossem usadas para um ataque man-in-the-middle dentro da rede, o que permitiria que um invasor se movesse lateralmente para outro dispositivo/estação de trabalho na rede. 

Em seguida, eles encontraram chaves privadas SSH (Secure Socket Shell) para um servidor em execução em uma instância do EC2 (sigla para Amazon Elastic Compute Cloud, parte central da plataforma AWS). Anexado a este EC2 estava uma função IAM — uma identidade que pode ser criada no AWS — e, usando suas permissões, foi possível criar um novo EC2. Por fim, isso poderia ser usado para comprometer um de seus ativos mais críticos, utilizado para implantação no ambiente do cliente. 

Embora seja um caminho um pouco complexo, é muito potente – e se as entidades erradas o localizassem, poderia ser um desastre. 

Como isso foi remediado? 

Eles imediatamente remediaram cada parte do ataque, removendo chaves SSH privadas, redefinindo as permissões de função do IAM e removendo usuários específicos. 

Feche as exposições de hoje para prevenir os ataques de amanhã 

A maioria das equipes de segurança tem muitas exposições e não tem tempo ou capacidade de ver quais delas mais impactam seu risco ou como todas podem se juntar para serem exploradas por um invasor. 

Com o gerenciamento de exposição, você pode entender onde estão as vulnerabilidades e exposições de maior risco na infraestrutura, para priorizá-las. Você não só pode identificar as exposições que representam o maior risco, mas também saberá exatamente quais ativos críticos estão em risco e como remediar, com instruções passo a passo. 

Algumas das maiores e mais complexas organizações de serviços financeiros do mundo usam a XM Cyber — parceira da Bravo em cibersegurança e líder global em segurança de nuvem híbrida — ​​para erradicar o risco. Saiba como você pode eliminar o risco em sua rede de nuvem híbrida com uma fração do esforço: 

Conheça a XM Cyber 

Publicado originalmente pela nossa parceira XM Cyber  

uma empresa