Teste de invasão não deveria ser uma perda de tempo

No artigo “Debunking myths: penetration testing is a waste of time”, Rohit Sethi olha para algumas desvantagens da maneira passiva e irresponsável como os testes de invasão são geralmente feitos hoje: aguarde até o sistema estar pronto para torná-lo ativo, contrate uma empresa ou um consultor externo, dê-lhes um curto espaço de tempo para tentar achar e corrigir algo importante que eles achem, talvez teste novamente para obter uma nota de aprovação, e agora o seu sistema será “certificado como seguro”.

Um teste como esse não lhe diz:

• Quais são as ameaças potenciais à sua aplicação?
• A quais ameaças sua aplicação “não está vulnerável”?
• Que ameaças fizeram os testadores não avaliarem sua aplicação? Que ameaças não foram testadas a partir de uma perspectiva de tempo de execução?
• Como o tempo e outras restrições sobre o teste afetaram a confiabilidade dos resultados? Por exemplo, se os testadores tivessem 5 dias adicionais, que outros testes de segurança eles teriam executado?
• Qual o nível de habilidade dos testadores e você obteria o mesmo conjunto de resultados de um testador diferente ou de outra consultoria?

Sethi salienta a importância da criação de expectativas e definição de requisitos para o teste de invasão. Um testador de invasão externo não será capaz de entender suas necessidades empresariais ou internas do sistema bem o suficiente para fazer um trabalho abrangente – a não ser, talvez, que seu aplicativo seja mais um simples portal online ou uma loja web escrita em PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) → ou Ruby on Rails, algo que eles certamente já terão visto muitas vezes antes.

Você deve considerar que testes de invasão vão perder alguma coisa, possivelmente muito, e não há nenhuma maneira de saber o que eles não testaram ou o quão bom foi o trabalho que eles fizeram no que realmente testaram. Você poderia tentar defect seeding para ter uma ideia de quão cuidadosos e inteligentes eles foram (e quantos erros eles não encontraram), mas isso pressupõe que você sabe muito sobre o sistema e sobre segurança e testes de segurança (e, se você é tão bom, provavelmente não precisa da ajuda deles). Ligar a análise de cobertura de código durante o teste lhe dirá que partes do código não foram tocadas – mas não vai ajudá-lo a identificar o código que você não escreveu mas deveria, o que muitas vezes é um problema maior quando se trata de segurança.

Você não pode esperar que um testador de invasão encontre todas as vulnerabilidades de segurança em seu sistema – mesmo que você esteja disposto a gastar muito tempo e dinheiro nisso. Mas os testes de invasão são importantes porque são uma maneira de encontrar coisas que são difíceis para você achar sozinho:

1. Vulnerabilidades específicas de tecnologia e da plataforma.
2. Erros de configuração e deployment no ambiente de tempo de execução.
3. Problemas em áreas como autenticação e gerenciamento de sessão que deveriam ter sido resolvidos pelo framework que você esta usando, se ele funcionar e se você estiver usando-o corretamente.
4. Problemas de vazamento de informações, enumeração de objetos e manipulação de erros – problemas que parecem pequenos para você, mas que podem ser explorados por um hacker inteligente e motivado com o tempo a seu lado.
5. Erros na validação de dados ou na saída de codificação e de filtragem, que parecem pequenos para você, mas…

E se você tiver sorte, alguns outros problemas que você deveria ter pego sozinho, mas não o fez, como deficiências no fluxo de trabalho, no controle de acesso ou no gerenciamento de senhas ou uma condição de corrida.

Teste de invasão é sobre informação, e não sobre vulnerabilidades

O verdadeiro ponto do teste de invasão, ou qualquer outro tipo de teste, não é encontrar todos os bugs do sistema. É obter informações.

1. Informações sobre os exemplos de bugs na aplicação que precisão ser revistos e corrigidos, como eles foram encontrados, e quão sérios ele são.
2. As informações que você pode usar para calibrar suas práticas e controles de desenvolvimento, para entender o quão bom (ou não) você é em construção de software.

O teste não fornece todas as informações possíveis, mas fornece algumas. Um bom teste irá fornecer muita informação útil. Jame Bach (Satisfice)

Essa informação leva a perguntas: quantos outros bugs como esse poderia haver no código? Onde mais devemos procurar por bugs, e que outros tipos de erros ou fraquezas poderia haver no código ou no design? De onde vieram esses bugs, para começar? Por que cometemos esses erros? O que não sabemos ou que não entendemos? Por que não pegamos esses problemas mais cedo? O que devemos fazer para nos prevenir contra esses problemas ou pegá-los no futuro? Se os erros são suficientemente graves, ou se há um numero suficiente deles, isso significa fazer análises profundas através de RCA e exercícios como os 5 Porquês, para entender e lidar com a causa inicial.

Para obter informações de alta qualidade, você precisa compartilhar informações com testadores de invasão. Dê a eles tanta informação quanto possível.

• Caminhe pelo aplicativo com testadores de invasão, destaque as funções importantes, e forneça a documentação.
• Tire um tempo para explicar a arquitetura e a plataforma.
• Compartilhe os resultados dos testes de invasão anteriores.
• Forneça acesso por trás de proxies etc.

Peça-lhes para fornecer informações em troca: peça-lhes para explicar suas conclusões, bem como a sua abordagem, o que eles tentaram e o que eles cobriram e não cobriram em seus testes, onde gastaram a maior parte de seu tempo, que problemas encontraram e onde desperdiçaram seu tempo, o que os confundiu e os surpreendeu. Informações que você pode usar para melhorar o seu próprio teste, e fazer o teste de invasão com mais eficiência no futuro.

Quando você contrata um testador de invasão, você está pagando pela informação. Mas é sua responsabilidade pegar o maior número de boas informações possível, para compreendê-las e usá-las corretamente.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/04/penetration-testing-shouldnt-be-waste.html