Um paradoxo da área de segurança advém da frase “um sistema nunca está seguro” e neste texto fazemos uma reflexão sobre isso.
Essa máxima pode levar a dois comportamentos extremos (ilustrativos), seja o “over-security”, isto é, uma ênfase exagerada em endereçar aspectos de segurança, que possui como impacto alto custo financeiro, de tempo ou até o não lançamento do projeto. No outro extremo, pode haver a abordagem de deixar para depois, isto é, responder aos incidentes de segurança conforme eles ocorrerem durante a operação.
Na vida real, as empresas estão trabalhando com boas práticas e recomendações para desenvolvimento seguro - e quando aplicável regulação do próprio setor de atuação. Segundo pesquisa da Veracode [1], grande parte dos esforços de segurança têm sido investidos durante o desenvolvimento (programação). Mostra também a realidade em que esses esforços ocorrem de forma que a atenção dada a segurança concorre com desafios como:
- Atender aos processos de auditoria internos;
- Atender prazo e orçamento do projeto;
- Cumprir requisitos de cliente e/ou regulatórios.
Ainda segundo a pesquisa [1], os métodos utilizados para desenvolvimento seguro tem sido:
- Web Application Firewall
- Runtime protection
- Penetration testing
- Análise estática de código
- Análise dinâmica
- Testes interativos
Retorno a frase inicial do texto - “um sistema nunca está seguro” - os esforços de segurança realizados durante o desenvolvimento são essenciais, no entanto, não endereçam um aspecto importante da segurança, o aspecto temporal. Isto é, quando um sistema é desenvolvido e testado, ele tem como base o conhecimento de segurança disponível naquele instante e como senso-comum na área de segurança, vulnerabilidades e ferramentas surgem a cada dia, como complicador tem a questão de que todas as vulnerabilidades devem ser resolvidas pelo desenvolvedor enquanto do lado do adversário, ele necessita de apenas uma brecha.
Para ilustrar essa questão, temos o caso da vulnerabilidade Heartbleed, divulgada em abril de 2014, que permitia atacantes lerem memória protegida remotamente devido a uma vulnerabilidade do OpenSSL. Segundo [2], após a divulgação da vulnerabilidade houve um aumento expressivo de scan por sistemas vulneráveis 22 horas após o release da vulnerabilidade, conforme figura abaixo, sendo que os autores afirmam que nenhum evento foi visto anterior ao dia 08/abril/2014.
Os autores afirmam também que houve um grande esforço de patch dos sistemas nas primeiras duas semanas após a divulgação da vulnerabilidade, mas depois esse comportamento se estabilizou e 3% dos sites HTTPS do Alexa Top 1 Million continuavam vulneráveis após dois meses.
Para endereçar a segurança durante operação com avaliações contínuas de segurança, ou mesmo para incluir especialistas com conhecimentos complementares a seus processos de desenvolvimento, existem os programas de bug bounty.
A BugHunt é a primeira plataforma brasileira de bug bounty e possui programas sob medida para atender às necessidades dos diversos negócios.
Fique à vontade para entrar em contato e conhecer mais.
[1] Veracode - Secure Development Survey
[2] Durumeric, Zakir, et al. "The matter of heartbleed." Proceedings of the 2014 conference on internet measurement conference. 2014.