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 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