Pentest: o que é, quando fazer e por que o relatório só vale com reteste

Toda empresa que contrata um pentest recebe, no fim, um documento. Ele costuma ser longo, cheio de capturas de tela e classificações de risco, e chega a uma caixa de entrada onde disputa atenção com o fechamento do mês. Semanas depois, boa parte dos achados continua lá, do mesmo jeito que o testador encontrou.

Este guia é para quem contrata o teste, não para quem quer seguir a carreira de pentester. Ele explica o que é o pentest, como ele se diferencia do scan, como escrever o escopo, o que o relatório precisa trazer e, principalmente, como transformar o relatório em correção comprovada. É nessa parte que a maioria das empresas perde o dinheiro investido.

O que é pentest e para que serve?

Pentest, abreviação de penetration test, é um ataque simulado, autorizado e controlado contra os sistemas da empresa: site, aplicativo, API, rede interna, nuvem ou até as pessoas, no caso de testes de engenharia social. Quem executa usa as mesmas técnicas de um invasor, mas com permissão por escrito, regras combinadas e a obrigação de documentar tudo.

A pergunta que o pentest responde é objetiva: um atacante consegue entrar, e até onde ele chega? Não basta apontar que um servidor está desatualizado. O teste mostra se aquela falha permite, por exemplo, ler a base de clientes, assumir uma conta de administrador ou pular de um sistema para outro.

Por isso o pentest serve a três fins práticos. Ele prioriza o que corrigir primeiro, porque separa o risco teórico do risco demonstrado. Ele gera evidência para cliente, auditoria e seguradora. E ele testa a própria capacidade de reação da empresa: se ninguém percebeu o teste acontecendo, isso também é um achado.

Qual a diferença entre pentest e scan de vulnerabilidades?

Os dois são confundidos com frequência, e a confusão custa caro. O scan é uma ferramenta automática que compara os sistemas com uma base de falhas conhecidas e produz uma lista. O pentest é trabalho humano que parte dessa lista, e de muito mais, para provar o que de fato pode ser explorado.

Comparativo da Alliance Comunicação com base nas fases de descoberta e ataque descritas no NIST SP 800-115.

A conclusão não é escolher um dos dois. O scan dá visibilidade contínua e pega o problema que surge na terça-feira depois da atualização. O pentest dá profundidade e encontra o que nenhuma assinatura automática conhece, como um fluxo de checkout que aceita alterar o preço no navegador. Empresa que só faz scan tem uma lista longa e nenhuma prioridade. Empresa que só faz pentest tem uma foto bonita de um dia do ano.

Quais são os tipos de pentest: black box, gray box e white box?

A classificação mais conhecida diz respeito a quanto o testador sabe antes de começar. Ela muda o custo, o prazo e o que o teste consegue revelar.

• Black box (caixa-preta). O testador recebe só o alvo, como o endereço do site, e nada mais. Simula um atacante externo sem informação privilegiada. É realista, mas gasta boa parte do tempo descobrindo o que a empresa poderia simplesmente ter contado.
• Gray box (caixa-cinza). O testador recebe credenciais de um usuário comum e alguma documentação. Simula um cliente mal-intencionado ou uma conta roubada. Para a maioria das empresas médias, é o melhor custo-benefício.
• White box (caixa-branca). O testador tem acesso a código, arquitetura e configurações. É o mais profundo e o que encontra mais falhas por hora contratada, mas exige preparo da equipe interna para entregar o material.

Há também a divisão por alvo: aplicação web, aplicativo móvel, API, rede externa, rede interna, nuvem, Wi-Fi e engenharia social. O erro comum é comprar um pentest de site quando o dado sensível mora numa API que o site consome. O alvo certo é onde está o que a empresa não pode perder.

Por que o pentest importa mais agora, e onde ele falha?

Durante anos, a principal forma de entrada dos invasores foi a credencial roubada: senha vazada, phishing, login reaproveitado. Isso mudou, e o relatório de violações mais citado do mercado registrou a virada.

Em outras palavras, a falha técnica que ninguém corrigiu virou o caminho mais usado. É exatamente o tipo de problema que o pentest encontra. A notícia ruim vem no mesmo relatório: encontrar não tem sido o gargalo. O gargalo é fechar.

O DBIR acompanha o que as organizações fazem com as vulnerabilidades mais perigosas que existem: as do catálogo KEV, mantido pela agência americana de cibersegurança (CISA), que lista falhas sabidamente exploradas por atacantes. Não são riscos hipotéticos. São portas que alguém já está usando.

Esse número diz algo direto a quem contrata pentest. Se nem as falhas já exploradas no mundo real, com alerta público e correção disponível, são fechadas a tempo, o achado de um relatório interno tem chance ainda menor. O relatório que não vira correção é só uma lista de portas abertas, agora documentada.

Pentest não é um documento que se compra; é uma correção que se comprova.

Como funciona um pentest por dentro?

O guia técnico do NIST para testes de segurança, o SP 800-115, organiza o teste de intrusão em quatro fases: planejamento, descoberta, ataque e relatório. Vale conhecer cada uma, porque é nelas que o contratante decide se o teste vai servir para alguma coisa.

• Planejamento. Define regras, alvos e objetivos, e formaliza a aprovação da gestão. Segundo o NIST, nenhum teste acontece nessa fase. É aqui que o contratante tem mais poder.
• Descoberta. O testador mapeia o que existe: endereços, serviços, versões, usuários, pontos de entrada. Também cruza o que encontrou com bases de falhas conhecidas.
• Ataque. Tenta explorar o que foi descoberto. Quando consegue, usa o novo acesso para avançar e volta à descoberta a partir dali. É esse ir e voltar que revela o caminho real de um invasor.
• Relatório. Descreve as vulnerabilidades, atribui uma classificação de risco e orienta a mitigação. É o ponto onde o fornecedor normalmente encerra o trabalho.

Repare no que falta nessa lista: a correção e a confirmação de que ela funcionou. Elas não fazem parte do teste em si, e é exatamente por isso que se perdem. Se o contrato termina no relatório, ninguém está obrigado a voltar.

Como escrever o escopo e as regras do pentest?

O escopo é o documento mais importante do teste, mais até que o relatório. O NIST traz, no Apêndice B do SP 800-115, um modelo de Regras de Engajamento (ROE, na sigla em inglês). Mesmo que o fornecedor use o modelo próprio, confira se estes pontos estão escritos:

1. Objetivo do teste. O que se quer provar: que um cliente não acessa dados de outro, que um invasor externo não chega à rede interna, que o painel administrativo resiste a credencial vazada.
2. Alvos dentro e fora do escopo. Endereços, aplicações e ambientes listados um a um. Inclua o que fica de fora, como sistemas de terceiros que a empresa não pode autorizar.
3. Janela e ambiente. Datas, horários e se o teste roda em produção ou em homologação. Teste em produção é mais realista e exige mais cuidado.
4. O que é proibido. Negação de serviço, alteração de dados reais, ataque a funcionários fora do combinado.
5. Contatos de emergência. Quem o testador avisa se encontrar algo crítico no meio do caminho, sem esperar o relatório final.
6. Formato do relatório e reteste. O que o documento precisa trazer (veja a próxima seção) e quantas rodadas de reteste estão incluídas no preço.
7. Aprovação formal. Assinatura de quem tem autoridade sobre os sistemas. Sem ela, tecnicamente, o teste é uma invasão.

O que um relatório de pentest precisa trazer para virar correção?

Um relatório bom não é o mais grosso. É o que permite a uma pessoa da equipe abrir um achado e começar a corrigir no mesmo dia. Exija que cada achado traga:

• Descrição em linguagem de negócio, além da técnica: o que um invasor faria com aquilo.
• Severidade e justificativa. Uma classificação de risco, com o porquê. Severidade sem justificativa vira discussão.
• Evidência reproduzível. Passos, requisições e capturas que permitem à equipe ver o problema acontecendo.
• Prioridade por exploração ativa. Achado ligado a falha que já está sendo explorada no mundo, como as do catálogo KEV, sobe para o topo, mesmo que a nota técnica seja parecida com a de outros.
• Recomendação de correção concreta, e não apenas “atualizar o sistema”.
• Sumário executivo de uma página para a diretoria, com o que é crítico e o que se espera dela.

O relatório traz a informação. Quem transforma informação em plano é a empresa, acrescentando os dois campos que nenhum fornecedor pode preencher sozinho: dono e prazo.

Como transformar os achados em plano de correção?

A régua é simples: achado sem dono e sem prazo é achado aberto, não importa o que diga a ata da reunião. Na prática, o caminho é este:

1. Leve o relatório para uma reunião de triagem

Junte quem testou, quem desenvolve e quem opera a infraestrutura na mesma conversa, até uma semana depois da entrega. Cada achado sai com um responsável nominal, não com um departamento.

2. Defina prazos por severidade antes de ler os achados

Combine a régua antes de discutir caso a caso: críticos em dias, altos em semanas, médios no ciclo seguinte de desenvolvimento. Os números exatos dependem da empresa; o que não pode é decidir o prazo depois de ver o tamanho do trabalho.

3. Registre os achados onde a equipe já trabalha

O relatório em PDF não é ferramenta de acompanhamento. Cada achado vira um item no sistema de chamados ou de tarefas que a equipe já usa, com o link para a evidência. O que fica só no PDF some.

4. Aceite o risco por escrito quando não for corrigir

Às vezes a correção é cara demais ou depende de um fornecedor. Tudo bem, desde que alguém com autoridade assine que aceita o risco, com data para revisar a decisão. Risco aceito é decisão; risco esquecido é exposição.

5. Agende o reteste já no dia da triagem

O reteste é quando o testador volta, tenta explorar de novo cada achado corrigido e confirma que ele fechou. Marcar a data na triagem cria o prazo que faltava para a equipe interna.

6. Garanta que o reteste esteja no contrato

Correção que ninguém verificou é hipótese. A equipe aplica a atualização, mas a falha estava em outro servidor; muda a regra de validação, mas só na tela, e a API continua aceitando o dado. O reteste existe para pegar esses casos, e ele só acontece com garantia quando está previsto e precificado na contratação.

Na hora de comparar propostas, coloque o reteste lado a lado: quantas rodadas, em que prazo depois do relatório e se cobre todos os achados ou só os críticos. Uma proposta mais barata sem reteste costuma sair mais cara, porque a segunda verificação vira um novo projeto.

O mesmo raciocínio vale para controles que vencem sozinhos. Assim como a validade dos certificados vem encurtando e exige renovação automatizada do certificado SSL, a segurança de uma aplicação também não fica pronta: ela precisa de verificação recorrente para continuar valendo.

Quando o pentest deve ser realizado?

A resposta mais repetida é “uma vez por ano”, porque é o que algumas normas e contratos pedem. Por exemplo, o padrão de segurança de quem processa cartão de pagamento (PCI DSS) exige teste de intrusão periódico e também depois de mudanças significativas. O calendário é o piso, não o critério. O critério é mudança relevante:

Critérios da Alliance Comunicação; a exigência de teste periódico e após mudança significativa consta do PCI DSS.

Para a empresa média, o arranjo que costuma funcionar é scan contínuo para a visibilidade do dia a dia, pentest anual para a profundidade e pentest pontual a cada lançamento ou mudança grande. E nada disso substitui o básico de prevenção, que é assunto do guia sobre segurança da informação para empresas que acham que não são alvo.

Quais são os erros mais comuns de quem contrata pentest?

• Comprar pelo preço do relatório. O custo real está na correção que não acontece e no reteste que não foi contratado.
• Escopo genérico. “Testar o site” sem dizer se inclui a API, a área logada e o painel administrativo deixa o fornecedor escolher o caminho mais fácil.
• Tratar scan como pentest. Um relatório automático com a palavra pentest na capa não prova exploração nenhuma.
• Esconder informação para “ver se ele acha”. Em teste de tempo limitado, black box por vaidade troca profundidade por descoberta.
• Engavetar o crítico porque o sistema vai ser trocado. O sistema novo costuma atrasar; a falha fica exposta enquanto isso.
• Deixar o PDF com uma pessoa só. Quando ela sai de férias ou da empresa, o plano de correção sai junto.

Como medir se o pentest valeu o investimento?

Pentest bom não se mede pelo número de achados. Uma empresa madura pode ter poucos achados, e isso é bom. Meça o que acontece depois:

1. Percentual de achados críticos e altos fechados e confirmados em reteste dentro do prazo combinado.
2. Tempo mediano até a correção, por severidade. Compare com o seu próprio número do teste anterior.
3. Achados repetidos de um teste para o outro. Falha que volta indica correção pontual sem mudança de processo.
4. Riscos aceitos com assinatura e data de revisão, separados dos simplesmente abertos.
5. Detecção do próprio teste. Se o monitoramento da empresa não percebeu nada durante o ataque simulado, isso vira meta para o próximo ciclo.

Por onde começar hoje

Se a empresa nunca fez pentest, comece pelo inventário: quais sistemas guardam dado de cliente, dinheiro ou acesso administrativo. Esse é o primeiro escopo. Se já fez, abra o último relatório e aplique a régua do dono e do prazo antes de contratar o próximo; um teste novo em cima de achados antigos abertos só repete a lista.

Na hora de contratar, peça a proposta com escopo escrito, modelo de relatório e reteste incluído. Se precisar de apoio para montar esse processo, do escopo à correção comprovada, é disso que trata o trabalho de tecnologia e segurança da Alliance. E se a dúvida ainda for onde estão os pontos frágeis da operação como um todo, o diagnóstico gratuito de maturidade mostra como a empresa está em tecnologia, dados e processos, lado a lado com as demais áreas.