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.

Fonte: [2]

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.