Relatório mostra que a violação de dados da Equifax era “totalmente evitável”

É sempre bom ver o dinheiro dos nossos impostos sendo bem utilizado. Recentemente, o governo dos EUA divulgou um relatório que mostra que a grave violação de dados da Equifax no ano passado era totalmente evitável, caso a empresa tivesse feito esforços razoáveis para se proteger — e proteger nossos dados. Neste post, destacamos algumas das principais descobertas do relatório e mostramos como você pode se proteger melhor do que a Equifax.

O relatório

O Comitê de Supervisão e Reforma Governamental da Câmara divulgou um relatório elaborado por sua equipe após uma investigação de 14 meses sobre a violação de dados da Equifax, amplamente documentada como um dos maiores incidentes de segurança da história dos EUA, que afetou mais de 148 milhões de consumidores. Como a maioria dos leitores já sabe, a Equifax não corrigiu uma vulnerabilidade conhecida no Apache Struts, um framework web Java de código aberto muito usado.

O comitê analisou mais de 122 mil páginas de documentos e entrevistou três ex-funcionários da Equifax que atuavam diretamente nas equipes de TI da empresa, para apoiar a investigação e elaborar o relatório, que você pode ler na íntegra aqui.

O relatório confirma que “a Equifax não detectou a exfiltração de dados porque o dispositivo usado para monitorar o tráfego da rede ficou inativo por 19 meses devido à expiração de um certificado de segurança”. Quando a Equifax atualizou o certificado dois meses depois, sua equipe “percebeu imediatamente um tráfego web suspeito.”

O erro: um único especialista em segurança para resolver tudo

O mais notável é que o ex-CEO da Equifax, Richard Smith, que se aposentou pouco depois do incidente, culpou um único funcionário de TI por não corrigir a biblioteca Struts que continha a vulnerabilidade conhecida. Smith explicou ao comitê o erro que levou ao incidente da seguinte forma:

“O erro humano foi que a pessoa responsável por comunicar à organização que o patch deveria ser aplicado não o fez”

Acreditar que a culpa era de uma única pessoa mostra o quanto a Equifax estava distante, na época, de adotar boas práticas de segurança em todas as suas equipes. O erro fundamental foi ter um processo de segurança que dependia de uma única pessoa, em vez de compartilhar essa responsabilidade entre as equipes, começando pelos desenvolvedores.

As conclusões do relatório também apontam uma “lacuna de execução entre a elaboração e a aplicação das políticas de TI.” Essas informações retratam uma Equifax com equipes de engenharia, operações e segurança isoladas, que não incorporavam práticas operacionais ou de segurança aos fluxos de desenvolvimento nem ao ciclo de vida das aplicações.

Esses são os principais problemas que o DevSecOps busca resolver: deslocar boa parte dos testes de segurança para as etapas iniciais do desenvolvimento, permitindo identificar e corrigir vulnerabilidades no código e em bibliotecas de código aberto o mais cedo e rapidamente possível. Assim, *todos* os desenvolvedores compartilham as responsabilidades de segurança, e os testes de segurança são incorporados a todas as etapas do fluxo de desenvolvimento. Isso contrasta fortemente com a dependência da Equifax em um único funcionário.

A solução: integrar a segurança ao fluxo de desenvolvimento

Vamos mostrar como boas práticas de DevSecOps poderiam ter evitado a violação de dados da Equifax por meio da biblioteca Struts vulnerável, com uma equipe de desenvolvimento no comando, em vez de depender de uma única pessoa. Houve dois dias entre a divulgação da vulnerabilidade no Apache Struts e o primeiro exploit na aplicação da Equifax. Vamos acompanhar o processo, do desenvolvimento à produção, para ver em que etapa esse problema de segurança deveria ter sido identificado e corrigido.

Desenvolvimento: Se o código da aplicação ainda estivesse em desenvolvimento ativo, as equipes estariam desenvolvendo, compilando e testando a aplicação localmente. A integração de testes de segurança para identificar dependências vulneráveis alertaria as equipes por meio de notificações nos IDEs e nos builds. Assim, todos os desenvolvedores saberiam que a nova vulnerabilidade existe e receberiam recomendações automatizadas para corrigi-la por meio de pull requests ou diretamente nos IDEs.

CI: Qualquer novo build executado por um servidor de CI testaria automaticamente as dependências da aplicação por meio de um plugin para servidor de CI ou da execução de uma CLI como tarefa. Isso sinalizaria imediatamente a nova vulnerabilidade, interromperia o job de CI e exigiria uma ação corretiva antes de prosseguir.

Monitoramento: Estejam ou não em desenvolvimento ativo, as aplicações em produção devem ser monitoradas continuamente. Assim, novas vulnerabilidades divulgadas poderiam ser tratadas imediatamente. As equipes de desenvolvimento receberiam notificações pelos canais de sua preferência, como PRs automáticos, e-mails ou mensagens no Slack, junto com as atualizações necessárias para eliminar o problema.

Tempo de execução: Com ferramentas de segurança em tempo de execução, qualquer comportamento anormal ou invocação de funções vulneráveis seria sinalizado imediatamente, permitindo que as equipes reagissem aos incidentes de segurança assim que ocorressem.

Principais conclusões

O relatório apresenta cinco principais conclusões sobre o incidente de segurança, conforme documentado pelo comitê:

1. Totalmente evitável. A Equifax não avaliou nem mitigou adequadamente seus riscos de cibersegurança. Se a empresa tivesse agido para resolver os problemas de segurança que já eram visíveis, a violação de dados poderia ter sido evitada.

2. Falta de responsabilização e de estrutura de gestão. A Equifax não definiu claramente as linhas de autoridade em sua estrutura interna de gestão de TI, o que levou a uma lacuna entre a elaboração e a aplicação das políticas de TI. Em última análise, essa lacuna limitou a capacidade da empresa de implementar iniciativas de segurança de forma abrangente e no momento certo.

3. Sistemas de TI complexos e desatualizados. A estratégia agressiva de crescimento da Equifax e o acúmulo de dados resultaram em um ambiente de TI complexo. Tanto a complexidade quanto a obsolescência dos sistemas legados desenvolvidos sob medida pela Equifax tornavam a segurança de TI especialmente desafiadora.

4. Falha na adoção de medidas de segurança responsáveis. A Equifax deixou mais de 300 certificados de segurança expirarem, incluindo 79 certificados usados para monitorar domínios essenciais para os negócios. A falta de renovação de um certificado digital por 19 meses deixou a Equifax sem visibilidade da exfiltração de dados durante o ataque cibernético.

5. Falta de preparo para dar suporte aos consumidores afetados. Depois de informar o público sobre a violação de dados, a Equifax não estava preparada para identificar, alertar e prestar suporte aos consumidores afetados. O site dedicado ao incidente e as centrais de atendimento ficaram sobrecarregados imediatamente, impedindo que os consumidores afetados acessassem as informações necessárias para proteger sua identidade.

Se você ainda não experimentou, pode testar gratuitamente seus projetos de aplicação com o Snyk! Vamos começar a analisá-los e monitorá-los em busca das vulnerabilidades existentes e ajudar você a eliminá-las da sua base de código.