Risco cibernético de terceiros chega à capa do DBIR 2025 da Verizon

O Data Breach Investigations Report de 2025 da Verizon agora está disponível. Como nós falamos do relatório de 2024 neste espaço, nada mais justo que a cobertura se repita este ano, especialmente considerando o dado de que o percentual de incidentes com perda de dados envolvendo um terceiro dobrou, chegando a 30%.

Não é de se surpreender, portanto, que o risco de terceiros é um ponto focal do relatório de 2025. A capa, inclusive, representa a difícil tarefa de proteger uma infraestrutura que depende de vários fornecedores.

O relatório deste ano analisa os incidentes que ocorreram entre 1º de novembro de 2023 e 31 de outubro de 2024, o que significa que tanto as violações de dados armazenados na Snowflake (que começaram em abril do ano passado) quanto o apagão da CrowdStrike (em julho) fizeram parte do escopo. A Verizon segue a política de não mencionar as empresas envolvidas nos incidentes, mas há uma exceção em casos de larga escala que foram divulgados publicamente, então tanto a Snowflake como a CrowdStrike foram mencionadas nominalmente. 

Isto dito, o DBIR sempre nos dá indicativos interessantes sobre padrões gerais e tendências, então é melhor não pensar demais nesses incidentes específicos. Aqui, nosso foco será em dois grandes temas do relatório: credenciais e vulnerabilidades.

Nosso podcast Alice in Supply Chains recebeu o autor do DBIR, Alex Pinto, como convidado especial para um episódio extra dedicado ao relatório. Ouça aqui ou em sua plataforma de podcast preferida (áudio original apenas em inglês).

Desafios com credenciais e autenticação

O infostealer é um tipo de malware que extrai credenciais e dados do sistema, normalmente logo após a vítima executar o arquivo malicioso. Para fazer isso, o infostealer varre o sistema em busca de senhas armazenadas, cookies de navegador e chaves criptográficas. Ao contrário de keyloggers tradicionais, eles não aguardam até o usuário digitar uma senha.

Existe todo um ecossistema criminoso no entorno dos infostealers. As credenciais roubadas normalmente são disponibilizadas em marketplaces criminosos ou em canais fechados para "assinantes".

Como essas credenciais normalmente estão dentro de "logs" que também contêm metadados sobre os sistemas de onde a senha foi obtida, os autores do DBIR na Verizon conseguiram estimar quantas credenciais corporativas foram roubadas de dispositivos gerenciados e não gerenciados.

O que eles descobriram pode surpreender algumas pessoas. Embora 30% das máquinas infectadas por infostealers fossem gerenciadas, 46% das credenciais corporativas foram roubadas de dispositivos não gerenciados.

O abuso de credenciais é principal para o acesso inicial, de acordo com o DBIR (22% de todas as brechas que não envolveram erro ou uso indevido). Portanto, incidentes de terceiros muitas vezes envolvem credenciais roubadas também. As violações do Snowflake, por exemplo, teriam sido possibilitadas por credenciais que já tinham sido roubadas com infostealers — e essas credenciais foram abusadas quando os criminosos perceberam o valor que elas tinham e a ausência do MFA nessas contas.

Como é dito no relatório, é difícil saber exatamente por que tantas credenciais corporativas foram roubadas de dispositivos não gerenciados. Pode ser que as empresas em questão tinham uma política Bring Your Own Device (BYOD), ou que elas não conseguiam fazer cumprir sua política sobre o uso dos dispositivos (talvez por estarem abaixo da "linha de pobreza de cibersegurança").

Contudo, vale lembrar que terceiros muitas vezes não estão sujeitos às mesmas regras rígidas que funcionários, mesmo quando recebem credenciais de sistemas corporativos, e que isso facilmente poderia explicar algumas dessas situações também.

Além disso, a autenticação não se limita a usuários e senhas. Há uma infinidade de tokens e segredos compartilhados em uso nas APIs, pipelines de desenvolvimento, sistemas de acesso remoto, entre outros.

Em um conjunto de dados analisado pelo DBIR, a mediana de tempo para remediar um segredo vazado em um repositório de GitHub foi de 94 dias, mostrando que usuários de conhecimento elevado (como desenvolvedores) não estão imunes a esse problema e que o tratamento é um desafio tão considerável quanto a prevenção.

Vulnerabilidades não se programam sozinhas (ainda)

A exploração de vulnerabilidades aumentou 34% no conjunto de dados do DBIR, sendo agora responsável por 20% de todas as violações. Este também é um vetor relevante na perspectiva de risco de terceiros, embora nem todos enxerguem as vulnerabilidades como um ponto a ser considerado na gestão de risco de terceiros.

Embora as empresas devam atualizar seus sistemas quando algum patch é disponibilizado, é fato que escolher um fornecedor diferente poderia ter dado mais tempo para que a atualização fosse aplicada ou ter gerado menos problemas que exigem patches urgentes. As empresas normalmente têm uma visibilidade limitada sobre as práticas e as pipelines dos desenvolvedores de software, mas cada vulnerabilidade tem um custo – ainda que seja apenas a indisponibilidade provocada pela atualização – e uma transparência maior seria bem-vinda.

Não devemos pensar que uma gestão de vulnerabilidades perfeita nos daria uma carta branca para desconsiderar as vulnerabilidades dos ambientes de TI, nem que que qualquer exploração que não use uma falha "dia zero" é sempre um fracasso da gestão de vulnerabilidades. Uma empresa pode estar com dificuldades em sua gestão de vulnerabilidades precisamente por ter escolhido fornecedores menos seguros sem ter consciência disso.

Iniciativas como o Software Bill of Material (SBOM) e outras recomendações estão trazendo alguns avanços, mas não há muita pressão para que os fornecedores de software sejam mais abertos a respeito de como lidam com seus repositórios e acesso dos desenvolvedores, por exemplo.

A preocupação é ainda mais considerável quando se considera as integrações com outros fornecedores. O uso de IA em tarefas de programação pode criar um cenário em que uma vulnerabilidade "se programou sozinha", já que estudos têm seguido que códigos gerados muitas vezes contêm alguma vulnerabilidade.

Uma descoberta recente é a de que modelos de linguagem de grande escala (large language models – LLMs) tendem a requisitar bibliotecas e dependências inexistentes que podem ser criadas por um indivíduo malicioso com o intuito de fazer com que o código gerado baixe códigos maliciosos. Esse ataque foi chamado de "slopsquatting".

Por enquanto, a maioria dos softwares ainda resulta do trabalho de humanos, então toda vulnerabilidade existe porque alguém (normalmente por descuido) a programou. Como o Alex Pinto da Verizon disse em nosso podcast: "pode ser que isso não seja verdade em alguns anos, mas a vulnerabilidade não se programou sozinha". E, se um fornecedor é responsável por ela, é um incidente na cadeia de fornecedores e, portanto, envolve um risco de terceiro.

Erros são lições

Todos cometem erros, mas esses erros devem se tornar lições para todos nós. Como sempre, o Data Breach Investigations Report da Verizon oferece um olhar excelente sobre a forma desses erros na área da cibersegurança, com muitos aprendizados.

Recomendados que você leia o relatório – incluindo todas as notas de rodapé! Se ainda tem sabe se vale a pena, aqui há alguns outros dados interessantes:

• Um elemento humano ainda está presente em 60% das violações. Talvez mais programas de conscientização em segurança ou mudanças em processos para diminuir falhas humanas sejam uma boa ideia?
• 28% dos ataques financiados por estados tinham um motivo financeiro, derrubando a ideia de que esses ataques ocorrem apenas por espionagem.

Riscos envolvendo IA. O uso de IA para gerar o texto de e-mails maliciosos dobrou nos últimos dois anos. Além disso, muitos funcionários (72%) estão se identificando em serviços de IA sem usar o e-mail corporativo. É possível que esses serviços estejam sendo usados sem aderência à política da empresa, criando riscos de vazamentos de dados.

‍