Como se preparar para o seu primeiro teste de intrusão
A maior parte do valor de um teste de intrusão é ganha ou perdida antes mesmo de alguém tocar no teclado. Uma equipe que se depara com um escopo vago, sem contas de teste e com um líder de engenharia nervoso passará os primeiros dois dias lidando com logística em vez de encontrar as falhas pelas quais você pagou para encontrar. Se este é o seu primeiro teste, algumas horas de preparação garantem um resultado significativamente melhor. Aqui está o checklist que gostaríamos que todo cliente de primeira viagem tivesse em mãos.
Saiba por que você está testando
Tudo o que vem a seguir deriva disso. Você está testando porque um contrato de cliente ou um auditor exige, porque sua seguradora pediu, ou porque realmente quer saber o quão exposto está? Um teste focado em conformidade pode ter um escopo ditado por uma norma. Um teste guiado por risco deve focar no que causaria maior impacto se falhasse. Escreva o seu motivo em uma única frase. Isso resolve diversas discussões futuras sobre o que está no escopo.
Defina o escopo, por escrito
O escopo é o insumo mais importante de todos. É a lista exata do que os testers podem tocar: quais domínios, quais aplicações, quais faixas de IP, quais APIs e quais técnicas estão fora de cogitação. O padrão aberto Penetration Testing Execution Standard (PTES) trata esta etapa prévia como uma fase própria por um motivo, pois um escopo confuso produz um teste confuso.
Seja específico e honesto sobre os limites. Se um sistema é mantido por um provedor terceiro, você geralmente não pode autorizar testes contra ele sem a permissão desse provedor, e nenhum tester sério irá atacá-lo apenas com a sua palavra. Decida o que entra, o que fica de fora, e registre tudo de forma assinada. Esse documento, frequentemente chamado de regras de engajamento, protege você tanto quanto protege os testers.
Escolha o ambiente: produção ou staging
Você será questionado se o teste deve ser feito em produção ou em uma cópia de staging. Ambos têm prós e contras.
- Produção é o ambiente real, portanto as descobertas são reais, mas há uma pequena chance de o teste causar lentidão ou efeitos colaterais. Bons testers trabalham com cuidado, mas você ainda deve prever e se planejar para isso.
- Staging é mais seguro para testar pesadamente, mas só é útil se espelhar fielmente a produção. Um ambiente de staging três versões desatualizado, com dados fakes e configurações diferentes, gera resultados que podem não se aplicar ao sistema que seus clientes realmente usam.
Se escolher staging, garanta que seja uma cópia fiel. Um ambiente enganoso é pior do que um ambiente levemente arriscado.
Prepare os acessos e contas de teste
Se você quer que o teste cubra o que um usuário autenticado ou cliente pode fazer, e você quase sempre deveria querer, os testers precisam de credenciais válidas. Testes não autenticados veem apenas a porta de entrada. A maior parte dos danos reais acontece atrás de um login.
Antes de o teste começar, prepare:
- Contas de usuário para cada perfil relevante: usuário padrão, administrador e quaisquer níveis intermediários.
- Mais de uma conta por perfil, para que os testers possam verificar se um usuário consegue acessar os dados de outro.
- Quaisquer chaves de API, tokens ou documentações necessárias para operar a aplicação da mesma forma que um cliente real faria.
- Uma nota sobre qualquer coisa que possa disparar bloqueios de conta, cobranças ou envios de e-mail, para evitar surpresas.
Defina o cronograma e a comunicação
Definam uma janela de testes e quem deve ser avisado. Indique um único ponto de contato técnico que possa responder a dúvidas rapidamente e que tenha autoridade para interromper o teste com uma única mensagem caso algo dê errado.
Decida com antecedência o que fazer com suas próprias defesas. Se um web application firewall ou sistema de monitoramento bloquear ou alertar sobre o tráfego do teste, você e os testers devem concordar em liberar o IP de origem na allowlist, já que um firewall que apenas bloqueia o teste pode esconder as próprias vulnerabilidades que estão atrás dele. Avise suas equipes de operações e suporte para que um pico de tráfego estranho não gere um chamado de incidente às 3 da manhã.
Tenha sua documentação pronta
Os testers ganham ritmo mais rápido quando você fornece contexto. O OWASP Web Security Testing Guide, uma metodologia aberta amplamente utilizada, trata a coleta de informações como a base de um bom teste. Você pode encurtar essa fase fornecendo uma visão geral da arquitetura, documentação da API, uma lista de perfis de usuário e notas sobre qualquer coisa incomum ou frágil. Você não está fazendo o trabalho deles, está garantindo que o tempo seja investido na busca por problemas, em vez de redescobrir como sua aplicação foi construída.
Resista ao impulso de arrumar tudo antes
Uma tentação comum antes do primeiro teste é aplicar correções rapidamente e limpar tudo para que o relatório pareça bom. Não faça isso. O objetivo é conhecer sua real situação, não simular um ambiente perfeito. Corrigir problemas conhecidos é ótimo e recomendado em geral, mas não esconda nem desative coisas apenas para esquivar-se do teste. Você estaria apenas pagando para enganar a si mesmo.
Saiba o que você receberá ao final
Confirme o entregável antes do primeiro dia: um relatório escrito com achados classificados e passos claros de reprodução e, idealmente, uma reunião para repassá-lo. Pergunte se o reteste das suas correções está incluído ou se tem custo adicional, pois uma vulnerabilidade não está resolvida até que alguém confirme que a correção realmente funciona.
Um primeiro passo mais acessível, caso não esteja pronto
Se um teste de intrusão completo ainda parece um grande compromisso inicial, é razoável começar menor e entender primeiro sua exposição externa. É para isso que serve a nossa verificação de $100: uma análise focada da sua superfície de ataque externa, em um escopo que você confirmou possuir e autorizou por escrito, revisada por um operador sênior e entregue com uma apresentação de 30 minutos.
Tenha clareza sobre o que é e o que não é. A verificação é um primeiro olhar, não um trabalho completo, e não vai satisfazer um auditor que solicitou um teste de intrusão. O que ela faz é mostrar o que um atacante vê pelo lado de fora e ajudar a definir o escopo do teste real adequadamente, para que, quando você agendar um, chegue preparado.
Leituras relacionadas
Comece com um primeiro olhar.
Antes de um trabalho completo, nossa verificação de $100 mostra o que um atacante vê pelo lado de fora, para que você chegue preparado. Ela não substituirá um pentest completo, e faremos questão de deixar isso claro.
Agendar verificação por $100