Corrigindo vulnerabilidades de segurança em aplicativos

É muito mais difícil corrigir vulnerabilidades de segurança de aplicativos do que deveria ser.

Em seu relatório de segurança de maio de 2013, a WhiteHat Security publicou alguns resultados desanimadores sobre quantas vulnerabilidades de segurança em aplicativos encontradas em testes de foram corrigidas, e quanto tempo levou para corrigi-los. Eles descobriram que apenas 61% das vulnerabilidades de segurança sérias são corrigidas, e que, em média, leva-se 193 dias para consertá-las.

Por que algumas vulnerabilidades são corrigidas, ou não

Convencer os gerentes e os clientes que pagam o trabalho de desenvolvimento de software – e os desenvolvedores que precisam fazer o trabalho – de que as vulnerabilidades de segurança realmente precisam ser corrigidas é uma parte do problema. Provar que isso pode ser feito de um modo economicamente eficaz e seguro é outra.

Para a maioria das organizações, a regra de negócio – não o risco operacional, nem as necessidades do cliente ou outras considerações de natureza comercial, e não preocupação com a qualidade – determina se as vulnerabilidades de segurança são corrigidas. Clientes da WhiteHat relataram que a razão número 1 de uma vulnerabilidade ser corrigida é por ser exigido pela regra de negócio. E a razão número 1 por que as pessoas não corrigem uma vulnerabilidade é por não ser exigido pela regra de negócio.

Um dos outros fatores que influenciam quantas vulnerabilidades de segurança são corrigidas e a rapidez com que podem ser corrigidas é o local onde o sistema está durante seu ciclo de vida. É muito mais fácil e muito menos dispendioso corrigir vulnerabilidades de segurança encontradas no início de um projeto, antes que você tenha escrito um monte de código que precisa ser revisto, corrigido e testado novamente.

Obviamente, é uma história muito diferente de sistemas legados que estão em “coma” e esperando a morte, de tão velhos e ultrapassados, nos quais ninguém realmente entende o código ou está confiante de que pode mudá-lo de forma segura, e ninguém tem certeza de por quanto tempo o sistema estará ativo (embora esses sistemas quase sempre durem mais do que se ninguém espera).

Tudo em algum ponto intermediário é onde as decisões são difíceis de fazer: o sistema já está em uso há algum tempo, e a equipe de manutenção e suporte que tem muito trabalho a fazer. Pode ser difícil fazer da correção de vulnerabilidades de segurança uma prioridade quando as coisas parecem estar correndo bem, e todos estão ocupados tentando as coisas dessa forma, a não ser talvez a política da organização esteja te pressionando o suficiente para que você faça algo para mostrar que você está levando a sério.

O que vai custar?

Se você sabe que há sérios problemas de segurança que que precisam de atenção, por onde começar? Uma revisão de segurança poderia descobrir centenas ou mesmo milhares de vulnerabilidades – a primeira vez que você faz uma varredura de segurança ou um pen test de um grande sistema pode ser esmagadora. Quanto trabalho será necessário para “tornar o sistema seguro”, e o que vai custar?

O Grupo Denim fez uma pesquisa interessante sobre a compreensão de quanto trabalho está envolvido na correção de vulnerabilidades de segurança.

Como quaisquer outros bugs no código, algumas vulnerabilidades são mais fáceis de encontrar e corrigir do que outras. Uma vulnerabilidade XSS pode demorar entre 10 minutos (armazenada XSS) e uma hora e meia (armazenado e refletido) para ser corrigida – e a maioria das aplicações web tem pelo menos um, muitas vezes centenas destes problemas. Corrigir um problema de SQL Injection também leva uma hora e meia, em média. A verificação de uma autorização que está faltando? Apenas 7 minutos. E, assim como qualquer outro erro no código, o trabalho de codificação é apenas uma pequena parte do tempo necessário para obter a correção feita  em média, 30% do tempo total). O teste leva cerca de metade do tempo, e o resto é gasto para fazer as coisas da configuração necessárias para a mudança, recebendo o novo código construído e implementado, e tudo mais.

Ao contrário de um bug funcional, o cliente não vai ver qualquer vantagem imediata na correção de uma vulnerabilidade – o código funciona bem agora pela percepção dele. Portanto, é importante que você possa corrigir vulnerabilidades sem gastar muito tempo ou dinheiro com isso, e que você possa fazê-lo sem quebrar o que já está funcionando.

É por isso que Nick Galbreath destaca o valor de uma capacidade de implementação contínua como um pré-requisito para um programa de segurança de software de sucesso, alavancando Integração Contínua e ferramentas e práticas de entrega contínua, de modo que, quando os desenvolvedores verificarem as alterações no código, o sistema é automaticamente construído, testado e ele pode ser implementado automaticamente se todos os testes passarem. Não se trata de empurrar cada mudança de código imediatamente – é sobre ter um pipeline provado no lugar para liberar mudanças para a produção de forma rápida e com o mínimo de risco, sabendo que você pode fazer correções e tirá-las de forma barata e com confiança, e que você é capaz de responder a uma emergência, se for preciso. Isso irá pagar dividendos fora do trabalho de segurança, reduzindo o custo e o risco de fazer qualquer mudança de software.

Corrigindo bugs de segurança

O Grupo Denim explica que remediar vulnerabilidades de software de segurança tem de ser gerido como qualquer outro projeto de desenvolvimento de software, e eles fornecem algumas orientações sobre como fazê-lo em uma espécie de efeito cascata, com o engajamento dos investidores iniciais e planejamento: uma abordagem que pode funcionar bem para muitas organizações, especialmente as maiores.

Uma abordagem Agile mais iterativa poderia começar com um curto pico de duração fixado. Pegue um par de desenvolvedores inteligentes e dê-lhes umas duas semanas para revisar a lista de vulnerabilidades (se possível, com quem as descobriu ), entenda quais são as sérias e filtre os falsos positivos, escolha algumas delas e as corrija (um poucos de cada tipo diferente). Eles deverão escolher em quais vulnerabilidades trabalhar trocando as que são fáceis de entender e corrigir, contra o risco de não corrigi-las. Ferramentas como OWASP Top 10 ou SANS/CWE Top 25 podem ajudar a compreender os problemas e a tomar essas decisões.

Injeções SQL seriam uma boa primeira escolha: uma vulnerabilidade grave que é fácil de explorar e que pode ter consequências graves, mas que também é fácil para um desenvolvedor entender e corrigir. Ou uma verificação de autorização perdida: outro bug potencialmente grave que deve ser fácil de entender, simples de resolver e testar. Um problema como um erro no armazenamento seguro de senha pode ser tecnicamente mais difícil de resolver, mas ainda é fácil de isolar e testar. Adicionar validação do lado do servidor (em vez de validação apenas no cliente) é outro lugar fácil e bom para começar.

É importante que os desenvolvedores levem tempo para entender o que eles estão fazendo e como fazê-lo direito: que eles entendam a vulnerabilidade, por que ela é um problema, como corrigi-la corretamente, e como testá-la (testá-la para se certificar de que eles realmente fecharam a brecha de segurança, e testes de regressão para se certificar de que eles não quebraram nada por acaso) . O importante aqui não é fazer algumas correções – é saber o que está envolvido em resolver corretamente esses problemas, e saber que você pode criar e implementar o código fixo corretamente.

Em seguida, execute um outro ponto. Escolha outros erros, talvez alguns que sejam mais difíceis de entender e corrigir, e alguns que sejam fáceis de corrigir, mas menos graves (como a falta de tratamento de erros ou vazamento de informações), e percorra os mesmos passos novamente.

Com um pequeno investimento de tempo como esse, você deve obter um entendimento do trabalho que precisa ser feito, como fazê-lo, o que vai custar, e você também deve ter a confiança de que você pode fazê-lo de forma segura. Você deve ter informação suficiente para estimar a quantidade de trabalho que será necessária para corrigir os problemas remanescentes; e uma compreensão suficiente do risco e do custo de trade- offs que precisam ser feitos, os problemas que precisam ser corrigidos – e podem ser corrigidos – mais cedo ou mais tarde.

Agora você pode adicionar os bugs restantes que pretende corrigir no seu backlog. Você pode optar por corrigir o máximo possível de uma vez ou em um hardening sprint, ou priorizar e corrigi-los com o outro trabalho em seu backlog.

Você não pode corrigir, ou efetivamente pretende corrigir, vulnerabilidades de segurança até que você as compreenda. Depois de entender os problemas (quais são os erros, o que precisa ser corrigido e por quê), e quanto vai custar para corrigi-los, e uma vez que você tem a confiança de que você pode corrigi-los corretamente, você pode tratar as vulnerabilidades de segurança como outros bugs – decidir o que precisa ser corrigido e quando, avaliando custos e riscos, de acordo com o que precisa ser feito. Os trabalhos de recuperação tornam-se apenas mais um problema de desenvolvimento de software a ser gerenciado, algo que os desenvolvedores e gerentes já sabem como fazer.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/08/getting-application-security.html