E-Zine Exclusivo para o Whastapp

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

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

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.
foto_ramos 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 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.

Quer aprender mais sobre o Kali Linux e suas Ferramentas? Conheça o treinamento que, particularmente, mais gosto, que é do Bruno Fraga do Técnicas de Invasão. 

Top
%d blogueiros gostam disto: