O que vem depois do Pentesting?

Se você trabalha com Segurança de Aplicações (AppSec), provavelmente já se deparou com essa situação: o que fazer depois de receber o relatório de pentesting?

Para explorar esse tema, convidei o @sushicomabacate para compartilhar sua visão e contribuir para essa discussão. O conteúdo deste artigo é baseado em várias pesquisas e também experiências e aprendizados, que podem não obrigatoriamente se aplicar ao seu caso, mas com certeza vão te inspirar a pensar em novas ideias e possibilidades.

Obs: não vamos abordar neste texto as diferenças de metodologia e escopo do pentesting; nem tampouco a efetividade desse tipo teste em um Programa de Segurança de Aplicações.

Um agradecimento especial aos profissionais de infosec que também de certa forma indiretamente colaboraram com essa pesquisa @Heitor Gouvêa, @Eduardo Santos e @Bruno Oliveira.

Ponto zero

Antes de tudo, vamos dar uma olhada em quando e por que realizamos o pentesting.

Quando o assunto é a segurança das nossas aplicações, o teste de penetração (penetration testing), ou pentest, geralmente acontece na fase de testes, quando a aplicação já está e produção no ciclo de desenvolvimento. Basicamente, é uma técnica que consiste em simular ataques reais contra um sistema, com o objetivo de identificar e explorar vulnerabilidades que possam comprometer a sua integridade, confidencialidade ou disponibilidade - os pilares de segurança da informação..

Dito isso, o penetration testing não pode ser tratado como uma peça isolada na sua estratégia de segurança.

Isso se torna ineficaz, uma vez que novos códigos estão constantemente sendo incorporados à aplicação, trazendo consigo potenciais vulnerabilidades.

Seguindo a máxima conhecida: o pentesting é como uma fotografia instantânea da sua aplicação, mas com data de vencimento.

(Imagem criada por IA)

Agora, dando esse passo para trás, podemos encarar o pentesting de uma maneira mais estratégica, especialmente para a gestão de AppSec.

Ao submeter suas aplicações a uma bateria de testes e simulações de ataques, você acaba se aproximando - pelo menos na essência - de uma possível realidade. Ao investir em nesses testes, algumas perguntas fundamentais devem surgir para justificar e acompanhar essa empreitada:

• As funcionalidades da minha aplicação estão sendo desenvolvidas com consideração aos requisitos de segurança?
• Os desenvolvedores estão recebendo treinamento adequado em Segurança de Aplicações (AppSec)? Existe um processo de revisão de código voltado para a segurança?
• Como estão sendo implementados os testes básicos de segurança no pipeline de desenvolvimento?
• Está claro para todos os envolvidos no desenvolvimento quem são os responsáveis, quais são os processos e objetivos em relação à Segurança de Aplicações?
• Qual é o nível de maturidade em Segurança de Aplicações que estamos atingindo?

Manter essas questões em mente vai fazer uma enorme diferença para a próxima etapa do processo.

1 Recebendo o Relatório de Pentesting

A empresa que fez o Pentest vai convidá-lo para uma call, na qual apresentará os achados. Em seguida, você definirá a forma de receber o relatório final de pentest em PDF, com senha, por ser uma informação muito sensível. O meio mais comum é o email, mas pode-se usar métodos mais seguros.

(Imagem fictícia de um relatório sendo compartilhado via e-mail)

Este documento é um exemplo acurado do que contém um desses reports. Fora a enrolação parte pré-textual, ele contém os seguintes itens:

• Um sumário executivo (já que eles não estão interessados no técniquês);
• Objetivo, premissas, etc;
• Metodologia de teste e escopo;
• Resumo das vulnerabilidades (quantidade, criticidade e classes de vulnerabilidades);
• Descrição das vulnerabilidades por ordem de criticidade (que é a melhor parte). Pra cada vulnerabilidade são apresentados:
• Detalhamento;
• Criticidade (contendo impacto e viabilidade técnica);
• Provas de conceito (geralmente não mais que 2);
• Sugestão de solução;
• Referências.

Bom, você abriu o relatório. A tensão e a frustração já percorreram todo o corpo: meus ativos estão vulneráveis. E agora?

Para muitos, esse momento pode ser como receber uma bomba nas mãos, e a vontade imediata é passar esse artefato explosivo para outra pessoa. Mas aqui, surpreendentemente, é necessário uma mente analítica e crítica para pensar em algo que muitas vezes é esquecido: a estratégia.

É hora da equipe de segurança se reunir e discutir sobre o relatório e seus resultados.

Com o documento em mãos, é possível repensar toda sua estratégia de desenvolvimento seguro através dessas evidências. Você pode olhar para aquelas perguntas do tópico zero e obter algumas hipóteses interessantes sobre seus processos e ferramentas de AppSec.

Não duvido da capacidade das empresas ou profissionais que realizam esses testes, mas erros podem acontecer. Ter sangue frio para analisar esses resultados também é fundamental para identificar possíveis problemas e abrir espaço para contestações que não foram feitas nas reuniões anteriores com a empresa que forneceu o serviço. “Será que essa vulnerabilidade de fato é crítica tendo em vista o impacto do negócio?”. Lembre-se do seguinte: quanto maior detalhe nas evidências e prova de conceito, mais fácil ficará para construir seu plano de remediação.

Os resultados obtidos trazem não apenas uma fotografia das suas aplicações, mas também revelam como está sua estratégia geral. Afinal, se um SQL injection simples na tela de login de um ativo crítico foi identificado, alguma coisa no início do seu processo necessita de atenção - muita atenção.

Em resumo: examine com carinho os principais tipos de vulnerabilidades identificados, pois eles dizem muito sobre o estado de segurança do seu desenvolvimento de software.

Alguns exemplos:
Se muitos pacotes desatualizados foram identificados, é hora de questionar a eficiência do seu Software Composition Analysis (SCA). Será que a gestão de dependências precisa ser aprimorada?

Questões básicas de segurança no código foram identificadas. Será que há algo a ser ajustado nos treinamentos realizados? Precisa investir mais tempo em code review com enfoque em segurança?

Essas questões precisam ser desdobradas, discutidas e analisadas, e se possível, documentadas.

Executivos, diretores, e outros gestores vão querer saber sobre o relatório do pentesting: prepara-se para uma reunião.

Se possível, prepare um material para uma apresentação, acompanhado de um resumo com uma linguagem específica para gestores, enfatizando a parte de impacto de negócio e técnico - campos que precisam estar descritos nos relatórios.

Com esse material, é possível angariar novos investimentos para seu time, principalmente se na construção de seu argumento deixar claro as evidências dos possíveis impactos de negócio.

Portanto, antes de iniciar as correções em si, pense em como esses resultados podem aprimorar sua estratégia como um todo. Este pode ser o maior valor gerado a partir desse processo.

2 Gestão de vulnerabilidades e orientação à riscos

Entramos em um momento interessante, as vulnerabilidades estão identificadas no relatório, e após uma análise cuidadosa foi possível documentar algumas hipóteses para a estratégia do time de segurança. Então, como vamos corrigi-las?

A realidade é que nenhuma vulnerabilidade pode ser corrigida de forma isolada. É necessário incorporá-la ao seu fluxo natural de vida, algo que chamamos aqui de gerenciamento de vulnerabilidades:

(Desenho do fluxo de tratamento de uma vulnerabilidade by @sushicomabacate)

Esse fluxo considera que a vulnerabilidade pode assumir alguns estados. Quando recebemos a vulnerabilidade, ela possui o estado Nova. Onde basicamente não sabemos nada sobre ela. Dependendo do resultado das primeiras validações, ela pode ir pro estado Duplicada ou Falso Positivo. Por exemplo, a vulnerabilidade pode ser reproduzida com sucesso pelo time que está analisando o resultado, mas se ela já foi achada anteriormente (por um scanner, outro pentest anterior ou qualquer outra coisa) aí ela vai para duplicada.
Após conseguirmos reproduzir a vulnerabilidade com sucesso, ela tem o estado Triada.

Nesse caso, vamos pensar que temos a vulnerabilidade já testada e comprovada sua veracidade, confirmando-se como um verdadeiro positivo - foi triada como segue a imagem:

(Desenho do fluxo de Estados de uma vulnerabilidade by @sushicomabacate)

Esse fluxo foi largamente inspirado nas recomendações da OWASP, porém, é apenas uma simplificação da tríade: Detection, Reporting e Remediation. Existem vários detalhes omitidos que são bem explorados em OWASP Vulnerability Management Guide. Dentre eles: definição do risco da vulnerabilidade, criação de reports para compartilhar na empresa- (incluindo o time owner do código vulnerável - e priorização da remediação das vulnerabilidades.

Compreender a existência desse fluxo é crucial para evitar redundância de dados. Chamamos isso de desduplicação: será que esse SQL Injection não é o mesmo identificado no mês passado por um DAST (Dynamic Application Security Testing) e já em processo de correção? Ou será esse XSS aquela vulnerabilidade que havíamos aceitado como um risco tolerável? Se todas essas informações estão sendo organizadas de maneira centralizada e padronizada, você terá essas respostas de maneira muito fácil e rápida.

Se você ainda não possui um sistema de gerenciamento de vulnerabilidades, este é o momento ideal para começar. Crie um fluxo, desenhe-o e documente o processo, alinhando as partes e padronizando as atividades.

Vale destacar que o gerenciamento de vulnerabilidades envolve mais do que identificar e corrigir falhas de segurança.

Para isso, é necessário adotar uma abordagem baseada em riscos, que considere o contexto, o impacto e a probabilidade de cada vulnerabilidade. Assim, você poderá proteger os ativos mais críticos para o seu negócio e alocar os recursos de forma mais eficiente. Para isso, é essencial ter uma gestão de ativos que permita identificar quais são os sistemas e aplicativos mais importantes e priorizar as ações de correção de acordo com o nível de severidade das vulnerabilidades.

3 Tratando a remediação

Vamos voltar para o relatório, a vulnerabilidade está descrita em detalhes juntamente com orientações sobre como deve ser remediada. É primordial examinar essas recomendações com a máxima atenção possível.

Eu costumo acreditar que a palavra final da orientação de como deve ser corrigido vem da OWASP, aliada à análise do contexto real da vulnerabilidade. Portanto, uma sugestão valiosa é consultar os materiais da OWASP, seja no cheat sheet ou nos projetos do próprio OWASP TOP 10. Além disso, você pode buscar outras referências para auxiliar, como o CAPEC para ataques e o CWE para vulnerabilidades. Discuta com o seu time sobre suas considerações, por fim, compare as informações de sua pesquisa interna com as do relatório.

Um aspecto fundamental é criar um plano de ação para a remediação individual de cada vulnerabilidade. Profissionalmente, costumo documentar todos os processos e atividades possíveis. Talvez você queira um documento específico para orientar a correção de cada vulnerabilidade, com exemplos de código, refinamento nos detalhes, referências importantes da OWASP para consulta, proporcionando objetividade e praticidade.

Ademais, acrescenta-se a esta documentação a realização de um acordo de nível de serviço (SLA), delineando prazos, os serviços a serem prestados, as metas de nível de serviço e as responsabilidades de cada parte no que tange à remediação. Lembre-se: vulnerabilidades classificadas como críticas devem ter prazos urgentes para remediação!

Relembrando: se você deseja ter controle total sobre seu processo de segurança de aplicações, quanto mais detalhes, contexto e refinamento, melhor será para o desenvolvedor.

4 O plano de ação para remediação

Se você se interessou por trabalhar com mais afinco na orientação da remediação, acredito que o método de divisão das correções em tasks possa te atrair.

Com o report em mãos, a pessoa do time de segurança pode criar cards na sua plataforma de gerenciamento (Jira, Kanban, etc) para cada uma dessas vulnerabilidades e seguir um fluxo de tratamento de vulnerabilidades.

Podendo conter nesse card o seguinte fluxo abaixo que ilustra o caminho de correção de uma vulnerabilidade:

1. Dado um report de vulnerabilidade, verificar se é uma duplicata de outro report já recebido;
2. Verificar se é possível reproduzir a vulnerabilidade;
3. Atribuir um risco, seguindo a política da empresa;
4. Atualizar a task/documentação com as informações obtidas durante a reprodução da vulnerabilidade;
5. Discutir com pares do time de segurança as melhores práticas pra fix, verificar a base de procedimentos da empresa se já existe alguma recomendação;
6. Apresentar todas as evidências + sugestão de fix para o time dono do código vulnerável e acompanhar o desenvolvimento, deploy e prazos;
7. Após desenvolvimento e deploy do fix, retestar/solicitar reteste da vulnerabilidade para garantir que foi resolvida;
8. Caso o reteste confirme que a vulnerabilidade foi erradicada, atualiza-se a documentação/task com os aprendizados.

Se a sua empresa adota uma abordagem ágil e de Produto no processo de desenvolvimento de software, é provável que os desenvolvedores estejam acostumados a receber esses tipos de cards com user stories, tasks, etc., detalhando o que precisam alcançar.

Ao seguir essa mesma estratégia, é possível tornar seu plano de ação mais acessível para desenvolvedores que preferem receber as atividades com a mesma padronização a que estão habituados no desenvolvimento de novas funcionalidades.

Exemplo de user story focada em segurança e tarefas de segurança associadas (SAFECode):

(Exemplo de User Story para correção de vulnerabilidades)

Esses itens são posteriormente inseridos no backlog, devidamente priorizados. Quando um novo sprint de desenvolvimento é iniciado, a equipe de desenvolvimento seleciona (ou recebe) as tarefas alocadas para o sprint, abrangendo tanto tarefas funcionais quanto aquelas focadas em segurança, e dá início ao trabalho de desenvolvimento.

Dentro desse contexto, algumas tarefas de segurança demandam ações combinadas de recursos arquitetos/desenvolvedores e controle de qualidade. Essas tarefas são prefixadas como A/D/T (Arquiteto/Desenvolvedor/Teste). Outras são marcadas como A/D (Arquiteto/Desenvolvedor) ou T (Teste).

5 Tornando a segurança uma responsabilidade compartilhada

Com toda a papelada pronta para botar todo mundo pra trabalhar, você deve imaginar, é só deliberar?

A real é que ninguém gosta de receber um trabalho a mais ou uma nova demanda assim inesperadamente. Quando se trata de AppSec, dimensionamos a cultura e a colaboração como fatores fundamentais. Todo mundo precisa estar conectado com este propósito. Se você busca apoio para resolver seus problemas, é crucial conscientizar e atualizar as pessoas sobre o que está acontecendo.

Para isso, é vital que sua equipe realize treinamentos, reuniões, seja com os líderes ou responsáveis pelo time de desenvolvimento ou até mesmo com os próprios desenvolvedores. Nesse momento, a comunicação, didática e clara é essencial. É importante também discutir sobre as estratégias de correção, pois os desenvolvedores são aqueles que mais conhecem o código. Vale lembrar que mesmo que você esteja familiarizado com os termos de segurança, outras pessoas podem não ter ideia do que significa.

Se deseja que essas vulnerabilidades sejam corrigidas, é preciso garantir que elas sejam compreendidas.

Apresentações, discussões e reflexões sobre o resultado do relatório são, portanto, peças chaves nesse processo, pois nesse momento você pode descobrir que no documento houve confusão entre autenticação de tokens JWT e autenticação de cookies, por exemplo. Quem conhece melhor as aplicações do que os desenvolvedores? Portanto, não subestime a autoridade que eles têm sobre o que constroem.

Se você transmitir a mensagem corretamente, todos, de alguma forma, abraçarão sua causa e se sentirão à vontade para incorporar as correções em suas sprints.

6 escrever, testar, corrigir, testar

Entregou os documentos, dividiu as tarefas e agora é só esperar o reteste do código corrigido? Assim como você precisa dos desenvolvedores, eles também vão precisar de você, e dessa vez de forma mais constante.

"Não entendi como funciona a correção dessa vulnerabilidade." Nesse momento, é fundamental prestar atenção às lacunas da equipe. Marcar treinamentos mais frequentes sobre as vulnerabilidades do relatório pode auxiliar em um alinhamento geral.

"Escrevi o código, mas não sei se corrigi de fato." Essa insegurança pode surgir nos desenvolvedores, pois, apesar de estarem acostumados com testes unitários, verificar um código para garantir sua efetividade contra um ataque pode ser uma novidade.

Profissionais de segurança são essenciais nessa fase de correções, seja para oferecer orientações sobre como lidar com esse tipo de vulnerabilidade recomendando documentações da OWASP ou do próprio framework, seja para analisar a execução de testes automatizados na esteira, como um SAST (Static application security testing).

Além disso, ter em mente o passo a passo de como funciona o ataque é um conhecimento que faz a diferença na hora de realizar um teste manual antes de ir para produção.

Se você entende que mensagens de erro não podem conter informações sensíveis, então teste todas as possibilidades para garantir que o que foi alterado no código seja efetivo. Esse tipo de teste, além de auxiliar no aprendizado sobre o funcionamento do ataque, fortalece o que pregamos em AppSec de "hacker mindset".

Em algumas situações, uma vulnerabilidade pode ter seu risco aceito pela organização, significando que ela opta por não corrigir ou mitigar o problema. Essa decisão pode ser baseada na percepção de que o impacto ou a probabilidade de exploração são baixos, ou que o custo e a complexidade da correção ou mitigação são consideráveis. Nesse cenário, a organização assume conscientemente o risco de possíveis ciberataques, monitorando a vulnerabilidade e revisando a decisão periodicamente.

Outros cenários

Quando uma vulnerabilidade não pode ser completamente remediada, ou seja, resolvida de forma a não ser mais explorada, a alternativa é a mitigação. Isso envolve tornar a exploração da vulnerabilidade mais difícil por meio de medidas de controle ou compensação. Por exemplo, se um software possui uma vulnerabilidade irremediável pelo fabricante, a organização pode optar por mitigá-la implementando um firewall, um antivírus ou uma política de acesso restrito.

Em times de segurança menos maduros, vulgo recém criados, é normal pedirem para o próprio time de segurança consertar as vulnerabilidades. O fluxo é basicamente o mesmo que foi comentado aqui, porém o item “owners do código vulnerável” é substituído pelo próprio time de segurança.

Geralmente, esse último cenário não se mantém por muito tempo, pois rapidamente se torna um gargalo. Mas é bom saber que existe.

Pentesting deve ser desafiador para quem faz

Se você contratou um serviço de pentesting ou possui uma equipe dedicada a isso, pense que esses profissionais adoram desafios, então dê trabalho a eles, dificultando ao máximo a possibilidade de encontrar uma brecha na aplicação. Para isso, invista em iniciativas de Segurança de Aplicações que estejam integradas desde o início do ciclo de desenvolvimento. Dessa forma, você potencializa a eficácia e o valor do pentesting.

Portanto, o fluxo apresentado neste artigo pode ser usado independentemente da origem das vulnerabilidades. Pode ser um report de pentest, um email relatando uma vulnerabilidade, ou mesmo um report de #bugbounty. O importante é que o fluxo de tratamento de vulnerabilidade seja uniforme e que se garanta que os passos sejam seguidos. Afinal, você não vai querer que uma vulnerabilidade seja marcada como Mitigada sem retestar, certo?

Lembre-se, pentesting deve ser apenas uma etapa dentro do seu abrangente Programa de Segurança de Aplicações. Não deixe de lado os outros processos.