Por que a triagem pode estar com os dias contados

Se há algo que a segurança como um todo pode melhorar, é a reputação de atrasar o trabalho de uma organização.

Um dos principais responsáveis por essa reputação é a “triagem” — o processo de validar se um alerta de segurança realmente afeta sua organização, avaliar o impacto estimado e descobrir como resolvê-lo.

Neste artigo, vamos analisar por que a triagem pode se tornar rapidamente um gargalo para as organizações e defender que todos devemos buscar eliminá-la e nos concentrar em corrigir vulnerabilidades.

Um fluxo de triagem exemplar

Vamos imaginar como poderia ser um fluxo de triagem para um alerta de vulnerabilidade de segurança recém-recebido.

Vou usar como exemplo a vulnerabilidade RCE (execução remota de código) encontrada recentemente no Apache Struts, que acabou sendo explorada no caso Equifax. Podemos imaginar como uma empresa desse porte poderia lidar com uma vulnerabilidade assim:

• Uma pessoa da equipe de segurança recebe um alerta sobre a existência da vulnerabilidade. Isso pressupõe que ela esteja inscrita nas listas de e-mails relevantes ou use ferramentas que a alertem sobre essa vulnerabilidade (e que também leia esses alertas!).

• Essa pessoa da equipe de segurança pediria a um dos engenheiros um relatório de todos os aplicativos do portfólio da empresa que usam Apache Struts. Só isso já é uma tarefa nada simples, pois gerenciar inventário e composição é bastante desafiador, principalmente para empresas que atuam há muito tempo. O desafio seria ainda maior para empresas que passaram por fusões e aquisições e incorporaram várias equipes com diferentes pilhas de tecnologia ao longo dos anos. Ainda assim, vamos supor que a organização conseguisse gerar um relatório com 100 projetos que usam Apache Struts.

• Em seguida, a pessoa da equipe de segurança abriria 100 chamados no Jira com severidade “crítica” e acionaria o protocolo de mobilização geral da empresa para resolver o problema imediatamente.

• Seria preciso identificar e designar 100 engenheiros de diferentes áreas da organização para corrigir essa vulnerabilidade.

Agora, vamos imaginar a situação pela perspectiva dos desenvolvedores. É provável que o desenvolvedor esteja trabalhando em um recurso de alto valor e queira entregá-lo rapidamente para cumprir um marco importante para os negócios ou um prazo. Ainda assim, trata-se de um alerta de segurança importante, então será preciso lidar com ele. Veja o que seria necessário fazer:

• Ler sobre a vulnerabilidade em questão.

• Estudar a execução remota de código e a classe da própria vulnerabilidade.

• Tentar descobrir se a vulnerabilidade afeta o aplicativo em questão. Talvez seja preciso localizar o exploit e confirmar se ele se aplica ou não.

• Pesquisar as possíveis correções para essa vulnerabilidade.

• Aplicar as correções.

• Confirmar que a vulnerabilidade foi removida.

É muito trabalho, e parte dele exige conhecimento especializado em segurança. Todo o fluxo de triagem pode levar dias, semanas ou até meses, dependendo da complexidade dos processos internos da sua empresa. E isso não é bom.

Podemos criar um software para ajudar na triagem?

Provavelmente! Com instrumentação de código e machine learning, poderíamos criar um sistema que identificasse caminhos de código que usam o método vulnerável nas bibliotecas afetadas. Se funcionasse com precisão (ou seja, com poucos falsos positivos e falsos negativos), isso reduziria algumas etapas da triagem para os desenvolvedores. No entanto, mesmo que comprovássemos que a vulnerabilidade pode ser explorada no nosso contexto, ainda caberia ao desenvolvedor descobrir como corrigi-la!

Muitas vezes, o mais perigoso é quando as ferramentas sugerem que, no contexto atual, talvez não existam fluxos de dados que permitam a exploração. Nesses casos, muitas organizações suprimem ou ignoram o alerta — e é aí que mora o perigo.

O fato de o código talvez não ter fluxos de dados vulneráveis agora não significa que isso continuará assim amanhã. Um método que não é chamado hoje pode ser chamado após o próximo commit de um desenvolvedor. Provavelmente, o próximo desenvolvedor não terá como saber que há um método vulnerável escondido na biblioteca que está usando, nem que o alerta foi suprimido porque esse método ainda não era chamado. Basear sua postura de segurança na premissa de que o método não é chamado hoje está muito perto de ser imprudente.

Olhando para o panorama geral, a triagem é apenas uma etapa preliminar para corrigir vulnerabilidades. Ela é usada porque corrigir vulnerabilidades parece difícil e trabalhoso. Mas e se, em vez de usar software para ajudar na triagem, eliminássemos esse processo e usássemos software para automatizar as correções?

Pull requests de alertas da Snyk: é isso aí!

Quando você adiciona seus projetos à Snyk, mantemos um inventário preciso e atualizado de todas as suas dependências. Por isso, quando uma vulnerabilidade importante, como a RCE no Apache Struts, é divulgada, podemos alertar você em tempo real. Mais importante ainda, podemos dizer exatamente quais dos seus aplicativos contêm a vulnerabilidade. Ao conectar a Snyk ao seu gerenciador de código-fonte (como Github, Gitlab ou BitBucket), podemos ir além e enviar uma pull request com a própria correção diretamente para os repositórios afetados.

Para remover a vulnerabilidade do seu código, basta aprovar a pull request. Corrigir a vulnerabilidade é a decisão certa, independentemente de esse código estar sendo executado ou não pelos seus fluxos de dados hoje.

Além de substituir todo o fluxo de triagem por um simples botão “aceitar” na pull request, isso também reduz o nível de conhecimento especializado em segurança necessário na organização para implementar as correções. Segurança simples e rápida — muito bom, não é?