Resposta a incidentes (IR) na nuvem

O que é resposta a incidentes (IR) na nuvem?

Resposta a incidentes (IR) na nuvem é o processo que você segue quando ocorre um incidente de cibersegurança em seu ambiente de nuvem. Embora os aspectos de nuvem da IR sigam essencialmente as fases típicas da IR (Preparação, Detecção e Análise, Contenção, Erradicação e Recuperação e Pós-Incidente / Post Mortem), há diferenças críticas entre as plataformas de nuvem (executadas na AWS, Azure, GCP, Oracle Cloud, etc.). Uma equipe de especialistas em resposta e ferramentas pode fazer a diferença na obtenção de respostas claras e definitivas e no suporte de decisão necessário para sua recuperação.

Qual é a diferença entre a IR na nuvem e a IR de endpoint tradicional?

1. Sem acesso físico aos servidores

Em troca de ter o provedor de serviços de nuvem gerenciando as operações de rede e data center e aplicando correções (para PaaS), bem como escrevendo e mantendo o software (para SaaS), você sacrifica coisas que os analistas de resposta a incidentes geralmente desejam: acesso físico aos servidores para se conectar a um console, capturar imagens forenses de discos rígidos e a capacidade de instalar utilitários de diagnóstico especiais.

Na maioria dos casos com ambientes de nuvem, você não pode fazer dumps de memória fora de banda, fazer logon no console físico ou receber discos rígidos reais de um provedor de nuvem. E está tudo bem. Você precisa trabalhar dentro dos parâmetros de acesso do provedor de nuvem — como tirar instantâneos de armazenamento lógico, coletar e analisar os logs que o provedor de nuvem disponibiliza e assim por diante.

2. Ciclos de vida acelerados da nuvem

A combinação dinâmica de tecnologias em ambientes de nuvem modernos — uma mistura de containers, funções como serviço, hipervisores e máquinas virtuais executando microsserviços com workloads aumentando e diminuindo para atender às demandas variáveis de uma organização — torna a IR na nuvem um ambiente muito diferente do incidente clássico de captura de imagem e coleta de logs em um endpoint típico.

Sem planejamento adequado e comunicação interna, artefatos forenses provavelmente serão perdidos, pois workloads consideradas "defeituosas" — seja por processos automatizados destinados a manter as workloads da nuvem íntegras, ou por equipes de operações bem-intencionadas quando lançam rapidamente novas versões de uma plataforma para lidar com uma vulnerabilidade ou exploit — são normalmente descartadas para economizar custos. Se você não sabe onde procurar e não planejou coletar logs e reter instantâneos relevantes, pode descobrir que não tem informações suficientes para responder às perguntas que sua organização precisa fazer para conter e se recuperar de um possível ataque.

3. As operações “não autorizadas” são quase a norma

Novos ambientes de nuvem podem ser estabelecidos por qualquer unidade de negócios com acesso a um cartão de crédito e geralmente são desconhecidos da organização central de segurança da informação. Embora seja muito comum que a organização de segurança conheça sobre algumas operações críticas essenciais na nuvem, também é muito comum que os adversários ataquem componentes do seu patrimônio na nuvem que são periféricos ao seu conhecimento, em subsidiárias adquiridas recentemente ou há muito tempo, em sistemas e aplicações que estavam programados para aposentadoria ou deveriam receber atualizações de controles de segurança como parte de uma fase posterior de um plano de segurança que não se concretizou a tempo. Essas operações periféricas podem não ser consideradas essenciais para a missão da organização, mas podem levar a violações cujo custo tremendo excede em muito o tempo e o orçamento alocados a elas antes desses ataques.

4. A identidade é o novo perímetro

Ao contrário de um data center tradicional, onde o perímetro é definido pela rede usando firewalls, a identidade se tornou o verdadeiro perímetro em um ambiente de nuvem. Isso muda drasticamente nossas estratégias de contenção e remediação quando enfrentamos um comprometimento de dados na nuvem. Não é mais prático bloquear endereços IP ruins, assim como não é mais possível presumir que todos os usuários autorizados vêm de uma rede específica.

Quando contas de usuários sem requisitos de autenticação multifatorial (MFA) ou chaves de API, comumente roubadas de estações de trabalho, sistemas de controle de origem e hosts CICD, entre outros, são descobertas por adversários, eles podem causar danos de qualquer lugar na Internet. Os adversários também têm como alvo contas sincronizadas entre o Active Directory (AD) e o Azure Active Directory, o que significa que um comprometimento local pode facilmente se tornar um ataque à nuvem.

5. A oferta de pessoal qualificado é ainda mais escassa

Assim como há escassez de pessoal técnico com experiência sênior em nuvem, aqueles com experiência em engenharia de segurança em nuvem são ainda mais difíceis de encontrar e reter, e aqueles com experiência em resposta a incidentes (IR) de segurança em nuvem ainda mais. Para organizações com presença em mais de uma plataforma de nuvem, esse desafio é multiplicado.

Entendendo as fontes de log da nuvem

Uma das maiores diferenças entre a IR tradicional em um endpoint e a IR na nuvem são as fontes de log. Os logs são sempre importantes em uma investigação de ataque, mas a “verdade básica” do que é normal e autorizado em um ambiente de nuvem é mais difícil de construir sem logs.

Os logs de eventos nos permitem reunir as ações maliciosas executadas por um ator de ameaças durante uma investigação forense e nos ajudam a conter e expulsar esse ator de ameaças. Mas as fontes de log da nuvem não se alinham às fontes de log do endpoint e exigem diferentes ferramentas e técnicas de coleta. Em muitos casos, os logs na nuvem não são habilitados por padrão ou foram desabilitados propositalmente e podem ser complexos de recuperar sem as ferramentas certas.

Sem uma compreensão desses serviços e ferramentas de nuvem criados usando esses serviços, as empresas de IR que não têm especialistas dedicados em IR na nuvem terão dificuldade para coletar os dados necessários para uma investigação eficiente e eficaz.

Em casos de SaaS, sempre coletamos logs de autenticação (logs de login) e um conjunto específico de operações para todos os usuários, bem como outro conjunto de operações para todos os usuários de interesse. Em casos de infraestrutura (PaaS), coletamos logs do plano de serviço de nuvem, bem como quaisquer logs relevantes do plano de dados, logs de fluxo de VPC/VNet e quaisquer logs especializados relevantes (logs de invocação de função como serviço, logs de balanceador de carga ou CDN, etc.

Em ambos os tipos de investigações, coletaremos dados de métricas de desempenho se forem relevantes (especialmente quando faltarem fontes de evidências mais diretas) e alertas de detecção de ameaças na nuvem para contexto valioso. Os instantâneos de configuração não são fontes de log em si, mas podem ajudar a interpretar os eventos registrados nos logs.

Além disso, depois de ter esses logs, a interpretação das entradas de log (ou sua ausência) nem sempre é direta. Investigadores de nuvem experientes sabem quais trilhas de log existem nos diferentes ambientes de nuvem (AWS, Azure, GCP) e como coletar e interpretar os dados deles de forma rápida e eficiente. A análise de logs é uma parte fundamental da avaliação de comprometimento da nuvem.

À medida que as organizações tentam equilibrar a velocidade de entrega de novas experiências digitais ao usuário para modernizar seus processos de negócios com as necessidades de segurança e os custos do registro de eventos em sua plataforma de nuvem, existe a tentação de minimizar ou desabilitar completamente o registro no ambiente de nuvem. Isso se torna problemático diante de um comprometimento de dados na nuvem.

Contendo uma ameaça de nuvem ativa

Diferentemente de um ataque em um dispositivo de endpoint, você não pode simplesmente desconectar a máquina comprometida e desconectá-la da rede em um comprometimento de dados na nuvem. E lembrando que comprometimentos de dados na nuvem podem se mover rapidamente pelo seu ambiente de nuvem, entenda que a contenção é consideravelmente mais difícil em um ambiente de nuvem do que em um ataque ao endpoint.

Conter um incidente na infraestrutura de nuvem inclui identificar todos os princípios de segurança comprometidos e/ou adicionados pelo adversário, incluindo usuários, funções comprometidas (como por meio de sessões federadas ou armazenamentos de identidades comprometidos) e contas de serviço. Em muitos casos, o provedor de nuvem oferece suporte a mais de uma fonte de credencial para uma entidade de segurança, permitindo que um adversário se faça passar por uma conta de usuário ou serviço sem interferir na finalidade original e autorizada dessa conta, dificultando assim a detecção.

Alguns exemplos disso incluem várias chaves de API, além de uma senha para um usuário, várias fontes de credenciais para uma conta de serviço e vários dispositivos de autenticação multifatorial (MFA) para um único usuário. Tudo isso deve ser cuidadosamente rastreado e eliminado, garantindo monitoramento adequado para detectar quaisquer tentativas do adversário de restabelecer a persistência.

O escopo da contenção não termina aí. Frameworks de automação e implementação em plataformas de nuvem e qualquer código definido pelo usuário que possa atuar como um princípio de segurança, incluindo funções como serviço, containers e hosts, podem ser usados pelo adversário para restabelecer a persistência no ambiente.

Backdoors de rede, incluindo pontos de peering VPC não autorizados e modificações simples nas regras do grupo de segurança de rede, podem expor recursos ao controle contínuo do adversário. E a infraestrutura baseada em nuvem com permissões de saída excessivas, com políticas como permitir acesso a todos os intervalos de IP pertencentes a um provedor de nuvem confiável, pode ser abusada por adversários para se misturar ao tráfego autorizado para esse provedor de nuvem. Uma revisão abrangente de todos os possíveis pontos de articulação, mecanismos de persistência e valores discrepantes no acesso configurado é necessária para garantir contenção completa e subsequente ejeção.

Você provavelmente sabe que uma solução de Gerenciamento de Postura de Segurança em Nuvem (CSPM) é uma defesa importante antes da ocorrência de um ataque, porque um CSPM ajuda a identificar Indicadores de Erros de Configuração (IOMs) que contribuem para o risco de uma violação e, claro, remediar esses IOMs pode realmente evitar uma violação. Mas, muitas vezes, um CSPM também é uma parte importante da contenção de ataques, tanto porque pode ajudar a identificar (em combinação com soluções de segurança de endpoint) um ataque ativo na interface entre o endpoint e a nuvem, quanto porque os adversários podem continuar tentando violar o ambiente de nuvem usando esses erros de configuração.

Em outras palavras, enquanto os esforços de visibilidade e contenção estão em andamento, sua organização pode aproveitar a urgência do ataque para remediar erros de configuração existentes e quaisquer novos que tenham sido introduzidos pelo adversário. Compartilhar o acesso ao console do CSPM com seus colegas nas operações da plataforma de nuvem e capacitá-los a ver o progresso que eles fazem pode encurtar consideravelmente o caminho para proteger o ambiente de nuvem.

Resposta a incidentes (IR) da CrowdStrike para serviço em nuvem

A resposta a incidentes (IR) para um comprometimento de dados na nuvem requer um conjunto diferente de habilidades, experiência e ferramentas do que a IR tradicional para um ataque local. Sem especialistas dedicados em IR na nuvem com as ferramentas certas para as diferentes plataformas de provedores de serviços de nuvem (AWS, Azure/O365, GCP), você enfrentará longos atrasos na obtenção de respostas críticas, o que diminuirá seu tempo de resposta e recuperação. Organizações sem as habilidades necessárias para responder efetivamente têm dificuldade em conter ameaças ativas e ejetá-las da rede, muitas vezes perdendo evidências críticas e sendo incapazes de determinar exatamente o que aconteceu durante o ataque e quais dados podem ter sido comprometidos.

A equipe dedicada de especialistas em IR na nuvem da CrowdStrike é chamada para realizar investigações sobre comprometimentos de dados em nuvem, muitas das quais são resultado de configurações de segurança de nuvem mal configuradas. Recomendamos que as organizações fortaleçam sua postura de segurança na nuvem antes que ocorra um ataque, em vez de lidar com as consequências de um comprometimento de dados na nuvem.

Caso você esteja sofrendo um comprometimento de dados na nuvem, você precisa contratar uma empresa de IR que tenha uma equipe especializada de investigadores e analistas de resposta a incidentes na nuvem. As empresas que fornecem serviços tradicionais de IR em um ataque ao endpoint não serão eficazes quando se trata de responder a um ataque à nuvem.

A CrowdStrike tem uma equipe dedicada de especialistas em IR na nuvem com conhecimento dos ambientes de nuvem AWS, Azure/O365 e GCP. Criamos nosso próprio conjunto de ferramentas do Cloud Data Collector, que usamos para acelerar a investigação forense e obter visibilidade das ações maliciosas que foram executadas por um ator de ameaças.

A CrowdStrike orgulha-se de ser líder na resposta a incidentes (IR) na nuvem e de trazer controle, estabilidade e organização a um cenário que pode se tornar um evento caótico. Saiba como a CrowdStrike pode ajudar você a responder a um comprometimento de dados na nuvem de forma mais rápida e eficaz: