O que um relatório de teste de intrusão deveria realmente te dizer
A maioria dos relatórios é uma exportação de scanner com um logotipo em cima. Veja o que exigir no lugar — e como saber em dez minutos se te venderam teste de verdade.
A red pen over a printed page
Close crop of one hand holding a red pen above a printed page, mid-annotation. Bare pale surface, nothing else in frame. The pen is the only colour.
2400×1350 · WebP · <350KB
Normalmente dá para perceber em dez minutos. Abra o relatório, vá até um achado e faça uma pergunta: meu engenheiro conseguiria corrigir isso na segunda-feira usando só o que está escrito aqui? Se a resposta for não, você não comprou um teste de intrusão. Comprou uma licença de scanner com o timbre de um consultor.
O sinal: severidade sem narrativa
Um scanner produz uma lista. Quarenta achados, cada um com um CVSS, cada um verdadeiro isoladamente, e nenhum conectado ao outro. Um testador produz uma narrativa: aquele subdomínio esquecido expunha um login de homologação, homologação compartilhava senha com produção, e produção não tinha MFA nas contas administrativas. Isolados, são médio, médio e baixo. Encadeados, é assim que alguém é dono do seu ambiente antes do almoço.
Se o seu relatório não tem nenhuma cadeia — nenhuma frase começando com "combinando os achados 12, 19 e 27" — ninguém realmente te testou. Apontaram uma ferramenta para você.
Quarenta achados ordenados por nota dizem o que um scanner notou. Nove achados ordenados pelo que um atacante faria com eles dizem o que corrigir.
O que todo achado precisa ter
- Passos de reprodução que seu engenheiro consiga seguir sem ligar para o testador. A requisição exata, o parâmetro exato, a pré-condição exata.
- Evidência. Uma captura de tela ou resposta registrada provando que o problema é real, não teórico.
- Impacto nos seus termos. Não "divulgação de informação" — mas "um usuário não autenticado consegue enumerar todos os e-mails de clientes".
- Uma correção que nomeia a coisa. O arquivo, a chave de configuração, o cabeçalho. Não "implemente validação de entrada".
- Uma severidade honesta, ajustada ao seu ambiente. Um RCE numa máquina isolada sem dados não é crítico, diga o que disser o scanner.
As partes que a maioria dos relatórios pula
Um bom relatório também diz o que não foi testado e por quê. Limites de escopo, sistemas fora do alcance, credenciais que nunca chegaram, o ambiente que ficou fora do ar dois dias da janela. Essas lacunas são risco que você continua carregando, e escondê-las deixa o relatório mais bonito e você menos seguro.
Ele também deveria dizer o que aguentou. Se o seu WAF bloqueou as tentativas de injeção e o seu EDR matou o payload, isso merece estar por escrito. Você pagou por isso; deveria conseguir provar que funciona.
O reteste faz parte do trabalho
Um achado não está fechado porque um chamado foi fechado. Está fechado porque alguém tentou o exploit de novo e ele falhou. Qualquer empresa que cobre à parte para verificar os próprios achados tem um incentivo que você não quer nessa relação. O reteste deveria estar incluído, e o relatório reemitido deveria mostrar o achado riscado com a data da verificação.
Um checklist curto
- Existe ao menos um caminho de ataque encadeado, escrito como narrativa?
- Um engenheiro consegue reproduzir o principal achado sem fazer perguntas?
- Cada correção nomeia um arquivo, uma configuração ou um cabeçalho?
- Existe uma seção sobre o que ficou fora de escopo ou não foi testado?
- O reteste está incluído, e para quando?
- Os achados críticos foram comunicados durante o teste, e não guardados para a reunião final?
Esse último ponto pesa mais que todos os outros juntos. Se um testador encontra um comprometimento ativo ou um crítico exposto à internet no segundo dia, você deveria saber dentro de uma hora. Descobrir por um PDF três semanas depois não é estilo de relatório. É negligência.