Páginas

agosto 19, 2020

[Segurança] Falando mais sobre o vazamento de dados da Capital One

O vazamento de dados do banco americano Capital One, que aconteceu em Julho de 2019, trouxe muita oportunidade de discussão, uma vez que envolveu um importante banco americano, que até então era considerado uma grande referência na adoção de computação em nuvem.

Por isso, eu resolvi listar aqui várias informações interessantes sobre o caso, que fui coletando na medida em que estudava mais detalhes e via mais artigos sobre o assunto:
  • A Capital One era considerada um importante estudo de caso sobre migração para a nuvem. O site da Amazon possui várias informações sobre a estratégia de adoção de nuvem do banco, em parceria com a AWS, desde 2013. O projeto da Capital One era zerar a sua quantidade de datacenters: dos 8 existentes em 2014, eles pretendiam fechar os últimos 3 datacenters em 2020, e assim o fizeram;



  • Esse incidente trouxe a tona uma discussão muito importante sobre o compartilhamento de responsabilidade na prestação de serviços em nuvem. Em poucas palavras, quanto maior a abstração dos serviços (ex: SaaS), maior a responsabilidade do provedor de serviços em nuvem;
    • A AWS se posicionou que não tem responsabilidade sobre a invasão na infra-estrutura da Capital One, uma vez que os serviços de infraestrutura funcionaram como esperado, e a invasão explorou falhas nas ferramentas e configurações sob responsabilidade da Capital One;
  • Eles tinham um seguro contra ciber ataques ("cyber insurance policy") que cobre até 400 milhões de dólares;
  • A Cobalt.io publicou um pequeno gráfico com o timeline do incidente, e o blog sobre o assunto é bem legal e detalhado, vale a leitura:


  • Um ponto bem importante sobre o incidente é que a Capital One somente identificou o vazamento porque foi informada por um terceiro (uma pessoa externa a empresa), por e-mail, através do seu "Responsible Disclosure Program". Assim, o ataque só foi descoberto 117 dias (aproximadamente 4 meses) após o início da invasão. Segundo o relatório M-Trends 2020 da Fireeye Mandiant, o tempo médio para uma empresa detectar um ataque (chamado de "dwell time" em inglês) em 2019 era de 141 dias (para empresas que detectaram incidentes através de denúncias de terceiros);



  • Após o anúncio do vazamento de dados, as ações da Capital One caíram cerca de 5%, e somente voltaram ao mesmo patamar quase 2 meses depois;

  • Quatro meses após o vazamento, a Capital One substituiu seu CISO;
  • Apesar de ser um banco líder em tecnologia, no período anterior ao incidente o time de segurança estava enfrentando um clima tóxico e conflitos com a gestão, que causou a saída de cerca e 30% do seu time;
  • Em agosto de 2020, a Capital One aceitou pagar uma multa de 80 milhões de dólares imposta pelos reguladores americanos (nota oficial). Segundo a notificação da OCC (Office of the Comptroller of the Currency), as principais causas do incidente estão relacionadas a deficiências nos processos de gestão de riscos e auditoria interna relacionados a migração para o ambiente em Nuvem, incluindo deficiências nos controles de segurança de redes, prevenção a vazamento de dados e gestão de alertas. O Board da empresa também falhou por não cobrar dos gestores pelas correções das vulnerabilidades e falhas apontadas pelas auditorias internas.
Baseado no relatório existente do FBI, no post da Cloudsploit e no artigo do Brian Krebs, eu criei um diagrama detalhando melhor os passos do ataque:


O framework ATT&Ck, do MITRE, é bem legal para nos ajudar a entender o passo-a-passo do ciber ataque e como ele poderia ser mitigado. Veja o mapeamento realizado pelo Ashwin Patil, da Microsoft:


No paper "A Case Study of the Capital One Data Breach", o ataque foi mapeado da seguinte forma:



Para saber mais:
Atualizado em 09/11: Veja mais 2 artigos sobre o incidente:

Atualizado em 25/05/2021: Seguem mais alguns artigos:

Um comentário: