Desenvolvimento

22 ago, 2013

Escolhendo entre um pen test e uma revisão segura de código

Publicidade

Revisão Segura de Código (traga alguém de fora da equipe para revisar/auditar o código para vulnerabilidades de segurança) e pen test em aplicação (mais uma vez, trazendo um especialista em segurança de fora da equipe para testar o sistema) são as duas práticas importantes de programa de desenvolvimento de software seguro. Mas, se você só pudesse fazer um deles, se você tivesse tempo limitado ou orçamento limitado, qual você escolheria? Que abordagem vai encontrar mais problemas e lhe dizer mais sobre a segurança do seu aplicativo e sua equipe? Qual vai lhe trazer mais retorno sobre o investimento?

Pen tests e revisões de código são coisas muito diferentes – eles requerem um trabalho diferente de sua parte, encontram problemas diferentes e lhe dão informações distintas. E o custo pode ser bastante diferente também.

White box/Black box

Nós todos sabemos a diferença entre a white box e black box.

Porque eles podem olhar dentro da caixa, revisores de código podem zerar em um código de alto risco: interfaces públicas, gerenciamento de sessão, gerenciamento de senhas, controle de acesso e criptografia e outro encanamento de segurança, o código que lida com dados confidenciais, tratamento de erros, auditoria. Ao escanear o código, eles podem verificar se o aplicativo é vulnerável a ataques de injeção comuns (injeção de SQL, XSS etc.), e eles podem procurar por bombas-relógio e backdoors (que são praticamente impossíveis de testar de fora) e outros códigos suspeitos. Eles podem encontrar problemas com a simultaneidade e tempo e outras questões de qualidade de código que não são exploradas, mas que devem ser fixadas de todas as maneiras. E um bom revisor, como eles trabalham para entender o sistema e seu design e fazer perguntas, pode também apontar erros de projeto, suposições incorretas e inconsistências – e não apenas os erros de codificação.

Pen testers contam com scanners e proxies de ataque e outras ferramentas para ajudá-los a procurar por muitas das mesmas vulnerabilidades de aplicativos comuns (injeção de SQL, XSS etc.), bem como problemas de configuração em tempo de execução. Eles vão encontrar divulgação de informações e problemas de tratamento de erros à medida que eles invadem o sistema. E eles podem testar problemas em gerenciamento de sessão, manipulação de senha e gerenciamento de usuário, autenticação e autorização ignoram fraquezas, e até mesmo encontrar falhas de lógica de negócios, especialmente em fluxos de trabalho conhecidos, como compras online e funções bancárias. Mas porque eles não podem ver dentro da caixa, eles – e você – não saberão se terão coberto todas as peças de alto risco do sistema.

O tipo de teste de segurança que você já está fazendo por sua conta pode influenciar se um pen test ou uma revisão do código é mais útil. Você está testando o seu aplicativo web regularmente com uma ferramenta black box de escaneamento dinâmico de vulnerabilidade? Ou executando verificações de análise estática, como parte de integração contínua?

Um pen test manual vai encontrar muitos dos mesmos tipos de problemas que um scanner dinâmico automatizado, e muito mais. Uma boa ferramenta de análise estática vai encontrar pelo menos alguns dos mesmos erros que uma revisão de código manual – um monte de revisores utilizam ferramentas de verificação de análise estática de código fonte para procurar frutos mais baixos (erros de codificação comuns, funções inseguras, senhas codificadas , injeção de SQL simples etc.). Testes superficiais ou reviews podem não envolver muito mais do que alguém executando uma dessas ferramentas de digitalização automatizada e revisando e qualificando os resultados para você.

Então, se você está confiando em testes de análise dinâmica, faz sentido obter uma revisão do código para procurar por problemas que você ainda não tenha testado sozinho. E se você estiver escaneando o código com ferramentas de análise estática, então um pen test pode ter uma melhor chance de encontrar problemas diferentes.

Custos e complicações

Um pen test é fácil de configurar e gerenciar. Ele não deve exigir muito tempo e cuidado de sua equipe; mesmo que você faça isso direito, certifique-se de explicar as principais funções do aplicativo para a equipe de pen test e caminhe com eles através da arquitetura, e lhes dê todo o acesso que precisarem.

As revisões de código são geralmente mais caras do que os pen tests, e vão exigir mais tempo e esforço de sua parte – você não pode apenas dar a um estranho uma cópia do código e esperar que ele descubra tudo por conta própria. Há maior necessidade de um acompanhamento bem de perto, e de dias vias. Você segura a mão dele, o acompanha, explica a arquitetura. e como o código é estruturado, e como funcionam o sistema e os drivers de conformidade e de risco, respondendo a perguntas sobre o design e a tecnologia à medida que eles vão avançando; e ele segura sua mão, pacientemente explicando o que encontrou e como corrigiu e trabalhou com sua equipe para entender se cada achado vale a pena ser corrigido, eliminando falsos positivos e outros mal-entendidos.

Esse cuidado é importante. Você deseja obter o máximo de valor do tempo de um revisor – você quer que ele se concentre em código de alto risco e não se perca em tangentes. E você quer ter certeza de que sua equipe entenda o que o revisor encontrou, quão importante é cada bug e como eles devem ser corrigidos. Assim, você não só precisa ter pessoas ajudando o revisor – eles devem ser suas melhores pessoas.

Propriedade Intelectual e Confidencialidade e outras questões legais são importantes, especialmente para as revisões de código – você está deixando um estranho olhar o código, e ao mesmo tempo você quer ser transparente, a fim de garantir que a análise é abrangente, você também pode estar arriscando seu segredo. Sólida contratação e trabalhar com empresas de renome irão minimizar algumas dessas preocupações, mas você também pode precisar limitar estritamente o código que o revisor começará a ver.

Outros fatores na escolha entre pen tests e revisões de código

O tipo de sistema e sua arquitetura também podem afetar sua decisão.

É fácil encontrar pen testers que têm muita experiência em testar portais e lojas online – eles estarão familiarizados com a arquitetura geral e reconhecerão funções e fluxos de trabalho comuns, e podem contar com verificação externa, e ferramentas de fuzzing para ajudar nos testes. Isso se tornou um serviço baseado em commodities, em que você pode esperar um bom trabalho feito por um preço razoável.

Mas se você está construindo um aplicativo com proprietário de APIs do sistema-a-sistema ou clientes proprietários, ou você está trabalhando em um domínio técnico altamente especializado, é mais difícil de encontrar pen testers qualificados, e eles custarão muito mais. Eles precisarão de mais tempo para compreenderem a arquitetura e o app, como tudo se encaixa e no que eles devem focar nos testes. E eles não serão capazes de aproveitar as ferramentas padrão, então eles vão ter que bolar algo por conta própria, o que vai demorar mais tempo e pode não funcionar tão bem.

Uma revisão de código poderia te dizer mais nesses casos. Mas o revisor tem que ser competente na (s) linguagem (s) em que seu aplicativo está escrito – e, para fazer um trabalho completo, ele também deve estar familiarizado com os frameworks e as bibliotecas que você está usando. Como nem sempre é possível encontrar alguém com o conhecimento e a experiência certa, você pode acabar pagando-os para aprenderem sobre o trabalho – e confiando muito em quão rápido eles aprendem. E, claro, se você estiver usando um monte de código de terceiros para os quais você não tem fonte, então um pen test é realmente a sua única opção.

Você está em um estágio avançado de desenvolvimento, preparando-se para lançar? Nesse momento, o mais importante é validar a segurança do sistema em execução, incluindo a configuração de tempo de execução e, se você está realmente atrasado em desenvolvimento, encontrar quaisquer vulnerabilidades exploráveis de alto risco, porque isso é tudo que você vai ter tempo para corrigir. Esse é o lugar onde vários pen tests são feitos.

Se você está nos estágios iniciais de desenvolvimento, é melhor escolher uma revisão de código. Pen test não faz muito sentido (você não tem o suficiente do sistema para fazer testar o sistema real), e uma revisão de código pode ajudar a definir o caminho certo para o time do resto do código que eles têm de escrever.

Aprendendo e utilizando os resultados

Além de encontrar vulnerabilidades e ajudá-lo a avaliar o risco, a revisão de código ou um pen test proporcionam oportunidades de aprendizagem – uma chance para a equipe de desenvolvimento entender e melhorar a forma como eles escrevem e testam o software.

Pen tests diz o que está quebrado e é explorável – os desenvolvedores não podem argumentar que o problema não é real, porque um invasor o encontrou, e que o atacante pode explicar quão fácil ou difícil é para eles encontrarem o erro, que o risco é real. Os desenvolvedores sabem que eles têm que corrigir alguma coisa – mas não está claro onde e como corrigi-lo. E não é clara a forma como eles podem verificar que eles consertaram. Diferentemente da maioria dos bugs, não existem passos simples para o desenvolvedor reproduzir o bug em si: eles têm que contar com o pen tester para voltar e fazer um “re-teste”. É ineficiente e não é um bom feedback  para reforçar a compreensão.

Outra desvantagem com os pen tests é que eles são feitos no final do desenvolvimento, muitas vezes, muito tarde. A equipe pode não ter tempo para fazer nada além da triagem dos resultados e corrigir o que tem de ser corrigido antes de o sistema entrar no ar. Não há tempo para os desenvolvedores refletirem, aprenderem e incorporarem o que aprenderam.

Também pode haver um déficit de comunicação entre testadores e desenvolvedores pen. A maioria dos pen testers pensa e fala como hackers, em termos de exploits e ataques. Ou eles falam como auditores, focados na conformidade, mapeando suas descobertas para taxonomias de vulnerabilidades e frameworks de gestão de risco, que não significam nada para os desenvolvedores.

Revisores de código pensam e falam como os programadores, o que torna as revisões de código muito mais fáceis de aprender – desde que o revisor e os desenvolvedores de sua equipe gastem tempo trabalhando juntos e compreendendo os resultados. Um revisor de código pode explicar ao desenvolvedor o que há de errado, explicar por que e como corrigi-lo e responder às perguntas do desenvolvedor imediatamente, em termos que um desenvolvedor vá entender, o que significa que os problemas podem ser consertados mais rápido e direito.

Você não vai encontrar todas as vulnerabilidades de segurança em um aplicativo por meio de uma revisão de código ou um pen test – mesmo fazendo os dois (embora você tenha uma chance melhor). Se eu pudesse fazer apenas uma coisa ou outra, com todos os outros fatores de lado, eu escolheria uma revisão de código. A revisão dará mais trabalho e provavelmente vai custar mais, e pode até não encontrar tantos bugs de segurança. Mas você vai ter mais valor no longo prazo a partir de uma revisão de código. Desenvolvedores vão aprender mais e mais rápido, espero que o suficiente para entender como procurar e corrigir problemas de segurança por conta própria e, ainda mais importante, para evitá-los em primeiro lugar.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/06/choosing-between-pen-test-and-secure.html