Preparação para um teste de invasão

Em um teste de invasão, você contrata uma equipe especializada para atacar seu produto, sob regras combinadas, e relatar o que encontrar. Clientes e auditores costumam exigir um, e essa é uma das melhores maneiras de encontrar problemas que sua própria equipe já não percebe mais. O quanto você aproveita esse processo depende bastante da preparação.

Defina o escopo

Liste exatamente o que os testadores podem atacar: o aplicativo web, os aplicativos móveis, a API, as ferramentas administrativas, a conta na nuvem. Especifique os ambientes e os domínios. Tudo o que ficar de fora da lista não será testado; portanto, inclua as partes que importam para os clientes, e não apenas as partes em que você confia. Se algum componente for operado por um fornecedor, verifique se você tem autorização para incluí-lo.

Combine as regras de engajamento

Defina por escrito o período de testes, os endereços de onde os testadores vão atuar, o que está fora dos limites (negação de serviço, engenharia social, dados reais de clientes) e quem contatar se algo quebrar. Verifique a política do seu provedor de hospedagem sobre testes de segurança e envie um aviso prévio se for exigido. Avise quem monitora os seus alertas de que um teste está em andamento, para que um incidente real não seja ignorado achando que faz parte do teste.

Prepare o ambiente e as contas

Testar um ambiente de homologação costuma ser mais seguro, desde que ele seja realmente idêntico ao de produção: o mesmo código, a mesma configuração e as mesmas definições de segurança. Crie contas de teste para cada perfil, incluindo contas em duas organizações de clientes distintas, para que os testadores possam verificar se um cliente consegue ver os dados de outro. Em um produto que atende a vários clientes, esse costuma ser o apontamento mais importante.

Compartilhe documentação, especificações de API e credenciais, a menos que você queira especificamente uma visão de fora para dentro. Testadores que começam sabendo o que alguém de dentro sabe aproveitam o tempo para encontrar problemas, em vez de redescobrir o básico.

Corrija por gravidade e por alcance

O relatório vai classificar os apontamentos por gravidade. Corrija primeiro os críticos e os altos, mas avalie também o que cada problema pode atingir: uma falha média na página de login pode ter mais impacto do que uma falha alta em uma ferramenta interna. Guarde uma breve anotação sobre cada correção, pois auditores e clientes podem perguntar como os apontamentos foram tratados.

Solicite um reteste

A maioria dos testadores inclui ou oferece um reteste dos problemas corrigidos. Aproveite essa etapa. O reteste confirma que as correções funcionam e fornece um relatório atualizado mostrando que foram resolvidas, que é o que os clientes querem ver.

Compartilhe o documento certo

Os clientes raramente precisam do relatório completo, que descreve em detalhes como atacar o seu produto. Peça aos testadores uma carta de atestado (letter of attestation): um resumo curto do escopo, das datas e dos resultados que você pode compartilhar sem problemas. Mantenha o relatório completo restrito apenas a quem realmente precisa vê-lo.

Em resumo

Escopo claro, regras por escrito, um ambiente idêntico ao de produção, contas de teste para cada perfil e um reteste após as correções. Prepare tudo isso, e o relatório se torna um plano de ação em vez de uma surpresa.