Você decidiu contratar um pentest. A decisão está tomada, o orçamento aprovado. Agora vem a parte que muita empresa negligencia: a preparação. E é aqui que se decide se o pentest vai gerar valor real ou frustração.
Um pentest bem preparado entrega resultados mais profundos, causa menos fricção operacional e permite que a equipe de TI aja sobre os achados com rapidez. Um mal preparado gera atrasos, resultados rasos e relatórios que acabam esquecidos numa gaveta.
1. Defina o escopo com clareza
O escopo é a decisão mais importante de todo o processo. Ele determina o que será testado, como será testado e o que está fora dos limites. Escopo mal definido é a causa número um de pentests que não entregam valor.
Antes de começar, a empresa precisa responder: quais sistemas, aplicações ou ambientes serão testados? Qual o tipo de teste (caixa preta, cinza ou branca)? Existem sistemas que não podem ser testados, como legados frágeis ou produção crítica? O teste acontece em produção, staging ou nos dois? Engenharia social entra no escopo ou só testes técnicos? Existe horário preferencial para testes mais pesados?
Os erros mais comuns nessa etapa são extremos. Escopo vago demais, do tipo "testem tudo", resulta em teste superficial porque nenhuma área recebe profundidade adequada. Escopo restrito demais, como "testem só o login", pode deixar de fora vetores de ataque importantes. E um clássico: pedir pentest da aplicação web mas esquecer que 80% da lógica vive nas APIs do backend.
Se possível, forneça uma lista de URLs, IPs, ranges de rede, endpoints de API e credenciais de teste. Quanto mais preciso o escopo, mais fundo o time de pentest consegue ir.
2. Escolha o tipo de teste certo
A escolha entre caixa preta, cinza e branca impacta diretamente profundidade e custo.
Caixa preta faz sentido quando o objetivo é simular um atacante externo sem nenhum conhecimento prévio. É o mais realista, mas boa parte do tempo é gasta em reconhecimento.
Caixa cinza é o mais contratado e geralmente o melhor custo-benefício. O time recebe credenciais de usuário, documentação de API e informações básicas da arquitetura. Isso permite ir direto à exploração e aproveitar melhor o tempo.
Caixa branca é ideal para auditorias profundas de aplicações críticas. Com acesso a código-fonte e arquitetura, o time encontra coisas que seriam invisíveis de outra forma.
Para a maioria das empresas fazendo pentest pela primeira vez, caixa cinza é a melhor pedida.
3. Prepare o ambiente
Algumas ações práticas antes de tudo começar.
Se o teste for caixa cinza ou branca, crie credenciais dedicadas para o time de pentest. Nada de reutilizar contas de colaboradores. Crie pelo menos dois perfis: um de usuário comum e um de administrador, para testar escalação de privilégios e controle de acesso.
Pergunte se precisa de whitelist de IPs no WAF, IPS ou rate limiting. Em testes de caixa cinza e branca, geralmente vale fazer whitelist para que o esforço foque nas vulnerabilidades de aplicação, não em contornar proteções de borda.
Se o teste for em staging, garanta que o ambiente está atualizado e reflete produção de verdade. Um staging desatualizado gera achados irrelevantes que ninguém vai priorizar.
Confirme que existem backups recentes dos sistemas no escopo. Pentests profissionais são feitos para minimizar impacto, mas incidentes podem acontecer.
E avise as operações e o SOC que testes de segurança vão acontecer em determinado período. Se o SOC não souber, pode interpretar as atividades do pentest como um ataque real e acionar resposta a incidentes desnecessariamente.
4. NDA e contrato primeiro, informação depois
Antes de compartilhar qualquer detalhe técnico sobre seus sistemas, exija três documentos.
NDA (Non-Disclosure Agreement) protegendo todas as informações trocadas durante o projeto, cobrindo tanto o período do teste quanto o período depois da entrega.
Contrato de serviço com escopo detalhado, cronograma, entregáveis, responsabilidades de cada parte, regras de engajamento e limitação de responsabilidade.
Autorização formal assinada pela liderança, autorizando explicitamente os testes nos sistemas definidos. Isso protege ambos os lados.
Qualquer empresa séria vai ter esses documentos prontos e vai insistir em assinar antes de iniciar qualquer trabalho. Se alguém propuser "começar logo e formalizar depois", considere isso um sinal de alerta.
5. Defina os pontos de contato
Situações que exigem comunicação rápida vão surgir durante o teste. É preciso definir antes quem é quem.
Um contato técnico do time de TI que possa tirar dúvidas sobre a infraestrutura, resetar credenciais de teste e avaliar se alguma atividade está causando impacto inesperado.
Um contato executivo da liderança que possa tomar decisões sobre escopo. Do tipo "encontramos um caminho que leva a um sistema fora do escopo, podemos seguir?"
E um canal de emergência, como celular ou WhatsApp de um responsável, caso o time de pentest encontre uma vulnerabilidade crítica sendo ativamente explorada por terceiros ou uma falha que represente risco iminente.
6. Alinhe o que vem no relatório
Antes do teste começar, converse com a empresa sobre o que esperar na entrega.
O relatório técnico é para o time de TI, com cada vulnerabilidade detalhada: descrição, severidade CVSS, evidência, passos de reprodução e recomendação de correção.
O relatório executivo é para a liderança, com resumo do risco em linguagem de negócio, impacto potencial e priorização de ações.
Alinhe também o formato e a entrega. Vai ser só PDF? Tem apresentação ao vivo? Vai ter sessão de perguntas e respostas com o time técnico?
E confirme a classificação de severidade. O ideal é que use um framework reconhecido como CVSS e que inclua contexto de impacto no negócio, não apenas severidade técnica isolada.
7. Planeje o que vem depois
O valor do pentest não está no relatório. Está nas correções que ele possibilita. Vale planejar o pós antes mesmo do teste começar.
Defina quem vai corrigir o quê. Vulnerabilidades de aplicação normalmente vão para o time de desenvolvimento. Configurações de infraestrutura vão para operações. Políticas de acesso vão para segurança. Se isso não estiver claro antes, o relatório vira ping-pong entre times.
Defina prazos de correção por severidade. Uma sugestão prática: críticas em 7 dias, altas em 30, médias em 60, baixas no próximo ciclo de manutenção.
Confirme que o reteste está incluso no contrato (e deveria estar). A janela de reteste geralmente é de 30 a 90 dias após a entrega, tempo suficiente para remediar pelo menos as falhas críticas e altas.
E defina quem acompanha o progresso. Sem alguém responsável por cobrar as correções, relatórios de pentest viram documentos decorativos.
8. Comunicação interna
Decida com antecedência quem na organização fica sabendo do pentest.
No cenário mais comum, todos sabem. O time de TI é informado, o SOC sabe, às vezes tem até canal dedicado para comunicação durante o teste. Isso é adequado para pentests focados em sistemas.
Em outro cenário, poucos sabem. Apenas os patrocinadores e o contato de emergência estão cientes. O SOC não é avisado de propósito, para testar se detecta a atividade. Isso faz sentido quando avaliar capacidade de detecção faz parte do objetivo.
E no cenário de red team, apenas diretoria e CISO sabem. Todos os demais, incluindo TI e SOC, fazem parte do teste. A preparação é diferente e o custo também.
Checklist antes de começar
Antes do primeiro dia de teste, passe por cada item. Escopo definido e documentado por escrito. Tipo de teste escolhido. NDA e contrato assinados. Autorização formal assinada pela liderança. Credenciais de teste criadas (se caixa cinza ou branca). IPs de whitelist fornecidos (se aplicável). Contatos técnico e executivo definidos. Canal de emergência estabelecido. SOC e operações notificados (se aplicável). Backups verificados. Expectativas sobre relatório alinhadas. Responsáveis pela correção identificados. Janela de reteste acordada.
O retorno real
Um pentest bem preparado e bem executado não é despesa. É investimento com retorno mensurável. Cada vulnerabilidade crítica encontrada e corrigida antes de um ataque real é um incidente evitado. E o custo de qualquer incidente, seja financeiro, operacional, regulatório ou reputacional, supera em ordens de grandeza o custo do teste.
A preparação é o que transforma um pentest burocrático em um pentest que gera valor de verdade. Invista tempo nela e o resultado vai aparecer na qualidade do que volta.
